active-directorykerberoskeytabgmsa

Kerberos Keytab: Getting error while creating keytab for MSA on Active Directory

I am trying to create a keytab for MSA on active directory using the ktpass command on my AD Domain Controller.

The command I am using is:

ktpass /princ ldap/KrbNeerajMSA@TEST.LAB /mapuser TEST\KrbNeerajMSA /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out KrbNeerajMSA.keytab /kvno 0 +rndPass

Error I got when I executed this command is:

Successfully mapped ldap/KrbNeerajMSA to KrbNeerajMSA$.
WARNING: Account KrbNeerajMSA$ is not a user account (uacflags=0x1041).
WARNING: Resetting KrbNeerajMSA$'s password may cause authentication problems if KrbNeerajMSA$ is being used as a server.

Reset KrbNeerajMSA$'s password [y/n]?  y
Aborted.

I also tried with:

ktpass /princ ldap/KrbNeerajMSA@TEST.LAB /mapuser TEST\KrbNeerajMSA /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out KrbNeerajMSA.keytab /kvno 0

Error I got after executing this command is:

Targeting domain controller: WIN-FMCL.Test.lab
Using legacy password setting method
Successfully mapped ldap/KrbNeerajMSA to KrbNeerajMSA$.
WARNING: Account KrbNeerajMSA$ is not a user account (uacflags=0x1041).
WARNING: Resetting KrbNeerajMSA$'s password may cause authentication problems if KrbNeerajMSA$ is being used as a server.

Reset KrbNeerajMSA$'s password [y/n]?  y
Aborted.

Note: TEST\KrbNeerajMSA is in fact an MSA. The same command worked well with normal service account (which has a password).

  1. Firstly, I would like to understand whether creating a Keytab for MSA and using it for authentication on non windows machine is a valid use case or not?
  2. My use case is to provide password less authentication for my Java LDAP client which is deployed somewhere on the network. Also, why I am using MSA is that this will eliminate the requirement of password management and henceforth keytab will remain valid.
  3. If I use normal service account then the keytab file will have to be periodically replaced after the service account's password is reset (..due to any reasons...).
  4. This is why I felt that using MSA would be better but, I am now getting a feeling that this may not be a right use case since MSA are meant to be used for authentication for windows machine (Correct me if I am wrong) and not for non windows machine the way I intend to use it.
  5. As far as I understand, ktpass requires /pass parameter and since for MSAs the password are managed by AD itself, there isn't any password to be provided and resetting it as I did in first command may or may not be always successful and will be dependent on AD configuration.
Solution

  • Firstly, I would like to understand whether creating a Keytab for MSA and using it for authentication on non windows machine is a valid use case or not?

    No, you'll need a non-MSA account.

    If I use normal service account then the keytab file will have to be periodically replaced after the service account's password is reset (..due to any reasons...).

    That's also the case with MSAs. Kerberos keys – which are what goes into the keytab – are simply derived from the password, so if the password changes, the old keytab is automatically no longer valid.

    If your server was the one maintaining the MSA's password (I don't think Samba supports that, but let's pretend it did), then the same software that updated the MSA's password would have the job of generating a keytab from that new password.

    (And if it was a gMSA, you would likewise need some software to fetch/decrypt the password from AD – exactly like Windows does – and to put new keys in the service keytab.)

    Also, why I am using MSA is that this will eliminate the requirement of password management and henceforth keytab will remain valid.

    No, it won't. It's literally the opposite.

    MSAs don't eliminate password management; they only eliminate manual password management by the sysadmin – but their explicit purpose is to manage the passwords; and as mentioned above, every time the password is changed, the keytab must be updated accordingly.

    As far as I understand, ktpass requires /pass parameter and since for MSAs the password are managed by AD itself, there isn't any password to be provided and resetting it as I did in first command may or may not be always successful and will be dependent on AD configuration.

    If I understand MSAs correctly, their password is not managed "by AD" – instead the machine that's actually using the MSA is tasked with changing its password every now and then1; i.e. exactly the same as what happens with computer accounts. So the account still definitely has a password, it's just not set to "asdf123!" by the sysadmin anymore.

    1 (This bit is probably incorrect for gMSA, I suspect, but nevertheless even gMSAs have a password that machines retrieve in order to acquire tickets.)

    The core point is: Kerberos keys are derived from the account's password. (This is true both for AD and for non-AD Kerberos.) If the password changes, the account's Kerberos keys also change and therefore the keytab also unavoidably has to change.