search

aws / credentials-fetcher

Credentials-fetcher is a Linux daemon that retrieves gMSA credentials from Active Directory over LDAP. It creates and refreshes kerberos tickets from gMSA credentials. Kerberos tickets can be used by containers to run apps/services that authenticate using Active Directory.
Apache License 2.0
90 stars 23 forks source link

kinit fails authentication when gMSA password contains an embedded newline #31

Open ebekker opened 1 year ago

ebekker commented 1 year ago

Since the the credential-fetcher renews the gMSA Kerberos Ticket by piping the gMSA password to kinit, if the gMSA password contains an character with a value of 0x0A (i.e. an embedded newline character), then the input to kinit is prematurely aborted and the authentication fails.

smhmhmd commented 1 year ago

Hi @ebekker ,

Could you contribute a PR ? We could also have a hands-on session as well, if you like.

ebekker commented 1 year ago

Hi,

I'm afraid it's been quite some time since I've done any C++ programming, so unlikely I could contribute a PR. :-)

However, the reason I stumbled upon this was that we has a very similar setup in our environment and we specifically ran into this very issue, so I was curious how others may have been addressing it. I'm happy to say that we did solve it, and I'm happy to share our approach.

A little background on our setup which is a little bit different -- we're not trying to use gMSA accounts inside containers, but simply using them on AD-joined Linux hosts. But the credential resolution and ticket renewal process is fundamentally the same as yours. Also our solution is primarily based on PWSH.

Initially, we too were piping the retrieved and decoded gMSA password to kinit via its STDIN. But just so happens the auto-managed password for one of our accounts recently got rotated and has an embedded 0x0A character value within. Our initial approach quickly broke, and we were fortunate that it happened in a pre-PROD environment.

While we researched a few different approaches, including modifying and rebuilding some of the krb5-workstation tools packaged with AL2 to accommodate alternate input methods -- in the end a more simpler approach was just to adjust our invocation of kinit to use its built-in mechanism for taking in credentials via a keytab file instead of its STDIN. And then the only challenge was to generate the keytab from within our scripts, but that was relatively easy thanks to this package which contains programmable support for creating, reading and writing keytab files.

If you would like more details or more discussion, happy to expound...

saikiranakula-amzn commented 1 year ago

Hi ebekker, we will like to know more about how you created gMSA account, we tried to mimic the behavior with almost 500 service account and didn't see any failure. We will be happy to help you to resolve this issue

smhmhmd commented 1 year ago

@ebekker

If you would like more details or more discussion, happy to expound...

Yes, we would love to learn from you over a conference call, my email is samiull at amazon

gMSA uses UTF16 encoding, UTF16 probably does not have the issues with blanks and newlines, I need to check this though.

ebekker commented 1 year ago

So just to be perfectly clear, I want to make sure you're aware, we are not currently using your tools from this repository. We have a similar tool we developed and it just so happens it works in very similar fashion. And to clarify -- we no longer have "an issue" that needs resolving, we solved our problem by switching to the use of a keytab file.

I'm only continuing this discussion because I think that your tool has the potential for a similar problem. It makes sense that you may not have run into the issue in your tests, as the range of possible characters in the Unicode alphabet is 2^16, so testing over 500 accounts could very well have still missed this one scenario. And it is exactly 1 character in 2^16 that is the problem -- it's the newline character, any other will be fine.

But to clarify things and provide a sample of what we ran into, I created this repo which contains a description of what I call the "bad password" scenario. It also contains a sample of the LDIF result containing the msDS-ManagedPassword blob of the bad password that's caused the issue.

If you would like to setup a test with your tools, you can inject this encoded managed password blob into your find_password routine and exercise your tests to see if you run into this issue or not.

Let me know if you would still like to connect, I'll be happy to setup some time next week to discuss.

smhmhmd commented 1 year ago

Thanks. I saw this late.

We will incorporate your repo as a self-test.

Regarding implementation, we cannot bundle dlls or binaries in the source code or use keytabs, we will have to find another way. I will keep this issue open until that time.

If you have time this week, we would love connect with you.