Linux an Active Direcory Domäne anmelden

Um sich bei einem Linux Server über das Actice Directory authentifizieren (anmelden) zu können gibt es mehrere Möglichkeiten.
Die populärsten sind kerbereos und winbind.
Hier wird erklärt, wie man sich mit winbind über ein AD-Login bei einem Linux Server anmelden kann:

Domäne konfigurieren

Achtung
Damit das Active Directry login funktioniert, MUSS die Ausgabe von

hostname --fqdn

zwingend genau dem Domänen Namen der Windows Domäne entsprechen!
Das heisst, wenn das Clients im Active Directoy die Domäne: client.example.net haben, das Server Netz aber die Domäne: my-server.linux.example.net, wird das nicht funktionieren. Die Server, müssen dann auch den Hostnamen (fqdn) my-server.example.net haben!

Sollte der Server nicht bereits im DNS so eingetragen sein, muss der Eintrag in /etc/hosts erfolgen:

192.168.1.30 my-server.example.net my-server

Erstmal installieren wir die benötigten Komponenten:

yum install krb5-workstation pam_krb5 samba-winbind samba-winbind-clients

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

Als nächstes kommt die Kerberos Konfiguration:

/etc/krb5.conf

[libdefaults]
        default_realm = AD.EXAMPLE.NET
        dns_lookup_realm = false
        dns_lookup_kdc = true

Danach noch die samba Konfiguration in /etc/samba/smb.conf anpassen, bzw. mit den folgenden Werten ergänzen:

