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.

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.

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.

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

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
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
}

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 rsync synchronisiert.
Dazu wird auf dem PDC ein rsync-server eingerichtet:

/etc/xinetd.d/rsync

service rsync
{
  disable               = no
  only_from             = 192.168.1.20
  socket_type           = stream
  wait                  = no
  user                  = root
  server                = /usr/bin/rsync
  server_args           = --daemon
  log_on_failure        += USERID
}

Danach noch xinetd neu starten:

systemctl restart xinetd

Dazu die rsync Konfiguationsdatei:
/etc/rsyncd.conf

[sysvol]
path = /var/lib/samba/sysvol/
comment = Samba sysvol
uid = root
gid = root
read only = yes
auth users = sysvol-repl
secrets file = /etc/samba/rsync.secret

Und das dazugehörige secrets file:
/etc/samba/rsync.secret

sysvol-repl:geheim

Dieses noch absichern:

chmod -v 600 /etc/samba/rsync.secret

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

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.

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

Die folgenden Schritte müssen nur auf dem zweiten Domain-Controller gemacht werden.

Replikation konfigurieren

Die Datei mit dem rsync Passwort anlegen:

echo "geheim" > /etc/samba/rsync.pass
chmod -v 600 /etc/samba/rsync.pass

cronjob für die Replikation erstellen

*/5 * * * * rsync -XAavz --delete-after --password-file=/etc/samba/rsync.pass rsync://sysvol-repl@dc01/sysvol/ /var/lib/samba/sysvol/ > /dev/null 2>&1

Das wars schon mit der extra Konfiguration!

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
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!

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

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.

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

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.

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
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!

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

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 <fqdn-des-dc>

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 <objectguid>._msdcs.ad.example.net
samba-tool dns query dc01  _msdcs.ad.example.net <objectguid> CNAME

Wird ein Eintrag nicht gefunden, muss dieser Manuell hinzugefügt werden:

samba-tool dns add dc01 _msdcs.ad.example.net <objectguid> CNAME <dc-hostname>.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 <IP>

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.

Hinweis

Ein gutes Tool um das Active Directory zu durchsuchen ist der AD Explorer.

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-Zertifizierter Linux-Crack und ist seit über 15 Jahren sowohl beruflich wie auch privat auf Linux spezialisiert. In seinem Keller steht ein Server Rack mit diversen ESX und Linux Servern.

One thought 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…

Schreibe einen Kommentar

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