Der primäre Domänencontroller oder PDC spielt eine wichtige Rolle in MS Windows NT4. In der Windows 200x-Domänenverwaltungsarchitektur wird diese Rolle von Domänencontrollern übernommen. Die „Folklore“ schreibt vor, dass dies wegen seiner Rolle im MS Windows-Netzwerk der stärkste und schnellste Rechner im Netz sein sollte. So seltsam das an dieser Stelle klingen mag, der Wunsch nach guter allgemeiner Netzwerk-Performance erfordert zwingend, dass die gesamte Infrastruktur ausgewogen gestaltet wird. Es ist ratsam, mehr in Stand-alone-(Domänen-Mitglieds-)Server zu investieren als in die DCs.

Im Falle von MS Windows NT4-Domänen ist es der PDC, der eine neue Datenbank zur Domänen-Verwaltungs initiiert. Diese bildet einen Teil der Windows-Registrierung namens Security Account Manager (SAM). Sie spielt eine Schlüsselrolle bei der NT4-artigen Domänen-Benutzer-Authentifizierung und in der Synchronisation der Domänen-Authentifizierungsdatenbank mit Backup-Domänencontrollern.

In MS Windows 200x-Server-basierten Active-Directory-Domänen initiiert ein Domänencontroller eine mögliche Hierarchie von Domänencontrollern, von denen jeder seinen eigenen delegierten Verwaltungsbereich erhält. Der Master-Domänencontroller hat die Möglichkeit, jeden „downstream controller“ zu übergehen, jedoch hat ein „downline controller“ nur die Kontrolle über seine „downline“. Mit Samba-3 kann diese Funktionalität durch Verwendung eines Konten-Backends auf LDAP-Basis implementiert werden.

Neu in Samba-3 ist die mögliche Verwendung einer Backend-Datenbank, die dieselben Daten enthält wie eine NT4-artige SAM-Datenbank (eines der Registrierungs-Files)^[1].

Der Backup-Domänencontroller oder BDC spielt eine Schlüsselrolle bei der Beantwortung von Netzwerk-Authentifizierungsanfragen. Der BDC ist darauf ausgerichtet, Logon-Anfragen vor dem PDC zu beantworten. In einem Netzwerk-Segment, das sowohl einen BDC als auch einen PDC beinhaltet, wird der BDC meist die Netzwerk-Logon-Anfragen bedienen. Der PDC wird diese dann beantworten, wenn der BDC überlastet ist. Ein BDC kann zum PDC ernannt werden. Wenn der PDC online ist, wenn der BDC zum PDC ernannt wird, wird der vorige PDC automatisch zum BDC zurückgestuft. Mit Samba-3 ist dieser Vorgang nicht automatisch; der PDC und der BDC müssen von Hand konfiguriert werden.

Bei der Installation von NT 4 wird die Entscheidung darüber getroffen, welcher Art von Maschine der Server angehören soll. Es ist möglich, einen BDC zu einem PDC zu ernennen und umgekehrt. Die einzige Möglichkeit, einen DC in einen Domänen-Mitgliedsserver oder einen Stand-alone-Server umzuwandeln, ist, ihn neu zu installieren. Die Wahlmöglichkeiten bei der Installation sind:

Bei der Verwendung von MS Windows 2000 wird die Konfiguration der Domänen-Verwaltung nach der Installation des Servers vorgenommen. Samba-3 kann als vollwertiges Mitglied einer Windows-200x-Server-Active-Directory-Domäne arbeiten.

Neu in Samba-3 ist die Fähigkeit, als vollwertiger MS-Windows-NT4-Domänencontroller zu arbeiten, mit Ausnahme der SAM-Replikationskomponenten. Bitte beachten Sie, dass Samba-3 auch die MS Windows 200x-Domänen-Verwaltungsprotokolle unterstützt.

Zum jetzigen Zeitpunkt ist jegliches Anzeichen dafür, dass Samba-3 als Domänencontroller im nativen ADS-Modus arbeiten kann, begrenzt und völlig experimenteller Natur. Diese Funktionalität sollte nicht verwendet werden, bis das Samba-Team formal die Unterstützung dafür anbietet. Sobald dies erfolgt, wird die Dokumentation revidiert werden, um alle Konfigurations- und Verwaltungsanforderungen vollständig widerzuspiegeln. Samba kann als NT4-DC in einer Windows 2000/XP-Umgebung arbeiten. Jedoch gibt es einige Kompromisse:

