MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Cloud Kerberos Trust

Wussten Sie, dass ein Anwender auf einem Entra ID-Joined Gerät, welche nicht "Domain-Joined" ist, per Kerberos auf interne Server ohne weitere Anmeldung zugreifen? Sie müssen es nur einrichten.

Ich habe das Thema auch als Audiodatei für einen Podcast aufbereitet.
 cloud_kerberos_trust.mp3

Domain oder Entra ID

In einer klassischen Welt sind alle Computer auch Mitglied in einem Active Directory und die Anwender als Benutzer im Active Directory angelegt. Der Anwender meldet sich auf seinem Client mit seinen Anmeldedaten an und der Client prüft diese mittels Kerberos gegen den Domain Controller. Wenn die Anmeldung erfolgreich war, bekommt der Anwender ein "Ticket Granting Ticket (TGT), quasi einen zeitlich beschränkten Ausweis, welcher durch den Schlüssel des KRBTGT-Kontos signiert ist. Mit diesem Ausweis kann der Anwender sich für den Zugriff auf weitere Dienste ein TGS  besorgen. Das Verfahren funktioniert seit Windows 2000 und Active Directory und ist nicht auf Windows beschränkt.

Wenn ein Client-Computer nun "Hybrid-Joined" ist, dann ist es neben der Mitgliedschaft im lokalen AD auch noch Mitglied in einem Entra ID. Durch die Anmeldung am Entra ID bekommt der Client auch von Ort ein besonderes Primary Refresh Token (PRT), mit welchem er sich weitere SAML-Tickets für die Cloud anfordern kann. Über App-Registration und Enterprise Applications können sich Anwender sogar SAML-Tickets für lokale Dienste besorgen, wenn lokale Dienste eine "Moderne Authentifizierung" unterstützen.

Was machen wir aber mit einem Computer, der nur noch "Entra ID Joined" ist und z.B. durch Intune verwaltet wird? Der Anwender meldet sich mit seinem Entra ID-Token an aber bekommt erst einmal kein Kerberos TGT und damit auch keine Servicetickets (TGS) für den Zugriff auf Server. Natürlich kann sich so ein Client immer noch per NTLM oder andere Anmeldeverfahren an lokalen Diensten anmelden. Es ist aber weder bequem, immer wieder seine Anmeldedaten einzugeben oder irgendwo zu speichern noch sicher gegen Phishing.

Hier wird dann "Cloud Kerberos" ein Thema, denn vereinfacht ausgedrückt bekommt der Client von Entra ID neben den bekannten SAML-Tokens auch ein Kerberos-Ticket. Wir müssen nur sicherstellen, dass die lokalen Server dem ausstellenden Kerberos Distribution Center (KDC) vertrauen. Technisch ist das gar nicht mal schwer, denn auch in einem Forest mit mehreren Domains gibt es pro Domain individuelle KDCs-Instanzen, die sich letztlich vertrauen. Durch Cloud Kerberos Trust wird genau diese Funktion bereitgestellt. Je nach Client kann es dann folgende Methoden geben:

Benutzeranmeldung Client-Mitgliedschaft Genutzte Funktion

 

DomainUser

Domainless Client

Nicht möglich. Der Benutzer kann sich auf dem Client gar nicht erst anmelden, wenn der Client nicht in der Domain ist.

 

DomainUser

DomainClient ohne Entra ID

Klassische Funktion von Kerberos

 

DomainUser

Entra ID Hybrid Joined Client

 Klassische Funktion von Kerberos, Technisch bekommt er aber auch ein Primary Refresh Token (PRT), welches er nutzen könnte aber nicht nutzt

 

DomainUser

Entra ID Joined Client

Nicht möglich, d.h. auf einem Computer, der nicht in einer Domain ist ist, kann sich auch kein Domain.User anmelden

 

Entra ID

Domainless Client

Nicht möglich. Der Benutzer kann sich auf dem Client gar nicht erst anmelden, wenn es kein lokales AD-Konto hat

 

Entra ID

