Kerberos Authentication Failure During Windows Domain Logon Due to KVNO Mismatch
Problem:
A Windows client fails to complete the domain logon process against the Samba-based domain controller (ucs5primary).
As a result, Group Policy Objects (GPOs) are not applied during Windows startup. The Samba log reports repeated Kerberos authentication errors, indicating that a specific Kerberos key version number (KVNO) could not be found in the local keytab file.
Symptoms:
During Windows domain logon, the following error messages appear in the Samba log (/var/log/samba/log.samba):
pid=11536] ../../source4/auth/gensec/gensec_gssapi.c:794(gensec_gssapi_update_internal)
GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text):
Failed to find UCS5PRIMARY$@UNIVENTION.INTRANET(kvno 5) in keytab FILE:/etc/krb5.keytab (aes256-cts-hmac-sha1-96)
pid=11536] ../../auth/gensec/gensec.c:543(gensec_update_done)
gensec_update_done: gssapi_krb5[0x55aa3e03bc80]: NT_STATUS_LOGON_FAILURE
As a consequence, Group Policy processing fails, and gpresult on affected Windows systems shows:
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-GroupPolicy' Guid='{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}'/><EventID>1058</EventID><Version>0</Version><Level>2</Level><Task>0</Task><Opcode>1</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime='2025-08-29T12:14:10.3790944Z'/><EventRecordID>13216</EventRecordID><Correlation ActivityID='{f48a9dc8-bc8d-4e3c-a099-9f91e3287bec}'/><Execution ProcessID='1708' ThreadID='1040'/><Channel>System</Channel><Computer>windows-client.univention.intranet</Computer><Security UserID='S-1-5-18'/></System><EventData><Data Name='SupportInfo1'>4</Data><Data Name='SupportInfo2'>912</Data><Data Name='ProcessingMode'>1</Data><Data Name='ProcessingTimeInMilliseconds'>563</Data><Data Name='ErrorCode'>1326</Data><Data Name='ErrorDescription'>Der Benutzername oder das Kennwort ist falsch. </Data><Data Name='DCName'>\\ucs5primary.univention.intranet</Data><Data Name='GPOCNName'>cn={C933DAC3-13F2-4F3F-8721-9250569C3E79},cn=policies,cn=system,DC=univention,DC=intranet</Data><Data Name='FilePath'>\\univention.intranet\SysVol\univention.intranet\Policies\{C933DAC3-13F2-4F3F-8721-9250569C3E79}\gpt.ini</Data></EventData></Event>
Investigation:
1. Check Kerberos Tickets
On the UCS Primary Domain Controller (ucs5primary), verify the Kerberos tickets in the local cache:
root@ucs5primary:~# kinit -k UCS5PRIMARY$
root@ucs5primary:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: UCS5PRIMARY$@UNIVENTION.INTRANET
Issued Expires Principal
Oct 15 22:24:16 2025 Oct 16 08:24:16 2025 krbtgt/UNIVENTION.INTRANET@UNIVENTION.INTRANET
2. Verify Keytab Entries
List all entries in the keytab file to ensure that valid principals exist for the domain controller:
root@ucs5primary:~# ktutil -k /etc/krb5.keytab list
Expected entries:
/etc/krb5.keytab:
Vno Type Principal Aliases
1 aes256-cts-hmac-sha1-96 HOST/ucs5primary@UNIVENTION.INTRANET
1 aes256-cts-hmac-sha1-96 HOST/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 aes256-cts-hmac-sha1-96 UCS5PRIMARY$@UNIVENTION.INTRANET
1 aes128-cts-hmac-sha1-96 HOST/ucs5primary@UNIVENTION.INTRANET
1 aes128-cts-hmac-sha1-96 HOST/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 aes128-cts-hmac-sha1-96 UCS5PRIMARY$@UNIVENTION.INTRANET
1 arcfour-hmac-md5 HOST/ucs5primary@UNIVENTION.INTRANET
1 aes128-cts-hmac-sha1-96 host/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 arcfour-hmac-md5 UCS5PRIMARY$@UNIVENTION.INTRANET
1 aes256-cts-hmac-sha1-96 host/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 aes256-cts-hmac-sha1-96 ldap/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 aes128-cts-hmac-sha1-96 ldap/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 arcfour-hmac-md5 HOST/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 arcfour-hmac-md5 host/ucs5primary.univention.intranet@UNIVENTION.INTRANET
1 arcfour-hmac-md5 ldap/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes256-cts-hmac-sha1-96 HOST/ucs5primary@UNIVENTION.INTRANET
2 aes256-cts-hmac-sha1-96 HOST/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes256-cts-hmac-sha1-96 host/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes256-cts-hmac-sha1-96 ldap/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes256-cts-hmac-sha1-96 UCS5PRIMARY$@UNIVENTION.INTRANET
2 aes128-cts-hmac-sha1-96 HOST/ucs5primary@UNIVENTION.INTRANET
2 aes128-cts-hmac-sha1-96 HOST/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes128-cts-hmac-sha1-96 host/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes128-cts-hmac-sha1-96 ldap/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 aes128-cts-hmac-sha1-96 UCS5PRIMARY$@UNIVENTION.INTRANET
2 arcfour-hmac-md5 HOST/ucs5primary@UNIVENTION.INTRANET
2 arcfour-hmac-md5 HOST/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 arcfour-hmac-md5 host/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 arcfour-hmac-md5 ldap/ucs5primary.univention.intranet@UNIVENTION.INTRANET
2 arcfour-hmac-md5 UCS5PRIMARY$@UNIVENTION.INTRANET
The relevant service principals for the host and its machine account should be present.
3. Increase Samba Debug Level
If Kerberos and keytab checks appear correct, but the issue persists, enable detailed Samba debugging:
ucr set samba/debug/level=5/etc/init.d/samba restart
Then attempt another Windows logon to generate detailed logs for further analysis.
Logs can be found under /var/log/samba/log.samba.
4. Further Analysis
Even after verification, the following errors persisted:
[2025/08/25 11:01:20.879288, 1, pid=14063] ../../source4/auth/gensec/gensec_gssapi.c:794(gensec_gssapi_update_internal)
GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find UCS5PRIMARY$@UNIVENTION.INTRANET(kvno 5) in keytab FILE:/etc/krb5.keytab (aes256-cts-hmac-sha1-96)
[2025/08/25 11:01:20.899915, 1, pid=14063] ../../auth/gensec/spnego.c:1245(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: gssapi_krb5: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_LOGON_FAILURE
[2025/08/25 11:01:37.459545, 1, pid=14070] ../../source4/auth/gensec/gensec_gssapi.c:794(gensec_gssapi_update_internal)
GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find UCS5PRIMARY$@UNIVENTION.INTRANET(kvno 5) in keytab FILE:/etc/krb5.keytab (aes256-cts-hmac-sha1-96)
[2025/08/25 11:01:37.459596, 1, pid=14070] ../../auth/gensec/spnego.c:1245(gensec_spnego_server_negTokenInit_step)
gensec_spnego_server_negTokenInit_step: gssapi_krb5: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_LOGON_FAILURE
The Samba log indicates a KVNO mismatch.
The system searches for KVNO 5, but the keytab only contains KVNO 1 and 2.
5. Check the domain controller’s servicePrincipals
univention-s4search sAMAccountName=UCS5PRIMARY$ msDS-KeyVersionNumber servicePrincipalName
Example output:
# record 1
dn: CN=UCS5PRIMARY,OU=Domain Controllers,DC=univention,DC=intranet
servicePrincipalName: HOST/ucs5primary.univention.intranet
servicePrincipalName: HOST/ucs5primary.univention.intranet/UNIVENTION
servicePrincipalName: ldap/ucs5primary.univention.intranet/UNIVENTION
servicePrincipalName: GC/ucs5primary.univention.intranet/univention.intranet
servicePrincipalName: ldap/ucs5primary.univention.intranet
servicePrincipalName: HOST/ucs5primary.univention.intranet/univention.intranet
servicePrincipalName: ldap/ucs5primary.univention.intranet/univention.intranet
servicePrincipalName: HOST/UCS5PRIMARY
servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2/0fdb1faa-d839-4c02-9690-f7ba6500f3bc/univention.intranet
servicePrincipalName: ldap/0fdb1faa-d839-4c02-9690-f7ba6500f3bc._msdcs.univention.intranet
servicePrincipalName: ldap/UCS5PRIMARY
servicePrincipalName: RestrictedKrbHost/UCS5PRIMARY
servicePrincipalName: RestrictedKrbHost/ucs5primary.univention.intranet
servicePrincipalName: ldap/ucs5primary.univention.intranet/DomainDnsZones.univention.intranet
servicePrincipalName: ldap/ucs5primary.univention.intranet/ForestDnsZones.univention.intranet
msDS-KeyVersionNumber: 2
6. Preventive Measures
-
Ensure DRS replication is consistent before performing machine password resets.
Reference: Samba 4 Troubleshooting -
If replication is verified, and the issue persists, a machine password change can be manually triggered following:
Manually Trigger Server Password Change
Root Cause Analysis:
An additional computer object with the hostname UNIVENTION existed in LDAP/Samba with msDS-KeyVersionNumber: 5.
This caused conflicting authentication behavior during Kerberos validation.
When the DC UCS5PRIMARY$ attempted to obtain a Kerberos ticket, the system occasionally referenced the object UNIVENTION (KVNO 5) instead of the correct DC object.
Because no KVNO 5 entry existed in /etc/krb5.keytab for the encryption type aes256-cts-hmac-sha1-96, authentication failed.
List all objects and their msDS-KeyVersionNumber attributes to identify discrepancies:
univention-s4search cn=* dn msDS-KeyVersionNumber | grep -iE '(dn:|msDS-KeyVersionNumber:)' > kvno_list
Identify the conflicting object as follows:
root@ucs5primary:~# univention-s4search CN=UNIVENTION msDS-KeyVersionNumber
# record 1
dn: CN=UNIVENTION,CN=Computers,DC=univention,DC=intranet
msDS-KeyVersionNumber: 5
Solution:
The issue was resolved by removing the conflicting computer object (UNIVENTION) from both LDAP and the Samba directory.
After deletion, Kerberos authentication requests correctly targeted the UCS5PRIMARY$ domain controller.
This restored successful Netlogon authentication, and GPOs were applied properly during Windows startup.
To delete the conflicting object via Univention Management Console (UMC):
- Open UMC → Computers
- Locate and select the UNIVENTION computer object
- Click Delete
- Confirm deletion with Delete referring objects
After removal, restart the Samba service and test Windows domain logon again:
/etc/init.d/samba restart
The domain logon should now succeed, and GPOs should apply correctly.
Conclusion
This issue was caused by a duplicate computer object with a conflicting KVNO (5) in the domain.
The Kerberos authentication mechanism attempted to use the incorrect KVNO, leading to NT_STATUS_LOGON_FAILURE.
Removing the conflicting object restored proper Kerberos authentication and normal GPO functionality across Windows clients.