Tanze Samba mit Pi - Teil 5: Einrichtung des Active Directory

Willkommen zurück beim fünften Teil der Reihe, heute geht es um die Einrichtung des Active Directory.


Doch zuvor ein wichtiger Hinweis:

Dieser Artikel beschäftigt sich damit, wie ihr auf dem Pi ein neues Active Directory einrichtet und konfiguriert. Solltet ihr ein existentes AD von eurem NAS (oder einem anderen Server) umziehen wollen, so ist die Vorgehensweise eine andere, bitte nutzt für diesen Fall nicht das im heutigen Artikel beschriebene Vorgehen. Ein Active Directory darf nur auf 1 DC provisioniert werden - ein provisionieren auf einem zweiten DC und nachträgliches Übertragen ist nicht möglich und kann zu schweren Fehlern in eurem bereits vorhandenen AD (z.B. auf der NAS) führen. Wenn ihr ein AD auf euren Raspberry verschieben wollt, so muss dieser zunächst als weiterer DC ins AD aufgenommen werden und danach die entsprechenden Serverrollen auf diesen übertragen werden - damit der Raspberry Pi zum PDC (primary domain controller) wird. Das entsprechende Vorgehen werde ich in einem weiteren Artikel beschreiben - die Schritte aus den Artikeln 1 bis 4 bleiben dabei gleich.


Ein kleiner Rückblick. Bisher haben wir den Raspberry Pi vorbereitet, die entsprechenden Pakete installiert, Bind 9 kompiliert, installiert und getestet sowie Samba kompiliert und installiert. Euer Bind9 DNS-Server sollte nach wie vor im Hintergrund laufen - dies testen wir direkt nochmal, da ihr den Pi ja heruntergefahren und gesichert haben solltet:

systemctl status bind9custom


Hier sollte, wie beim letzten Test, eine Ausgabe ähnlich der folgenden erscheinen (wichtig ist erst mal nur der obere Teil der Ausgabe, da dieser uns mitteilt, ob der Service läuft):

Code
  1. ● bind9custom.service - LSB: Start and stop bind9
  2. Loaded: loaded (/etc/init.d/bind9custom; generated; vendor preset: enabled)
  3. Active: active (running) since Sun 2018-10-21 22:25:05 CEST; 21min ago
  4. Docs: man:systemd-sysv-generator(8)
  5. Process: 453 ExecStart=/etc/init.d/bind9custom start (code=exited, status=0/SUCCESS)
  6. Tasks: 5 (limit: 19660)
  7. CGroup: /system.slice/bind9custom.service
  8. └─475 /usr/local/bind9/sbin/named

Da es für unser Active Directory elementar ist, dass die Namen innerhalb der Domäne direkt korrekt aufgelöst werden und wir zunächst keine weiteren Pakete herunterladen müssen, tragen wir unseren eigenen Raspberry nun als DNS-Server in der Netzwerkkonfiguration ein:

nano /etc/network/interfaces


Hier ersetzen wir den alten Eintrag des DNS-Servers durch die IP des Raspberry (die ihr als Eintrag address in der selben Datei findet):

dns-nameservers 192.168.0.150


Wir machen das selbe auch in der Datei resolv.conf:

nano /etc/resolv.conf


Auch hier ersetzen wir im Eintrag nameserver die IP des Raspberry Pi:

nameserver 192.168.0.150


Als nächstes passen wir unsere Kerberos Konfigurationsdatei an:

nano /etc/krb5.conf


Wir ersetzen den Inhalt der Datei durch folgendes:

Code
  1. [libdefaults]
  2. dns_lookup_realm = false
  3. dns_lookup_kdc = true
  4. default_realm = HEAVEN.HOME

Damit die Änderungen Wirkung zeigen, rebooten wir den Raspberry. Dieser wird ab sofort sich selbst als DNS-Server verwenden.

reboot


Jetzt sind wir soweit und provisionieren unser Active Directory:

samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=BIND9_DLZ --realm=HEAVEN.HOME --domain=HEAVEN --adminpass=Passw0rd


Es erscheint eine Menge Text, wichtig ist für uns zunächst nur das, was am Ende ausgegeben wird:

Code
  1. Server Role: active directory domain controller
  2. Hostname: ADAM
  3. NetBIOS Domain: HEAVEN
  4. DNS Domain: heaven.home
  5. DOMAIN SID: S-1-5-21-701497469-2038700851-1821049440

