Dummerweise betreiben Menschen Windows-AD-Server. Meistens, weil sie bereits Windows-Clients nutzen und weil sie zuvor bereits PDCs eingesetzt haben.
Eine AD kombiniert DNS, DHCP, Kerberos, LDAP und Samba. Es gibt nun also tatsächlich ein TCP/IP-Netzwerk, kein netbios mehr und die zentrale Verwaltung wird mittels LDAP gewährleistet, welches sogar (und dummerweise) Kerberos ins LDAP integriert.
Für Server und Clients sollte die Uhrzeit syncron gehalten werden, d.h. si esollten auch in der selben Zeitzone sein:
ls -l /etc/localtime AD
Das Problem ist hauptsächlich ein AD einzurichten, da Windows ein gewachsenes System ist und die Konfiguration über Programme geschieht. Wir richten mit der AD eine Domäne ein, in der auch der AD-Server als Domänen-Controller arbeitet.
Erstens sollte man die Netzwerkkarten eirichten. eine statische Adresse für den Server im internen Netz vergeben, die Netzwerkkarten entsprechend umbenennen (extern, intern).
In w2k-Windows-Servern sollte man zweitens DHCP und DNS einrichten. Dies geschieht über das Hinzufügen von Rollen. Dabei sollte man die Server auf die nötigenn Interfaces beschränken.
Drittens sollte man RAS (unter welchem Namen es auch immer unter Rollen liegt) einrichten, dies ermöglicht das Forwarding und Masquerading auf der externen Netzwerkkarte.
Viertens soltle man nun die Rolle des AD-Domain-Controllers hinzufügen. Hier wird der LDAP-Tree erzeugt.
Der AD-Server wird die vorhergehenden Services verändern. Man muss u.a. den DHCP Server Authorisieren (d.h. vermutlich authoritative setzen) bzw. alles nochmals prüfen.
Am Ende müssen die (neu angelegten) User wie auch die (Linux-)Maschinen in die AD-Domäne aufgenommen werden.
Clients
Um die Linux-Clients in die AD zu bekommen, ist es nötig,
dass sie per DNS ansprechbar sind. Dies kann man per ping bzw. Aufruf von Adressen prüfen.
Zudem müssen sie Kontakt zum LDAP erhalten und die Kerberos-Tickets verarbeiten können.
Außerdem nutzen wir Samba mit winbind, welches den Client in die AD-Domäne einbindet.
Die Pakete unterscheiden sich zwischen Debian und RedHat:
Debian 8
krb5-user
samba-client
winbind
libnss-winbind
libpam-winbind
CentOS 7
krb5-workstation
samba-client
samba-winbind-client
Wir müssen den Kerberos-Client konfigurieren und den Samba-Cleint. Zudem müssen wir noch die nsswitch und die Pam.d-Dateien anpassen.
Bei Debian wird immer noch der nscd gestartet. Diesen sollte man disablen oder zumindest für die Zeit der Konfiguration stoppen.
Kerberos
Wir bearbeiten die Datei /etc/krb5.conf. Wir müssen die Domäne angeben und die realms einrichten.
[libdefaults]
...
default_realm = DOMÄNE.LAN
[realms]
DOMÄNE.LAN = {
kdc = adhost.domäne.lan
admin_server = adhost.domäne.lan
default_domain = domäne.lan
}
[domain_realm]
.domäne.lan = DOMÄNE.LAN
domäne.lan = DOMÄNE.LANWir prüfen die Funktionsfähigkeit mit kinit und klist, ob ein Ticket für den Administrator auf der AD-Maschine vergeben wird:# kinit Administrator# klist
Samba
In der /etc/samba/smb.conf tragen wir die notwendigen Dinge ein:
[global]
workgroup = DOMÄNE
realm = DOMÄNE.LAN
security = ads
idmap uid = 10000-20000
idmap gid = 10000-20000
template homedir = /home/%D/%U
template shell = /bin/bash
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yesWir schauen mit testparm, ob die Konfiguration in Ordnung ist.
Maschine zur Domain hinzufügen
Die Maschine muss zur Domäne hinzugefügt werden.
# net ads join -U Administrator%passWortNun sollte die Maschine angemeldet sein, was man auf der AD-Maschine unter Ad-Domain-Controller sehen in der Domäne sehen kann.
Winbind
Nun müssen wir uns noch um die Anmeldung der User kümmern und die Maschine in die Doäne eintragen. Windows AD verwaltet eben nicht nur User, sondern auch Maschinen.
/etc/nsswitch ergänzen wir:
passwd: files winbind
group: files winbindBei CentOs steht dort zusätzlich noch der sss-Daemon in den Zeilen.
Num müßten wir über #getent passwd oder #wbinfo -u die User auf dem AD-Server angezeigt bekommen.
Wir müssen die Winbind-Anmeldung über PAM ermöglichen. Am einfachsten macht man dies über die entsprechenden Ncurses-Programme pam-auth-update bzw. authconfig-tui. Die authconfig-tui unter CentOS macht allerdings auch einigen Scheiß in der smb.conf und krb5.conf, die dann nochmals überprüft werden sollten, ist aber gut für die pam-Module. Eventuell sollte man dies Programm vor den Anpassungen von smb.conf und krb5.conf ausführen.
Ansonsten müssen wir das händisch vornehmen für die verschiedenen Management-Gruppen in PAM (auth, session, account, password bzw. bei Debian die entsprechenden common-Dateien). Die richtige Position habe ich aus Faulheit nun nicht angezeigt:
Debian:
auth sufficient pam_winbind.so use_first_pass
account [success=1 new_authtok_reqd=done default=ignore] pam_winbind.so
password sufficient pam_winbind.so use_authtok try_first_pass
session optional pam_winbind.soCentOS:
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
session optional pam_winbind.soZudem ergänzen wir /etc/pam.d/common-session bzw. unter CentOS /etc/pam.d/system-auth und passord-auth am Ende der Dateien, um den Usern bei der Anmeldung ein Home-Verzeichnis zu garantieren:
session optional pam_mkhomedir.so umask=077Nun muss der Service winbind gestartet werden:
# systemctl start winbind.servicebzw.
# service winbind start Ergebnis
Nun sollten über die unprivilegierte login-shell die User, die auf der Windows-Maschine verwaltet werden, angemeldet werden können.