Unser WAC-Installations-SSO (über ressourcenbasierte Delegation) hat letzte Woche aus unbekannten Gründen aufgehört zu funktionieren und das macht mich wahnsinnig. Das folgende Ereignis wird auf dem WAC-Server protokolliert, wenn versucht wird, in der WebUI eine Verbindung zu einem verwalteten Client (einem beliebigen) herzustellen:
A Kerberos error message was received:
on logon session
Client Time:
Server Time: 19:6:29.0000 11/29/2021 Z
Error Code: 0x29 KRB_AP_ERR_MODIFIED
Extended Error: 0xc00000bb KLIN(0)
Client Realm:
Client Name:
Server Realm: DOMAIN.COM
Server Name: HTTP/accounting-02-m.domain.com
Target Name: HTTP/[email protected]
Error Text:
File: onecore\ds\security\protocols\kerberos\client2\kerbtick.cxx
Line: 128d
Error Data is in record data.
Der entsprechende Fehler 0x29 wird auch auf dem Ziel-KDC protokolliert.
Der Zugriff auf die WAC-WebUI funktioniert für Benutzer einwandfrei und Remote-PowerShell für Zielcomputer außerhalb von WAC funktioniert für dieselben Benutzer ebenfalls. Wenn der Zugriff auf den Zielcomputer in WAC verweigert wird und Anmeldeinformationen abgefragt werden, kann der Zugriff durch manuelle Eingabe meiner Anmeldeinformationen gewährt werden. Die WebUI direkt auf dem WAC-Server ermöglicht die bestimmungsgemäße Verwendung für den Zugriff auf Zielcomputer über SSO. Dies schließt Berechtigungsprobleme aus und scheint auf ein Problem mit der Double-Hop-Delegation hinzuweisen.
Eine Erfassung des Netzwerkverkehrs zeigt den TGS-REQ/REP für mich selbst, um auf die WAC$-Maschine zuzugreifen, und dann sehe ich den TGS-REQ für den Zielmaschinendienst (d. h. HTTP/accounting-02-m.domain.com) mit KRB-OPTION „constrained-delegation: True“, gefolgt vom KRB-ERROR für KRB5KRB_AP_ERR_MODIFIED …
Ich habe die Delegierung für eine Beispielmaschine geprüft und sie sieht wie erwartet aus:
Path Owner Access
---- ----- ------
BUILTIN\Administrators DOMAIN\WAC$ Allow
Ich habe sichergestellt, dass der sichere Kanal zwischen Server/Ziel und DC funktioniert (ich habe das Computerkennwort trotzdem zurückgesetzt).
PS C:\> Test-ComputerSecureChannel
true
Ich suche nach SPN-Problemen:
PS C:\> setspn -L accounting-02-m Registered ServicePrincipalNames for CN=ACCOUNTING-02-M,OU=Workstations,OU=Domain Computers,DC=domain,DC=com:
WSMAN/ACCOUNTING-02-M
WSMAN/ACCOUNTING-02-M.domain.com
TERMSRV/ACCOUNTING-02-M
TERMSRV/ACCOUNTING-02-M.domain.com
RestrictedKrbHost/ACCOUNTING-02-M
HOST/ACCOUNTING-02-M
RestrictedKrbHost/ACCOUNTING-02-M.domain.com
HOST/ACCOUNTING-02-M.domain.com
PS C:\> setspn -Q HTTP/accounting-02-m
Checking domain DC=domain,DC=com
No such SPN found.
Ich glaube, dass die SPN-Zuordnung die HOST->HTTP-Äquivalenz berücksichtigen sollte:
host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin
Ich lösche klist purge -li 0x3e7vor jedem Test Automatentickets.
Der WAC-Server ist Win2019, der Dienst läuft als „Netzwerkdienst“, KDCs sind Win2019 und die Clients sind eine Mischung aus Win10 und Win2012R2/2016/2019. Die Zeitdifferenz beträgt auf allen beteiligten Maschinen (KDC, Server, Ziel) maximal 1 Sekunde. Wir haben eine einzelne Domänengesamtstruktur.
Ich habe KB5008380 vermutet, da dieser Fehler im KDC protokolliert wurde:
During TGS processing, the KDC was unable to verify the signature on the PAC from WAC$. This indicates the PAC was modified.
Der Registrierungsschlüssel konnte jedoch nirgendwo in der Domäne gefunden werden (und auch das auf den KDCs installierte Update nicht).
So wie ich die Kerberos-RFCs verstehe, schlägt entweder die Prüfsumme fehl, weil das Ticket während der Übertragung verändert wurde (unwahrscheinlich), oder der Dienst kann das Ticket aufgrund eines Problems mit dem sicheren Kanal oder einer falschen SPN-Konfiguration nicht entschlüsseln. Die Konfiguration scheint aber in all diesen Fällen korrekt zu sein.
Was übersehe ich hier? Was ist kaputt?
Antwort1
Ok, also stellt sich heraus, dass KB5007206 schuld ist, obwohl das potenzielle Problem in den ersten Hinweisen nicht erwähnt wurde … ich riskiere das OOB-Update nicht, also hat die Deinstallation von KB5007206 auf den DCs das Problem gelöst.