Samba Active Directory Server

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 Rhyth­mus.
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/GruppeBerechtigungÜbernehmen für
Domain UsersOrdner Durchsuchen / Datei ausführen
Ordner auflisten / Daten lesen
Ordner erstellen / Daten anhängen
Nur diesen Ordner
CREATOR OWNERVollzugriffNur Unterordner und Dateien
Domain AdminsVollzugriffDiesen Ordner, Unterordner und Dateien
SYSTEMVollzugriffDiesen 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.

Share-Root

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.

Published by

Steven Varco

Steven ist ein Redhat RHCE- und Kubernetes CKA Zertifizierter Linux-Crack und ist seit über 20 Jahren sowohl beruflich wie auch privat auf Linux spezialisiert. In seinem Keller steht ein Server Rack mit diversen ESX und Linux Servern.

13 thoughts on “Samba Active Directory Server”

  1. 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…

  2. 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

  3. 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?

  4. 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?

  5. 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.

    1. 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. 😄

      1. 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.

  6. 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

    1. 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 🙂

  7. 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?

  8. 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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert