SSO-ul nostru de instalare WAC (prin delegație bazată pe resurse) a încetat să funcționeze săptămâna trecută din motive necunoscute și mă înnebunește. Următorul eveniment este înregistrat pe serverul WAC atunci când încercați să vă conectați la un client gestionat (oricare dintre ele) în WebUI:
A fost primit un mesaj de eroare Kerberos:
la sesiunea de conectare
Ora clientului:
Ora serverului: 19:6:29.0000 29.11.2021 Z
Cod de eroare: 0x29 KRB_AP_ERR_MODIFIED
Eroare extinsă: 0xc00000bb KLIN(0)
Domeniul clientului:
Numele clientului:
Domeniul serverului: DOMAIN.COM
Nume server: HTTP/accounting-02-m.domain.com
Nume țintă: HTTP/[email protected]
Text de eroare:
Fișier: onecore\ds\security\protocols\kerberos\client2\kerbtick.cxx
Linia: 128d
Datele de eroare sunt în datele de înregistrare.
Eroarea corespunzătoare 0x29 este înregistrată și pe KDC-ul vizat.
Accesul la WAC WebUI funcționează bine pentru utilizatori și PowerShell de la distanță pentru a viza mașinile din afara WAC, de asemenea, pentru aceiași utilizatori.Când accesul este refuzat la mașina țintă în WAC și sunt solicitate acreditările, introducerea manuală a acreditărilor mele permite accesul. WebUI direct pe serverul WAC vă permite să îl utilizați așa cum este intenționat pentru a accesa mașinile țintă prin SSO. Acest lucru exclude problemele de permisiune și pare să indice o problemă de delegare a saltului dublu.
O captură a traficului de rețea arată TGS-REQ/REP pentru a accesa mașina WAC$ și apoi văd TGS-REQ pentru serviciul de mașină vizat (adică HTTP/accounting-02-m.domain.com) cu KRB- OPȚIUNEA „constrained-delegation: True”, urmată de KRB-ERROR pentru KRB5KRB_AP_ERR_MODIFIED...
Am verificat delegația pentru o mașină de probă și arată așa cum era de așteptat:
Acces proprietar al căii
---- ----- ------
BUILTIN\Administrators DOMAIN\WAC$ Permite
M-am asigurat că canalul securizat funcționează între server/țintă și DC (resetez parola mașinii oricum)
PS C:\> Test-ComputerSecureChannel
Adevărat
Verific problemele SPN:
PS C:\> setspn -L accounting-02-m Registered ServicePrincipalNames pentru CN=ACCOUNTING-02-M,OU=Workstations,OU=Domain Computers,DC=domain,DC=com:
WSMAN/CONTABILITATE-02-M
WSMAN/ACCOUNTING-02-M.domain.com
TERMSRV/CONTABILITATE-02-M
TERMSRV/ACCOUNTING-02-M.domain.com
RestrictedKrbHost/ACCOUNTING-02-M
GAZDA/CONTABILITATE-02-M
RestrictedKrbHost/ACCOUNTING-02-M.domain.com
HOST/ACCOUNTING-02-M.domain.com
PS C:\> setspn -Q HTTP/accounting-02-m
Se verifică domeniul DC=domain,DC=com
Nu a fost găsit un astfel de SPN.
Cred că maparea SPN ar trebui să aibă grijă de echivalența HOST->HTTP:
gazdă=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msserver,ias,messenger,netlogon,netman,netdde,netddedsm, plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,www,,, http,w3svc,iisadmin
eu folosesc klist purge -li 0x3e7 pentru a șterge tichetele aparatului înainte de orice testare.
Serverul WAC este Win2019, serviciul rulează ca „Serviciul de rețea”, KDC-urile sunt Win2019, iar clienții sunt o combinație de Win10 și Win2012R2/2016/2019. Delta de timp este de maxim 1s pe toate mașinile implicate (KDC, Server, țintă). Avem un singur domeniu de pădure.
Am suspectat KB5008380 din cauza acestei erori înregistrate pe KDC:
În timpul procesării TGS, KDC nu a putut verifica semnătura de pe PAC de la WAC$. Aceasta indică faptul că PAC a fost modificat.
Dar nu am putut găsi cheia de registry nicăieri în domeniu (și nici actualizarea instalată pe KDC-uri).
Din înțelegerea mea despre RFC-urile Kerberos, fie suma de control eșuează din cauza biletului modificat în tranzit (putin probabil), fie serviciul nu poate decripta biletul din cauza problemei canalului securizat sau a unei configurări greșite SPN, dar toate acestea par configurate corect.
Ce îmi lipsește aici? Ce este rupt?
