Logos von UCS und Windows mit verbindenden Pfeilen

Eine Vertrauensstellung einzurichten bedeutet, Benutzern einer Domäne Zugriff auf die Ressourcen einer anderen zu geben. Dies kann in manchen Situationen den Handlungsspielraum erweitern. In dem nun beschriebenen Beispiel werde ich mich konkret auf das Zusammenspiel zwischen Samba in UCS und Microsoft Windows beziehen und dabei im Einzelnen erklären, wie eine sogenannte Vertrauensstellung dafür konfiguriert werden kann und wie der aktuelle Stand der Implementierung ist.
Mit UCS 4.4-0 werden unidirektionale, von Windows ausgehende Vertrauensstellungen unterstützt, d.h. die Richtung „Windows vertraut UCS“. In dieser Konfiguration können sich Benutzer aus einer UCS Samba/AD Domäne z.B. an einer Microsoft Active Directory Domäne authentifizieren und dort Ressourcen nutzen. Dies stellt in gewisser Weise eine Alternative zum Betrieb von UCS als Mitglied einer AD-Domäne dar. Weitere Informationen zur Konfiguration liefert der entsprechende Abschnitt im UCS Handbuch für Administratoren. Darüber hinaus haben wir auf unserem Blog grundlegende Informationen zum Thema „Zentrale Domänenverwaltung mit Active Directory“ für Sie bereitgestellt.

Vertrauensstellungen in Windows: Option „External Trust“

Zusätzlich zu Vertrauensstellungen des Typs „external“ zwischen Domänen bietet Active Directory auch solche des Typs „forest“. In Kontext dieses Blogartikels geht es um Vertauensstellungen zwischen zwei Domänen, nicht zwischen oder innerhalb von Forests. Weitere Details zu diesem Thema erklärt die Microsoft Dokumentation.

Uni- und Bidirektionale Vertrauensstellung

Eine Vertrauensstellung zwischen zwei Domänen kann unidirektional oder bidirektional konfiguriert sein. Zur Einrichtung einer unidirektionalen Vertrauensstellung, die von einer “Resource Domain” (auch “trusting domain”) ausgeht und einer “Account Domain” (auch “trusted domain”) entgegengebracht wird, muss ein sogenanntes “Trust Domain Object” (TDO) in der Resource Domain angelegt werden. Dieses ist ein spezielles Authentifizierungskonto, das in der Resource Domain angelegt wird und auf das ein Passwort gesetzt ist, welches bei der Einrichtung in der “Account Domain” im Klartext hinterlegt wird. In Samba/AD Domänen ist diese Konstellation sehr einfach an der Kommandozeile über das Werkzeug samba-tool einrichtbar, egal ob unidirektional oder bidirektional.
Voraussetzung dafür ist allerdings, dass die DNS-Auflösung über beide Domänen funktioniert. Zumindest die FQDN der Domänencontroller der jeweils anderen Domäne müssen auflösbar sein, damit die Kommunikation zwischen den Domänen funktioniert. In beiden Domänen richtet man dazu am besten ein DNS Forwarding ein.

Beispiel für eine bidirektionale Vertrauensstellung

Für das folgende Beispiel sei angenommen, dass der UCS DC Master „master.ucsdom.example“ die IP-Adresse 10.200.8.10 hat und dass z. B. der native Microsoft Active Directory DC „dc1.addom.example“ die IP 10.200.8.20 hat.

UCS-Seite:
root@master:~# cat >> /etc/bind/local.conf.samba4 <<%EOR

zone "addom.example" {
type forward;
forwarders { 10.200.8.20; };
};
%EOR
root@master:~# service bind9 restart

## Checks:
root@master:~# host dc1.addom.example
dc1.addom.example has address 10.200.8.20
Zusätzlich kann es sinnvoll sein, einen statischen Eintrag in der /etc/hosts anzulegen:
root@master:~# ucr set hosts/static/10.200.8.20=master.ucsdom.example

AD-Seite:

Auf dem Windows AD DC kann über die DNS-Server Konsole eine sogenannte „Bedingte Weiterleitung“ („Conditional Forwarding“) für die UCS Domäne eingerichtet werden. Nach dieser Vorarbeit kann die Vertrauensstellung an sich direkt von der Kommandozeile des UCS Samba/AD DCs eingerichtet werden.
Die folgenden Schritte richten z. B. eine bidirektionale Vertrauensstellung vom Typ „external“ ein:

root@master:~# samba-tool domain trust create addom.example \
-k no -UADDOM\\Administrator%ADAdminPassword \
--type=external
## Checks:
root@master10:~# samba-tool domain trust list
Type[External] Transitive[No] Direction[BOTH] Name[addom.example]
root@master10:~# wbinfo --ping-dc –domain=addom.example
checking the NETLOGON for domain[ADDOM] dc connection to "dc1.addom.example" succeeded
root@master10:~# wbinfo --check-secret –domain=addom.example
checking the trust secret for domain ADDOM via RPC calls succeeded

Nach der Einrichtung sollte sich ein UCS-Benutzer an Systemen der Windows Active Directory Domäne anmelden können. Als Login-Name muss dabei entweder das Format UCSDOM\username oder der Kerberos-Prinzipal in der Notation username@ucsdom.example angegeben werden.

Weitere Optionen des Samba-Tools

Das Samba-Tool bietet noch einige weitere Möglichkeiten, z. B. die Validierung der Vertrauensstellung (samba-tool domain trust validate) oder die Einrichtung einer unidirektionalen Vertrauensstellung in beliebiger Richtung.

Einschränkungen der aktuellen Samba-Implementierung

Die aktuelle Samba-Implementierung genügt jedoch leider noch nicht vollständig den Kriterien, die native Windows-Systeme bieten, z.B. das SID filtering, wodurch es erforderlich ist, dass die vertrauten Domänen im gleichen administrativen Vertrauenskontext stehen (weitere Details liefern beispielsweise das die Microsoft-Dokumentation zu SID Filtering and Claims Transformation, dem Microsoft Secruity Bulletin MS02-001  oder auch der Präsentation „Trusted Domain Support as Active Directory Domain Controller“ von Stefan Metzmacher (Samba).
Mit dem aktuellen Stand der Implementation in UCS ist es für Benutzer einer UCS-Domäne möglich, Ressourcen in einer vertrauten Microsoft Active Directory Domäne zu nutzen, z.B. sich an einem Desktop einzuloggen, der Teil der nativen MS AD-Domäne ist.
Zusätzlich sollte auch die Authentifizierung von Benutzern aus der Microsoft Active Directory Domäne an einem UCS Samba/AD DC grundsätzlich möglich sein. Für den produktiven Praxiseinsatz ist hier allerdings zusätzlich auch das sogenannte Identity Mapping, d. h. die Zuordnung von SIDs zu Posix IDs (UID/GID) notwendig, das hier jedoch erst einmal nicht weiter Thema sein soll. Nur so viel: Jeder UCS-Server nimmt ohne weitere Konfiguration sein eigenes individuelles ID-Mapping vor. D.h. wenn sich ein externer Bentzer anmeldet, ordnet der lokale Winbind-Dienst diesem Benutzer eine POSIX-uid (& POSIX-gid) zu. Das kann zu unerwünschte Effekten führen, wenn ein solcher Benutzer Dateien in einem Dateisystem ablegen kann und dies zu einem späteren Zeitpunkt auf einem anderen Server gemountet wird.

Sachdienliche Hinweise

Eine Eigenheit von Vertrauensstellungen ist, dass Benutzer in der jeweiligen Fremddomäne den Namen der Domäne als Prefix erhalten. Das ist notwendig, um Namenskollisionen zu vermeiden. Bei Windows sollte das transparent geschehen; unter Linux folgen die Benutzernamen der Gäste dann dem Schema „OTHERDOMAIN+username“. An Microsoft Windows clients kann man sich entweder per „OTHERDOMAIN\username“ oder mit dem Kerberos-User-Principal-Name username@OTHERREALM anmelden.

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich

Arvid Requate ist Open Source Software Engineer bei Univention und hauptsächlich im Bereich Directory Services, Authentifikation und Samba tätig.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.