Domainanmeldung

Diese Seite beleuchtet, welche verschiedene für eine Anmeldung der Überprüfung von Zugangsdaten genutzt werden, was ihre Vorteile aber auch Nachteile sind. Es gab durchaus eine Zeit vor SAML/OAUTH und Windows Domain Diensten. Ich beschreibe einen ganz durch die Geschichte um dann die verschiedenen Kopplungen aufzuzeigen. Auslöser war eine Kundenanfrage, wie man denn per LDAP externen Zugang sichern könnte und meine Versuche eine Anmeldung an Squid-Proxy mittels Kerberos zu erreichen.

Peer2Peer und lokale Konten

Die meisten Leser dürfte nicht mehr wissen, was "Windows for Workgroups" war. Alle privaten PCs sind "Standalone-Rechner" und viele Linux-System vermutlich aus. Sie zeichnen sich alle dadurch aus, dass es eine lokale Benutzerdatenbank mit Kennworten gibt und sich Anwender mit einem Kennwort auf genau diesem System anmelden. Sobald Sie auf Dienste anderer Systeme zugreifen wollen, müssen Sie sich dort auch wieder anmelden und dort muss es ebenfalls ein Benutzerkonto geben. Das ist aufwändig in der Verwaltung, unsicher und bei Kennwortänderungen sehr unbequem.

Domains und Anmeldeserver

Sehr früh haben sich daher System entwickelt, die einen Verbund mehrere Computer leichter verwaltbar machen konnten, in dem es ein oder mehrere "Verzeichnisserver" gab und die anderen Mitgliedssysteme diesem Verwaltungsserver vertraut haben. Die ersten System waren:

Viele Systeme hatten am Anfang eine "Flache Struktur", d.h. es gab einfach eine Liste der Benutzer und Gruppen. Eine Strukturierung über OU's, wie wir sie heute kennen, kam erst mit dem Active Directory oder NetWare DNS. Einige Verzeichnisdienste haben nicht nur Benutzer und Gruppen bereitgestellt, sondern auch Hostnamen verteilt. Heute ist dies aber eine Aufgabe für DNS. Damit haben wir aber das erste Bild.

  • Verzeichnisserver
    Diese halten die Datenbank mit den Identitäten und stellen die Anmeldedienste, (SAM NETLOGON, KERBEROS) bereit.
  • MemberServer
    Dateiserver, Mailserver, Proxyserver etc. bieten ihre Dienste den Clients an und erwarten eine Anmeldung. Sie haben zwar noch eine rudimentäre lokale Benutzerdatenbank aber nutzen ansonsten die Verzeichnisdienste.
  • Memberclient
    Auch Desktops der Anwender erfordern heute eine Anmeldung und auch hier wird die Benutzerdatenbank der Verzeichnisdienste zurückgegriffen. Wenn der Client aber dann auf den Memberserver zugreift, kann er seine Anmeldeinformationen einfach durchreichen.

Damit die Clients und Server die Dienste der Verzeichnisserver nutzen dürfen, muss es eine Kopplung geben. Die Clients und Server müssen die Verzeichnisdienste kennen und sich dort authentifizieren. bei Windows ist das der klassische "Domain Join", mit dem ein Server oder Client in die Domäne aufgenommen wird. Der Computer bekommt ein eigenes Computerkonto um sich am Verzeichnisdienst als Mitglied auszuweisen.

Bei der Anmeldung gibt es in der Windows Welt seit dem Active Directory nun zwei Möglichkeiten, sich an einem Server anzumelden.

  • NTLM
    Der Anwender nutzt z.B. Benutzername/Kennwort, um sich am Client anzumelden. Wenn er dann auf den Server zugreift, dann sendet er nicht mehr das Kennwort dort hin, sondern einen Hashwert und der Server prüft diese Anmeldung gegen den Verzeichnisdienst (SAM)
  • Kerberos
    Der Benutzermeldet sich wieder an aber beim Zugriff auf den Server fordert der Benutzer auf dem Client nun ein Zugriffstoken (Kerberosticket) vom Verzeichnisdienst an, mit dem er dann auf den Server zugreift. Der Server kann direkt das Ticket prüfen und muss nicht mehr selbst den Verzeichnisserver abfragen. Dieser Ansatz ist in vielerlei Hinsicht besser, was ich auf Warum Kerberos besser ist beschrieben habe.

Soweit bewegen wird uns noch auf Windows Standardfunktionen.