Die Domäne wurde erfolgreich eingerichtet, hat eine SID erhalten und läuft unter dem korrekten Namen. Herzlichen Glückwunsch, die Domäne wurde erstellt und ist grundsätzlich schon einmal vorhanden. Nun müssen wir noch ein paar Scripte anpassen, damit auch Bind9 weiss, dass es innerhalb eines AD läuft und hier die entsprechenden Aufgaben übernimmt, sowie Samba noch ein paar Dinge mitteilen. Wir haben bei der Provisionierung auch erst einmal ein temporäres Administrator-Kennwort vergeben (Passw0rd), dieses werden wir im Laufe dieses Artikels selbstverständlich ebenfalls noch ändern.

Als nächstes prüfen wir, ob Samba die korrekte Library für Bind9 verwendet:

nano /usr/local/samba/bind-dns/named.conf


Hier sollte lediglich die letzte Zeile auskommentiert sein:

Hintergrund:

Bind muss für die korrekte Funktion innerhalb eines AD auf Sambafunktionen zugreifen, hierfür stellt Samba unterschiedliche Libraries zur Verfügung. Da wir Bind 9.11 einsetzen, muss natürlich die entsprechende Library geladen werden, was in diesem Fall auch seitens Samba bei der Provisionierung schon korrekt hinterlegt wurde. Sollte bei euch keine - oder eine andere - der Libraries (.so) auskommentiert sein, so passt euer File entsprechend an. Ein # vor einer Zeile bedeutet, dass diese Zeile einem Kommentar entspricht und sie nicht als zu verwendendes Kommando genutzt wird.

Jetzt teilen wir Bind9 mit, dass es diese Datei beim starten auch benutzen soll:

nano /usr/local/bind9/etc/named.conf


Und fügen am Ende folgende Zeile ein:

include "/usr/local/samba/bind-dns/named.conf";


Die Datei sieht nun so aus:

Jetzt wird es interessant, denn wir konfigurieren Bind9 um innerhalb unserer Domäne korrekt zu funktionieren:

nano /usr/local/bind9/etc/named.conf.options


Wir ersetzen den Inhalt der Datei durch folgendes:

Wichtiger Hinweis:

Im Abschnitt forwarders (das ist der Bereich zwischen den beiden geschweiften Klammern { } ) werden die DNS-Server eingetragen, an die unser Bind9 alle Anfragen weiterleitet, die nicht innerhalb der Domäne aufgelöst werden können. Hier tragt ihr normalerweise die IP Adresse eures Routers ein, bzw. des Rechners, der für euer Netzwerk bisher die Namensauflösung übernommen hat. In meinem Fall ist das ein weiterer Raspberry auf dem die Software Pi-Hole läuft, die ich in einem anderen Artikel beschreiben werde. Ihr könnt hier durchaus mehrere DNS-Server für das Forwarding hinterlegen. Für jeden weiteren DNS-Server legt ihr einfach eine weitere Zeile im Abschnitt an, gebt die IP-Adresse an und beendet sie jeweils mit einem Semikolon ;.

Da Bind extrem anfällig für fehlerhafte Konfigurationen ist, prüfen wir jetzt, ob wir alles richtig gemacht haben:

named-checkconf


Solltet ihr alles richtig gemacht haben, passiert nichts weiter und ihr erhaltet einfach wieder den Eingabeprompt. Ansonsten prüft bitte, ob ihr alles gemäß dieses Artikels korrekt eingetragen habt. Testweise habe ich einfach mal das Semikolon hinter dem DNS-Forwarder weggelassen und schon erhalte ich eine Fehlermeldung:

Code
  1. root@ADAM:~# named-checkconf
  2. /usr/local/bind9/etc/named.conf.options:8: missing ';' before '}'
  3. root@ADAM:~#

Bind9 ist nun fertig für unser AD eingerichtet. Genauso ändern wir jetzt die provisorische Konfiguration unseres AD, die Samba für uns beim Provisionieren erzeugt hat:

nano /usr/local/samba/etc/smb.conf


Samba hat uns in diesem File schon ein bisschen Arbeit abgenommen, wir können das aber noch verbessern. Das File sieht jetzt erst mal wie folgt aus:

Zuerst ändern wir die Zeile server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, daraus machen wir:

server services = -dns


Das bedeutet, unser Active Directory nutzt alle seitens Samba standardmässig aktivierten Funktionen, ausser dem Samba-internen DNS-Server. Diesen braucht Samba in unserem Fall auch nicht, da wir Bind9 einsetzen. Zusätzlich schreiben wir unterhalb des Eintrags idmap_ldb:use rfc2307 = yes noch folgende Zeilen: (eine Erklärung habe ich unterhalb in einer Tabelle angegeben):