Es gibt zwei Arten, wie MS Windows-Maschinen miteinander, mit anderen Servern und DCs zusammenarbeiten können: entweder als Stand-alone-Systeme, üblicherweise als Workgroup-Mitglieder bezeichnet, oder als vollwertige Teilnehmer eines Sicherheitssystems, die in der Regel als Domain-Mitglieder bezeichnet werden.

Beachten Sie, dass eine Workgroup-Mitgliedschaft keine spezielle Konfiguration erfordert, außer dass die Maschine so konfiguriert werden muss, dass die Netzwerk-Konfiguration einen gebräuchlichen Namen für den Workgroup-Eintrag enthält. Oft wird hierfür der Name WORKGROUP verwendet. Bei dieser Art der Konfiguration gibt es keine Maschinen-Vertrauenskonten und jegliches Konzept von Mitgliedschaft ist darauf beschränkt, dass alle in der Netzwerkumgebung auftauchenden Maschinen als logische Gruppe erscheinen. Zur Wiederholung und Klärung: Der Workgroup-Modus beinhaltet keine Maschinen-Sicherheitskonten.

Rechner, die Domänen-Mitglied sind, haben ein Maschinen-Konto in der Domänen-Konten-Datenbank. Eine spezielle Prozedur muss auf jeder Maschine ausgeführt werden, um eine Domänen-Mitgliedschaft zu erwerben. Diese Prozedur, die nur vom lokalen Administrator-Konto aus erfolgen kann, legt das Domänen-Maschinen-Konto an (falls es noch nicht existiert), und initialisiert dieses Konto. Wenn der Client sich erstmals in der Domäne anmeldet, wird ein Maschinen-Passwort-Wechsel ausgelöst.

Folgendes ist nötig, um Samba-3 als einen MS Windows NT4-artigen PDC für MS-Windows-NT4/200x/XP-Clients zu konfigurieren:

Die folgenden Voraussetzungen sind erforderlich, um MS Windows 9x/Me-Clients bedienen zu können:

Ein Domänencontroller ist ein SMB/CIFS-Server, der:

Es ist ziemlich einfach, Samba so zu konfigurieren, dass er all dies zur Verfügung stellt. Jeder Samba-Domänencontroller muss den NETLOGON-Dienst anbieten, der von Samba als domain logons-Funktionalität bezeichnet wird (nach dem Parameter in der smb.conf-Datei). Außerdem muss ein Server in einer Samba-3-Domäne sich selbst als Domain Master Browser bekannt geben ^[3]. Dies veranlasst den PDC dazu, einen domänen-spezifischen NetBIOS-Namen zu beanspruchen, der ihn als Domain Master Browser für die gegebene Domäne/Workgroup identifiziert. Lokale Master Browser in derselben Domäne/Workgroup und in broadcast-isolierten Subnetzen erfragen dann eine komplette Kopie der „browse list“ für das gesamte WAN. Browser-Clients kontaktieren daraufhin ihren lokalen Master Browser und erhalten die „browse list“ der gesamten Domäne statt nur der Liste für ihr broadcast-isoliertes Subnetz.

Alle Domänencontroller müssen den netlogon-Dienst ausführen (domain logons in Samba). Ein Domänencontroller muss mit domain master = Yes konfiguriert werden (der PDC); auf allen BDCs muss domain master = No gesetzt werden.

Wir müssen noch ein paar Anmerkungen machen, um einige offene Fragen zu klären. Es gab viele Diskussionen darüber, ob es richtig sei, Samba als Domänencontroller in anderen Sicherheitsmodi als „user“ zu konfigurieren. Der einzige Modus, der aus technischen Gründen nicht funktionieren wird, ist der Modus der Freigaben-Sicherheit. Domänen- und Server-Modus-Sicherheit sind in Wirklichkeit einfach nur Abwandlungen der SMB-Benutzer-Ebenen-Sicherheit.