Cloud und Internet

Mittlerweile befinden sich die Server aber nicht mehr nur im lokalen LAN, sondern bei Dienstleistern und vor allem auch in der Cloud. Der Server eines Cloud-Anbieters hostet die Daten vieler Kunden und selbst wenn Sie über das Internet eine sichere Verbindungen zu ihren lokalen Verzeichnisdiensten per VPN o.ä. aufbauen würden, würde der Provider sein System sicher nicht in viele Kunden-Domänen integrieren können. NTLM-Hashwerte, die vom Service gegen ihren DC geprüft werden, scheiden aus. Da der Cloud-Anbieter auch kein Computer in ihrer Domain ist, ist eine Anmeldung per Kerberos auch erst mal nicht so einfach. Aber Microsoft zeigt mit Seamless Single Sign On, dass es schon möglich ist, ein lokales Computerkonto mit Kerberos SPN anzulegen und das Geheimnis in der Cloud zu hinterlegen, so dass ein geeigneter Client mit einem Ticket vom lokalen Verzeichnisserver sich an der Cloud anmelden kann.

In der Cloud ist heute irgendwie alles SAML/OAUTH und im Grund ist es nicht viel anders als Kerberos. Der Anwender nutzt einen SAML-Server, z.B. die Windows ADFS-Rolle oder das AzureAD, um sich für einen Dienst ein SAML-Token/JSON_Web_Token) anzufordern. Der Ausstelle bestimmt, welche Informationen in dem Token enthalten sind und der Service kann eine Vertrauensstellung zu dem Aussteller einrichten. (Stichwort FederationMetadata)

OAUTH ist nicht nur die Zukunft sondern schon die Gegenwart und sollte für jegliche Authentifizierung mit Diensten genutzt werden, die nicht "Domainmitglied" sind oder Kerberos können.

SSO und Sicherheit

Wenn es um Anmelden geht, dann vertrete ich die Ansicht, dass ein Anwender möglichst überhaupt kein Kennwort mehr eingibt oder maximal einmal morgens bei der Anmeldung an seinem verwalteten und vertrauenswürdigen Endgeräte sich authentifiziert. Das kann ein Kennwort sein aber gerne auch Windows Hello etc. Damit ist der Benutzer durch den Verzeichnisdienst legitimiert. Alle folgenden Zugriffe auf interne oder externe Services sollten komplett transparent erfolgen. Wir schlagen damit gleich mehrere Fliegen

  • Bequem
    Der Benutzer muss nicht weitere Kennworte merken oder eingeben und kann einfach arbeiten. Auch Links in Mails auf andere Webseiten etc funktionieren einfach ohne weitere Anmeldungen
  • Weniger Risiko für Phishing
    Je mehr Kennwort-Dialoge ein Benutzer bekommt, desto häufiger muss er seine Zugangsdaten eingeben. Sind sie sicher, dass jeder Anwender genau das Fenster betrachtet, ob es eine erwünschte Anmeldung ist oder doch eine Phishing-Seite die nur eine Anmeldung vorspielt um an die Daten zu kommen ?
  • Keine Kennworte
    NTLM aber insbesondere Kerberos und OAUTH übertragen keine Kennwort sondern Tickets, die verschlüsselt, signiert und zeitlich begrenzt sind. Damit entfällt das Risiko, dass ein externer Dienst z.B. vom Benutzer eingegebene Zugangsdaten im Klartext hat
  • SameSignOn ist nicht genug. SingleSignOn ist Pflicht
    Es reicht nicht, wenn die Anwender überall die gleichen Zugangsdaten eingeben dürfen. Sie sollten idealerweise nur einmal sich an dem Gerät ausweisen, an dem Sie Arbeiten und jede weiterer Anmeldedialog sollte vermieden werden.

Nun gibt es natürlich verschiedene Systeme und unterschiedlichste Anmeldemöglichkeiten. Nicht alle bieten alle Vorteile-

Squid - Flexibilität extrem

Leider ist noch nicht bei allen Administratoren angekommen, dass Kerberos und OAUTH das Ziel sein sollte und es gibt sehr viele Dienste, die weder das Eine noch das Andere können und stattdessen auf "bewährte Methoden" setzen. Ich nehme als Beispiel den HTTP-Proxy-Server "Squid" her, der eigentlich alles kann, was die Welt zu bieten hat.

