Mit einem normalen ldap search nach beispielsweise:
(&(objectCategory=user))Findet man alle Benutzer in einem Active Directory.
Dies beinhaltet jedoch auch deaktivierte (gesperrte) Benutzer Accounts. Zwar wird man sich so trotzdem nicht am Active Directory anmelden können, häufig will man aber der übersichtlicher in externen Applikationen diese auch gleich von der Ansicht ausschliessen.
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:
[stextbox id=“warning“ caption=“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 |
[/stextbox]
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 |
[stextbox id=“note“ caption=“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.[/stextbox]
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 |
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' |
Nun geben wir den Leuten in der Gruppe Linux-Admin noch eine sudo-Berechtigung:
echo "%linux-admins ALL=(ALL) ALL" >> /etc/sudoers.d/ad |
[stextbox id=“tip“ caption=“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 |
[/stextbox]
Um SSH login zu ermöglichen muss die Datei: /etc/pam.d/password-auth-ac mit den folgenden Einträgen ergänz werden:
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 |
[stextbox id=“note“ caption=“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.[/stextbox]
Nun wird ein home Verzeichnis fürs ActiveDirectoy erstellt, um die Übersicht über lokale- und AD Logins zu behalten:
mkdir -v /home/AD |
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 ~]$ |
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 |
[stextbox id=“note“ caption=“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.
[/stextbox]
Die einzelnen Anweisungen bedeuten folgendes:
Der Rest entspricht den Standard Apache-Authentifizierungs Konfigurationen.
[stextbox id=“tip“ caption=“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.
[/stextbox]