Erläuterungen zu den Einträgen:

Befehl Erklärung
server max protocol = SMB3 höchste vom Server genutzte SMB-Version
client min protocol = SMB2_10 SMB-Version die ein Client mindestens haben muss
client max protocol = SMB3 SMB-Version die ein Client maximal haben darf
spoolss: architecture = Windows x64 Unterstützung, damit unter Samba sowohl x86 als auch x64 Druckertreiber zur Verfügung stellen kann
log level = 1 Log-Level mit dem Samba protokolliert (je höher, umso feiner)
log file = /var/log/samba/log.%m Verzeichnis in das Samba Logs schreibt
max log size = 10000 maximale Größe (in KB) eines Logfiles


Achtung:

Leider gibt es unter Samba einen Bug der dazu führt, dass zwar für die einzelnen Samba-Funktionalitäten ein einzelnes Log angelegt wird, als grundlegendes Log aber zusätzlich ein File namens "log.%m". Das wäre noch nicht so schlimm (nur der Name ist unschön), leider zieht für diese Datei aber nicht die max log size. In höheren Log Leveln wird diese Datei daher leider sehr schnell sehr groß - wenn ihr ein solches also einstellt, überwacht regelmässig, dass euch die SD-Karte nicht volläuft.


Interessant ist hier der Eintrag wins support = yes - dieser kleine Eintrag reicht bereits, damit Samba euch einen vollwertigen WINS-Server für euer AD zur Verfügung stellt. Solltet ihr diesen nicht wünschen, so könnt ihr ihn mit wins support = no ausschalten. Wenn ihr bereits einen WINS-Server im Netz habt und diesen weiter nutzen möchtet, so könnt ihr auch diesen angeben: wins server = [IP-Adresse des Servers]. Bitte richtet jedoch keinen zweiten WINS-Server unter Samba ein, da WINS unter Samba keine Replikation der Datenbanken unterstützt. Unsere endgültige smb.conf sollte nun so aussehen:

Weiterführende Informationen zu den Einstellungen in der smb.conf findet ihr hier: https://www.samba.org/samba/do…/man-html/smb.conf.5.html


Jetzt legen wir lediglich noch das soeben konfigurierte Verzeichnis für die Logfiles an:

mkdir /var/log/samba


Damit haben wir Samba grundlegend konfiguriert und können unsere Services starten. Jetzt starten wir das erste Mal unseren Samba Service:

service samba4 start


Und starten Bind9 mit den neuen Einstellungen neu:

systemctl restart bind9custom


Unser System wurde nun für die grundlegenden Funktionalitäten eines AD-Controllers konfiguriert und sollte einsatzbereit sein. Es wird also Zeit, um die ersten Funktionalitäten zu testen und zu sehen, ob alles so funktioniert wie wir uns das wünschen:

host -t SRV _ldap._tcp.heaven.home. localhost; host -t SRV _kerberos._udp.heaven.home. localhost


Hier sollte eine Ausgabe wie die folgende erscheinen:

Prima, ldap und kerberos sind korrekt im DNS eingetragen. Jetzt testen wir, ob wir uns über Kerberos authentifizieren können und ein Ticket erhalten:

kinit Administrator


Wir geben das Kennwort ein, dass wir bei der Provisionierung vergeben haben und erhalten:

Code
  1. root@ADAM:/# kinit Administrator
  2. Passwort for Administrator@HEAVEN.HOME:
  3. Warnung: Ihr Passwort wird in 41 Tagen auf So 02 Dez 2018 22:02:47 CET ablaufen.
  4. root@ADAM:/#

Jetzt schauen wir uns das Kerberos Ticket an:

klist


Es sollte eine Ausgabe ähnlich der folgenden erscheinen:

Code
  1. Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
  2. Standard-Principal: Administrator@HEAVEN.HOME
  3. Valid starting Expires Service principal
  4. 22.10.2018 22:06:51 23.10.2018 08:06:51 krbtgt/HEAVEN.HOME@HEAVEN.HOME
  5. erneuern bis 23.10.2018 22:06:47

Da Kerberos einwandfrei läuft, ändern wir jetzt, wie schon angedeutet, das Kennwort unseres Administrators. Grundsätzlich gibt es voreingestellte Sicherheitseinstellungen für Kennwörter in unserem AD, unter anderem ist das Mindestalter eines Kennworts auf 1 Tag gesetzt - daher können wir unser Kennwort nicht direkt ändern. Wir setzen also das Mindestalter auf 0 Tage:

samba-tool domain passwordsettings set --min-pwd-age=0


Vergeben direkt ein neues Kennwort:

kpasswd


Und setzen das Mindestalter, aus Sicherheitsgründen, wieder auf 1 Tag:

samba-tool domain passwordsettings set --min-pwd-age=1


Für Interessierte, hier eine Liste der Befehle, um die Kennwort-Sicherheitseinstellungen der Domäne direkt über die Kommandozeile zu ändern:

Befehl Erklärung
samba-tool user setexpiry Administrator --noexpiry Disable password expiration for the Administrator account.
samba-tool domain passwordsettings show Show domain level password options.
samba-tool domain passwordsettings set --complexity=off Disable password complexity at the domain level.
samba-tool domain passwordsettings set --history-length=0 Disable password history at the domain level.
samba-tool domain passwordsettings set --min-pwd-age=0 Disable password min-age at the domain level.
samba-tool domain passwordsettings set --max-pwd-age=0 Disable password max-age at the domain level.
samba-tool domain passwordsettings set --min-pwd-length=0 Disable minimum password length at the domain level.
*andere Werte als 0 setzen die jeweilige Eigenschaft auf den ensprechenden Wert


Nun testen wir, ob unser DNS-Server eine der wichtigsten Funktionen des AD (dynamische Updates) korrekt ausführt:

samba_dnsupdate --verbose --all-names


Hier erscheint nun eine Wall of Text. Wichtig ist, dass am Ende keinerlei Fehlermeldungen erscheinen. Während dieses Befehls werden 29 Blöcke mit Update-Kommandos erzeugt, jeder dieser Blöcke sollte Einträge wie die folgenden enthalten:

Code
  1. Successfully obtained Kerberos ticket to DNS/adam.heaven.home as ADAM$
  2. Outgoing update query:
  3. ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
  4. ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0

Sollten am Ende Fehlermeldungen erscheinen, z.B.:

Code
  1. Failed nsupdate: 1
  2. Failed update of 29 entries

So habt ihr eine der Anweisungen nicht korrekt befolgt. Bitte schaut einmal, ob ihr alle Einträge dieses Artikels korrekt ausgeführt habt und rebootet dann testweise einmal euren Pi. Wenn ihr z.B. vergesst, euren BInd9 Service neu zu starten, oder ihr erst Bind9 restartet und dann den Samba-Service, so kann es, beim ersten Start der Domäne, zu Fehlermeldungen kommen. Diese sind allerdings nach einem Neustart des Pi Vergangenheit.

Damit unser DNS-Server in unserem AD aus IP-Adressen auch wieder Namen auflösen kann, benötigt er eine Reverse-Lookup-Zone. Diese richten wir ihm nun ein:
samba-tool dns zonecreate adam.heaven.home 0.168.192.in-addr.arpa -U Administrator


Und legen für unseren Domain-Controller auch direkt den PTR-Eintrag an:

samba-tool dns add adam.heaven.home 0.168.192.in-addr.arpa 150 PTR adam.heaven.home -U Administrator


Erklärung:

Die 192.168.0.150 entspricht dabei unserem Pi (auf dem läuft der DNS) und die 0.168.192 dem "umgedrehten" Subnetz unseres Netzwerks ohne dem letzten Byte. Aus dem Subnetz 192.168.0.0 wird also 0.168.192. Die 150 entspricht in diesem Fall dann dem 4ten Byte der IP des Raspberry, da die Reverse Zone für den gesamten IP-Adressbereich ohne dem letzten Byte entspricht, brauchen wir nur das letzte anzugeben. Damit IP-Adressen in Namen umgewandelt werden können, braucht der DNS-Server eine sog. Reverse-Lookup-Zone. Hier sucht der DNS-Server, wenn nur eine IP-Adresse angegeben wird nach dem entsprechenden Namen (der vorher im DNS eingetragen werden sollte). Rechner die in die Domäne aufgenommen werden, werden automatisch (dynamisch) im DNS eingetragen. Daher war der vorhergehende Test der dynamischen Updates so wichtig.


Wir testen nun, ob der DNS-Server sowohl den Namen, als auch die IP korrekt auflösen kann:

nslookup adam


erzeugt folgende Ausgabe:

Code
  1. Server: 192.168.0.150
  2. Address: 192.168.0.150#53
  3. Name: adam.heaven.home
  4. Address: 192.168.0.150