DB: Uses a SQL database.
getpwam: Uses the old-fashioned Unix password file.
LDAP: Uses the Lightweight Directory Access Protocol.
MSNT: Uses a Windows NT authentication domain.
MSNT-multi-domain: Allows login to one of multiple Windows NT domains.
NCSA: Uses an NCSA-style username and password file.
NIS (or YP): Uses the NIS database
PAM: Uses the Unix Pluggable Authentication Modules scheme.
POP3: Uses an email server to validate credentials. Useful for single-signon to proxy and email.
RADIUS: Uses a RADIUS server for login validation.
SASL: Uses SASL libraries.
SMB: Uses a SMB server like Windows NT or Samba.
SSPI: Windows native authenticator
Quelle: https://wiki.squid-cache.org/Features/Authentication

Wem das immer noch nicht reicht, kann auch gerne einen eigenen Authenticator schreiben:

Q: Can I write my own authenticator?
A: Squid has a large range of versatile helpers to integrate with a very large number of popular authentication backends. Including custom-built corporate databases. Take a look through the bundled helpers manuals and online search engines. You will likely find someone has already done the hard work.
However, you may still find the need to write your own one for some system which has not been dreamed of yet. The protocol(s) Squid uses to communicate with its authentication helpers are very simple, and there are several examples in the wiki
https://wiki.squid-cache.org/Features/Authentication#can-i-write-my-own-authenticator

Ich würde davon aber abraten, denn es kann nur unsicherer werden. Dankenswerterweise kann Squid alle "sicheren" Verfahren, so dass Sie keine unsicheren Optionen wählen müssen. Aber schon die Vielzahl an "Connectoren" zu anderen Anmeldediensten zeigt doch, dass ein Squid-Administrator am liebsten keine lokalen Benutzerdatenbank verwaltet.

Alternative Verifizierung

Aber nicht alle Produkte können Kerberos oder OAUTH und in den früheren Jahren wurden manchmal sehr komische Verfahren umgesetzt, um die Anmeldung an einem Service über einen Verzeichnisdienste er ermöglichen. Meist geht das aber nicht über SingleSignOn sondern der Anwender meldet sich an dem jeweiligen Service mit Benutzername und Kennwort an und der Service nutzt einen der beschrieben Weg, um sich mit den Anmeldedaten des Benutzers woanders anzumelden. Gelingt diese Anmeldung, dann müssen die übergebenen Anmeldedaten ja wohl gültig sein. Diese Ansätze haben Vorteile aber auch Nachteile:

  • Keine Kennworte beim Betreiber
    Der Betreiber der Plattform musste zwar weiterhin die Benutzer für eine Applikation irgendwo verwalten aber er musste keine Kennworte speichern und verwalten. Das wäre an sich schon mal ein Pluspunkt, wenn auf dem Service-System keine Kennworte mit einer unbekannten Absicherung (Hash + Salt, Verschlüsselung o.ä.) liegen würden
  • Kontosperrung durch Anmeldung
    Wird das Anmeldekonto im Verzeichnisdienst gesperrt oder gelöscht, dann kann sich der Anwender auch nicht mehr an allen anderen Diensten anmelden. Das ist ein Vorteil.
  • Anmeldedaten beim Services
    Aber dafür kommt das Risiko dazu, dass die Anmeldedaten vom Client zu diesem Server nicht zwingend sicher sind und auch die Prüfung im Backend nicht sicher sein muss. Wir können nur darauf vertrauen, dass der Service die zur Anmeldung übermittelten Daten nicht irgendwo "sichert" oder protokolliert und auch kein Angreifer mit Zugriff auf das System diese Informationen ausleitet
  • Kein SingleSignOn
    Durch die Nutzung der gleiche Anmeldedaten muss der Anwender natürlich keine weiteren Kennworte merken aber er muss es für jeden Dienst immer wieder eingeben. Das ist ein Nachteil
  • MFA/Conditional Access unklar
    Es mag Verfahren geben, mit denen auch MFA-geschützte Anmeldungen über solche Konstruktionen möglich sind, aber sie beschränken sich und schwächen damit die Sicherheit.
  • Firewall-Tauglichkeit
    Nicht alle Protokoll beschränken sich auf einen statischen Port, sondern nutzen gleich ganze Portbereich oder gänzlich dynamische Ports. Für die Anbindung von Cloud-Diensten ist das sicher keine gute Wahl.

Aus meiner Sicht sind die "Credentials beim Service" und fehlendes SingleSignOn die wesentlichen Gründe, die indirekte Authentifizierung möglichst zu vermeiden.

