Logo Samba, Sprechblase "what do you think"

In diesem Artikel möchte ich alle IT-Administratoren und IT-Interessierten unter Ihnen über die Möglichkeiten von Vertrauensstellungen zwischen zwei Domänen (UCS Samba/AD und Microsoft AD) informieren. Gerne würde ich außerdem erfahren, was Ihre Meinung zu diesem Thema ist und würde mich über Feedback sehr freuen.

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.

Vertrauensstellungen in Windows: Option „External Trust“

Schon Windows/NT Domänen haben die Option einer Vertrauensstellung – auch “external Trust” genannt -, geboten und das Samba-Projekt unterstützte sie dementsprechend in der 3.x Serie der Software.

Zusätzlich zu Vertrauensstellungen des Typs „external“ kennen Active Directory Domänen auch solche des Typs „forest“. Für Forest Trust ist wie immer bei Kerberos die Synchronisierung der Systemzeiten zwischen beiden Domänen essenziell.

Vertrauensstellungen in Samba 4

In Samba/AD Domänen, d. h. ab Samba 4.0 wurden Vertrauensstellungen dann leider erst einmal nicht mehr unterstützt, weil das Projekt zunächst Priorität auf die Stabilisierung der neuen Active Directory-bezogenen Komponenten und im weiteren Verlauf auf die neuen Protokollvarianten SMB2 und SMB3 legte. Mit der Vereinigung der beiden Winbind-Implementierungen aus Samba 3.x und Samba 4.x, die auch von Univention unterstützt wurde, wurde es prinzipiell erstmals möglich, dass Vertrauensstellungen auch mit Samba 4.3 eingerichtet werden konnten. Erste Tests mit Samba 4.3.7 zeigten allerdings Anfang 2016, dass die Stabilität der Vertrauensstellungen noch keinen produktiven Einsatz ermöglicht. Mit Samba 4.5.1 ist dieses Problem erfreulicherweise behoben.

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 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.local“ die IP-Adresse 10.200.8.10 hat und dass z. B. der native Microsoft Active Directory DC „dc1.addom.local“ die IP 10.200.8.20 hat.

UCS Seite:

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

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

## Checks:
root@master:~# host dc1.addom.local
dc1.addom.local 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.local

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.local \
-k no -UADDOM\\Administrator%ADAdminPassword \
--type=external
## Checks:
root@master10:~# samba-tool domain trust list
Type[External] Transitive[No] Direction[BOTH] Name[addom.local]
root@master10:~# wbinfo --ping-dc –domain=addom.local
checking the NETLOGON for domain[ADDOM] dc connection to "dc1.addom.local" succeeded
root@master10:~# wbinfo --check-secret –domain=addom.local
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.local 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 in manchen Situationen erwarten, denn nach Konfiguration einer Vertrauensstellung zwischen einer UCS Samba/AD Domäne und z.B. einer nativen Microsoft Active Directory Domäne werten Windows-Clients, die in die UCS Domäne gejoined sind, z.B. leider Gruppenrichtlinien nicht mehr aus. Erste Schritte zur Analyse der Netzwerktraces lieferten leider bisher noch keinen Aufschluss über die Ursache dieser Einschränkung.

Auch die Authentifizierung von Benutzern aus der Microsoft Active Directory Domäne an einem UCS Samba/AD DC sollte dann 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) wichtig, das hier jedoch erst einmal nicht weiter Thema sein soll.

Ausblick UCS Services für Windows

Es wird deutlich, dass es im Themenbereich UCS Services für Windows spannend bleibt. Der Fokus der verschiedenen Akteure des Samba-Teams verschiebt sich stetig über Releases hinweg. Neben den beiden Kern-Themen Active Directory Domänendienste auf der einen Seite und den SMB-Protokollerweiterungen auf der anderen Seite, erfahren spezielle, in diesem Fall domänenübergreifende Features wie dieses weniger Aufmerksamkeit. Auch Sicherheitsaspekte wie SID-Filterung stehen hier noch auf der TODO-Liste des Samba-Teams.

Univention wird sowohl diese Entwicklung aktiv begleiten als auch das Interesse unserer Kunden an Themen wie diesen aufmerksam beobachten. Unser Ziel ist schließlich, dass alle Informationstechnologien einfach miteinander kombinierbar sind.

Hinterlassen Sie gerne einen Kommentar/Feedback zu dieser Thematik!

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!

Kommentare

  1. Danke für den sehr informativen Artikel.
    Hierzu kam mir in der Vergangenheit schon etwas, wobei die Frage ist, ob da eine Samba-Vertrauensstellung im UCS sinnvoll ist, oder ob der UCS hierfür andere „Bordmittel“ für Vertrauensstellungen zwischen UCS-Domänen hat…
    Hintergrund: wir haben im Verein eine UCS-Domäne ads.schaffenburg.org sowie eine Testdomäne, welche für Testmaschinen und demnächst auch für Gastaccounts – primär für LDAP-Auth an Webseiten – genutzt werden soll (ebenfalls UCS).
    Die Maschinen sind im Serverbereich UCS- und Debian-Maschinen, im Clientbereich diverse Linux-Distributionen sowie Windows-Maschinen.
    Die Frage wäre jetzt – gibt es eine Möglichkeit, hier eine Vertrauensstellung aufzubauen, mit der ich hauptsächlich die Möglichkeit habe, Mitgliedern aus der Produktiv-Domäne die Authentifizierung an Testmaschinen zu ermöglichen, außerdem Mitgliedern aus beiden Domänen den Zugriff auf Ressourcen (Drucker, Ordner mit Bildern von Veranstaltungen etc.) zu erlauben und möglicherweise auch an einzelnen Rechnern explizit die Anmeldung aus der Gastdomäne freizuschalten?
    Danke für Antworten!

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