nslookup 192.168.0.150


erzeugt folgende Ausgabe:

Code
  1. 150.0.168.192.in-addr.arpa name = adam.heaven.home.

Wunderbar, der DNS-Server arbeitet auch für Reverse-Lookups einwandfrei. Nun geben wir unserer Gruppe "Domain Admins" noch ein paar elementare Rechte:

net rpc rights grant 'HEAVEN\Domain Admins' SePrintOperatorPrivilege SeDiskOperatorPrivilege -Uadministrator


Und prüfen diese direkt:

net rpc rights list accounts -Uadministrator


Wichtig ist, dass dabei dann auch die gerade hinzugefügten Rechte angezeigt werden:

Code
  1. HEAVEN\Domain Admins
  2. SePrintOperatorPrivilege
  3. SeDiskOperatorPrivilege

Jetzt können wir unseren Samba-Service dann auch ruhigen Gewissens so konfigurieren, dass er bei einem Neustart direkt geladen wird:

systemctl enable samba4


Eigentlich sind wir fertig. Eigentlich. Eigentlich zerstört eigentlich aber auch den deutschen Satzbau :P . Ok. Wer aufgepasst hat weiss, dass uns noch eine Kleinigkeit fehlt. Innerhalb einer Domäne benötigen alle Client die sich anmelden eine Uhrzeit, die sich maximal um ~5 Minuten vom AD-Controller unterscheidet - ansonsten wird die Anmeldung, auch bei korrekten Anmeldedaten, abgelehnt. Daher sollte unser Domain-Controller natürlich auch einen Dienst bereitstellen, über den sich unsere Clients die Zeit holen können. Diesen werden wir jetzt konfigurieren und für unsere Domäne einrichten: NTP.

Das ganze ist schnell erledigt und erfordert nicht viel Aufwand. Zunächst installieren wir die aktuelle Version von NTP:

apt-get install ntp


und schalten den auf neueren Raspberry-Pi bereits standardmässig installierten timesyncd aus:

systemctl stop systemd-timesyncd

systemctl disable systemd-timesyncd


Wir stoppen unseren gerade installierten ntp:

systemctl stop ntp


und editieren die NTP-Konfiguration:

nano /etc/ntp.conf


Wir ersetzen den Inhalt der Datei durch das folgende:

Jetzt schalten wir noch den Autostart des Service an und starten diesen auch:

systemctl enable ntp

systemctl start ntp


Unsere NTP-Konfiguration können wir nun auch testen:

ntpq -p


Wenn ihr ein paar Minuten wartet, dann wird euch NTP in der Anzeige auch anzeigen, welchen Server er als Referenzquelle verwendet:

Code
  1. root@ADAM:~# ntpq -p
  2. remote refid st t when poll reach delay offset jitter
  3. ==============================================================================
  4. LOCAL(0) .LOCL. 10 l 265 64 20 0.000 0.000 0.000
  5. *y.ns.gin.ntt.ne 249.224.99.213 2 u 60 64 17 25.677 -0.855 0.988
  6. +cipher-code.de 178.63.61.67 3 u 59 64 17 31.856 -2.473 1.309
  7. +165.227.247.48 131.188.3.220 2 u 62 64 17 26.948 -2.053 1.438
  8. +fra1.m-d.net 193.190.230.65 2 u 64 64 17 28.315 -3.365 1.649
  9. root@ADAM:~#

Der Server mit dem * bezeichnet die Referenzquelle. Wundert euch nicht, ihr werdet bei jedem Start des Pi andere Zeitserver verwenden. Das ist völlig normal, denn in der Konfigurationsdatei wurden Poolserver konfiguriert aus dem dann automatisch jeweils 1 Eintrag ausgewählt wird.


Testweise könnt ihr euren Raspberry nun auch nochmal rebooten um festzustellen, ob nach einem reboot auch alles noch so funktioniert wie ihr das möchtet:

reboot


Das wars auch schon. Nun stellt unser Raspberry für die Domäne auch direkt einen NTP-Server zur Verfügung. Ihr könnt, wenn ihr das möchtet, per GPO für eure Clients einstellen, wie und in welchem Intervall die Zeit vom Server abgeholt wird - mehr dazu dann in einem meiner weiteren Artikel.

Ich hoffe, euch hat dieser Teil der Reihe gefallen, vielen Dank fürs lesen und bis demnächst in einem weiteren Artikel zum Thema Raspberry und Active-Directory,


euer Lauri.