Tatsächlich hängt dieses Thema auch eng mit der Debatte zusammen, ob Samba der Domänen-Master-Browser für seine Domäne sein muss, wenn er als DC arbeitet. Auch wenn es technisch möglich sein mag, einen Server so zu konfigurieren (schließlich sind Browsing und Domänenanmeldungen zwei völlig verschiedene Funktionen), ist es doch keine gute Idee, dies zu tun. Sie sollten sich daran erinnern, dass der DC den DOMAIN<#1b> NetBIOS-Namen registrieren muss. Dies ist der Name, der von den Windows-Clients verwendet wird, um den DC ausfindig zu machen. Windows-Clients unterscheiden nicht zwischen dem DC und dem DMB. (Ein DMB ist ein Domänen-Master-Browser siehe ???.) Aus diesem Grunde ist es ratsam, den Samba DC auch als DMB zu konfigurieren.

Kommen wir nun zu dem Thema zurück, wie man einen Samba-DC so konfiguriert, dass er einen Modus verwendet, der von security = user abweicht. Wenn ein Samba-Rechner so konfiguriert ist, dass er einen anderen SMB-Server oder -DC verwendet, um Benutzeranmeldungen zu prüfen, dann ist es ein Faktum, dass irgendeine andere Maschine in diesem Netz (der password server) mehr über den Benutzer weiß, als der Samba-Rechner. In ungefähr 99% der Fälle ist dieser Rechner ein DC. Um nun im Domänen-Sicherheitsmodus zu arbeiten, ist es notwendig, den workgroup-Parameter auf den Namen der Windows NT-Domäne zu setzen (die bereits einen DC hat). Wenn die Domäne noch keinen DC hat, haben Sie noch keine Domäne.

Das Konfigurieren von Samba als DC für eine Domäne, die (per Definition) bereits einen PDC hat, bedeutet, sich seine Probleme selbst heraufzubeschwören. Deshalb sollten Sie den Samba-DC immer als DMB für seine Domäne konfigurieren und security = user setzen. Dies ist der einzige offiziell unterstützte Arbeitsmodus.

Ein Maschinenkonto, üblicherweise in /etc/passwd gespeichert, hat die Form des Maschinennamens, dem ein „$“ folgt. FreeBSD (und andere BSD-Systeme) legen keinen Benutzer mit einem „$“ im Namen an.

Das Problem liegt nur im Programm, das zum Anlegen des Eintrags verwendet wird. Einmal angelegt, funktioniert es perfekt. Legen Sie einen Benutzer ohne das „$“ an. Benutzen Sie dann den Befehl vipw, um den Eintrag zu editieren bzw. das „$“ hinzuzufügen. Oder legen Sie den ganzen Eintrag mit vipw an, wenn Sie wollen; stellen Sie sicher, dass Sie eine einmalige Benutzer-ID (UID) verwenden.

„Ich bekomme "You already have a connection to the Domain...." oder "Cannot join domain, the credentials supplied conflict with an existing set...", wenn ich ein Maschinen-Vertrauenskonto anlegen will.“

Dies passiert, wenn Sie versuchen, ein Maschinen-Vertrauenskonto von der betreffenden Maschine aus anzulegen, und bereits eine bestehende Verbindung (wie z.B. ein verbundenes Netzlaufwerk) zu einer Freigabe (oder zu IPC$) auf dem Samba-PDC haben. Der folgende Befehl trennt alle bestehenden Netzlaufwerksverbindungen:

C:\> net use * /d

Wenn die Maschine bereits ein „Mitglied einer Arbeitsgruppe“ ist, die denselben Namen hat wie die Domäne, der Sie sich anschließen wollen (schlechte Idee), werden Sie dieselbe Meldung erhalten. Ändern Sie den Namen der Arbeitsgruppe in etwas anderes, egal was, rebooten Sie, und versuchen Sie es erneut.

„Ich schloss mich erfolgreich der Domäne an, aber nach dem Upgrade auf eine neue Samba-Release bekomme ich die Meldung "The system cannot log you on (C000019B), Please try again or consult your system administrator", wenn ich versuche, mich anzumelden.“

Dies geschieht, wenn der Domänen-SID, der in der secrets.tdb-Datenbank gespeichert ist, geändert wird. Die häufigste Ursache für eine Änderung ist die Änderung des Domänen-Namens und/oder des Server-Namens (NetBIOS-Namens). Die einzige Lösung ist es, den originalen Domänen-SID wiederherzustellen oder den Domänen-Client aus der Domäne zu entfernen und neu einzubinden. Der Domänen-SID kann mit dem net- oder rpcclient-Werkzeug zurückgesetzt werden.