Folgende Verfahren habe ich im Laufe der Zeit gesehen. Vielleicht finden Sie die ein oder andere Variante auch heute noch in ihrem Netzwerk und sollten überlegen, ob eine Weiterentwicklung angebracht ist

Verfahren Beschreibung

LDAP mit BIND-User

Jeder Benutzer eines Verzeichnisdiensts kann sich in der Regel per LDAP am Server anmelden. Diverse Services nutzen diese Funktion, um die vom Anwender erhaltene Daten einfach mit einem "LDAP BIND" zu überprüfen. Voraussetzung ist natürlich eine LDAP-Verbindung zwischen dem Service und dem Verzeichnisdienst. Mit der gültigen Anmeldung könnte der Anbieter natürlich per LDAP weitere Informationen auslesen. Das kann gewollt sein aber auch nicht.

Wer seinen Domain aber nicht durch so ein Dienstkonto auslesbar präsentieren will, für den ist die nächste Option interessant.

LDAP Proxy mit BIND-User

Wer seinen Domain-Controller nicht per LDAP zu einem fremden Dienst öffnen möchte, kann z.B. einen ADAM/AD LDS Service dazwischen schalten. Über ADAMSync replizieren sie dann nur die Benutzer in den AD LDS, die überhaupt eine Anmeldung nutzen sollen und tragen Sie als "ProxyAuth"-User ein. Damit reduzieren Sie die Daten, die jemand per LDAP von extern lesen könnte.

HTTP-Request

Was sollte Sie daran hindern, einen Webserver (z.B. IIS) auf einem Server zu installiere, der einfach eine statische HTML-Seite an authentifizierte Benutzer ausliefert. Jeder kompatible Dienst kann mit den erhaltenen Anmeldedaten versuchen, diese URL abzurufen. Auf den anonymen http-Request kommt noch ein 403, worauf der Request mit Zugangsdaten wiederholt wird. Kommt dann ein „200 OK“, dann sind die Anmeldedaten korrekt. HTTP kann auch gut "veröffentlicht" und mit TLS abgesichert werden. In den Webserver-Logs können Sie sogar sehen, wer sich wann angemeldet hat. Zudem stehen viele Optionen von ReverseProxy, Loadbalancer, DoS Schutz etc. bereit.

Cloud Kerberos

Diesen Weg nutzt Microsoft in Microsoft 365, wenn Sie sich per Seamless Single Sign On anmelden aber auch eine Kerberos-Anmeldung an einem Unix-System ist ähnlich. Sie definieren im AD ein Computer/User-Konto mit SPN und das Kennwort bekommt der Service, z.B. als Keytab-Datei. Ihr Client geht zum Service, der "Negotiate" als Verfahren anbietet, der Client holt sich ein Ticket und sendet es an den Service, der das Ticket dank Keytab decodieren und die gewünschten Informationen extrahieren kann.

SMB-Zugriff

Was per HTTP und LDAP geht, kann natürlich auch per Dateizugriff auf eine Freigabe erfolgen, die mit ACLs abgesichert ist. Auch hier sind die Hürden der Implementierung sehr gering aber SMB über Port 135/137-139 ist sicher kein Protokoll, was Sie von extern oder aus einer DMZ erlauben sollten.

Radius

Das primäre Einsatzgebiet von Radius/AAA waren früher Dial-UP-Zugänge und sind heute immer noch bei DSL-, WiFi, 802.1x und VPN-Verbindungen in Benutzung. Der Username hat meist eine Userpart und einen Domainpart. Über den Domainpart kann ein Access-Point einfach die Anfragen an unterschiedliche Radius-Server geben. So können z.B. unterschiedliche Internetprovider die Leitung eines anderen Providers nutzen.

Letztlich wird mittels Radius die Anmeldung überprüft, ggfls. eine Konfiguration mit gesendet und auditiert. Niemand verbietet ihnen, eine 3rd-Party-Lösung über Radius die Gültigkeit von Anmeldedaten zu prüfen.

Schattten AD

Sie glauben gar nicht, wie viele Firmen einen zweiten AD-Forest für den Betrieb von externen Zugriffen betreiben. Oft werden dort "externe konten" angelegt, über die dann Lieferanten, Partner oder Kunden auf Dienste der Firma zugreifen, die ebenfalls in der DMZ angesiedelt sind.

