Du kommst hier nicht rein! Oder doch?

Hallo!

Wer kennt das nicht: Man will in einen Club hinein und der Türsteher sagt einem „Du kommst hier nicht rein“. Der Türsteher weiß das einfach so, er macht seine eigenen Regeln, die er auch keinem mitteilt. Für ein Authentifizierungs-System ist es da schon schwieriger, vernünftig verwaltbare Regeln aufzustellen.

Euch ist sicher eine Reihe von Optionen bekannt, wie Ihr Benutzer in der Anmeldung an bestimmte Workstations oder Server binden könnt:

1. „UserWorkstations“ Attribut des Benutzers (in den Benutzereigenschaften Konto der Knopf „Anmelden an“)
2. Benutzerrechte zur „Anmeldung über das Netzwerk“ oder „interaktiv“, gesetzt durch Gruppenrichtlinien aus der Domäne oder lokal.
3. Der Benutzer kann einen Server verwenden über ein Rollensystem, das auch aus den Active Directory Gruppen gefüttert werden kann.

Diese Methoden werden meist innerhalb eines Forests angewendet. Manchen Kunden wird die Vergabe dieser Rechte allerdings zu kleinteilig. Besonders bei Punkt 2 ist oft „Jeder“ oder „Authentifizierte Benutzer“ eingetragen. Dadurch wird die Verwaltung von „viele dürfen, wenige dürfen nicht“ erschwert, da man sich um den Regelfall kümmern muss, nicht um die Ausnahme.

Vor diese Optionen gestellt, hat ein Kunde neulich den Ansatz zur Diskussion gestellt, solche Benutzer (hier externe Mitarbeiter oder Praktikanten) in einen eigenen Forest „externe.contoso.com“ auszulagern. Seine Idee war, dass man mit Hilfe eines Forest Trusts und selektiver Authentifizierung den Benutzern (bzw. den passenden Gruppen aus dem Forest des Externen-Forests) wieder die Ausnahme verwalten kann und dadurch effektiver wird.

Eine gute Dokumentation zu selektiver Authentifizierung findet Ihr auf Technet: https://technet.microsoft.com/en-us/library/cc787646.aspx

Das Szenario des Kunden hat nun als Authentifizierungsmethode NTLM vorgesehen, da die Benutzer immer aus einem externen Netzwerk kommen und sie keinen eigenen Zugang zu Domain Controllern haben. Der Kunde war sich nun nicht sicher, ob die Einstellungen zur selektiven Authentifizierung auch für NTLM gelten.

Das obige Dokument macht jedoch keine Unterscheidung zwischen NTLM und Kerberos. In dem Dokument werden die Regeln der Anwendung besprochen, und dort werden auch „external Trusts“ erwähnt, und diese verwenden nur NTLM: https://technet.microsoft.com/en-us/library/cc755321.aspx

Soweit, so gut, es funktioniert also mit NTLM. Als ich diese Ergebnisse mit dem Kunden besprochen habe, fiel mir ein, dass ein wichtiges Detail die Anmeldung mit NTLM oder Kerberos unterscheidet:

• NTLM kann nur gegen die Maschine authentifizieren.
• Kerberos kann gegen die Maschine authentifizieren, aber auch gegen ein Server-Benutzer-Konto, das auf der Maschine läuft, zum Beispiel einer SQL-Datenbank auf einem Cluster oder eine Web Site auf mehreren Servern. Es kommt darauf an, wo der SPN registriert ist.

Im Szenario des Kunden ging es nun um einen Zugriff auf eine Web Site. Deswegen war interessant, wie die Rechte angewendet werden und was ausschlaggebend ist, wenn die Web Site auf mehreren Servern unter einem Benutzerkonto läuft.

Ich habe zu diesem Detail keine Dokumentation gefunden, deshalb habe ich die Konfiguration einfach einmal ausprobiert. Im Gegensatz zum Plan des Kunden habe ich einen „externen Trust“ zwischen meinen Forests verwendet. Das war für mich der einfachste Weg sicher zu stellen, dass NTLM verwendet wird. Aus anderen Tests wusste ich bereits, dass für den Kunden ein Fallback von Kerberos auf NTLM möglich sein würde.

Das waren die Ergebnisse:

Web Site Konto	Authentifizierung erlaubt auf	Zugriff
Netzwerkdienst	Computer	möglich
Netzwerkdienst	Benutzer	verweigert
Benutzer	Computer	möglich
Benutzer	Benutzer	verweigert
Netzwerkdienst	Beide	möglich
Benutzer	Beide	möglich

Es ist zu sehen, dass nur die Rechte auf das Computerkonto bestimmen, ob die Anmeldung über NTLM erlaubt ist oder nicht. Die Granularität von NTLM wird also auch bei selektiver Authentifizierung sichtbar. Insgesamt ist selektive Authentifizierung eine interessante Erweiterung der Authentifizierungs-Optionen. Es ist fast schon Schade, dass man dafür einen zweiten Forest braucht.

Die Ergebnisse meiner Tests werden bald auch auf der Technet zu sehen sein. Den Lesern dieses Blogs stehen sie nun vorab exklusiv zur Verfügung.

Zum Schluss noch ein eher philosophischer Einwurf. Zu dem Zeitpunkt, an dem „Allowed to authenticate“ geprüft wird, ist der Benutzer bereits authentifiziert. Das Feature müsste also korrekterweise selektive Autorisierung heißen, genau so wie die Anmelderechte schon zur Autorisierung gehören. Im echten Leben müsste sich der Türsteher von jedem Besucher den Ausweis zeigen lassen, bevor er den Daumen hebt oder senkt. Aber wie schon gesagt, er braucht ja seine Entscheidungen nicht transparent machen oder begründen.

Schöne Grüße

Herbert