Seit samba4 lässt sich unter Linux ein vollwertiger Active Directory Server aufbauen!
Doch bei der Installation ist einiges zu beachten wie dieses How-To zeigt.
Inhalt
Einleitung
Zuerst mal ein kleiner Wermutstropfen, denn das AD mittels samba4 lässt sich derzeit nur auf Debian basierten Systemen (wie z.B. ubuntu) installieren.
Dies weil samba4 zur Zeit nur mit dem heimdal kerberos funktioniert und beispielsweise RedHat basierende Systeme (wie z.B. CentOS) das konkurrierende MIT-Kerberos fest im System integriert haben.
In diesem Tutorial wurde deshalb Ubuntu verwendet.
Ferner braucht es für ein Active Directory (AD) mindestens drei Server: Zwei Domain Controller (DC) und ein Fileserver (FS).
Zwar würde das AD mit nur einem DC funktionieren, die ganze Architektur ist aber auf mindestens zwei ausgelegt, und dies sollte man für einen stabilen Betrieb auch beachten.
Weiter sollten auch keinerlei Freigaben auf den Domain-Controllern liegen, da diese ein anderes ID-Mapping haben und somit die User auf den DCs andere IDs haben wie auf den restlichen Servern.
Daher wird für die Benutzer Heimverzeichnisse (homes) und Server gespeicherten Profile (profiles) ein eigener Fileserver verwendet; dieser kann natürlich noch beliebige andere Freigaben enthalten.
Ebenfalls erwähnenswert ist, dass auf den DCs ein Nameserver laufen muss, der von den DCs selbst und sämtlichen mit diesen verbunden Clients als Nameserver konfiguriert sein muss!
Samba bringt dazu einen internen Nameserver mit, welcher jedoch ziemlich eingeschränkt ist und es sich empfiehlt bind als DNS zu verwenden.
Das spätere wechseln vom internen zu bind oder umgekehrt ist jedoch extrem simpel und man kann auch bedenkenlos mal mit dem internen anfangen und später wechseln.
[stextbox id=“note“ caption=“bind als DNS Server für Samba-AD“]
Wenn man bind als Nameserver verwenden will, muss dieser mit den DLZ (Dynamic Loadbale Zones) Extension ausgestattet sein.
Dies war früher oft nicht der Fall und es war empfehlenswerter den internen DNS zu verwenden anstelle bind selbst zu kompilieren.
Mittlerweile ist jedoch die DLZ Unterstützung zumindest bei ubuntu schon in normalen repository Paket integriert und es gibt keinen Grund mehr bind nicht zu verwenden. 😉
Auf jeden Fall muss der Nameserver aber direkt auf dem Domain Controller laufen, ihn auf einem externen Server laufen zu lassen geht nicht.
Auch kann man die Zone welche das AD verwendet nicht mittels DNS Replikation (master/slave) replizieren; samba macht dies mit einem internen Mechanismus, bzw. eben dem DLZ.
Im folgenden werde ich jeweils beide Varianten beschreiben.
[/stextbox]
Zuletzt sollte werden noch zwei wichtige Angaben gebraucht: Der Name der Domäne und der Kerberos realm.
Dies sollte keinesfalls ein Fantasie-Namen (wie z.B. meine.domain) sein, sondern entweder auf eine selbst registrierte Domain gehen oder eine reservierte, wie beispielsweise AD.EXAMPLE.NET.
In diesem Beispiel, welches ferner verwendet wird ist AD der Domain-Name und AD.EXAMPLE.NET der realm. Will man den ersten Teil „AD“ weg lassen, ist das auch möglich, dann ist der Name der Domain einfach EXAMPLE und der realm EXAMPLE.NET. Da jedoch manchmal die Domain auch noch für andere Dinge wie beispielsweise einer Webseite unter www.example.net verwendet werden soll ist es praktisch für die Domain eine dedizierte Subdomain zu machen. Ansonsten könnte man alternativ auch zwei Domains registrieren, etwa „example.com“ für extern und „example.net“ intern, bzw. fürs AD.
Zu den Servernamen die hier verwendet werden, heissen die beiden DCs dc01.ad.example.net (192.168.1.10), dc02.ad.example.net (192.168.1.20) und der Fileserver fs01.ad.example.net (192.168.1.30)
Beide Domain Controller (PDC und SDC)
Installation
Folgendes muss auf beiden domain controllern identisch installiert/konfiguriert werden:
apt install samba smbclient heimdal-clients winbind ldb-tools ldap-utils libnss-winbind libpam-winbind ntp xinetd |
Falls man bind als DNS server verwenden will, muss dieser noch installiert werden:
apt install bind9 |
Die Frage nach der „Kerberos Authentication“ realm kann man ignorieren, bzw. einfach den Standard nehmen. Dieser wird später ohnehin in der Konfiguration noch angepasst.
Konfiguration
Zunächst überprüfen ob der Hostname korrekt mit seiner IP in /etc/hosts eingetragen ist:
127.0.0.1 localhost 192.168.1.10 dc01.ad.example.net dc01 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters |
Nun muss die samba Konfigurationsdatei wie folgt (neu) erstellt werden:
>/etc/samba/smb.conf |
/etc/samba/smb.conf
[global] workgroup = AD realm = AD.EXAMPLE.NET netbios name = DC01 server role = active directory domain controller dns forwarder = 8.8.8.8 idmap_ldb:use rfc2307 = yes wins support = yes [netlogon] path = /var/lib/samba/sysvol/ad.example.net/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No |
[stextbox id=“note“ caption=“bind DLZ“]
Verwendet man bind als DNS backend muss man hier die Zeile mit dns forwarder
entfernen und stattdessen die Zeile: server services = -dns
einfügen.
[/stextbox]
Als „workgroup“ wird der Name der Domain eingetragen, dann der realm und der unter „netbios name“ der Name des Servers. (dies ist bei jedem DC anders, beim zweiten, beispielsweise DC02!)
Einen (externen) „dns forwarder“ braucht es auch zwingend, da der integrierte Nameserver keine externen Namen auflösen kann; somit hätten andernfalls die Domain-Controller keinen Internet Zugriff.
Eine wichtige Option ist fernen die „idmap_ldb:use rfc2307 = yes“: Damit ist es möglich später Unix UIDs/GIDs bei den Benutzern zu vergeben.
Dies ist zwar normalerweise dank des id mappings von windind nicht nötig, es ist aber sehr aufwändig diese Option später hinzuzufügen!
Die beiden Freigaben [netlogon] und [sysvol] sind System-Freiagben die jeder DC zwingend braucht und, wie anfangs erwähnt die einzigen Freigaben darauf bleiben sollten.
Als nächstes kommt die kerbereos Konfiguration:
>/etc/krb5.conf |
/etc/krb5.conf
[libdefaults] default_realm = AD.EXAMPLE.NET dns_lookup_realm = false dns_lookup_kdc = true |
Dann muss noch die Datei /etc/nsswitch.conf angepasst werden damit im System die AD Benutzer und Gruppen benutzt werden können.
Bei den zwei Einträgen „passwd“ und „group“ muss einfach noch „winbind“ angefügt werden:
passwd: files winbind group: files winbind |
Nun müssen beim Verzeichnis /var/lib/samba/ntp_signd/ die Berechtigungen angepasst werden:
mkdir -pv /var/lib/samba/ntp_signd/ chown -v root:ntp /var/lib/samba/ntp_signd/ chmod -v 750 /var/lib/samba/ntp_signd/ |
Und die NTP Konfiguration wie folgt (neu) erstellt werden:
>/etc/ntp.conf |
server 127.127.1.0 fudge 127.127.1.0 stratum 10 server 0.pool.ntp.org iburst prefer server 1.pool.ntp.org iburst prefer driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp.log ntpsigndsocket /var/lib/samba/ntp_signd/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable restrict default kod nomodify notrap nopeer mssntp restrict 127.0.0.1 restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap nopeer noquery |
Auch ein anpassen der ulimits ist erforderlich; dazu einfach zuunterst in der Datei: /etc/security/limits.conf folgendes anfügen:
* - nofile 16384 |
Zum Schluss ist noch auf beiden Domain Controllern die IP der Nameserver und der Suchpfad einzutragen und zwar am besten so, dass auf jeweils die eigene IP zuerst kommt.
Beispiel auf DC01:
/etc/resolv.conf
nameserver 192.168.1.10 nameserver 192.168.1.20 search ad.example.net |
Einrichten der WINS Replikation
Zuerst wird auf dem ersten Domain Controller eine Datei: /root/wins.ldif mit folgendem Inhalt erstellt:
/root/wins.ldif
dn: CN=dc02,CN=PARTNERS objectClass: wreplPartner address: 192.168.1.20 |
Dann mittels ldbadd in die WINS Datenbank eingefügt:
cd /var/lib/samba/private/ ldbadd -H wins_config.ldb /root/wins.ldif |
Danach muss dass auf dem zweiten DC mit umgekehrten Angaben wiederholt werden; in der wins.ldif Datei müssen nun aber Hostnamen und IP vom ersten DC stehen!
Damit ist auch der WINS Server fertig.
Nun noch sicherstellen, dass die Dienste: samba-ad-dc, winbind, ntp (und wenn BIND_DLZ als DNS backend verwendet wird zusätzlich bind9) gestartet werden:
systemctl enable samba-ad-dc systemctl enable winbind systemctl enable ntp #systemctl enable bin9 systemctl start samba-ad-dc systemctl start winbind systemctl start ntp #systemctl start bind9 |
[stextbox id=“warning“ caption=“BIND_DLZ“]
Verwendet man bind als nameserver, darf man diesen nicht reloaden, sonden muss ihn immer restarten.
Ansosnten führt dies zu Problem, z.B. beim automatischen hinzufügen von Einträgen per DHCP, oder beim hinzufügen von Rechnern in die Domäne.
Besonders wichtig ist dies bei logrotate, da hier standardmässig das reload Kommando ausgeführt wird.
Das heisst man muss das logrotate Script (/etc/logrotate.d/bind) entsprechend anpassen und das „reload“ mit „restart“ erstezen. z.B.:
/var/log/bind/named.log { monthly rotate 12 compress delaycompress missingok notifempty #create 0664 bind root postrotate /bin/systemctl restart bind9 endscript } |
[/stextbox]
Primärer Domain Controller (PDC)
Die folgenden Schritte müssen nur auf dem ersten Domain-Controller gemacht werden.
sysvol Replikation
Da samba derzeit noch keine Dateisystem Replikation unterstützt wird das sysvol Verzeichnis mittels lsyncd synchronisiert.
Dazu wird auf dem PDC ein lsync-server eingerichtet.
[stextbox id=“info“ caption=“lsyncd“]
Wenn man Verzeichnisse auf unterschiedlichen Servern synchron halten will, macht man dies meist mittels rsync und cron. Das funktioniert jedoch nur in einem 1 Minuten Rhythmus.
Lsyncd befragt den Linux Kernel mittels inotify ob sich Dateien in einem beobachteten Ordner inklusive Unterordner geändert haben, und synchronisiert diese je nach Einstellung mittels rsync auf einen oder mehrere Server, was die Einschränkung mit der rsync/cron Lösung aufhebt.
Wer keinen Passwortlosen SSH-Zugriff vom PDC auf die SDCs möchte kann stattdessen einen rsync-server aufsetzen und mittels cron-job synchronisieren.
[/stextbox]
SSH keys erzeugen
Auf dem primären Domain-Controller (PDC) werden nun SSH keys erzeugt um ohne Passwort auf die anderen SDCs zu kommen:
ssh-keygen -t rsa -b 4096 -q -f /root/.ssh/id_rsa -N "" |
Danach wird der Inhalt von: /root/.ssh/id_rsa.pub bei allen SDCs in der Datei: /root/.ssh/authorized_keys hinzugefügt:
ssh-copy-id -i ~/.ssh/id_rsa.pub root@dc02 |
Installation von lsyncd
apt install lsyncd mkdir -v /var/log/lsyncd/ /etc/lsyncd/ chgrp -v adm /var/log/lsyncd/ update-rc.d lsyncd enable |
Für die Konfiguration wird eine neue Datei: /etc/lsyncd/lsyncd.conf.lua mit folegndem Inhalt angelegt:
settings { logfile = "/var/log/lsyncd/lsyncd.log", statusFile = "/var/log/lsyncd/status.log", statusInterval = 5, maxDelays = 10, } targetList = { "dc02", -- Liste kann hier ggf. erweitert werden } targetDirs = { "/var/lib/samba/sysvol/", -- Liste kann hier ggf. erweitert werden } for _, server in ipairs(targetList) do for _, dir in ipairs(targetDirs) do sync { default.rsyncssh, source=dir, host=server, targetdir=dir, rsync = { archive = true, xattrs = true, acls = true, _extra = {"--delete-after",}, }, } end end |
Nun lsyncd noch neu starten:
systemctl restart lsyncd |
ACL fixing
Weil die ACL Dateien manchmal korrupt werden können legt man am besten noch den folgenden cronjob an, damit diese automatisch repariert werden:
0 */12 * * * /usr/bin/samba-tool ntacl sysvolreset |
Domain provisionieren
Nun kann endlich die Domäne erstellt werden!
Mittels:
samba-tool domain provision --use-rfc2307 --domain=AD --realm=AD.EXAMPLE.NET --dns-backend=SAMBA_INTERNAL |
wird das actice directory erstellt!
BIND_DLZ
[stextbox id=“note“ caption=“bind DLZ“]
Verwendet man bind als DNS backend muss man hier die Option: --dns-backend=SAMBA_INTERNAL
mit: --dns-backend=BIND9_DLZ
ersetzen.
Dann muss nach der Provisionierung bind noch konfiguriert werden:
In der options {}
Sektion von bind folgende Zeile einfügen:
tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab"; |
In /etc/bind/named.conf die folgende Zeile einfügen:
include "/var/lib/samba/private/named.conf"; |
Zuletzt muss AppArmor noch entfernt werden:
service apparmor stop service apparmor teardown /usr/sbin/update-rc.d -f apparmor remove |
Hinweis: Wer sich die Mühe machen will AppArmor oder SELinux zu integriren findet in der Dokumentation: BIND9 DLZ AppArmor and SELinux Integration Hinweise.
=> Diese Schritte müssen auf allen DCs gemacht werden.
[/stextbox]
Nun sollte als nächstes der Server rebootet werden, damit alle services danach laufen.
Testen
Nach dem Neustart sollte die Domain als erstes getestet werden.
Server Ports
netstat -tlpn | egrep 'samba|named'
Sollte eine Liste wie folgt ausgeben:
tcp 0 0 0.0.0.0:88 0.0.0.0:* LISTEN 3337/samba tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 3335/samba tcp 0 0 0.0.0.0:1024 0.0.0.0:* LISTEN 3332/samba tcp 0 0 0.0.0.0:3268 0.0.0.0:* LISTEN 3335/samba tcp 0 0 0.0.0.0:3269 0.0.0.0:* LISTEN 3335/samba tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 3335/samba tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN 3332/samba tcp 0 0 0.0.0.0:42 0.0.0.0:* LISTEN 3334/samba tcp 0 0 0.0.0.0:464 0.0.0.0:* LISTEN 3337/samba tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 3345/samba tcp6 0 0 :::88 :::* LISTEN 3337/samba tcp6 0 0 :::636 :::* LISTEN 3335/samba tcp6 0 0 :::1024 :::* LISTEN 3332/samba tcp6 0 0 :::3268 :::* LISTEN 3335/samba tcp6 0 0 :::3269 :::* LISTEN 3335/samba tcp6 0 0 :::389 :::* LISTEN 3335/samba tcp6 0 0 :::135 :::* LISTEN 3332/samba tcp6 0 0 :::464 :::* LISTEN 3337/samba tcp6 0 0 :::53 :::* LISTEN 3345/samba |
DNS-Server
host dc01 dc01.ad.example.net has address 192.168.1.10 |
host -t SRV _kerberos._tcp.ad.example.net _kerberos._tcp.ad.example.net has SRV record 0 100 88 dc01.ad.example.net. |
host -t SRV _ldap._tcp.ad.example.net _ldap._tcp.ad.example.net has SRV record 0 100 389 dc01.ad.example.net. |
host -t SRV _gc._tcp.ad.example.net _gc._tcp.ad.example.net has SRV record 0 100 3268 dc01.ad.example.net. |
Hier wird ersichtlich: Beim active directory funkiotniert die Abfgrage wo ein spezifischer Dienst (z.B: ldap) läuft immer über einen spezillen SRV-Eintrag im Nameserver.
Es müssen alle Einträge aufgelöst werden können.
Verbindungsaufbau
smbclient -L localhost -Uadministrator |
Nach Eingabe des Administrator Passwortes sollten die Freigaben angezeigt werden:
Domain=[AD] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu] Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.3.11-Ubuntu) Domain=[AD] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu] Server Comment --------- ------- Workgroup Master --------- -------
Wie man sieht gibt sich hier der Server tatsächlich als „Windows 6.1“ aus. 😉
Kerberos
Nun wird das erste „Kerberos Ticket“ erzeugt:
kinit administrator |
mittels „klist“ kann dieses dann auch angezeigt werden:
Credentials cache: FILE:/tmp/krb5cc_0 Principal: administrator@AD.EXAMPLE.NET Issued Expires Principal Jan 5 04:13:55 2018 Jan 5 14:13:52 2018 krbtgt/AD.EXAMPLE.NET@AD.EXAMPLE.NET
Damit kann man isch nun direkt via kerberos anmelden und muss das Passwort nicht mehr angeben:
smbclient -L dc01 -k |
(Parameter -k)
Wichtig: Mit kerberos kann man sich nie gegen „localhost“ authentifizieren, stattdessen muss immer der richtige name des Servers angegeben werden!
LDAP-Server
Zuletz wird nun noch der ldap-server getestet:
ldbsearch -H ldap://dc01 "cn=administrator" -k yes |
Dies sollte so was ausgeben:
# record 1 dn: CN=Administrator,CN=Users,DC=ad,DC=example,DC=net objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Administrator description: Built-in account for administering the computer/domain instanceType: x whenCreated: xxxxxxxxxxxxx uSNCreated: xxxx name: Administrator objectGUID: xxxxxxxxxxxxx userAccountControl: xxx badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 primaryGroupID: xxx objectSid: xxxxxxxxxxxxx adminCount: 1 accountExpires: xxxxxxxxxxxxx logonCount: 0 sAMAccountName: Administrator sAMAccountType: xxxxxxxxxxxxx objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=example,DC=net isCriticalSystemObject: TRUE memberOf: CN=Administrators,CN=Builtin,DC=ad,DC=example,DC=net memberOf: CN=Group Policy Creator Owners,CN=Users,DC=ad,DC=example,DC=net memberOf: CN=Enterprise Admins,CN=Users,DC=ad,DC=example,DC=net memberOf: CN=Schema Admins,CN=Users,DC=ad,DC=example,DC=net memberOf: CN=Domain Admins,CN=Users,DC=ad,DC=example,DC=net lastLogonTimestamp: xxxxxxxxxxxxx pwdLastSet: xxxxxxxxxxxxx whenChanged: xxxxxxxxxxxxx.0Z uSNChanged: xxx lastLogon: xxxxxxxxxxxxx distinguishedName: CN=Administrator,CN=Users,DC=ad,DC=example,DC=net # Referral ref: ldap://ad.example.net/CN=Configuration,DC=ad,DC=example,DC=net # Referral ref: ldap://ad.example.net/DC=DomainDnsZones,DC=ad,DC=example,DC=net # Referral ref: ldap://ad.example.net/DC=ForestDnsZones,DC=ad,DC=example,DC=net # returned 4 records # 1 entries # 3 referrals |
Vorbereitungen für zweiten Domain Controller
Nun noch kleine Vorbereitungen für den zweiten domain controller.
DNS Reverse Zone erstellen
Da keine reverse Zone automatisch im DNS erstellt, aber zukünftig benötigt wird, sollte das nun nachgeholt werden:
samba-tool dns zonecreate dc01 1.168.192.in-addr.arpa |
Zweiten DC eintragen
Leider werden neu beigetretene hosts nicht automatisch im DNS erstellt, weshalb dies nun für den zweiten DC noch gemacht werden muss:
samba-tool dns add dc01 1.168.192.in-addr.arpa 20 PTR dc02.ad.example.net |
Und das ganze noch in der forward Zone
samba-tool dns add dc01 ad.example.net dc02 A 192.168.1.20 |
Sekundärer Domain Controller (SDC)
Konfiguration
smb.conf
In der Datei /etc/samba/smb.conf muss man „netbios name“ auf den Servernamen anpasssen, sowie bei den beiden Freigaben „netlogon“ und „sysvol“ den Wert „read only = Yes“ setzen, da diese sich nur auf dem primären domain controller ändern dürfen.
Der Domäne beitreten
Bevor nun der Domäne beigetreten werden kann, sollten dieselben tests wie beim PDC durchlaufen werden!
Nun kann der zweite DC der Domäne beitreten:
samba-tool domain join ad.example.net DC --realm=ad.example.net -Uadministrator |
[stextbox id=“note“ caption=“bind DLZ“]
Verwendet man bind als DNS backend muss auch hier die Option: --dns-backend=BIND9_DLZ
mitgegeben werden, da ansonsten standarmässig der interne DNS konfiguriert wird!
[/stextbox]
Nun sollte auch dieser Server zuerst rebootet werden.
Testen
Nach dem Neustart sollten nun die folgenden zusätzlichen Tests gemacht werden:
domain info
samba-tool domain info 192.168.1.20 |
ldap
ldbsearch -H /var/lib/samba/private/sam.ldb '(invocationid=*)' --cross-ncs objectguid |
KCC
samba-tool drs kcc -U administrator dc01.ad.example.net |
Replikation
samba-tool drs showrepl |
FSMO Rollen
samba-tool fsmo show |
Läuft das Active Directory bereit und es kann mit dem Fileserver fortgefahren werden!
Fileserver
Anders als bei den Domain Controllern ist es bei Domain Mitgliedern (also z.B: Fileserver) egal welches Linux verwendet wird.
Der Fileserver wird deshalb nachfolgend mit CentOS aufgesetzt.
Installation
Für einen fileserver müssen auf CentOS die folgenden Pakete installiert werden:
yum install samba samba-client samba-winbind samba-winbind-clients pam_krb5 krb5-workstation ntp |
bzw. für Debian/Ubuntu:
apt install samba smbclient heimdal-clients winbind ldb-tools ldap-utils libnss-winbind libpam-winbind ntp |
Konfiguration
Nun müssen in der Datei /etc/resolv.conf die DNS-Server der Domaincontroller- und die Domain eingetragen werden:
nameserver 192.168.1.10 nameserver 192.168.1.20 search ad.example.net |
Ausserdem muss in /etc/hosts noch zwingend die IP des Servers eingetragen werden, da ansonsten der Beitritt in die Domäne nicht funktioniert:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.30 fs01.ad.example.net fs01 |
Als nächstes kommt die kerbereos Konfiguration.
Dazu kann die Datei: /etc/krb5.conf einfach von einem der domain controller kopiert werden, da diese identisch sein muss wie auf den DCs:
[libdefaults] default_realm = AD.EXAMPLE.NET dns_lookup_realm = false dns_lookup_kdc = true |
Danach noch die samba Konfiguration in /etc/samba/smb.conf:
[global] workgroup = AD realm = AD.EXAMPLE.NET security = ADS winbind enum users = yes winbind enum groups = yes winbind use default domain = no winbind refresh tickets = yes template shell = /bin/bash idmap config * : range = 10000 - 19999 idmap config AD : backend = rid idmap config AD : range = 1000000 - 1999999 inherit acls = yes store dos attributes = yes vfs objects = acl_xattr |
Und wie schon bei den Domain Controllern muss auch noch die Datei /etc/nsswitch.conf angepasst werden damit auf dem fileserver die AD Benutzer und Gruppen benutzt werden können.
Bei den zwei Einträgen „passwd“ und „group“ muss einfach noch „winbind“ angefügen:
passwd: compat winbind group: compat winbind
Ausserdem sollte noch das file limits in /etc/security/limits.conf angepasst werden. In die Datei, einfach die folgende Zeile anfügen:
* - nofile 16384
Jetzt noch samba und winbind als autostzart Konfigurieren:
systemctl enable smb systemctl enable nmb ssystemctl enable winbind |
Und zum Schluss das System neu starten.
Zum Schluss kann man nun den fileserver mit der Domäne verbinden:
net ads join -Uadministrator
Und testen:
[root@fs01 ~]# net ads testjoin Join is OK |
Danach sollte man wieder auf einem der Domaincontroller den reverse looup DNS-Eintrag hinzufügen:
samba-tool dns add dc01 1.168.192.in-addr.arpa 30 PTR fs01.ad.example.net. |
Damit ist der Fileserver nun in der Domäne eingebunden und mittels den Kommandos: wbinfo -u
und wbinfo -g
sollten bereits schon die AD Benutzer und Gruppen angezeigt werden:
[root@zh-v-fs01 ~]# wbinfo -u AD\hmuster AD\administrator AD\krbtgt AD\guest |
Nun kann man wie gehabt in der Datei /etc/smb.conf die Freigaben erstellen und den entsprechenden AD Benutzern die Rechte Zuweisen.
Spezielle Freigaben
Die zwei speziellen Freigaben für die Benutzer-Heimverzeichnisse und die Server gespeicherten Profilverzeichnisse werden nachfolgend erklärt.
Zuvor sollte man jedoch die „Domain Admins“ Gruppe mit dem Speziellen Recht „SeDiskOperatorPrivilege“ ausstatten, da diese ansonsten keine Berechtigungen auf die Verzeichnisse setzen dürfen:
net rpc rights grant 'AD\Domain Admins' SeDiskOperatorPrivilege -UAdministrator -S fs01 |
Homes
Um Benutzern ein Home-Laufwerk zuweisen zu können muss dieses erst mit speziellen Berechtigungen angelegt werden:
mkdir -v /home/AD chmod -v 775 /home/AD chgrp -v 'AD\Domain Admins' /home/AD |
Nun kann die Freigabe wie folgt in der /etc/samba/smb.conf eingetragen werden:
[users] path = /home/AD comment = Home directories guest ok = no read only = no browseable = no create mask = 700 directory mask = 700 veto files = /.*/lost+found/.BIN/desktop.ini/Default.rdp/ |
Danach muss man sich nur noch als administrator auf einem Windows-Client in der Domäne anmelden, mittels der RSAT bei: „Active Directory Users and Computers“ den Benutzer öffnen und im Tab: „Profile“ bei „Home folder“ einen Laufwerksbuchstaben (z.B: H:\) und der pfad zum fileserver angeben: \\fs01\users\hmuster
Meldet sich nun der Benutzer „hmuster“ an der Domäne an, bekommt dieser automatisch sein Home-Laufwerk zugeordnet und auch auf dem Server wird das Benutzerverzeichnis automatisch erstellt.
Profiles
Will man noch sein Windows-Profil auf dem Server speichern erstellt man in ähnlicher Weise noch eine Profil-Freigabe:
mkdir -v /home/profiles chmod -v 1770 /home/profiles chgrp -v 'AD\Domain Users' /home/profiles |
Nun kann die Freigabe wie folgt in der /etc/samba/smb.conf eingetragen werden:
[profiles] path = /home/profiles comment = User Profiles guest ok = no read only = no browseable = no |
[stextbox id=“note“ caption=“‚profile acls‘ nicht mehr setzen“]
Früher, in der vor-AD-Ära von samba musste man im [profiles] share noch den Eintrag:
profile acls = yes |
setzen. Dies ist mittlerweile aber veraltet (und wird vom samba Projekt in einer nächsten Version entfernt), auch wenn es sogar bei modernen Tutorials und Büchern noch steht.
Bei einer AD Konfiguration setzt man die Profil ACLs direkt unter Windows auf das Profilverzeichnis, wie nachfolgend beschrieben wird.
Siehe dazu auch im samba wiki: Roaming Windows User Profiles.
[/stextbox]
Nun muss man sich nur noch als Administrator auf einem Windows-Client in der Domäne anmelden, die Freigabe \\fs01\profiles
öffnen und in die Eigenschaften des profiles/ Verzeichnisses gehen.
Nun muss man zuerst die „Vererbung deaktivieren“ und alle schon gesetzten Berechtigungen entfernen.
Danach werden folgende Berechtigungen vergeben:
Benutzer/Gruppe | Berechtigung | Übernehmen für |
---|---|---|
Domain Users | Ordner Durchsuchen / Datei ausführen Ordner auflisten / Daten lesen Ordner erstellen / Daten anhängen | Nur diesen Ordner |
CREATOR OWNER | Vollzugriff | Nur Unterordner und Dateien |
Domain Admins | Vollzugriff | Diesen Ordner, Unterordner und Dateien |
SYSTEM | Vollzugriff | Diesen Ordner, Unterordner und Dateien |
Jetzt kann man mittels der RSAT bei: „Active Directory Users and Computers“ den Benutzer öffnen und im Tab: „Profile“ bei „Profile path“ Das Profilverzeichnis angeben: \\fs01\profiles\hmuster
Auch dieses wird beim erstmaligen Anmelden automatisch erstellt.
Damit der Administrator aus Windows heraus selbstständig freigaben erzeugen kann, wird zunächst ein „root-share“ erzeugt.
Danach kann der Administrator innerhalb diesem Unterverzeichnisse erstellen und mittels eintragen in der Registry (wie unten erklärt wird) die Freigaben eintragen.
Erstellen des Verzeichnisses und Berechtigungen:
mkdir -pv /srv/smb chown -v root:'AD\Domain Admins' /srv/smb chmod -v 775 /srv/smb |
Damit der Administrator später Verzeichnisse hier erstellen kann, braucht er die Spezielle Berechtigung: SeDiskOperatorPrivilege
.
Eintragen des Shares in die Samba-Konfiguration:
[smb] browseable = No comment = SAMBA shares admin hide unreadable = Yes path = /srv/smb read only = No |
Unter diesem Verzeichnis sollten die Verzeichnisse nur noch unter Windows angelegt werden, siehe die Erklärung in der Box: „Berechtigungen nicht mehr über Linux verwalten“.
[stextbox id=“info“ caption=“Berechtigungen nicht mehr über Linux verwalten“]
Beim Verbinden von Linux und Windows mit einem SAMBA ActiveDirectory muss man sich bewusst sein, dass auch die Datei- und Verzeichnisrechte nur noch über Windows administriert werden sollten.
Denn um die Windows-Berechtigungen in Netzwerkfreigaben möglichst detailiert abzubilden verwendet samba extensiv die Filesystem ACLs (facl) unter Linux.
Schaut man sich Besipielsweise das erstellte Heimverzeichnis unter Linux an, sieht dieses so aus:
[root@fs01 ~]# ls -lahd /home/AD/hmuster/ drwxrwx---+ 30 HOME\administrator HOME\domain users 4.0K Apr 4 10:25 /home/HOME/hmuster/ |
Doch das sind eigentlich keine Berechtigungen mehr, sondern lediglich ein Maske für die ACLs, auf welche das „+“ am Schluss hinweist.
Diese kann man mit getfacl
anschauen:
[root@fs01 ~]# ls -lahd /home/AD/hmuster/ [root@zh-v-fs01 ~]# getfacl /home/HOME/hmuster getfacl: Removing leading '/' from absolute path names # file: home/HOME/hmuster # owner: HOME\134administrator # group: HOME\134domain\040users user::rwx user:1000513:--- user:HOME\134hmuster:rwx group::--- group:BUILTIN\134administrators:rwx group:HOME\134administrator:rwx group:HOME\134domain\040users:--- group:HOME\134hmuster:rwx mask::rwx other::--- default:user::rwx default:user:HOME\134administrator:rwx default:user:HOME\134hmuster:rwx default:group::--- default:group:BUILTIN\134administrators:rwx default:group:HOME\134domain\040users:--- default:group:HOME\134hmuster:rwx default:mask::rwx default:other::--- |
Aus diesem Grunde sollte man auch nie bei Verzeichnissen, welche ACLs besitzen (die mit dem +) per chmod
ändern, sondern nur noch in den Windows Einstellungen.
[/stextbox]
Freigaben erstellen
Nun können die Freigaben wie folgt erstellt werden:
- Auf einem im AD eingebundenen Windows-Rechner als Domain Administrator (AD\Administrator) anmelden und die Share-Root-Freiagbe:
\\fs01\smb
aufrufen - Ein Unter-Verzeichnis erstellen (z.B. „files\“)
- In den „Eigenschaften“ dieses Verzeichnisses unter „Sicherheit“ -> „Erweitert“ auf „Vererbung aufheben“ klicken und wählen, dass die Berechtigungen entfernt werden sollen
- In den „Eigenschaften“ dieses Verzeichnisses unter „Sicherheit“ -> „Erweitert“ alle Einträge entfernen und mit OK bestätigen.
- Nun neue Einträge hinzufügen, im Minimum: „Domain Admins“ mit „Vollzugriff“ und in der Regel: „Domain Users“ mit „Ändern“.
In der Samba-Konfiguration den folgenden Eintrag einfügen:
[files] comment = Allgmeine Dokumente path = /srv/smb/files read only = No |
Dies kann auch direkt in Windows über die Registry gemacht werden, so dass gar keine Interaktion mit dem Linux Fileserver mehr nötig ist!
Siehe dazu das Nachfolgende Kapitel: „Verwaltung der samba Konfiguration über die registry“.
Verwaltung der samba Konfiguration über die registry
Eine interessante Möglichkeit beim samba AD ist, es, dass man die gesammt SAMBA Konfiguration auch in der Registry Verwalten kann.
Dies hat mehrere grosse Vorteile:
- Normalerweise wird bei jedem Zugriff auf eien Freigabe die ganze Datei smb.conf eingelesen und übers Netzwerk gesendet, was vor allem bei vielen Benutzern Netzwerklastig ist. Bei der registry wird nur noch der Teil der Freigabe gelesen und gesendet.
- Mehrere Administratoren können simultan Freigaben erstellen und verändern, da die registry eine Datenbank ist.
- Freigaben können optional komplett aus Windows heraus erstellt- und Konfiguriert werden.
Auch ein „Mischbetrieb“ ist so möglich: Man kann beispielsweise den [global] Teil noch immer in der smb.conf Verwalten und die Freiagben über die registry.
Dazu muss man in der Datei smb.conf lediglich den Eintrag:
[global] include = registry |
anfügen.
Damit wird zuerst die smb.conf gelesen und danach die registry, d.h. alle doppelt vorkommenden Werte werden mit denen in der registry überschrieben.
Die „komplette“ samba Konfiguration lässt sich danach mit dem Kommando: net conf list
anzeigen.
Von einem Windows-Client in der Domäne, als Administrator angemeldet kann man dann auch regedit aufrufen und unter Datei: „Mit Netzwerk Registry verbinden“ den fileserver angeben und damit die Freigaben Verwalten.
Unter Linux lässt sich eine Freigabe in der registry dann wie folgt erstellen:
net conf addshare myshare /srv/smb/myshare writeable=y guest_ok=n "Neue Netzwerkfreigabe" net conf setparm users "browsable" "no" |
Wichtig dabei zu wissen ist, dass man mit net conf addshare
nur die Parameter: „writeable“ und „guest_ok“ angeben kann. Alle weiteren Parameter werden mit net conf setparm
gesetzt.
smb.conf in registry importieren
Will man die sich den Aufwand ersparen die Freigaben initial alle so anzulegen kann man auch die ganze smb.conf importieren:
net conf import /etc/samba/smb.conf |
[stextbox id=“warning“ caption=“Achtung“]
Vor dem importieren der smb.conf muss die Zeile: include = registry unbedingt aus der smb.conf entfernt werden!
Ansonsten gibt es einen loop und die Konfiguration funktioniert nicht mehr!
[/stextbox]
Nach dem import reicht es dann wenn man in der Datei: /etc/samba/smb.conf nur noch diese zwei Zeilen rein schreibt:
[global] include = registry |
SSH Login mit Domänenbenutzern
Damit sich nun AD-Benutzer auch per SSH in die Domäne anmelden können, müssen die folgenden Zeilen zur Datei: /etc/pam.d/password-auth-ac hinzugefügt werden:
- auth sufficient pam_winbind.so use_first_pass
- account [default=bad success=ok user_unknown=ignore] pam_winbind.so
- password sufficient pam_winbind.so use_authtok
Die Datei sollte nachher so aussehen:
#%PAM-1.0 auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_winbind.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so |
Danach kann man sich mittels
ssh AD\\hmuster@fs01 |
anmelden.
Weitere Information liefert das samba wiki unter: Authenticating Domain Users Using PAM
Erweiterungen
Nachfolgend werde ich einige nützliche, aber vollkommen Optionale Erweiterungen beschreiben.
DHCP
Es lohnt sich auf dem PDC und SDC je einen DHCP-Server im failover Setup zu haben.
Denn bei Windows Domeincontrollern ist der DHCP-Server häufig ebenfalls Bestandteil, man hat diesen gleich redundant ausgelegt und man kann z.B. Clients welche eine DHCP IP-Adresse beziehen automatisch im DNS Server ein- und austragen, wie das bei Windows Active Directories häufig auch gemacht wird.
Nachfolgend wird aufbauend auf das Tutorial DHCP failover mit Linux beschrieben wie eine automatische ein-/austragung der DHCP-Client realisiert werden kann.
SSH public keys aus dem Active Directory auslesen
Eine überaus praktische Angelegenheit wäre es nun, wenn man die SSH public keys der Benutzer im AD hinterlegen könnte; so würde das extrem mühsame Verwalten der authorized_keys Dateien auf jedem Server entfallen.
Diese Möglichkeit gibt es, denn man kann dem sshd mittels der Konfigurationsoption: AuthorizedKeysCommand
ein Programm angeben, welches SSH keys zurückliefern kann.
Damit muss dann nur noch ein Script geschrieben werden, welches das AD nach einem bestimmten Attribut mit den keys drin abfragt und diese ausliefert.
Da man das LDAP-Schema des ActiveDirectory nach Möglichkeit nicht erweitern sollte, bietet sich das bereits vorhandne Attribut: altSecurityIdentities
an.
Zunächst meldet man sich als Administrator auf einem Windows-Rechner im AD an und öffnet Active Directory Users and Computers.
Dann kann man die Benutzer, für welche man SSH public keys hinzufügen möchte bearbeiten und im Tab: Attribute Editor das Attribut: „altSecurityIdentities“ editieren und dort die keys (einen pro Zeile) hinzufügen.
Im nächsten Schritt muss nun auf jedem Linux-System, auf dem man sich mit SSH public keys anmelden will das Script: /etc/ssh/ad-ssh-key
erstellt werden:
#!/bin/bash ldap_uri="ldap://ad.example.net" ldap_user="sshd@ad.example.net" ldap_base="dc=ad,dc=example,dc=net" ldap_pw="geheim" ldap_login_attribute="sAMAccountName" ldap_ssh_key_attribute="altSecurityIdentities" ldap_lookup_user=$1 ldapsearch -o nettimeout=2 \ -o ldif-wrap=no -D "$ldap_user" \ -w "$ldap_pw" \ -H "$ldap_uri" \ -b "$ldap_base" \ "(${ldap_login_attribute}=${ldap_lookup_user})" \ ${ldap_ssh_key_attribute} \ | /bin/grep "^${ldap_ssh_key_attribute}" \ | perl -MMIME::Base64 -MEncode=decode -ne 'chomp; s/.*:: (\S+)/decode("UTF-8",decode_base64($1))/e; s/^.*?: //; printf "%s\n", $_' | grep -vE "^$" |
chown -v root /etc/ssh/ad-ssh-key chmod -v 755 /etc/ssh/ad-ssh-key |
Für die Abfrage von AD-Benutzern braucht es einen berechtigen Benutzer. Am besten legt man sich dazu einen „System-Benutzer“ im AD (hier heisst der Benutzer: „sshd“) an.
Testen kann man dies nun indem man das Script aufruft und als Argument einen Benutzer mit hinzugefügten SSH public keys angibt:
/etc/ssh/ad-ssh-key hmuster |
Als Rückgabe sollten nun die hinterlegten SSH public keys ausgegeben werden.
Nun bearbeitet man die Datei: /etc/ssh/sshd_config
und fügt die folgenden zwei Zeilen hinzu:
AuthorizedKeysCommand /etc/ssh/ad-ssh-key AuthorizedKeysCommandUser nobody |
systemctl reload ssh |
Nach einem reload des SSH-Daemons sollte man sich nun mit den hinterlegten SSH public keys anmelden können.
Troubleshooting
ldapsearch konfigurieren
Damit man mit ldapsearch im ActiveDirectory suchen kann, muss in der Konfiguration von ldap unter: /etc/ldap/ldap.conf noch das Zertifikat von SAMBA und nicht das Standard eingetragen werden:
#TLS_CACERT /etc/ssl/certs/ca-certificates.crt TLS_CACERT /var/lib/samba/private/tls/cert.pem |
Ansonsten erhält man bein Zugriff die Meldung:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) |
Danach kann man ldapsearch so zugreifen:
ldapsearch -x -H "ldaps://dc01.ad.example.net:636" -D administrator@ad.example.net -W -b "DC=ad,DC=example,DC=net" cn=guest |
ldbsearch funktioniert nicht mit SSL und kereros
Wenn man versucht ldbsearch mit SSL und Kerbereos zu benützen, bekommt man die Fehlermeldung:
ldbsearch -H ldaps://dc01 "cn=administrator" -k yes TLS failed to missing crlfile - with 'tls verify peer = as_strict_as_possible' Failed to connect to ldap URL 'ldaps://dc01' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER_MIX Failed to connect to 'ldaps://dc01' with backend 'ldaps': (null) Failed to connect to ldaps://dc01 - (null) |
Diese Kombination wird von samba nicht unterstützt, weil es auch keinen Sinn macht, da Kerberos selbst schon verschlüsselt. 😉
Replikation klappt nicht
Ruft man:
samba-tool drs showrepl |
auf, erhält man einen Fehler wie:
DC=ForestDnsZones,DC=ad,DC=example,DC=net Default-First-Site-Name\DC02 via RPC DSA object GUID: 1b44348a-bf0f-43bd-9968-5aa47c12af89 Last attempt @ Wed Jun 13 14:57:38 2018 CEST failed, result 2 (WERR_BADFILE) 278 consecutive failure(s). Last success @ NTTIME(0)
Zunächst kann man den „Knowledge Consistency Checker“ (KCC) laufen lassen, um zu sehen ob es ein Verbindungsproblem zwischen den DCs gibt:
samba-tool drs kcc -UAdministrator |
Dann kann man die Replikation Manuell testen (jeweils vor und zurück):
samba-tool drs replicate dc02 dc01 CN=Configuration,DC=ad,DC=example,DC=net samba-tool drs replicate dc01 dc02 CN=Configuration,DC=ad,DC=example,DC=net |
Hier erhält man dann möglicherweise eine Fehlermeldung wie diese:
ERROR(<class 'samba.drs_utils.drsexception'="">): DsReplicaSync failed - drsException: DsReplicaSync failed (2, 'WERR_BADFILE') File "/usr/lib/python2.7/dist-packages/samba/netcmd/drs.py", line 348, in run drs_utils.sendDsReplicaSync(self.drsuapi, self.drsuapi_handle, source_dsa_guid, NC, req_options) File "/usr/lib/python2.7/dist-packages/samba/drs_utils.py", line 83, in sendDsReplicaSync raise drsException("DsReplicaSync failed %s" % estr) |
Nun sollte man überprüfen ob die speziellen DNS-Einträge, welche beim hinzufügen jedes DCs angelegt werden sollten auch wirklich angelegt wurden; denn ab und zu gehen diese beim join „vergessen“.
Alle DCs mit deren objectGUID’s lassen sich wie folgt auflisten:
ldbsearch -H /var/lib/samba/private/sam.ldb '(invocationid=*)' --cross-ncs objectguid |
Nun überprüft man für jeden DC ob dessen objectGUID im DNS eingetragen ist:
host -t CNAME ._msdcs.ad.example.net
samba-tool dns query dc01 _msdcs.ad.example.net CNAME |
Wird ein Eintrag nicht gefunden, muss dieser Manuell hinzugefügt werden:
samba-tool dns add dc01 _msdcs.ad.example.net CNAME .ad.example.net |
DNS-Eintrag wird beim hinzufügen eines (Linux-) Clients nicht automatisch erstellt
Damit beim hinzufügen (join) eines Clients der DNS (A-Record) Eintrag automatisch gemacht wird, muss dieser Zuvor auch mit FQDN im hosts file stehen:
/etc/hosts
[...] 192.168.1.101 client01.ad.example.net client01 [...] |
Ist das beim join nicht der Fall wird kein DNS-Eintrag erstellt.
Dann kann man diesen nachträglich Manuell erstellen mit:
samba-tool dns add dc01 ad.example.net client01 A |
Der Reverse-Eintrag (PTR-Record) wird leider nie automatisch erstellt und muss immer manuell hinzugefügt werden:
samba-tool dns add dc01 1.168.192.in-addr.arpa 101 PTR client01.ad.example.net |
testparm Meldung: rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Bekommt man beim Aufruf von testparm
die Meldung:
Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) |
muss das ulimit erhöht werden:
ulimit -n 16384 (temporär) |
/etc/security/limits.conf (permanent)
* - nofile 16384 |
Keine LDAP-Verbindung von externen hosts
Möchte man eine LDAP-Abfrage von einem externen host, beispielsweise dem Fileserver machen, schlägt dies fehl:
ldapsearch -x -H "ldaps://dc01.ad.example.net" -D administrator@ad.example.net -W -b "DC=ad,DC=example,DC=net" cn=administrator Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) # Im debug Modus (-d 1) zusätzlich: TLS certificate verification: Error, unable to get local issuer certificate |
Dies liegt daran, dass der lokale ldap-client Standardmässig zwingend das CA Zertifikat des DCs will.
Dies lässt sich abschalten, indem man in die Datei: /etc/openldap/ldap.conf die Zeile:
TLS_REQCERT never |
einfügt.
Alternativ kann man das CA-Zertifikat auch vom DC rüber kopieren:
Vom DC das CA-Zertifikat unter: /var/lib/samba/private/tls/ca.pem (nicht das cert.pem!) kopieren, z.B. nach: /etc/openldap/certs/ (CentOS).
Dann trägt man in: /etc/openldap/ldap.conf einfach folgendes ein:
TLS_CACERT /etc/openldap/certs/ca.pem |
Ausserdem ist es dann noch wichtig, dass man den vollen FQDN host zum Verbinden nimmt, also: „ldaps://dc01.ad.example.net“ und nicht etwa: „ldaps://dc01“.
Informationen dazu im Post: Performing ldapsearch over TLS/SSL against Active Directory und dem Samba SSL HowTo.
[stextbox id=“tip“ caption=“Hinweis“]
Ein gutes Tool um das Active Directory zu durchsuchen ist der AD Explorer.
[/stextbox]
Quellen
Besonderen dank gilt an Stefan Kania, mit dessen Buch: Samba 4 ich mir das Wissen ereignen konnte einen stabiles Samba Active Directory aufzubauen.
- wiki.samba.org: BIND9 DLZ DNS Back End
- wiki.samba.org: Changing From the Samba Internal DNS Server to the BIND9_DLZ Back End
- wiki.samba.org: Roaming Windows User Profiles
- wiki.samba.org: Setting up a Share Using Windows ACLs
- wiki.samba.org: Configuring LDAP over SSL (LDAPS) on a Samba AD DC
- wiki.samba.org: Installing RSAT
- wiki.samba.org: Authenticating Domain Users Using PAM
- wiki.samba.org: Configure DHCP to update DNS records with BIND9
- Samba 4 Troubleshooting Guide
- Samba 3: testparm meldet „rlimit_max (1024) below minimum Windows limit (16384)“
- Lsyncd – Lokale Dateien mit mehreren Servern synchronisieren
- How to Synchronize Directories Using Lsyncd in Linux
Wow, thats hardcore – Danke für die ausführliche (deutsche) Anleitung, das bringt mir vereinfacht Klarheit in den Ablauf! Wertvoll finde ich auch die cronjobs für die Replikation. Mein Ziel: Ablösung von Win2003/08 Server. Das wird ja noch spannend…
Erstklassiges Tutorial. Vielen Dank für Deine Arbeit. Habe soeben zwei DC aufgesetzt. Der Tipp mit dem CNAME Eintrag war Gold wert.
Prinzipiell gutes Tutorial, unter Ubuntu 18.04.02 LTS Server startet allerdings der SAMBA Daemon nicht.
# systemctl status samba-ad-dc
● samba-ad-dc.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
# systemctl start samba-ad-dc
Failed to start samba-ad-dc.service: Unit samba-ad-dc.service is masked.
# service smbd restart
Jun 11 07:37:08 dc01 smbd[1133]: [2019/06/11 07:37:08.727111, 0] ../source3/smbd/server.c:1815(main)
Jun 11 07:37:08 dc01 smbd[1133]: server role = 'active directory domain controller' not compatible with running smbd standalone.
Jun 11 07:37:08 dc01 smbd[1133]: You should start 'samba' instead, and it will control starting smbd if required
Jun 11 07:37:08 dc01 systemd[1]: smbd.service: Main process exited, code=exited, status=1/FAILURE
Jun 11 07:37:08 dc01 systemd[1]: smbd.service: Failed with result 'exit-code'.
Jun 11 07:37:08 dc01 systemd[1]: Failed to start Samba SMB Daemon.
# service samba restart
Failed to restart samba.service: Unit samba.service not found.
Workaround für Ubuntu Server:
sudo systemctl disable nmbd
sudo systemctl disable smbd
sudo systemctl unmask samba-ad-dc
sudo systemctl enable samba-ad-dc
danke!
Danke für das tolle Tutorial.
Ich hänge leider beim starten des samba-ad-dc Deamon fest. Ich nutze Ubuntu 18.04.3 LTS. Selbst mit Hilfe Dennis‘ Kommentar ende ich immer im Timeout. Hat jemand einen Tip für mich?
Habe das selbe Problem mit dem Timeout wie Oliver, die Logfiles meinen:
*** systemctl status samba-ad-dc.service / journalctl -xe ***
— The leading process of the session is 5943.
Okt 28 19:36:14 S-DC1 systemd[1]: samba-ad-dc.service: Start operation timed out. Terminating.
Okt 28 19:36:14 S-DC1 samba[5903]: [2019/10/28 19:36:14.104293, 0] ../source4/smbd/process_standard.c:86(sigterm_signal_handler)
Okt 28 19:36:14 S-DC1 samba[5903]: Exiting pid 5903 on SIGTERM
Okt 28 19:36:14 S-DC1 systemd[1]: samba-ad-dc.service: Main process exited, code=exited, status=127/n/a
Okt 28 19:36:14 S-DC1 samba[5909]: [2019/10/28 19:36:14.105483, 0] ../source4/smbd/process_standard.c:86(sigterm_signal_handler)
Okt 28 19:36:14 S-DC1 samba[5909]: Exiting pid 5909 on SIGTERM
Okt 28 19:36:14 S-DC1 samba[5914]: [2019/10/28 19:36:14.105574, 0] ../source4/smbd/process_standard.c:86(sigterm_signal_handler)
Okt 28 19:36:14 S-DC1 samba[5914]: Exiting pid 5914 on SIGTERM
Okt 28 19:36:14 S-DC1 samba[5916]: [2019/10/28 19:36:14.105767, 0] ../source4/smbd/process_standard.c:86(sigterm_signal_handler)
Okt 28 19:36:14 S-DC1 samba[5916]: Exiting pid 5916 on SIGTERM
Okt 28 19:36:14 S-DC1 samba[5905]: [2019/10/28 19:36:14.105818, 0] ../source4/smbd/process_standard.c:86(sigterm_signal_handler)
Okt 28 19:36:14 S-DC1 samba[5905]: Exiting pid 5905 on SIGTERM
Okt 28 19:36:14 S-DC1 samba[5904]: [2019/10/28 19:36:14.105883, 0] ../source4/smbd/process_standard.c:86(sigterm_signal_handler)
Okt 28 19:36:14 S-DC1 samba[5904]: Exiting pid 5904 on SIGTERM
Okt 28 19:36:14 S-DC1 systemd[1]: samba-ad-dc.service: Failed with result ‚timeout‘.
Okt 28 19:36:14 S-DC1 systemd[1]: Failed to start Samba AD Daemon.
*** Syslog ***
Oct 28 19:34:44 S-DC1 systemd[1]: Starting Samba AD Daemon…
Oct 28 19:34:44 S-DC1 samba[5879]: [2019/10/28 19:34:44.072932, 0] ../source4/smbd/server.c:448(binary_smbd_main)
Oct 28 19:34:44 S-DC1 samba[5879]: samba version 4.7.6-Ubuntu started.
Oct 28 19:34:44 S-DC1 samba[5879]: Copyright Andrew Tridgell and the Samba Team 1992-2017
Oct 28 19:34:44 S-DC1 samba[5879]: [2019/10/28 19:34:44.741827, 0] ../source4/smbd/server.c:620(binary_smbd_main)
Oct 28 19:34:44 S-DC1 samba[5879]: samba: using ’standard‘ process model
Oct 28 19:34:44 S-DC1 samba[5908]: [2019/10/28 19:34:44.765907, 0] ../source4/lib/tls/tlscert.c:72(tls_cert_generate)
Oct 28 19:34:44 S-DC1 samba[5908]: Attempting to autogenerate TLS self-signed keys for https for hostname ‚S-DC1.ad.schulz.intern‘
Oct 28 19:34:44 S-DC1 samba[5911]: [2019/10/28 19:34:44.777105, 0] ../source4/smbd/service_task.c:35(task_server_terminate)
Oct 28 19:34:44 S-DC1 samba[5911]: task_server_terminate: [kdc: krb5_init_context samdb RODC connect failed]
Oct 28 19:34:44 S-DC1 samba[5912]: [2019/10/28 19:34:44.779637, 0] ../source4/smbd/service_task.c:35(task_server_terminate)
Oct 28 19:34:44 S-DC1 samba[5915]: [2019/10/28 19:34:44.780678, 0] ../source4/smbd/service_task.c:35(task_server_terminate)
Oct 28 19:34:44 S-DC1 samba[5912]: task_server_terminate: [dreplsrv: Failed to connect to local samdb: WERR_DS_UNAVAILABLE
Oct 28 19:34:44 S-DC1 samba[5912]: ]
Oct 28 19:34:44 S-DC1 samba[5915]: task_server_terminate: [kccsrv: Failed to connect to local samdb: WERR_DS_UNAVAILABLE
Die beiden letzten Zeilen im syslog bringen mich auch nicht weiter, hängt wohl mit neuer Samba-Version nach Updates zusammen.
Irgendwelche Ideen?
Als Windows Administrator dreht sich mir jedes Mal der Magen um wenn ich PDC, SDC etc in einer AD-Umgebung lese und ich bekomme Schwierigkeiten zu Verstehen, was der Author sagen möchte.
In einem Active Directory gibt es eine PDC-Emulator, aber keinen PDC. Somit kann es auch keinen BDC/SDC geben.
In einem ADC gibt es eine Multi-Master-Replikation, somit ist jeder Domain Controller gleichberechtigt und hält auch alle Rollen bereit.
Es kann also nur den ersten Active Directory Controller geben, den man aufsetzt um ein AD bereit zustellen.
Dieser MUSS ein stabiles DNS bereitstellen (75% aller Fehler haben ihre Ursache im DNS).
Anschließend lassen sich nur Member Server hinzufügen, die im AD aufgenommen werden, die dann wiederum zum ADC hinaufgestuft werden können. Wichtig (!). Die aktuelle Zeit/Datum auf dem hinzuzufügenden Computer darf nicht mehr als 5 Minuten von der Zeit des AD abweichen.
Böse Administratoren verringern sogar die Tolleranz 🙂
Allerdings lassen sich diese Schritte auch zusammenfassen und eine Server kann gleich als ADC arbeiten.
Die Funktionsrollen (FSMO) liegen in der Regel immer aus dem zuerst aufgesetzten ADC, lassen sich aber verschieben, selbst wenn der erste Controller abgeraucht ist (da auf jeden DC die Rollen repliziert werden, aber nicht aktiv sind).
Der Global Catalog (GC) kann nur auf einem ADC liegen, kann und sollte aber auf mindesten zweien liegen.
Nur an einem ADC der einen GC bereithält kann sich der Benutzer/Computer anmelden.
Ja, auch die Computer müssen sich am ADC authentifizieren.
Ein Member Server ist lediglich ein Mitglied der Domain, so wie jeder Client und kann Applikationen wie File Services, SQL ö. ä. bereitstellen. Innerhalb des ADs ist in der Regel keine weitere Authentication notwendig (SSO), das machen de Rechner unter sich mittels Kerberostickets aus.
Standalone Server können lediglich Mitglied einer Workgroup sein und stellen eigene (!) Anmelde Daten zu Authentication bereit.
Die Anmelde Konten werden also dezentral auf jedem Computer verwaltet, nur wer die passen den Daten hat kann sich anmelden. Damit sich ein Client oder Standalone Server am ADC anmelden kann muss also im AD ein Konto und Passwort hinterlegt sein und – der anmeldende Benutzer muss sich mit genau diesen Daten anmelden (WORKGROUP/USER Password).
Ich hoffe ich habe ein wenig zum Verständnis beigetragen und hoffe das die Altlasten aus NT4-Zeiten endlich aus den Köpfen verschwinden.
Ein NT4 Server kann kein Active Directory bereitstellen, das geht erst ab Windows Server 2000. NT4 kann bestenfalls ein Member Server werden und selbst dann ist der eine Krücke.
Ich glaube, das auch nur die wenigsten in der Lage sein werden einen NT4 Server heute noch zu aktualisieren und ins Internet zu bekommen.
Vielen Dank für die ausführlichen Zusatz-Informationen, Dieter! 😃
Es stimmt natürlich schon, dass Linux-Administratoren nicht das selbe tiefgreifende Fachwissen zum Active Directory haben, wie Windows-Admins. 😉 Auch basiert die „AD-Implementation“ auf Linux/SAMBA noch grösstenteils auf Windows 2000 und zahlreiche Möglichkeiten, die man mit einem „echten“ Windows Active directory in aktuelleren Windows-Server Versionen hat, sind so nicht möglich. Der Linux-Admin ist meist schon zufrieden, wenn er das SAMBA-AD als authentifizierungs/authorisierungs Quelle für andere Applikationen (single sign-on) nutzen kann. 😄
Ich verstehe in der Tat den Standpunkt der Linux Administratoren, aber ihr wollt eine Windows AD emulieren und dann sollte man natürlich sich auch an die Spielregeln der Vorlage halten.
Ich halte Deine Anleitung, trotz meiner Kritik, für eine der am besten gelungen Anleitungen überhaupt.
Noch ein paar Bemerkungen zur Anregung und Überarbeitung.
Fehler in dieser Doku:
“ Nun muss die samba Konfigurationsdatei wie folgt (neu) erstellt werden:
>/etc/samba/smb.conf
“
In der in /etc/hosts sollte immer der fqdn dens Servers eingetragen sein
also
127.0.0.1 localhost
192.168.1.10 dc01.meinedomain.loc dc01
Zur Verbesserung.
Warum haben wir denn einen zweiten DC aufgesetzt?
Natürlich als Failover und zum Lastenausgleich. Der Failover ist die wichtigste Funktion, also muss sichergestellt sein, das sowohl der DC, KCC, der NTP und auch der lsyncd umschalten.
Der DC auf dem der PDC-Emulator läuft stelle IMMER ALLEIN die Zeit innerhalb der Domain zur Verfügung, also der Master of Desaster.
Jeder andere DC, Member Server oder Client hat sich danach zu richten, sie tun es auch sobald sie Mitglied in der Domain sind, was aber bei einem Fail Over?
Mit einem script (quick and dirty) lässt sich ermitteln wer die PDC Rolle hält und wo die Zeitquelle liegt, diese kann dann dem lokalem NTP-Server untergejubelt werden.
Vorsicht, wenn das DNS zickt, kommt Müll raus.
—————–
# PDC an den NTP
ldapstr=“_ldap._tcp.pdc._msdcs.meinedomain.loc“
PDC=$( nslookup -type=any $ldapstr | grep $ldapstr | sed ’s/.* //‘ )
PDC=${PDC:0:-1}
# echo $PDC
cat < /etc/PDC.conf
server ${PDC} burst prefer
EOFPDC
systemctl restart ntp
————-
Wie erwähnt, bei den Windows Servern/Rechnern ist das nicht notwendig.
Es stellt sich dann noch die Frage ob die PDC-Rolle unter Samba selbstständig wechselt, wenn nicht muss die dazu genötigt werden.
Es gibt keinen Grund WINS zu benutzen, das ist ein Relikt aus der Frühzeit und wird nur noch in alten Umgebungen (<= XP/2003) genutzt.
Eine weitere interessante Möglichkeit bietet das AD bei der Verwaltung von Zertifikaten, die sich dort ablegen und leicht verteilen lassen.
So richtig spannend wird eine derartige Konstruktion sowieso erst, wenn man als ersten DC einen echten Windows Server nutzt.
hallo und vielen Dank
Das ist ja eine ausführliche Anleitung die ich gerne umsetzen will obwohl es im Netz nur ein paar User hat.
Aber noch 2 fragen,
1) ich habe auf einer VM eine ISP Installation dort sind web und Mailserver aber eben auch schon ein BIND Server für die Homepage mapping. Ist es vernünftig einen zweiten Bind einzurichten und gibt es eine möglichkeit die Infos vom ersten BIND zu lernen?
2) ich habe eine VM auf der CUPS läuft an dem ein Printer angeschlossen ist. wie kann ich diese VM Integrieren damit alle
a) den Drucker nützen können
b) die richtigen Treiber zur Verfügung gestellt werden?
vielen Dank
gruss
vinc
Zu deinen Fragen:
1) Da das Samba Active Directory mit Dynamic Loadbale Zones arbeitet, bzw. den Bind mittels einer Dateibasierten Datenbank auf dem AD Domain Controller füttert, ist es nicht möglich einen externen bind für das Active Directory zu verwenden; bind muss dafür zwingend auf den AD Domain Controllern laufen.
Was möglich wäre, wäre die externen Zonen auf dem AD-Bind zu konfigurieren, sofern dieser von aussen erreichbar ist. Das ist aber schon aus Sicherheitsgründen generell nicht empfehlenswert und es ist allgemein besser für die internen und externen Zonen je einen eigenen Nameserver zu betreiben (ich mache das selbst auch so).
2) Ich habe das Samba Printer Sharing zwar schon ewig nicht mehr verwendet, aber sobald die VM mit CUPS als Active Directory Client am AD angebunden ist, sollte sich der Drucker problemlos teilen lassen, ganz wie auf einem Windows Printserver. Zur Einrichtung dessen habe ich ein seperates Tutorial geschrieben: https://www.tech-island.com/tutorials/homeserver/services/printserver 🙂
Moin,
vielen Dank für das Tutorial 🙂 Ich habe den ersten Teil streng nach deinem Tutorial gemacht. Den ersten Fehler konnte ich Dank des Tipps weiter unten lösen und samba-ad-dc lies sich enablen. Leider kommt es nun zu dem Fehler „exit_daemon: daemon failed to start: Samba failed to prime database, error code 22“ wenn ich samba-ad-dc starten möchte. Ich setze Ubuntu 20.04 lts ein. Kennst du oder jemand hier diesen Fehler?
Hallo Steven,
dein Tutorial ist wirklich ausführlich und gelungen! Danke fürs Teilen 😊
Eine Anmerkung für alle Leser, schaut euch Mal lxc Container an und betreibt eure samba Server in diesen. Bietet ganz interessante Ansätze – so lässt sich auch AD, File und Printserver schön auf einer Maschine betreiben.
Schöne Grüße
Manfred