DomainClient ohne Entra ID

Nicht möglich. Der Benutzer kann sich auf dem Client gar nicht erst anmelden, wenn es kein lokales AD-Konto hat

 

Entra ID

Entra ID Hybrid Joined Client

 Der Anwender meldet sich an Entra ID an und bekommt ein Primary Refresh Token (PRT)

 

Entra ID

Entra ID Joined Client

 Der Anwender meldet sich an Entra ID an und bekommt ein Primary Refresh Token (PRT)

 

In all den Fällen, in denen der Anwender von Entra ID ein Primary Refresh Token (PRT) bekommt, könnten der Anwender auch ein partielles Token bekommen, mit der im lokalen AD ein Kerberos-Ticket für die Nutzung lokaler Dienste bekommt.

Funktionsweise

Die Funktion von "Cloud Kerberos" ist schnell erklärt. Durch die Einrichtung wird im lokalen Active Directory ein "Kerberos Server Objekt" angelegt und das "Geheimnis" in die Cloud übertragen. Damit kann Entra nun TGT-Tickets für ihren Benutzer ausstellen, die von OnPremises DCs akzeptiert werden. Der Prozess funktioniert mit "Entra ID Joined" und "Hybrid Joined" Geräten, bei denen sich der Mitarbeiter auch an Entra ID authentifiziert.

  1. Benutzer meldet sich am Client an
    Bei entsprechender Konfiguration des Clients findet auch eine Anmeldung an Entra ID statt.
  2. Entra ID erstellt Tickets
    Normalerweise würde Entra ID dem Benutzer nur ein Primary Refresh Token (PRT) ausstellen. Zusätzlich findet Entra ID aber nun die Information über das "Kerberos Server-Objekt" und erstellt auch nochi ien Kerberos Granting Ticket (TGT). Dieses Ticket enthält u.a. die SID des Benutzers aber sonst keine Authentifizierungsdaten.
  3. Beide Daten werden an den Client zurück gesendet.
  4. Anmeldung gegen lokalen DC
    Der Client sendet das Entra ID-TGT an den lokalen DC, der dieses mit dem lokalen "Kerberos-Server-AD-Objekt" verifiziert und damit die Gültigkeit prüfen kann.
  5. DC liefert vollwertiges TGT
    Der Domain Controller stellt ein "richtiges TGT" für den Benutzer aus und ab nun geht es den klassischen Weg.
  6.  Alle weiteren Zugriff.
    Gehen vom Client direkt zum Server und wenn dieser "Kerberos" anbietet, dann kann sich der Client mit dem TGT des lokalen Domain Controllers ein TGS für den Dienst anfordern und weiter zugreifen. Diese Anmeldungen erscheinen nicht im Entra ID Log sondern sind rein lokal.

Damit das funktioniert, muss der Client natürlich per DNS die Domain und Domain Controller finden und erreichen können. Die Nutzung lokaler Ressourcen funktioniert also nur im LAN oder über VPN. Zudem muss der Benutzer natürlich ein lokalen Konto im Active Directory haben.

Voraussetzungen

Damit Sie diese Funktion nutzen können, sind auf dem Client, den Domain Controllern und dem Tenant einige Voraussetzungen zu erfüllen:

  • Domain Controller: Windows 2016 oder höher
  • Client: Windows 10 21H2 mit KB5010415 und höher oder Windows 11 21H2 mit KB5010414 und höher
  • Client: Entra ID Joined oder Hybrid Joined
    Verwaltung per Inunte ist nicht zwingend.
  • Active Directory: AES256_HMAC_SHA1 muss erlaubt sein.
    Auch das ist per Default normalerweise eingeschaltet. Siehe auch Kerberos RC4 Abschaltung und Kerberos Encryption
  • Verzeichnisabgleich mit Entra ID Sync
    Damit alle lokalen Benutzerobjekte auch in Entra ID synchron sind. ADSync muss zwingend die Felder "onPremisesSamAccountName", "onPremisesDomainName" und "onPremisesSecurityIdentifier" replizieren. Das ist aber der Regelfall und mit "Get-EntraUser | FL onprem*" schnell zu prüfen.
  • Windows Hello for Business mit PIN, Finger, Gesicht
    Aber heute ist auch das hoffentlich eher Standard zur Absicherung der Anmeldung. MFA alleine z.B. über Conditional Access und Netzwerk-IP reicht nicht. Es muss ein Authentication Device konfiguriert sein
  • Richtlinien für Clients verteilen
    Das kann Intune sein aber auch andere Produkte können die Funktion auf dem Client freischalten

