Cloud Kerberos Trust (CKT) mit Yubico YubiKey 5 NFC
Das Ganze mit einem hybrid joined device (HJD). Beim HJD Device werden beide Welten, On-Premises mit Active Directory und Cloud mit Entra Id, bedient. In meinen Augen, vergleichbar mit einem Plug-in Hybrid-Kfz: das Schlechte aus beiden Welten vereint.
Wieso das Schlechte aus beiden Welten vereint?
Na, weil das Gerät beiden Instanzen, Active Directory und Entra Id, unterliegt. Group Policy und Intune. Das Gerät ist nicht mehr klar in der Verwaltung zugeordnet: Intune und GPO können sich inhaltlich wiedersprechen. Andererseits brauche ich im hybrid-Modus GPO um die Geräte für Intune zu verwalten. Einmal GPO, dann Intune?
Meiner Meinung nach sollten die Geräte entweder:
- Active Directory joined sein oder
- Entra Id joined
Dann halt Entra Id joined.
Ja, Moment: was ist mit den Ressourcen On-Premises? Was ist mit dem Zugriff auf den freigegeben Drucker? Der Zugriff auf die NetApp? Der Zugriff auf das SAP?
Der Weg von der Wolke (Entra Id) hin zur Erde (Active Directory) erfolgt mit Cloud Kerberos Trust (CKT)
Authentifizierungsmöglichkeiten
Wir müssen erst mal schauen, wie denn in den verschiedenen Instanzen authentifiziert wird. Authentisierung bedeutet, dass jemand oder etwas beweisen muss, dass er oder es wirklich derjenige ist, der er vorgibt zu sein. Authentisierung ist einem Identitätsnachweis gleichzusetzen.
Authentisierung oder Authentifizierung?
- Authentisierung: bezeichnet eigentlich den Vorgang, des Identitätsnachweises (z. B. durch Passwort, Ausweis, Fingerabdruck). ➡️ Der Nutzer authentisiert sich mit seinem Passwort.
- Authentifizierung: bezeichnet die Bestätigung/Prüfung durch das System, dass dieser Nachweis gültig ist. ➡️ Das System authentifiziert den Nutzer.
- Aber: Im Alltag und auch in vielen Fachtexten / technischen Artikeln werden beide Wörter oft synonym benutzt. ➡️ Sogar die DIN-Norm 44300 spricht nur von „Authentifizierung“, obwohl rein sprachlich „Authentisierung“ exakt wäre.
On-Premises mit Active Directory
Im Bereich des On-Premises Active Directory haben wir vier Protokolle, eigentlich drei Protokolle, nomaler Weise zwei Protokolle und idealer Weise ein Protokoll, welches zur Authentisierung / Authentifizierung zur Verfügung:
- LM: das LM-Protokoll entstand 1980 ursprünglich im Rahmen des IBM/Microsoft OS/2 LAN Manager (daher „LANMAN“). 1993 (!) übernahm Microsoft das Protokoll in die Windows-NT-Reihe, um Abwärtskompatibilität zu OS/2-LAN-Manager-Clients sicherzustellen. Parallel wurde NTLM eingeführt, ein moderneres Protokoll, aber LM blieb aktiv, weil viele Clients es nutzten. Seit Windows XP SP2 ist es „Best Practice“, LM zu deaktivieren.
- NTLMv1: 1993 (!) eingeführt, sollte NTLMv1 das alte LM-Protokoll ablösen, war aber parallel aktiv zu LM. Seit NT 4.0 wird NTLMv1 in den Microsoft Workgroup- und Domänenumgebungen genutzt. Microsoft empfiehlt ausschließlich NTLMv2 oder Kerberos.
- NTLMv2: 1996 mit Windows NT 4.0 eingeführt um die Schwachstellen von LM und NTLMv1 zu beheben. NTLMv2 ist die letzte unterstützte NTLM-Variante und Microsoft empfiehlt, wo möglich, auf Kerberos zu setzen.
- Kerberos V5: 1983 entstand Kerberos am MIT als Teil des Project Athena, um sichere Authentifizierung in verteilten Netzwerken zu ermöglichen. 1993 (!) (RFC 1510, später RFC 4120) Einführung von Kerberos v5 als Standardprotokoll, mit verbesserter Verschlüsselung, Internationalisierung, flexibleren Ticketformaten. V5 löste v4 vollständig ab. 2000 übernimmt Microsoft Kerberos v5 als Standard für Domänenanmeldungen.
Eine Übersicht, mit Hilfe von ChatGPT zusammengestellt, habe ich hier bereitgestellt.
AuthN und AuthZ On-Premises
LM, NTLMv1, NTLMv2, Kerberos V5 und Digest gehören alle zum Bereich AuthN. Sie validieren eine Identität, sie autorisieren nicht.
AuthZ ist im On-Premises-Bereich alles von einer Zugriffsliste (DACL), einem Rollenmodell (RBAC) und einem attributsbezogenem Rollenmodell (ABAC)
Alles verwirrend. On-Premises-Authentifizierung, Cloud-Authentifizierung!
Wie führe ich das denn nun zusammen?
Cloud mit Entra Id
Bei Entra Id ist die Anzahl der Protokolle deutlich größer:
- SAML 2.0: Standardisierung des SSO im Web durch das OASIS-Konsortium (1999 / 2000). XML-basierend und in der Regel auf HTTP 302-Redirects zu IdPs (Identity Provider) beruhend. Implementierung bei Microsoft durch ADFS. SAML wird immer stärker durch OIDC und OAuth abgelöst.
- OAuth 2.0: 2006 / 2007 als einheitliche Lösung für delegated Access in Web-APIs gestartet. 2012 mit OAuth 2.0 in der RFC 6749 vorgestellt. Seit 2014 setzt OIDC auf OAuth 2.0 auf um die Authentifzierung zu ergänzen. Heute der de-facto Standard für API-Autorisierung.
- OpenID Connect (OIDC): 2005 entstanden als dezentrale Authentifzierung im Web. Grob an SAML angelehnt durch HTTP 302-Redirects und einer URL-basierenden Identität. 2010 begann die Weiterentwicklung zum heutigen OpenID auf Basis von OAuth 2.0. Der Fokus lag auf Simplifizierung und Sicherheit. Anders als SAML fusst der Transport auf JSON / JWT. OIDC ist heute der de-facto-Standard für moderne Authentfizierung (OIDC = Authentifizierung / OAuth = Autorisierung).
- WS-Federation: Ab 2000 entwicklen IBM, Microsoft und andere die WS-Suite (Web Services Security Framework). 2006 wird durch OASIS WS-Fed 1.1 veröffentlicht, Microsoft integriert dieses in seinem Produkt ADFS. Derzeit in direkter Konkurrenz zu OIDC und SAML 2.0; Microsoft stuft WS-Fed als Legacy ein.
Eine Übersicht der Authentisierungsmöglichkeiten im Entra Id habe ich, mit Hilfe von ChatGPT, hier bereit gestellt.
AuthN und AuthZ
💡 AuthN ist die Abkürzung für (hier in Deutsch super exakt wiedergegeben) Authentisierung (authentication im Englischen).
💡 AuthZ ist die Abkürzung für (hier in Deutsch super exakt wiedergeben) Authorisierung (authorization im Englischen).
Warum ist das wichtig zu wissen?
Weil es jetzt unterschiedliche Verfahren gibt, die AuthN liefern!
- Windows Hello for Business: Microsofts moderne, kennwortlose Anmeldemethode für Windows-Geräte
- Passkeys / FIDO2: eine moderne, kennwortlose Anmeldemethode, die auf kryptografischen Schlüsselpaaren basiert und meist per Fingerabdruck, Gesichtserkennung oder Gerätesperre funktioniert.
- Microsoft Authenticator App: eine mobile Anwendung für iOS und Android, die sichere Anmeldungen durch MFA (Multi-Faktor-Authentifizierung), passwortlose Anmeldung und Verwaltung von Geschäftskonten ermöglicht.
- Certificate-based Authentication: ein Anmeldeverfahren, bei dem sich Benutzer mit einem digitalen Zertifikat (z. B. auf Smartcard, Hardwaretoken oder im Gerätespeicher) ausweisen, anstatt ein Passwort einzugeben.
- Hard- und Software OATH Token: Einmalpasswort-Generatoren (OTP), die nach dem offenen OATH-Standard zeitbasierte (TOTP) oder zählerbasierte (HOTP) Codes erzeugen und als Hardwaregerät (z. B. Schlüsselanhänger) oder App (z. B. Microsoft/Google Authenticator) bereitgestellt werden.
- Temporary Access Pass (TAP): ein zeitlich begrenztes, einmaliges Anmelde-Geheimnis in Entra ID, das Benutzern den sicheren Einstieg ohne Passwort oder zweiten Faktor ermöglicht – typischerweise zur Erstregistrierung von MFA/Passkeys oder zur Wiederherstellung des Zugangs.
Eine (mit Hilfe von ChatGPT) zusammengestellte Übersicht von AuthN und AuthZ ist hier zu finden.
Zwei Welten
die jetzt irgendwie zusammengeführt werden müssen.
Der User verwendet seine Idenität, die per Entra Id-Connect vom lokalen Active Directory in das Entra Id synchronisiert wird. Der User verwendet hierzu ein Gerät, welches aber nur im Entra Id / Intune bekannt ist. Im lokalen Active Directory ist dieses Gerät nicht zu finden.
Das Zusammenführen der beiden Welten ist die Aufgabe vom Cloud Kerberos Trust (CKT).
Das Setup von CKT ist identisch zu dem vom hybriden Ansatz bei der Authentisierung mit einem hybid joind device (HJD). Die schnelle Checkliste hierzu:
- Tenant und Active Directory über Entra Id Connect verbunden
- Alle Domain Controller müssen bei Kerberos V5 die AES256-Bit-Verschlüsselung unterstützen
- Über Set-AzureADKerberosServer die Vertrauensstellung zwischen Active Directory (On-Premises) zu Entra Id (Cloud) herstellen.
Beispiel: Zugriff auf einen On-Premises File-Server
Ticketfluss im Detail
User Sign-In mit FIDO2 Security Key
- Der Benutzer meldet sich am Entra ID-joined Device mit FIDO2 (Passkey/Security Key) an.
- Entra ID authentifiziert den Benutzer (der aus dem On-Premises AD synchronisiert ist).
- Ergebnis: Ein PRT (Primary Refresh Token) + Cloud Kerberos Trust (CKT)-Informationen für Kerberos sind verfügbar.
Cloud Kerberos Trust Einrichtung
- Entra ID stellt einen „Kerberos Cloud Ticket Granting Ticket“ (Cloud TGT) bereit, das auf dem On-Premises Key Distribution Center (KDC, AD-DC) vertraut ist.
- Das Gerät speichert diese Informationen im Kerberos SSP.
Client möchte auf den File-Server zugreifen
- Der Client erkennt, dass er ein Kerberos Ticket für cifs/fileserver.domain.local benötigt.
- Er nutzt den Cloud TGT, um ein Service Ticket beim On-Prem AD-KDC zu bekommen.
Kerberos Ticket Request
- Der Client sendet (über das Kerberos SSP) eine Anfrage an den On-Premises KDC: „Gib mir ein Ticket für cifs/fileserver.domain.local“.
- Der On-Prem KDC prüft die Cloud Kerberos Trust-Informationen gegen den synchronisierten Benutzer.
Ticket Issuance
- Der KDC stellt ein Service Ticket (ST) für den Fileserver aus.
- Dieses Ticket wird zurück an den Client geliefert.
Zugriff auf den Fileserver
- Der Client präsentiert das ST an den File-Server (SMB/CIFS).
- Der Fileserver vertraut dem On-Prem KDC und gewährt Zugriff entsprechend den NTFS/Share-Berechtigungen.
Was brauche ich dazu?
Neben dem Cloud Kerberos Trust (CKT) benötige ich eine
➡️ „line of sight“ mit Read-Write Domain Controllern.
Das ist nicht immer gewünscht, manchmal auch nicht möglich. Es kann hier hilfreich sein über einen KDC-Proxy nachzudenken.
Bedeutet was?
Bedeutet, dass sich, beispielsweise, Frau Renate Ratlos per YubiKey 5NFC an Ihrem Entra Id-joined Gerät anmelden kann.
Aus Gründen der Sicherheit heraus wurde bei Frau Ratlos der Haken gesetzt „Smart card is required for interactive logon“. Dieses führt dazu, dass Frau Ratlos ihr eigenes, 120 Zeichen langes, komplexes Kennwort nicht kennt und dieses Kennwort auch noch spätestens alle 30 Tage geändert wird.
Frau Ratlos ist Mitglied einer Gruppe, welches ihr Zugriff auf eine Freigabe On-Premises auf einem Windows-File-Server gestattet: FS-ACCESS-READ.
Worauf ich hinaus will: „Ausführen als“, „Verbinden als“ ist keine Option mehr. Das wird jetzt entweder eine echte CKT-SSO-Nummer oder nix mit dem Zugriff.
klist.exe
Das erste klist.exe war vor dem Zugriff auf die Freigabe.
Das zweite klist.exe war nach dem Zugriff auf die Freigabe.
Bist Du DEPPERT!
Cloud Kerberos Trust lässt mich folgenden Weg beschreiten:
Primary Refresh Token (PRT) ➡️ Partitial Ticket Granting Ticket (PTGT) ➡️ (Full) Ticket Granting Ticket (TGT) ➡️ Ticket Granting Service Ticket (TGS) ➡️ Access Token
- PRT: per Sign-in mit FIDO2 dank YubiKey 5NFC
- PTGT: per Cloud Kerberos Trust dank Vertrauenstellung zwischen On-Premises AD und Entra Id. Das PTGT enthält nur die User-SID im PAC-Feld, On-Premises-Gruppenverschachtelungen werden nicht berücksichtigt.
- TGT: per PTGT. Das PTGT wird vom Domain Controller On-Premises auf basis der User-SID vom PTGT zu einem Full TGT.
- TGS. per (Full) TGT bekomme ich ein TGS für den File-Server On-Premises
- Access Token: per TGS bekomme ich vom File-Server ein Access Token. Autorisiert werden ich auf Basis der Gruppenverschachtelungen im On-Premises AD
Hmmm…
Nehmen wir mal an, wir haben eine Hybridstellung mit Active Directory und Entra Id.
Nehmen wir weiter an, dass wir in der Regel Ressourcen aus der Microsoft Cloud nutzen (Azure what-ever-as-a-service (weaas), M365, Teams und dergleichen).
Ebenso angenommen es gibt noch ein paar Ressourcen On-Premises wie File-Services, Websites und ähnliche Dinge, die man nicht (*hust*) in eine Cloud packen kann (*hust* *hust*). Oder will! Oder darf!
Wie also vorgehen?
Meine Vorschläge hierzu:
- 💡Workstations Entra Id joined, end of discussion (EOD).
- 💳 Anmeldung der User auf dem Gerät ausschließlich per physischem Security Token im Entra Id.
- 🔒 Im On-Premises Active Directory den Haken setzen „Smart card is required for interactive logon“.
- 🔐 Reine On-Premises User, insbesondere die administrativen User, melden sich ausschließlich per Smart Card an.
Nachtrag vom 30.09.2025
Auf Linkedin wurde ich, dankbarer Weise, darauf aufmerksam gemacht, dass die Password Replication Policy (PRP) auf dem Read-Only Domain Controller (RODC) vom Entra Id, AzureADKerberos, etwas zu liberal eingestellt ist.
Die „Domain Users“, welche ja auch das Tier 0 inkludieren, sollten sich nicht über den RODC AzureADKerberos authentifizieren lassen.
Vorzugsweise nur die Gruppe der Objekte (User und Computer (!)), welche auch zum Entra Id synchronisiert werden, hier: OnEntraId.
| Merkmal | LM (LAN Manager) | NTLMv1 | NTLMv2 | Kerberos v5 |
|---|---|---|---|---|
| Einführung | 1980er (IBM/Microsoft LAN Manager) | 1993 (Windows NT 3.1) | 1996/97 (Windows NT 4.0 SP4) | 1993 (RFC 1510 → RFC 4120), Windows 2000 AD |
| Verwendung | OS/2, frühe Windows-Versionen | Windows NT/2000/XP | Ab Windows 2000 empfohlen, Vista/2008 Standard | Standard ab Windows 2000 Active Directory |
| Passwortlänge | max. 14 Zeichen | bis 127 Zeichen | bis 127 Zeichen | abhängig vom KDC / AD |
| Case-Sensitivity | nur Großbuchstaben | ja | ja | ja |
| Hash-Algorithmus | DES auf Uppercase-PW | MD4-NT-Hash + DES | NT-Hash + HMAC-MD5 | symmetrische Kryptographie (z. B. AES) |
| Challenge/Mechanik | 2×7-Zeichen-Blöcke mit DES | 3 DES-Blöcke auf 8-Byte-Challenge | Server + Client Challenge, Zeitstempel, HMAC | Ticket-basiert (AS/TGS), Zeitstempel, Nonces |
| Replay-Schutz | nein | begrenzt | ja (Nonce + Zeitstempel) | ja (Tickets + Lifetimes) |
| Single Sign-On (SSO) | nein | nein | eingeschränkt | ja |
| Skalierbarkeit | kaum | gering | moderat | hoch (Cross-Realm, Trusts) |
| Sicherheitslage | extrem schwach | schwach | deutlich sicherer, aber Pass-the-Hash möglich | stark, aber anfällig für Ticket-Angriffe (Kerberoasting, Golden Ticket) |
| Status heute | obsolet, deaktiviert | obsolet, deaktiviert | aktiv, Fallback wenn kein Kerberos | Standard in Windows-Domänen, weit verbreitet |
| Merkmal | SAML 2.0 | OAuth 2.0 | OIDC | WS‑Federation |
|---|---|---|---|---|
| Einführung / Standardisierung | 2005 (OASIS) | 2012 (IETF RFC 6749 / 6750) | 2014 (OpenID Connect 1.0, OpenID Foundation) | 2006 (OASIS WS‑Fed 1.1, basiert auf WS‑Trust) |
| Primärer Zweck | Web‑SSO & Föderation (AuthN + Attribute) | Autorisierung (Delegated Access zu APIs) | Authentifizierung (Identity Layer auf OAuth 2.0) + Autorisierung | Web‑SSO/Föderation für SOAP/XML‑basierte Dienste |
| Datenformat | XML (Assertions, Protocol, Bindings) | JSON/HTTP (oft JWT Access Tokens; auch opak) | JWT (ID Token) + JSON/HTTP; Discovery via /.well-known/openid-configuration |
XML + SOAP; Security Tokens (häufig SAML Assertions) |
| Token / Assertions | SAML Assertions (Authn, Attribute, Decision) | Access Token, Refresh Token (kein ID‑Token per se) | ID Token (JWT), Access Token, Refresh Token | Security Tokens (z. B. SAML Assertion) vom STS |
| Typische Flows / Bindings | HTTP‑Redirect/POST, Artifact; Web Browser SSO Profile | Authorization Code (+PKCE), Client Credentials, Device Code; (Implicit/ROPC: legacy) | Authorization Code (+PKCE), Hybrid; (Implicit: legacy) | Passive Requestor Profile (Browser‑SSO) über WS‑Trust |
| Browser‑SSO | Ja (Standard‑Einsatz) | Indirekt (über OIDC); nativ primär API‑Zugriff | Ja (webfreundlich, modern) | Ja (insb. mit ADFS) |
| Mobile / SPA / API‑Tauglichkeit | Begrenzt (XML/Redirects; nicht ideal für Mobile/SPAs) | Sehr gut für APIs, mit PKCE auch Mobile/SPAs | Sehr gut (moderne Web/Mobile; JSON/JWT) | Schwach (SOAP/XML; nicht API‑/Mobile‑orientiert) |
| Logout | Single Logout (SLO) spezifiziert (Redirect/POST) | Kein standardisierter Logout (abhängig vom Anbieter) | Front‑/Back‑Channel Logout Spezifikationen verfügbar | Sign‑Out‑Mechanismen (wsignout) in ADFS/WS‑Fed |
| Föderation / Verbund | Ja (stark, verbreitet zw. Organisationen) | Primär nicht; Föderation via OIDC/SAML üblich | Ja (über OP‑zu‑RP; Föderation via IdP/OP) | Ja (insb. in Microsoft‑Ökosystemen) |
| Typische Anbieter / Stacks | Shibboleth, ADFS, Ping, Okta, Entra ID, SAP | Entra ID, Auth0, Okta, Google, GitHub, Cognito | Entra ID, Google, Okta, Auth0, Cognito, Keycloak | ADFS, SharePoint (historisch), WS‑*/SOAP‑Stacks |
| Heutiger Einsatz | Breit in Enterprise‑SSO; rückläufig zugunsten OIDC | De‑facto‑Standard für API‑Autorisierung | De‑facto‑Standard für moderne Authentifizierung | Legacy/Kompatibilität; Migration zu SAML/OIDC empfohlen |
| Stärken | Reif, interoperabel, Attribute‑Rich, SLO | Flexibel, API‑freundlich, Scopes, breite Unterstützung | Einfach, JSON/JWT, Discovery, Mobile/SPA‑tauglich | Gute MS‑Integration, Claims‑basiert für SOAP‑Dienste |
| Schwächen | XML‑Overhead, komplex, nicht Mobile‑optimiert | Nur Autorisierung (AuthN via OIDC nötig); viele Legacy‑Flows unsicher | Abhängigkeit vom OAuth‑Sicherheitsmodell; Implementierungsfehler möglich | SOAP/XML schwergewichtig; außerhalb MS selten |
| Status heute | Weit verbreitet, aber abnehmend | Aktiver Kernstandard | Aktiver Kernstandard für Authentifizierung | Legacy (Kompatibilitätsbetrieb) |
| Verfahren | Primärer Faktor‑Typ | AuthN‑Rolle | Passwordless | Protokoll‑Einsatz (Transport & Autorisierung) | Typische Szenarien & Hinweise |
|---|---|---|---|---|---|
| Windows Hello for Business | Asymmetrischer Schlüssel (TPM‑gebunden), entsperrt per Biometrie/PIN | Primäre AuthN | Ja | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos (on‑prem): ◐ | Windows‑Anmeldung & SSO zu Cloud‑Apps; Kerberos‑SSO bei Hybrid mit Cloud Kerberos Trust / Zertifikat‑Trust. |
| Passkeys / FIDO2 Security Keys | FIDO2/WebAuthn (asymmetrischer Schlüssel; Hardware/Plattform) | Primäre AuthN | Ja | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos (on‑prem): ◐ | Passwordless Anmeldungen für Web & Windows; SSO zu On‑Prem über AAD‑/Cloud‑Kerberos‑Trust in Hybrid‑Setups. |
| Microsoft Authenticator App | App‑Bestätigung (Push/Nummernabgleich), TOTP; Phone Sign‑in | Primäre AuthN oder MFA | Ja (Phone Sign‑in) | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos: ✕ | Passwordless Phone Sign‑in oder als zweiter Faktor; weit verbreitet für Cloud‑Apps und Adminzugänge. |
| Certificate‑based Authentication (CBA) | X.509‑Zertifikat (Smartcard/virtuell/Device‑Zert.) | Primäre AuthN oder MFA | Ja (je nach Policy) | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos (Smartcard‑Logon): ✓ | Cloud CBA (IdP‑seitig) und klassisches Smartcard‑Logon; stark für regulierte Umfelder. |
| Hardware OATH Token | HOTP/TOTP Einmalpasswort (Hardware) | MFA‑Faktor | Nein | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos: ✕ | Zweiter Faktor in Web‑Flows; kein eigenständiger Login ohne Primärfaktor; gut für „No‑Phone“‑Szenarien. |
| Software OATH (TOTP App) | TOTP Einmalpasswort (Software/App) | MFA‑Faktor | Nein | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos: ✕ | Zweiter Faktor in Web‑Flows; weit verbreitet; nicht phishing‑resistent wie FIDO2/WHfB. |
| Temporary Access Pass (TAP) | Zeitlich begrenzter Einmal‑Code (IdP‑ausgestellt) | Temporäre Primär‑AuthN | Teilweise (für Onboarding/Recovery) | OIDC/OAuth 2.0: ✓ · SAML 2.0: ✓ · WS‑Fed: ✓ · Kerberos: ✕ | Onboarding/Recovery, Registrierung von FIDO2/WHfB; kurze Gültigkeit, nicht für Dauerbetrieb gedacht. |
Legende: ✓ = üblich/unterstützt · ◐ = abhängig von Hybrid‑Konfiguration/Trust · ✕ = nicht zutreffend.
AuthZ (Autorisierung): OIDC/OAuth 2.0 → Access/ID Tokens (Scopes/Claims), SAML 2.0 → SAML Assertions, WS‑Fed → Claims Tokens, Kerberos → Service‑Tickets.