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):

● bind9custom.service - LSB: Start and stop bind9
Loaded: loaded (/etc/init.d/bind9custom; generated; vendor preset: enabled)
Active: active (running) since Sun 2018-10-21 22:25:05 CEST; 21min ago
Docs: man:systemd-sysv-generator(8)
Process: 453 ExecStart=/etc/init.d/bind9custom start (code=exited, status=0/SUCCESS)
Tasks: 5 (limit: 19660)
CGroup: /system.slice/bind9custom.service
└─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:

[libdefaults]
dns_lookup_realm = false
dns_lookup_kdc = true
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:

Server Role:           active directory domain controller
Hostname:              ADAM
NetBIOS Domain:        HEAVEN
DNS Domain:            heaven.home
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:

# This DNS configuration is for BIND 9.8.0 or later with dlz_dlopen support.
#
# This file should be included in your main BIND configuration file
#
# For example with
# include "/usr/local/samba/bind-dns/named.conf";

#
# This configures dynamically loadable zones (DLZ) from AD schema
# Uncomment only single database line, depending on your BIND version
#
dlz "AD DNS Zone" {
# For BIND 9.8.x
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";

# For BIND 9.9.x
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";

# For BIND 9.10.x
# database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";

# For BIND 9.11.x
database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so";
};

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:

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /usr/local/bind9/etc/named.conf.local

include "/usr/local/bind9/etc/named.conf.options";
include "/usr/local/bind9/etc/named.conf.local";
include "/usr/local/bind9/etc/named.conf.default-zones";
include "/usr/local/samba/bind-dns/named.conf";

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:

options
{
    directory "/var/cache/bind";
    forward first;
    forwarders
    {
        192.168.0.105;   # lokaler Router oder jeder andere Rechner, der bei euch bisher die DNS-Auflösung übernimmt.
    };
    notify no;
    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { no; };
    tkey-gssapi-keytab "/usr/local/samba/bind-dns/dns.keytab";

    dnssec-enable no;
    dnssec-validation no;
};

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:

root@ADAM:~# named-checkconf
/usr/local/bind9/etc/named.conf.options:8: missing ';' before '}'
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:

# Global parameters
[global]
netbios name = ADAM
realm = HEAVEN.HOME
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
workgroup = HEAVEN
idmap_ldb:use rfc2307 = yes

[netlogon]
path = /usr/local/samba/var/locks/sysvol/heaven.home/scripts
read only = No

[sysvol]
path = /usr/local/samba/var/locks/sysvol
read only = No

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):

    #additional Samba-Settings
    wins support = yes
    allow dns updates = nonsecure and secure
    server max protocol = SMB3
    client min protocol = SMB2_10
    client max protocol = SMB3

    #printer settings
    spoolss: architecture = Windows x64

    #log settings
    log level = 1
    log file = /var/log/samba/log.%m
    max log size = 10000                  

Erläuterungen zu den Einträgen:

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:

# Global parameters
[global]
    netbios name = ADAM
    realm = HEAVEN.HOME
    server role = active directory domain controller
    server services = -dns
    workgroup = HEAVEN
    idmap_ldb:use rfc2307 = yes

    #additional Samba-Settings
    wins support = yes
    allow dns updates = nonsecure and secure
    server max protocol = SMB3
    client min protocol = SMB2_10
    client max protocol = SMB3

    #printer settings
    spoolss: architecture = Windows x64

    #log settings
    log level = 1
    log file = /var/log/samba/log.%m
    max log size = 10000

[netlogon]
    path = /usr/local/samba/var/locks/sysvol/heaven.home/scripts
    read only = No

[sysvol]
    path = /usr/local/samba/var/locks/sysvol
    read only = No

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:

Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:

_ldap._tcp.heaven.home has SRV record 0 100 389 adam.heaven.home.
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:

_kerberos._udp.heaven.home has SRV record 0 100 88 adam.heaven.home.

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:

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

Jetzt schauen wir uns das Kerberos Ticket an:

klist

Es sollte eine Ausgabe ähnlich der folgenden erscheinen:

Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
Standard-Principal: Administrator@HEAVEN.HOME

Valid starting       Expires              Service principal
22.10.2018 22:06:51  23.10.2018 08:06:51  krbtgt/HEAVEN.HOME@HEAVEN.HOME
        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:

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:

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

Sollten am Ende Fehlermeldungen erscheinen, z.B.:

Failed nsupdate: 1
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:

Server:         192.168.0.150
Address:        192.168.0.150#53

Name:   adam.heaven.home
Address: 192.168.0.150

nslookup 192.168.0.150

erzeugt folgende Ausgabe:

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:

HEAVEN\Domain Admins
SePrintOperatorPrivilege
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 . 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:

# Local clock. Note that is not the "localhost" address!
server 127.127.1.0
fudge  127.127.1.0 stratum 10

# Where to retrieve the time from
server 0.de.pool.ntp.org     iburst prefer
server 1.de.pool.ntp.org     iburst prefer
server 2.de.pool.ntp.org     iburst prefer
server 3.de.pool.ntp.org     iburst prefer

driftfile       /var/lib/ntp/ntp.drift
logfile         /var/log/ntp
ntpsigndsocket  /usr/local/samba/var/lib/ntp_signd/

# Access control
# Default restriction: Allow clients only to query the time
restrict default kod nomodify notrap nopeer mssntp

# No restrictions for "localhost"
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0

# Enable the time sources to only provide time to this host
restrict 0.de.pool.ntp.org   mask 255.255.255.255    nomodify notrap nopeer noquery
restrict 1.de.pool.ntp.org   mask 255.255.255.255    nomodify notrap nopeer noquery
restrict 2.de.pool.ntp.org   mask 255.255.255.255    nomodify notrap nopeer noquery
restrict 3.de.pool.ntp.org   mask 255.255.255.255    nomodify notrap nopeer noquery

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:

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