[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
Hinweis
Obwohl wir die smb.conf geändert haben, muss sama (smb/nmb) NICHT gestartet werden.
Die smb.conf wird in diesem Falle nur vom winbind daemon gebraucht.

Nun muss noch die Datei /etc/nsswitch.conf angepasst werden damit auf dem Server 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

Jetzt noch winbind als Autostart Konfigurieren:

systemctl enable winbind

Domäne Beitreten

Nun können wir der Domäne beitreten:

net ads join -Uadministrator

Und testen:

[root@my-server ~]# net ads testjoin
Join is OK

Danach winbind neu starten:

systemctl restart winbind

Und testen:

wbinfo -u
wbinfo -g
getent passwd 'AD\administrator'

sudo Erlaubnis für AD-Gruppenmitglieder

Nun geben wir den Leuten in der Gruppe Linux-Admin noch eine sudo-Berechtigung:

echo "%linux-admins ALL=(ALL) ALL" >> /etc/sudoers.d/ad
Gruppen mit Leerzeichen
Haben hier AD Gruppen Leerzeichen (z.B. "Domain Admins"), so lässt sich dies konfigurieren, indem man die Leerzeichen escaped:

visudo -f /etc/sudoers.d/ad
User_Alias MYADMINS=%AD\\Domain\ Admins
MYADMINS        ALL=(ALL)       NOPASSWD: ALL

SSH login

Um SSH login zu ermöglichen muss die Datei: /etc/pam.d/password-auth-ac mit den folgenden Einträgen ergänz werden:

  • auth sufficient pam_winbind.so use_first_pass
  • account [default=bad success=ok user_unknown=ignore] pam_winbind.so
  • (OPTIONAL) account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed
  • password sufficient pam_winbind.so use_authtok
  • (OPTIONAL) session optional pam_mkhomedir.so umask=0077

Das ganze sieht dann so aus:

#%PAM-1.0
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
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
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_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed
account     required      pam_permit.so
 
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_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     optional      pam_mkhomedir.so umask=0077
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Mehrere Gruppen lassen sich mit den folgenden Änderungen zuweisen:

File erstellen, indem alle erlaubten Gruppen sind

/etc/login.group.allowed

root
AD\linux-admins
Einschränkungen
Es gibt allerdings die Einschränkung dass AD Gruppen keine Leerzeichen (spaces) haben dürfen.
Hat man nur Gruppen mit Leerzeichen (z.B. "Domain Admins"), dann muss man lokale Gruppen machen und die entsprechenden Leute manuell in diese Aufnehmen.

Nun wird ein home Verzeichnis fürs ActiveDirectoy erstellt, um die Übersicht über lokale- und AD Logins zu behalten:

mkdir -v /home/AD

Testen

Nun kann das gnaze getestet werden:

tail -f /var/log/secure
$ ssh AD\\hmuster@my-server
AD\hmuster@my-server's password: 
Creating directory '/home/AD/hmuster'.
[AD\hmuster@my-server ~]$

Quellen

apache: Am ActiveDirectory authentifizieren

Den Weg Benutzer über .htaccess und .htpasswd beim apache Webserver zu authentifizieren ist hinlänglich bekannt.
Noch interessanter ist jedoch die Authentifizierung über ein Zentrales ActiveDirectory (oder einen beliebigen LDAP Server) – Und dabei ist es fast so einfach wie über die .htpasswd files.

Als erstes benötigt man das modul yum install mod_ldap:

yum install mod_ldap

Danach erstellt man im zu schützenden Web-verzeichnis einfach eine Datei mit dem Namen .htaccess und folgendem Inhalt:

# Username to bind
AuthLDAPBindDN "CN=unprivilegierter-user,OU=User Accounts,DC=ad,DC=example,DC=net"
AuthLDAPBindPassword "xxxxxx"
 
# search for users
AuthLDAPURL "ldap://ad.example.net/OU=User Accounts,DC=ad,DC=example,DC=net?sAMAccountName?sub?(objectClass=*)"
 
AuthType Basic
AuthName "WINDOWS ACCOUNT LOGIN"
AuthBasicProvider ldap
 
# Important, otherwise "(9)Bad file descriptor: Could not open password file: (null)"
AuthUserFile /dev/null
require valid-user
Hinweis bei der Verwendung von SSL (ldaps://)

Verwendet man SSL, also als AuthLDAPURL beispielsweise: ldaps://ad.example.net/, muss man im apache in der Server Konfiguration das checken des CA-Zertifikats deaktivieren, z.B. mit der folgenden Zeile in: /etc/httpd/conf.d/ldap.conf:

LDAPVerifyServerCert Off

Alternativ kann man auch das CA-Zertifikat vom LDAP-Server auf den Webserver kopieren (z.B. nach: /etc/openldap/certs/ldap_ca.crt und dann in: /etc/httpd/conf.d/ldap.conf anstelle von: LDAPVerifyServerCert Off die Option:

LDAPTrustedGlobalCert CA_BASE64 "/etc/openldap/certs/samba_ca.crt"

einfügen.

Die einzelnen Anweisungen bedeuten folgendes:

  • AuthLDAPBindDN: Dies ist der DN eines unprivilegierten users; da man beim ActiveDirectory nur schon einen user braucht um andere user zu suchen. 😉
  • AuthLDAPBindPassword: Das Passwort für diesen (system-) user
  • AuthLDAPURL: Die URL für die Domain Suche (muss mindestens ein Unterverzeichnis (OU) enthalten!)

Der Rest entspricht den Standard Apache-Authentifizierungs Konfigurationen.

mod_ldap debuggen

Falls bei mod_ldap etwas nicht funktioniert, erhält man nicht mehr als einen HTTP 500 Fehler im apacher error.log und mit dieser Info lässt sich leider nicht so viel anfangen.
Glücklicherweise gibt es die Option: LDAPLibraryDebug, welche man in der Server-Konfiguration, beipspielsweise mit der folgenden Zeile in: /etc/httpd/conf.d/ldap.conf hinzufügen kann:

LDAPLibraryDebug 7

Nach einem restart des apache servers steht dann die ganze LDAP connection info im error.log.

Hinweis: Auch SELinux kann in diesem Kontext für Probleme verantwortlich sein.

Quellen