Diese Voraussetzungen sollten also wirklich kein Problem darstellen. 

Einrichtung Backend

Die Konfiguration bedeutet, dass im lokalen Active Directory ein Objekt angelegt wird, welches als "Vertrauensanker" dient. Es muss pro Domain angelegt werden, in denen Benutzer sind, die ein Kerberos-Ticket erhalten müssen. Ein Domain Admin muss dazu eine PowerShell auf einem Domainmitglied oder dem DC ausführen, der mit Entra ID kommunizieren kann.

Write-Host "Installieren des erforderlichen Moduls"
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Write-Host "Lokale AD-Domain, in der das Konto angelegt wird"
$domain = $env:USERDNSDOMAIN

Write-Host "Entra ID Konto, welches Mitglied in Hybrid Identity Administrators ist"
$cloudCred = Get-Credential -Message "Entra ID-Admin. Mitglied in Entra ID Hybrid Identity Administrator Gruppe"

Write-Host "DomainAdmin im lokalen AD"
$domainCred = Get-Credential -Message "DomainAdmin in der Domain $($domain) und Enterprise Admin"

Write-Host "Lokales Microsoft Entra ID Kerberos Server Object im AD anlegen und zu Entra ID hochladen"
Set-AzureADKerberosServer `
   -Domain $domain `
   -CloudCredential $cloudCred `
   -DomainCredential $domainCred `
   -SetupCloudTrust

Write-Host "Kontrolle der Änderung"
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName admin@msxfaq.onmicrosoft.com

Beispielausgabe von Get-AzureADKerberosServer

Id                 : 26627
UserAccount        : CN=krbtgt_AzureAD,CN=Users,DC=msxfaq,DC=de
ComputerAccount    : CN=AzureADKerberos,OU=Domain Controllers,DC=msxfaq,DC=de
DisplayName        : krbtgt_26627
DomainDnsName      : msxfaq.de
KeyVersion         : 44893
KeyUpdatedOn       : 10.03.2025 12:05:24
KeyUpdatedFrom     : DC.msxfaq.de
CloudDisplayName   : krbtgt_12345
CloudDomainDnsName : msxfaq.de
CloudId            : 12345
CloudKeyVersion    : 44893
CloudKeyUpdatedOn  : 10.03.2025 12:05:24
CloudTrustDisplay  : Microsoft.AzureAD.Kdc.Service.TrustDisplay

Sie können natürlich auch über die MMC für Benutzer und Computer die beiden entsprechende Objekte im lokalen Active Directory finden. 

Beim Computerobjekt befindet sich im Feld "msDS-KrbTgtLink" der Verweis auf das User-Object:

Denken Sie daran, dass auch der Schlüssel dieses Kerberos-Servers regelmäßig rotiert werden sollte.

Set-AzureADKerberosServer `
   -Domain $domain `
   -CloudCredential $cloudCred `
   -DomainCredential $domainCred `
   -RotateServerKey

Als am besten stellen Sie sich einen regelmäßigen Termin ein. 

Zum Rückbau der Konfiguration sollten sie nicht einfach die beiden Objekte löschen, da dann die Keys in Entra ID vorhanden bleiben. Besser ist folgender Befehl:

Remove-AzureADKerberosServer `
   -Domain $domain `
   -CloudCredential $cloudCred `
   -DomainCredential $domainCred

Fehlersuche beim Backend Setup

Nicht immer funktioniert alles fehlerfrei beim Setup, auch wenn die Microsoft Anleitungen nicht so schlecht sind. Zwei Fehler habe ich bislang wie folgt gelöst:

Fehler Lösung 
Set-AzureADKerberosServer : The authority 
(including the tenant ID) must be in 
a well-formed URI format

Kontrollieren Sie genau die Domain, die sie bei der Anmeldung genutzt haben. In meinem Fall hatte ich eine "Umlautdomäne" und wirklich einen Umlaut im Domainnamen eingegeben. Beim "Get-Credential" für die Entra-ID Informationen wird dies ja nicht geprüft.

 
Set-AzureADKerberosServer : Failed 
to read secrets from the domain <domain> 

Hier war der Fehler dann schlicht ein falsches Kennwort. Set-AzureADKerberosServer nutzt nicht die Anmeldedaten des aktuell angemeldeten Benutzers, sondern erwartet explizite Zugangsdaten. Beim "Get-Credential" für die Domain-Anmeldung werden diese aber nicht geprüft.

Auch wenn "Set-AzureADKerberosServer" eigentlich ein PowerShell-Commandlet ist, schreib es dennoch eine Protokolldatei im Hintergrund. Die Dateien landen an folgender Stelle:

C:\ProgramData\AADConnect\Trace*.log

Dort liegen auch andere Protokolldateien, z.B. vom ADSync Setup etc.

Einrichtung Client

Damit Cloud Kerberos Trust funktionieren kann, muss natürlich der Client nicht nur eine aktuelle Windows Version nutzen und Entra ID Joined/Hybrid-Joined sein. Sie müssen im natürlich auch über Richtlinien beibringen, wo es Kerberos-Server gibt, denn die Clients sind ja nicht zwingend Mitglied eines lokalen Active Directory. Auch hier hat Microsoft ein nettes Bild veröffentlicht:

 


Quelle: Windows Hello for Business authentication - Microsoft Entra join authentication to Active Directory using cloud Kerberos trust
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/how-it-works-authentication#microsoft-entra-join-authentication-to-active-directory-using-cloud-kerberos-trust 

Hier sehen sie ganz links unter Windows als ersten Punkt ein "Get Domain hint from key metadata" und danach eine Abfrage per DNS nach den Adressen für "_ldap._tcp.dc._msdcs.<domainname>". Das ist aber nicht alles. Sie müssen dem Client schon mitteilen, dass er diese Funktion überhaupt nutzen soll. Das geht per Kommandozeile, Gruppenrichtlinien oder Intune-Policy.

Das geht per Kommandozeile ist "ksetup" das Hilfsmittel, z.B.

ksetup /addhosttorealmmap <AppFQDN> KERBEROS.MICROSOFTONLINE.COM 

Ich beschreibe hier auch kurz die Konfiguration über Gruppenrichtlinien, aber wenn Sie "Cloud Kerberos Trust" für ihre Computer einsetzen wollen, die "Entra ID Joined" sind, dann sind diese ja gerade nicht Mitglied in einer Domäne und damit können Sie Gruppenrichtlinien hier gar nicht ansetzen. Es kann aber helfen, wenn Sie "Entra-ID Hybrid-Joined"-Geräte nutzen die per Kerberos z.B. auf einen anderen Forest zugreifen wollen, der Kerberos mit Entra-ID unterstützt. Wenn Sie Einstellungen in ihrer GPMC nicht sehen, dann müssen Sie erst neuere ADMX-Datei einspielen.

In den Computerrichtlinien finden Sie dann die Einstellungen zu Kerberos. Hier sind zwei Dinge zu verwalten.

Zuerst müssen wir aktivieren, dass sich der Client ein Entra ID TGT-Token während der Anmeldung besorgt. In der GPO von Windows 11 24H2 steht noch Azure AD

Die zweite Einstellung ist dann maßgeblich, für welche DNS-Host oder DNS-Endungen dieses TGT verwendet wird.

In meinem Beispiel habe ich dem Client gesagt, dass er für den Zugriff auf server.mxfaq.de und exchange.msxfaq.de den Realm "KERBEROS.MICROSOFT.COM" nutzen soll.

Hinweis: In der MMC für Gruppenrichtlinien können Sie beim REALM maximal 1024 Zeichen eintragen. Windows unterstützt aber 32768 Zeichen. Der Kerberos Client auf Windows akzeptiert aber nur 2048 Zeichen als HostNameListe.

Technisch sind das natürlich Einstellungen, die über die Gruppenrichtlinien in die lokale Registrierung geschrieben und dort vom Betriebssystem gelesen werden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\Kerberos]
"domain_realm_Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\Kerberos\domain_realm]
"KERBEROS.MICROSOFTONLINE:COM"="server.msxfaq.de;exchange.msxfaq.de"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\Kerberos\Parameters]
"CloudKerberosTicketRetrievalEnabled"=dword:00000001

Ohne Gruppenrichtlinien können Sie die Werte auch direkt in folgenden Schlüssel schreiben: 

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm

Gruppenrichtlinien funktionieren natürlich nur mit Clients, die Mitglied in einem Active Directory sind. Das sind aber "Entra ID Joined"-Devices nicht. Hier muss dann eine MDM-Lösung die Einträge vornehmen. Bei Intune gibt es entsprechende Einstellungen auf "https://intune.microsoft.com/" unter "Devices -> Configuration - Policy" und wenn Sie dann ein neues oder bestehendes "Windows 10+"- Profil verwalten, finden Sie im "Settings-Katalog" in den "Administrative Templates > System > Kerberos" den Ort:

 

Das reicht aber noch nicht aus. Zusätzlich müssen Sie auch noch folgende zwei Werte setzen, die sich aber manuell erfassen müssen

OMA-URI (3): ./Device/Vendor/MSFT/Policy/Config/Kerberos/CloudKerberosTicketRetrievalEnabled
Data type (4): Ganze Zahl
Value (5): 1
OMA-URI (3): ./Device/Vendor/MSFT/PassportForWork/TENANTID/Policies/UseCloudTrustForOnPremAuth
Data type (4): Boolescher Wert
Value (5): True

Denken Sie auch noch an die Voraussetzung "Windows Hello for Business", die Sie in ihrem Tenant und Intune auch noch aktivieren müssen. Auch dazu starten Sie wieder das Intune Admin Center und gehen über "Devices->Windows->Configuration->Create->New Policy->Windows 10 und neuer->Settings Katalog" und suchen nach "Hello" und wählen dann die gewünschten Einstellungen aus.

Vergessen Sie bei den Einstellungen aber auch nicht, "Use Cloud Trust For On Prem Auth" zu aktivieren.

 

Damit sollte Client Setup auch abgeschlossen sein.

Clients im Internet - VPN oder KDCProxy

Die beschrieben Konfiguration ist aktuell nur für Clients geeignet, die direkt mit dem Domain Controller sprechen können. Sie sind also im internen Netzwerk aber nicht Domain-Joined und melden sich an Entra ID an und bekommt ein TGT aus der Cloud. Es gibt aber auch den Fall, dass ein Anwender, z.B. im HomeOffice sitzt und über den Weg auch ein Entra ID-TGT bekommt, aber mit dem er eigentlich nichts anfangen kann, da er der DC nicht erreichen kann. Zugegeben, das ist auch meist nicht wichtig, da auch die meisten Dienste über das Internet ebenfalls kaum Kerberos nutzen und OAUTH/SAML viel flexibler ist, z.B. über eine Veröffentlichung mittels Azure AD Application Proxy.

Wenn Sie aber auch Clients im Internet per Entra ID mit einem TGT ausstatten um beim Zugriff auf andere Server per Kerberos ein TGS von ihrem lokalen DC anfordern sollen, dann haben Sie zwei Optionen:

  • VPN
    Sie bauen einen VPN-Tunnel zum Domain Controller auf. Das kann ein klassische VPN oder auch eine IPSec-gesicherte Verbindungen sein. Damit kann der authentifizierte Client direkt den DC erreichen.
  • KDCProxy
    Die zweite und von mir bislang noch nicht genutzte Möglichkeit ist der Aufbau einen KDCProxy. Das ist etwa wie ein ADFS-Proxy für den Zugriff auf einen internen ADFS-Service. Der Client aus dem Internet verbindet sich mit dem KDC-Proxy, der dann als Application Firewall die Anfragen nach einer Prüfung an den eigentlichen KDC weitergibt.

Auf beide Möglichkeiten werde ich hier aber nicht weiter eingehen.

Client-Test

Nach der Konfiguration kommt die Überprüfung. Dies erfolgt am besten auf dem Client, der erst einmal nur "Entra ID Joined" ist und damit ohne Active Directory Mitgliedschaft keine Kerberos-Funktion hat. Ein einfacher KLIST sollte hier zeigen, dass Sie keine Kerberos-Tickets von einem lokalen DC haben. Sobald der Computer aber "Entra ID Joined" ist und die Richtlinien die Funktion "CloudKerberosTicketRetrievalEnabled" aktiviert haben, sollten Sie bei der nächsten Anmeldung ein TGT aus der Cloud bekommen. Zuerst schauen wir mit KLIST nach.

KLIST Cloud_Debug

Hier sollte sichtbar sein, dass ich ein "Cloud Primary (Hybrid logon) TGT" bekommen habe.

Details dazu sehe ich nicht. Wenn der Benutzer nicht an Entra ID angemeldet ist, dann sehen Sie hier einen Fehler:

Wenn ich dann aber z.B. per UNC-Pfad einen Zugriff auf einen internen Service mache, sollte ich danach die Kerberos-Tickets sehen. Ich habe einfach per SMB das "SYSVOL"-Verzeichnis der Domain anzeigen lassen.

Mein Client hat sich mittels dem Cloud-TGT zuerst ein vollwertiges TGT besorgt und damit dann ein TGS für den Domain Controller.

Nur zur Sicherheit: Das funktioniert natürlich nur mit Kerberos. Lokale Dienste, die nur per NTLM erreichbar sind, kann ich so nicht per SSO ansprechen. Dort muss ich dann weiter ein Active Directory Anmeldekonto + Kennwort eingeben.

ADSync SSO abschalten

Wenn ihre Anwender alle über Entra ID authentifiziert werden und sowohl ein Primary Refresh Token (PRT) als auch partielles TGT bekommen um damit lokale Tickets zu erhalten, dann können Sie die SSO-Funktion in ADSync wieder abschalten. Sicher kennen Sie noch die Checkbox bei der Installation von ADSync.

Auf der Seite Seamless Single Sign On habe ich die Zusammenhänge beschrieben. Diese Funktion ist aber nicht mehr erforderlich, wenn sich ihre Client sowieso schon bei der Anmeldung des Anwender an Windows direkt auch an Entra ID authentifizieren und von dort ein Primary Refresh Token (PRT) bekommen. Damit ist "Seamless Single SignOn" schon direkt aktiviert.

Diese Funktion brauchen Sie nur, wenn ihre Clients zwar Mitglied einer Active Directory Domäne sind aber nicht mit Entra ID verbunden sind. Das war gerade in der Anfangszeit von Microsoft 365 häufig der Fall, wo die Funktion "Hybrid Join" mit ADSync nicht aktiviert wurde. Heute dürften die meisten Firmen mit Microsoft 365-Nutzung auch ihre Clients in Entra ID als "Joined" oder "Hybrid Joined"-Geräte aufgenommen haben. Das bedeutet ja nicht, dass Sie zwingend Intune nutzen müssen. Auch andere MDM-Lösungen können Endgeräte verwalten und den Compliance-Status am Entra ID Device aktualisieren, damit sie diese Information in Conditional Access nutzen können. Wenn ihre Geräte also Entra ID Joined/HybridJoined sind, dann können Sie diese Funktion wieder deaktivieren.

Weitere Links