Samba und AD-Domäne einrichten

Posted by DH an Monday, 20 January 2014

Damit Samba als Active Directory-Domain Controller arbeiten kann, müssen wir diese Domäne jetzt erstellen und einrichten („provisionieren“).

samba-tool domain provision

Wir verwenden dazu für diese Anleitung folgende Daten:

Beispiel

Domänenname („Realm“): ad.example.com
Windows-Domäne: AD
Serverrolle („Server Role“): dc
DNS-Backend: BIND9_DLZ
Administrator-Paßwort: (Mindestens acht Zeichen, sowohl Groß- und Kleinbuchstaben als auch Zahlen)

Hinweis

In vielen Anleitungen wird eine Domäne wie mydomain.local oder Ähnliches verwendet. Das kann klappen, muß aber nicht, denn je nachdem wie das Netzwerk oder auch nur einzelne Geräte darin konfiguriert sind, ist die Endung .local für andere Aufgaben reserviert. Im Zweifelsfalle ist intranet.meinefirma.com eine gute Idee (sofern meinefirma.com einem auch gehört).

Nach diesen Eingaben wird die Domäne provisioniert, alle Datenbanken und Netzfreigaben erzeugt und die DNS-Einträge aktualisiert. Das dauert einen kleinen Moment und sieht im Erfolgsfall etwa so aus:

Rot markiert sind hier noch die Hinweise auf zwei nötige, gleich folgende Konfigurationsanpassungen.

Kerberos-Konfiguration übernehmen

Falls schon eine eigene Kerberos-Konfiguration existiert, muß der Inhalt der von Samba erzeugten Konfigurationsdatei /usr/local/samba/private/krb5.conf bestehende /etc/krb5.conf integriert werden. Ansonsten kann die aktuellen Konfiguration gesichert und danach einfach ersetzt werden:

mv /etc/krb5.conf /usr/local/samba/private/krb5.conf.original
cp /usr/local/samba/private/krb5.conf /etc

Domäne in Bind integrieren und DNS-Dienst übernehmen

Zunächst muß in der Datei /usr/local/samba/private/named.conf die für unsere Bind-Version
9.9 zutreffende Konfiguration aktiviert und die andere auskommentiert werden:

dlz "AD DNS Zone" {

    # For BIND 9.8.0

    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";

    # For BIND 9.9.0

    database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";

};

Anschließend wird diese Samba-Konfiguration in der Datei /usr/local/bind9/etc/named.conf eingebunden. Im folgenden Beispiel ist das die letzte Zeile:

include "/etc/bind/named.conf.options";

include "/etc/bind/named.conf.local";

include "/etc/bind/named.conf.default-zones";

include "/usr/local/samba/private/named.conf";

Warnung

Bind-Konfigurationsdateien sind sehr empfindlich, was falsche Schreibweisen angeht!

Optional: DNS-Weiterleitung

Um den Pi zu entlasten, können wir ihm einen Forwarder zur Verfügung stellen. Dazu kann ein öffentlicher DNS, der lokale Internetrouter und weitere Server in /usr/local/bind9/etc/named.conf.options ergänzt werden:

options {

        // ... andere Optionen ...

        forward first;

        forwarders {

                192.168.1.1; // Lokaler Router

                8.8.8.8; // Google oder ein beliebiger anderer

                // Beliebige weitere externe DNS-Server.

                // Jede Adresse muß mit einem Semikolon enden.

        };

        notify no;

};

Wer statt Bind den eingebauten Samba-DNS nutzen will, kann bzw. muß stattdessen einen(!) Forwarder in der /usr/local/samba/etc/smb.conf eintragen:

[global]

    ; ...

    ; andere Optionen

    ; ...

    dns forwarder = 192.168.1.1

    allow dns updates = nonsecure and secure

x64-Support vorbereiten

Um später Druckertreiber auch für x64-Systeme hochladen zu können, müssen wir aufgrund von Windows-Konventionen einen x64-Server betreiben. Das ist der Pi zwar nicht, aber mit der folgenden Anpassung der /usr/local/samba/etc/smb.conf können wir ihn gegenüber Windows-Clients so tun lassen, als ob:

[global]

    ; ...

    ; andere Optionen

    ; ...

    spoolss: architecture = Windows x64

Tipp

Weitere Informationen zur Samba-Konfiguration.

Konfiguration prüfen

Nach einem Neustart beider Dienste ist es Zeit für ein paar Testkommandos:

service bind9custom restart
service samba4 start
host -t SRV _ldap._tcp.ad.example.com. localhost; host -t SRV _kerberos._udp.ad.example.com. localhost

Dabei sollte eine Antwort wie

Name: localhost
Address: 127.0.0.1#53
Aliases:
_ldap._tcp.ad.example.com has SRV record 0 100 389 raspberrypi.ad.example.com.
Name: localhost
Address: 127.0.0.1#53
Aliases:
_kerberos._udp.ad.example.com has SRV record 0 100 88 raspberrypi.ad.example.com.

herauskommen. Wenn das der Fall ist, kann unser Domain Controller die Rolle des lokalen Nameservers übernehmen.

DNS-Einstellungen/DHCP-Server umstellen

Sofern der Pi nicht bereits im lokalen Netz als Primärer DNS bekannt ist, wird das jetzt nachgeholt. Am einfachsten ist das mit DHCP, wo wir nur den DNS-Eintrag am DHCP-Server (bzw. in den DHCP-Optionen des Routers) anzupassen brauchen.

Wer kein DHCP nutzt, muß nun als DNS-Server-Adresse für jeden Computer im LAN die IP des Pi eintragen.

Als Suchdomäne (je nach System manchmal auch nur Domain o.ä.) wird, entweder am DHCP-Server oder an jedem Client einzeln, der Name unserer Domäne (hier: ad.example.com) eingetragen.

In beiden Fällen ist noch einmal ein Neustart fällig.

NTP testen

Spätestens jetzt sollte der NTP-Client, den wir zuvor bereits installiert haben, richtig funktionieren. Das läßt sich relativ einfach überprüfen:

ntpq -p

sollte etwas ähnliches wie dies ausgeben:

Hinweis

Da der Raspberry Pi keine eingebaute Uhr besitzt, kann es nach längeren Ausschaltzeiten zu erheblichen Zeitabweichungen kommen. Das wiederum kann zum Problem beim Start einiger Dienste werden. Siehe hierzu den entsprechenden Hack.

Kerberos testen

Zuletzt testen wir noch, ob Kerberos wie gewünscht funktioniert, denn ohne diesen Dienst würde der gesamte Controller niemals richtig arbeiten:

kinit administrator

Nach Eingabe des beim Provisionieren vergebenen Paßworts wird nun ein „Berechtigungsausweis“ („Ticket“) erstellt. Ob das funktioniert, überprüfen wir mit:

klist

Das Ergebnis sollte in etwa so aussehen:

Admin-Privilegien vergeben

Zwei wichtige Rechte müssen jetzt noch an die Gruppe „Domain Admins“ vergeben werden. Der Namenspräfix AD wird dabei ggf. durch den tatsächlichen (Kurz-)Namen der Domäne ersetzt. Anschließend wird das Ergebnis kontrolliert:

net rpc rights grant 'AD\Domain Admins'\
  SePrintOperatorPrivilege SeDiskOperatorPrivilege\
  -Uadministrator
net rpc rights list accounts -Uadministrator

Als Paßwort dient wiederum das bei der Provisionierung erstellte. Bei Erfolg sieht das Ergebnis ungefähr so aus: