Kerberos in heterogenen Netzwerken: Windows und Linux gemeinsam mit Active Directory Services verwalten

Textprobe:

Kapitel 5.3.8, Test der Implementierung:

Der letzte Schritt zur Implementierung eines Linux-Clients in ein Active Directory dient dem Test der durchgeführten Konfiguration. Nach einem Neustart des Computers ist zu verifizieren, ob die benötigten Dienste (Network, Zeitserver, Winbind) verfügbar sind. Mittels # net ads info werden die Serververbindungen zu LDAP, Domain Controller und KDC sowie ein Server Time Offset (Abweichung zwischen lokaler Zeit und jener des Servers) ausgegeben. Mitglieder der Domain-Gruppen AD_UX_Users sowie AD_UX_Admins ist es nun möglich, sich mit den üblichen Windows Credentials der Domäne AUSTRIA am System anzumelden. Die Benutzer, die der Gruppe AD_UX_Admins angehören, haben die Möglichkeit mittels dem sudo Befehl Anweisungen mit erweiterten Rechten durchzuführen und sind dadurch in der Lage, das gesamte System zu administrieren. Dabei kann auch zu lokal definierten Service-Accounts gewechselt werden, ohne deren Passwörter kennen zu müssen. Durch eine Strukturierung der Active Directory-Gruppen und einem entsprechenden Mapping in der sudoers Konfigurationsdatei wird somit eine transparente Zuweisung von Rechten durch eine zentrale Stelle ermöglicht, deren Granularität sich ohne großen Aufwand anpassen lässt.
Zusammenfassend zeigt sich, dass durch Editieren von fünf Konfigurationsdateien (siehe Anhang A) eine Anbindung eines Linux/Unix Hosts in ein Active Directory realisiert werden kann:

- /etc/krb5.conf.
- /etc/samba/smb.conf.
- /etc/nsswitch.conf.
- /etc/pam.d/system-auth-ac.
- /etc/sudoers.
Während bei Vorliegen der bereits weiter oben dargelegten administrativen Voraussetzungen die Konfiguration von Kerberos, des NSS-Moduls und der sudoers Datei zielgerichtet vorgenommen werden kann, erfordern die Einstellungen der Module Winbind und PAM eine umfangreichere Kenntnis der jeweiligen Dokumentation. Sollten die Konfigurationen bei abweichenden Distributionen als der in dieser Studie verwendeten erfolgen, empfiehlt es sich, die Änderungen schrittweise nach dem vorliegenden Schema vorzunehmen. Andernfalls wird ein Debugging durch unterschiedlichste Seiteneffekte wesentlich erschwert. Wichtigste Grundvoraussetzung für eine optimale Funktion sind korrekte Netzwerkeinstellungen (im Besondern der FQDN in der /etc/hosts), die Zeitsynchronisierung mit dem KDC sowie ein korrektes Computer-Konto innerhalb der Domäne.
Kapitel 5.4, Service Principals im Active Directory:

Der vorherige Abschnitt hatte zum Ziel, einen Linux-Client innerhalb eines Corporate Netzwork für eine bestimmte Gruppe von Active Directory-Mitgliedern zugänglich zu machen. Dieser Abschnitt behandelt nun im nächsten Schritt die Implementierung eines Services auf diesem Host. Dazu wird beispielhaft die Konfiguration eines HTTP Service angeführt. Um ein derartiges Service mittels Keberos-Authentifizierung zugänglich zu machen, muss der Dienst dem KDC bekannt sein und sich gegen diesen auch authentisieren können. Weiter oben wurde mit dem Befehl # net ads join -U admin@AUSTRIA.LOCAL createcomputer='Telekom/Graz/Linux' bereits ein Computer-Konto im Active Directory erstellt und im Zuge dessen ein generischer SPN in der Form host/f.q.d.n@REALM vergeben, der für den bisherigen Zugang genügte, um entsprechende Tickets vom KDC zu beziehen. Sollte nun, wie im vorliegenden Fall ein Webservice genutzt werden können, muss in der KDC-Datenbank ein entsprechender SPN vorhanden sein. Im Speziellen muss dieser HTTP/atredhat2015.austria.local@AUSTRIA.LOCAL lauten. Da sich jeder Principal, in der vorliegenden Annahme ein Webserver, gegen das KDC authentisieren muss um Service-Tickets zu beziehen und eine lokale Speicherung von Klartext-Passwortinformationen jeglichem Sicherheitsbestreben widerspricht, kommt zu diesem Zweck ein Keytab File zum Einsatz. Der grundsätzliche Einsatz dieser Dateien sowie deren Speicherort wurde bereits in der Samba (Winbind)-Konfiguration durch die Einträge kerberos method und dedicated keytab file definiert.
5.4.1, Authentisierung mittels Keytab Files:

Für eine nahtlose Abfolge der weiteren Implementierung wäre seite