Im gleichen Zug könnten Sie ja auch die ausgewählten internen Mitarbeiter in diese AD exportieren oder besser noch synchronisieren. Früher habe ich mit ADMT bei einem Kunden eine Lösung aufgebaut, bei dem ADMT per MSTask-Job regelmäßig eine Teilmenge der Anwender samt Kennwort in einen anderen Forest "geclont" hat, damit diese auch dort immer das gleiche Kennwort hatten. Es gibt sogar kommerzielle Tools für solche Koexistenz-Szenarien, z.B. beim Migrationen. Oder sie nutzen ein Provisioning, bei dem eine Kennwortänderung durch den Anwender in alle verbundenen Verzeichnisdienste geschrieben werden.

Selbstbau-URL/Deeplink

Diese Option eröffnet sich immer dann, wenn Sie das Zielsystem über einen Hyperlink ansprechend, den Sie selbst generieren können und direkt vom Zielsystem als Authentication verstanden wird. Stellen Sie sich vor, das System würde eine URL in der folgenden Form akzeptieren.

"https://portal.externsysten.tld/auth.php?userid=<username>%time=<aktuelle zeit>&sign=<signatur>"

Ihr lokales System generiert den Link mit Zeitstempel und Benutzerkennung und signiert diese Daten digital mit einem privaten Schlüssel. Der Zielserver bekommt den Public-Key, um die Signatur zu prüfen. Das ist dann eine Eigenbau-Version und ähnlich einer Kerberos-Anmeldung. Für die Sicherheit sind sie natürlich selbst verantwortlich.

Die meisten diese Protokolle funktionieren zwar über TCP/IP aber die wenigsten Administratoren würden diese Zugänge an den Verzeichnisdienst auch aus dem Internet erreichbar machen. Das Risiko einer DoS-Attacke oder Password-Spray-Attacke ist hoch. Eine Beschränkung auf eine Source-IP des Service wäre denkbar. Ein VPN zu verschiedenen Diensten hingegen weniger, da IP-Konflikte schwer zu vermeiden sind.

Risikobetrachtung

Ich kann verstehen, dass früher die ein oder andere Variante zum Einsatz gekommen ist. Heute würde solche Systeme aber nicht mehr neu aufbauen. Es gibt mit Kerberos und OAUTH/SAML bessere, bewährte und sichere Methoden. Speziell OAUTH/SAML ist bei vielen Administratoren aber auch Entwicklern und Produktplanern noch nicht angekommen oder verstanden worden. Starten Sie mit einer Risikoabschätzung der Umsetzung, die sie heute geplant haben. Prüfpunkte dabei sind:

  • SingleSignOn
    Nicht nur aus Gründen der Bequemlichkeit sollten Sie ein „Single Sign On“ anstreben. Die Eingabe von Kennworten oder wiederholte Authentifizierung durch den Anwender stört nicht nur den Arbeitsfluss sondern schwächt die Sicherheit, das jede Anmeldung ein Risiko für Phishing ist.
  • Userkennwort auf fremden Portal eingeben
    Ein Webservice kann ja gerne "SameSignOn" mit dem gleichen Usernamen und Kennwort erlauben. Was auf den ersten Blick schon mal besser ist als separate Zugangsdaten ist letztlich doch schlecht, denn Sie verleiten den Benutzer dazu sein Kennwort in einem Anmeldeformular einzugeben. Der Anbieter hat damit die Zugangsdaten selbst bei Nutzung von HTTPS damit Zugriff auf das Klartextkennwort.
  • Kennwortübertragung vom Portal zum OnPrem-Authenticator
    Der Service muss sich nun vergewissern, dass die erhaltenen Anmeldedaten korrekt sind. Auf dem Weg vom Service zu ihrem Authentication-Endpunkt hängt es auch wieder von der Sicherheit der Protokolle ab, ob ein Risiko besteht. Eine Anmeldung per HTTP ohne TLS mit Basic-Authentication ist unsicher. Auch SMB1 mit NTLM1 oder selbst Kerberos mit MD5 und RC4 würde ich heute nicht mehr zulassen. Denken Sie aber auch an Proxy-Systeme es. Alle Teilstrecken müssen sicher sein, da die Credentials übertragen werden und das haben sie nicht immer unter Kontrolle.
  • Kein self managed MFA
    Stellen sie sich vor, sie sichern ihr Netzwerk und alle Zugänge per MFA ab. Wir soll da der Service mit seinen Daten die Anmeldung prüfen? Darauf hat nicht jeder Anbieter eine Antwort. Natürlich kann er selnst auch eine MFA-Lösung anbieten aber dann haben Sie wieder mehrere Geräte oder Einträge im Authenticator und beim Gerätewechsel muss alles wieder mehrfacht eingerichtet werden.
  • DMZ-Verbindung
    Die Verbindung vom Service zum Authentication Services muss identifiziert und verschlüsselt erfolgen. Ein VPN ist denkbar aber aufgrund IP-Subnetzproblemen vielleicht nicht immer einfach umzusetzen. Eine https-Verbindung/Websockets könnte eine Abhilfe sein. Prüfen Sie, welche Anforderungen der Service stellt.
  • DoS gegen Kennworte
    Wenn ein Anbieter im Internet nicht nur für Sie sondern viele Kunden eine gemeinsame Plattform betreibt, dann können Sie den Zugang zu dem System nicht über ihre eigene Firewall beschränken. Ein Angreifer kann also mit Wissen von Benutzernamen einfach mal Kennwort ausprobieren, die er "gefunden" hat. Vielleicht passen Sie ja. Sie sehen auf dem Anmeldeserver jeden Versuch und können bei Überschreitungen natürlich das Konto sperren. Nur kann dann der Anwender auch nicht mehr arbeiten.

