Problem: Entra Joined Client mit Global Secure Access (Entra Private Access), Anmeldung des vom AD gesyncten Entra-Accounts erfolgt über PIN (=Windows Hello for Business). Zugriff auf on-prem Resourcen via SSO funktioniert nicht (es wird nach PIN gefragt um dann fehlenden Zugriff auf Domain Controller zu melden). Es gibt eine Enterprise Application mit den notwendingen Ports für den Domain Controller, Private DNS ist enabled – Zugriff wenn mit Passwort angemeldet funktioniert einwandfrei.

Ursache: Für SSO bei Anmeldung via WHfB muss was Zertifikat am Domain Controller angeht mehrere Punkte erfüllt sein:

  • Zertifikat am DC muss „KDC Authentication“ als EKU haben
  • Aktuelles Template dafür ist „Kerberos Authentication“, Domain Controller enrolled es aber nicht vollelektrisch
  • Client muss Root CA des DC Zertifikats in den Trusted Root CAs haben
  • CRL im CDP und AIA dürfen nicht (zuerst) auf LDAP liegen weil Client zum Zeitpunkt des Zugriffs zwar CRL prüfen muss aber noch kein Ticket hat um im AD den LDAP Zugriff machen zu dürfen

Lösung: Die Vorraussetzungen schaffen 😀

  • Auf der CA die CDP und AIA Extensions um LDAP erleichtern und HTTP enablen – je nach Geschmack auch gleich die Delta CRLs disablen.
  • Altes Zertifikat am DC löschen.
  • Alte Templates für Domain Controller von CA entfernen: Domain Controller, Domain Controller Authentication, Directory Email Replication.
  • Eine Group Policy erstellen oder bestehende die (auch) auf Domain Controller wirkt ändern sodass AutoEnrollment enabled ist (Template Kerberos Authentication hat schon AutoEnroll für DCs).
  • gpupdate/certutil -pulse/Reboot – was auch immer Autoenrollment heute triggert.
  • In der GSA Enterprise App für Domain Controller Access (oder in einer neuen App) ein Segment hinzufügen damit der Client durch den Tunnel auf den HTTP Ort wo die CRL liegt kommt – bei mir hats nur mit FQDN funktioniert.
  • Am Client das Root CA Zertifikat in die Trusted Root CAs importieren (Machine Store).

Quellen: