New Kerberos ticket of computer account is found by adcli update but not saved in keytab file.
adcli update --domain=example.org -v
The output "Retrieved kvno '4' for computer account" appears, but in the keytab file KVNO 3 is still the largest number.
Detailed Description
Environment
- Client: Ubuntu Desktop with adcli, sssd, idmapd
- KDC: Microsoft Active Directory
Domain join successful
The initial join of the domain works fine, via adcli join --domain=example.org --domain-realm=EXAMPLE.ORG --login-type=user --login-user=join-admin. On the initial join, the computer object is created correctly, the properties (computer attributes, DNS hostname, SPN) are set correctly, and the computer account ticket and SPNs are stored correctly in the /etc/krb5.keytab.
sssd and idmapd
sssd and idmapd are configured and working. The id domain-user command gives correct results, also a su domain-user works.
keytab contains kvno 2 and 3 now
# klist -kt | uniq
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 06/22/2022 14:37:42 TESTCLIENT1$@EXAMPLE.ORG
2 06/22/2022 14:37:42 host/TESTCLIENT1@EXAMPLE.ORG
2 06/22/2022 14:37:42 host/testclient1.example.org@EXAMPLE.ORG
2 06/22/2022 14:37:42 RestrictedKrbHost/TESTCLIENT1@EXAMPLE.ORG
2 06/22/2022 14:37:42 RestrictedKrbHost/testclient1.example.org@EXAMPLE.ORG
3 06/27/2022 18:11:24 TESTCLIENT1$@EXAMPLE.ORG
3 06/27/2022 18:11:24 host/TESTCLIENT1@EXAMPLE.ORG
3 06/27/2022 18:11:24 host/testclient1.example.org@EXAMPLE.ORG
3 06/27/2022 18:11:24 RestrictedKrbHost/TESTCLIENT1@EXAMPLE.ORG
3 06/27/2022 18:11:24 RestrictedKrbHost/testclient1.example.org@EXAMPLE.ORG
Problem after about a week
The su domain-user command does not work anymore, the following error can be found in the syslog:
[sssd[krb5_child[14085]]]: Cannot find key for TESTCLIENT1$@EXAMPLE.ORG kvno 4 in keytab
The Active Directory check showed that the KeyVersionNumber is at 4.
PS> Get-ADComputer TESTCLIENT1 -Property msDS-KeyVersionNumber
DistinguishedName : CN=TESTCLIENT1,CN=Computers,DC=example,DC=org
DNSHostName : testclient1.example.org
Enabled : True
msDS-KeyVersionNumber : 4
Name : TESTCLIENT1
ObjectClass : computer
ObjectGUID : [...]
SamAccountName : TESTCLIENT1$
SID : [...]
UserPrincipalName :
adcli update
The adcli update command finds the kvno 4 for the computer account, but nothing is updated in the /etc/krb5.keytab file. The output of klist -kt remains the same after adcli update.
# adcli update --domain=example.org -v
* Found realm in keytab: EXAMPLE.ORG
* Found computer name in keytab: TESTCLIENT1
* Found service principal in keytab: host/TESTCLIENT1
* Found service principal in keytab: host/testclient1.example.org
* Found host qualified name in keytab: host/testclient1.example.org
* Found service principal in keytab: RestrictedKrbHost/TESTCLIENT1
* Found service principal in keytab: RestrictedKrbHost/testclient1.example.org
* Using domain name: example.org
* Calculated computer account name from fqdn: TESTCLIENT1
* Using domain realm: example.org
* Discovering domain controllers: _ldap._tcp.example.org
* Sending netlogon pings to domain controller: cldap://141.3.80.11
* Sending netlogon pings to domain controller: cldap://141.3.80.12
* Sending netlogon pings to domain controller: cldap://141.3.80.13
* Received NetLogon info from: DC01.example.org
* Wrote out krb5.conf snippet to /tmp/adcli-krb5-Te0RhG/krb5.d/adcli-krb5-conf-M8VMw2
* Authenticated as default/reset computer account: TESTCLIENT1
* Using GSS-SPNEGO for SASL bind
* Looked up short domain name: EXAMPLE
* Using fully qualified name: testclient1.example.org
* Using domain name: example.org
* Using computer account name: TESTCLIENT1
* Using domain realm: example.org
* Using fully qualified name: testclient1.example.org
* Enrolling computer name: TESTCLIENT1
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for TESTCLIENT1$ at: CN=TESTCLIENT1,CN=Computers,DC=example,DC=org
* Retrieved kvno '4' for computer account in directory: CN=TESTCLIENT1,CN=Computers,DC=example,DC=org
* Password not too old, no change needed
* Modifying computer account: userAccountControl
! Couldn't set userAccountControl on computer account: CN=TESTCLIENT1,CN=Computers,DC=example,DC=org: Insufficient access
* Updated existing computer account: CN=TESTCLIENT1,CN=Computers,DC=example,DC=org
# echo $?
0
adcli exits with 0, despite the hint
! Couldn't set userAccountControl on computer account: CN=TESTCLIENT1,CN=Computers,DC=example,DC=org: Insufficient access
I found the following ticket about this: realmd/adcli#4
I think that the ticket should already be updated in the keytab file before changing the computer object.
What could be the problem?
Why does the update of the ticket or the ticket version not work?
I'm not sure if sssd takes care of updating the computer account ticket stored in the keytab file by itself? I have read something about that. Presumably sssd then has the same problem as when I run the update manually?
Edit: Workaround
With the adcli update command I could not update the key to KVNO 4.
Instead, I now created a new ticket with KVNO 5 using adcli join ... (see above command), which was then successfully transferred to the keytab file. So now the AD and the local keytab file are at KVNO 5. I executed adcli join ... without leaving the domain or deleting the keytab file.
However, I could not find out why this happened in the first place, but I will continue to monitor it. On the Internet I have read mainly about this problem when it is a multi-boot client with Linux and Windows.