Ich bin nicht sicher, ob ich alle Aspekte aufgeführt habe. Skizzieren Sie ihre geplante Lösung und überlegen Sie sich, was der "Bad Guy" machen könnte. Alles was theoretisch möglich ist, wird irgendwann auch passieren. Es ist nur eine Frage der Zeit

SAML/OAUTH und Kerberos sind besser

Kommen wir wieder auf den Abschnitt "Cloud und Internet" zurück. Ich bin davon überzeugt, dass heutige moderne Lösungen entweder Kerberos (am besten mit AES256) oder SAML/OAUTH nutzen. Die beiden Verfahren unterscheiden sich zwar in den Protokollen und Datenstrukturen aber sind in der Funktionsweise doch ähnlich.

  • Authentication Server pro Domain/Realm
    Jeder Benutzer hat zu seiner "Domain" einen Token Server. Im LAN ist das das Kerberos Distribution Center (KDC) und für externe Dienste dann ein SAML/ADFS-Service. Diesen Dienst können Sie selbst betreiben oder sie nutzen den Service von AzureAD/EntraID, wenn Sie eh eine Anbindung an Microsoft 365 haben.
  • Trust
    Ein interne Memberserver vertraut durch seine Domainmitgliedschaft dem KDC und über entsprechende Schlüssel kann der KDC die Tickets für die Dienste digital signieren und verschlüsseln. Im Token steht dann der Benutzer und seine Gruppen drin.
    bei SAML/OAUTH ist es vergleichbar. Der Benutzer erhält vom SAML-Server ein digital signiertes Ticket, welches seine Identität und Berechtigungen für den anfordernden Dient enthält. Dazu muss der SAML-Administrator natürlich einrichten, für welche Dienste ein Ticket ausgestellt wird und der Dienst muss dem ausstellenden SAML-Server vertrauen. Das könnten wir fast mit einem Domaintrust vergleichen.
  • Verifikation
    Der Client muss ich natürlich "sicher" an seinem Tokenserver anmelden. Das passiert in der Regel über die lokale Anmeldung am PC, die durch den Firmenadministrator entsprechend sicher gestaltet werden kann. Danach kann der Client immer wieder Tickets für die Dienste anfordern. Die Anmeldung am SAML-Server der Cloud kann z.B.: über lokal ausgestellte Kerberos-Tickets erfolgen.
  • Authorization
    Der Dienst bekommt dann ein Ticket, welches vom Aussteller digital signiert und damit prüfbar und unveränderlich ist. Der empfangene Server muss dann einfach nur die Daten aus dem Ticket nutzen, und die Daten entsprechend der Berechtigungen ausliefern. Eine Rückfrage zum ausstellenden Token-Server ist nicht erforderlich

Diese Beschreibung ist nun technisch nicht ganz korrekt sondern vereinfacht. Aber ich hoffe Sie nehmen mit, dass Kerberos und SAML heute das Mittel der Wahl sind und irgendwelche Bastellösungen mit LDAP, SMB, HTTP o.ä. möglichst bald ersetzt und bitte nicht mehr neu aufgebaut werden sollen.

Weitere Links