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.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 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!

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich
Arvid Requate

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!

    Antworten
  2. Ja das sollte möglich sein, es gibt aber gewisse Hinweise dabei zu beachten. Vorab: Damit die Authentifizierung an UCS-Diensten gelingt, die PAM verwenden, muss die UCR-Variable auth/methods um die Methode „winbind“ erweitert werden.

    -> Benutzernamen: 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“.

    -> Generell empfehlen wir hier die Verwendung von UCS Samba/AD DCs (Slave, Backup, Master). Falls Sie dennoch Memberserver einsetzen: Das Verhalten von UCS-Memberservern ist hier aktuell noch nicht getestet worden, als Grundlage für Experimente kann der entsprechende Abschnitt aus den 3.x Handbüchern dienen.

    -> ID-Mapping und Dateiablagen: jeder Server nimmt ohne weitere Konfiguration sein eigenes individuelles ID-Mapping vor. D.h. wenn sich ein „Gast“ anmeldet, dann vergibt der lokale Winbind-Dienst ihm eine POSIX-uid (& POSIX-gid). Das kann unerwünschte Effekte geben, wenn der Gast Dateien in einem Dateisystem ablegen kann und dies zu einem späteren Zeitpunkt auf einem anderen Server gemountet wird.

    Sie merken sicher, dass es hier schnell sehr in die Details der konkreten Umgebung geht. Daher empfehlen wir, zu diesem Thema die gängigen Kommunikationskanäle wie z.B. das Forum zu verwenden.

    Antworten
  3. Hallo,
    wir haben das Szenario eben nachgebaut.
    Windows: ADC 2008R2 + Windows Client
    UCS: UCS Server + Windows Client

    Ich kann in der Windowsdomäne UCS Benutzern Dateirechte auf meinem Client geben.
    In der UCS Domäne kann ich leider keine Dateirechte vergeben, da mir die Windowsdomäne auf meinem Client garnicht zur Auswahl steht.
    Die Validierung ist auf beiden Seiten war erfolgreich.
    DNS funtkioniert problemlos.
    Woran kann das liegen?

    Für eine Antwort wären wir sehr dankbar.

    Antworten
  4. Hallo,
    danke für den Kommentar, wir werden das von Ihnen berichtete Verhalten versuchen nachzustellen. Im Moment sind wir mit der Entwicklung von UCS 4.2 ausgelastet, daher wird eine konkrete Hilfestellung leider ein wenig dauern. Falls Sie Log-Dateien haben (/var/log/samba/*) dann würde ich Sie bitten, diese mit Ihrem kurzen Problembericht an feedback@univention.de zu schicken. Darüber können wir dann auch gezielt antworten.

    Antworten
  5. Ganz großer Fauxpas in der Beschreibung!
    Niemals *.local für DNS-Suffix verwenden. Der ist für Multicast-DNS-Domänen vorgesehen, siehe RfC6762. Das gibt unter iOS, Android und Linux große Probleme in der Namensauflösung! (Es muss „mDNS“ in resolv.conf rausgenommen werden.)
    Diese Fehler wird in Microsoft-Dokumenten seit Jahren begangen!

    Antworten
  6. 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.

    Antworten

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