Zum Zurücksetzen oder Ändern des Domänen-SID können Sie den net-Befehl wie folgt verwenden:

root# net getlocalsid 'OLDNAME'
root# net setlocalsid 'SID'

Maschinen-Vertrauenskonten von Workstations arbeiten nur mit dem Domänen-SID (Netzwerk-SID). Wenn dieser SID sich ändert, können sich Domänen-Mitglieder (Workstations) nicht in der Domäne anmelden. Der originale Domänen-SID kann aus der secrets.tdb-Datenbank wiederhergestellt werden. Die Alternative ist es, jede einzelne Workstation aufzusuchen und neu an die Domäne anzuschließen.

„Wenn ich versuche, mich der Domäne anzuschließen, bekomme ich die Nachricht "The machine account for this computer either does not exist or is not accessible". Was ist falsch?“

Dieses Problem wird dadurch verursacht, dass der PDC kein passendes Maschinen-Vertrauenskonto bereitstellt. Wenn Sie die add machine script-Methode zum Anlegen von Konten verwenden, ist dies ein Zeichen dafür, dass diese Methode nicht funktioniert hat. Stellen Sie sicher, dass der Benutzer des Domänen-Administrators richtig arbeitet.

Außerdem: Wenn Sie Konten von Hand erstellen, dann wurden diese nicht korrekt erstellt. Stellen Sie sicher, dass Sie den Eintrag für das Maschinen-Vertrauenskonto in der Datei smbpasswd auf dem Samba-PDC korrekt erstellt haben. Wenn Sie den Eintrag mit einem Editor erstellt haben, anstatt das Programm smbpasswd zu verwenden, sollten Sie kontrollieren, dass der Name des Kontos dem NetBIOS-Namen der Maschine entspricht, gefolgt von einem „$“ (z.B. computer_name$). Es muss je einen Eintrag in /etc/passwd und in der Datei smbpasswd geben.

Manche Benutzer haben auch berichtet, dass inkonsistente Subnetz-Masken zwischen dem Samba-Server und dem NT-Client dieses Problem verursachen können. Stellen Sie sicher, dass diese Masken für Client und Server übereinstimmen.

„Wenn ich versuche, mich einer Domäne von einer NT4/W200x-Workstation aus anzuschlie?en, bekomme ich die Nachricht, dass mein Konto deaktiviert wird.“

Aktivieren Sie die Benutzer-Konten mit smbpasswd -e Benutzername. Dies wird normalerweise beim Anlegen eines Kontos ausgeführt.

„Ein paar Minuten, nachdem Samba gestartet worden ist, bekommen die Clients den Fehler "Domain Controller Unavailable"“.

Ein Domänencontroller muss seine Rolle im Netzwerk bekannt geben. Dies braucht üblicherweise eine Weile. Haben Sie bis zu 15 Minuten Geduld, versuchen Sie es dann nochmals.

Nach dem erfolgreichen Beitritt zu einer Domäne scheitern Benutzeranmeldungen mit einer von zwei Meldungen: die eine besagt, dass der DC nicht gefunden werden könne, die andere behauptet, dass das Konto nicht in der Domäne existiere bzw. dass das Passwort falsch sei. Dies kann durch imkompatible Einstellungen zwischen dem Windows-Client und dem Samba-3-Server verursacht werden, und zwar durch die schannel- (secure channel) oder smb signing-Einstellungen. Prüfen Sie die Einstellungen client schannel, server schannel, client signing, server signing durch das Ausführen von:

testparm -v | more

und prüfen Sie die Werte dieser Parameter.

Benutzen Sie auch die Microsoft Management Console Local Security Settings. Dieses Werkzeug ist in der Systemsteuerung verfügbar. Die Policy-Einstellungen finden Sie im Bereich "Local Policies/Security Options": Sie erkennen Sie am Präfix Secure Channel: ..., and Digitally sign .....

Es ist wichtig, dass diese Einstellungen genauso gesetzt sind wie die des Samba-3-Servers.