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 seitens der Net Ads Tools der Samba Suite die Generierung von Keytab Files direkt vom betroffenen Linux oder Unix Host aus vorgesehen. Dafür sollte sich der Active Directory-Administrator per SSH unter Verwendung seines persönlichen Accounts einloggen und die bereits weiter oben realisierte sudo su root Funktion nutzen, um als lokaler Administrator agieren zu können. Die Ausführung der Net Ads-Befehle # net ads keytab create -U adamin@AUSTRIA.LOCAL sowie # net ads keytab add HTTP -U adadmin@AUSTRIA.LOCAL erzeugt zwar ein lokales Keytab File unter /etc/krb5.keytab, welches mittels # net ads keytab list eingesehen werden kann, dennoch schlägt eine Verifizierung mittels kinit unter der Verwendung des Keytab Files fehl, da der Service Principal für den HTTP-Dienst nicht in der KDC-Datenbank hinzugefügt wird und folgende Fehlermeldung retourniert wird: KDC_ERR_S_PRINCIPAL_UNKNOWN. Diese Einschränkung seitens Samba bedingt den Bruch eines nahtlosen Workflows zur effizienten Servicedefinition. Als Workaround muss der Prozess zur Generierung von einem Windows Host aus erfolgen und das Keytab File auf gesichertem Weg über das Netzwerk übertragen werden. Eine weitere Einschränkung ergibt sich dadurch, dass das Windows Tool zur Erzeugung von Keytab Files (ktpass) jeweils nur ein Service zu definieren in der Lage ist - im Zuge dessen Generierung wird aber ein neues Passwort generiert beziehungsweise bei Verwendung desselben Passworts die Key Version Number (KVNO) am KDC inkrementiert. Vorhandene Keytab Files werden somit in jedem Fall unbrauchbar. Als eine mögliche Variante wird in Anlehnung an die Vorgehensweise bei Application Pools des Microsoft Internet Information Server (IIS) vom Active Directory-Administrator ein Dienstkonto erstellt, mit dem der SPN verknüpft werden kann. Im vorliegenden Beispiel wird ein Konto AUSTRIA\dk_atredhat2015 erstellt und anschließend mit der Funktion ktpass der Service Principal erzeugt, mit dem Benutzerobjekt gemappt und ein Keytab File generiert: C:\Users\adadmin>ktpass /princ ? HTTP/atredhat2015.austria.local@AUSTRIA.LOCAL ? mapuser AUSTRIA\dk_atredhat2015 ? +rndPass ? -ptype KRB5_NT_PRINCIPAL ? -crypto RC4-HMAC-NT ? -out keytabs\atredhat2015.keytab. Das Service HTTP/atredhat2015.austria.local ist nun in der KDC-Datenbank mit einem normalen Benutzerkonto verknüpft. Ein Webservice, das dieses Keytab File nun nutzt, verwendet somit die Zugangsinformationen des Domänenbenutzers (in diesem Fall jene des Dienstkontos) um seine Identität gegenüber dem KDC als auch gegenüber dem aufrufenden Principal zu beweisen - ein Widerspruch zum Konzept des Kerberos-Protokolls, da dieses ein Vertrauen gegenüber dem Host voraussetzen würde. Um eine dauerhafte Funktion dieses Kontrukts zu gewährleisten, müssen für das Dienstkonto noch die Optionen 'User cannot change password', 'Password never expires' und 'Trust this user for delegation to any service (Kerberos only)' aktiviert werden. Ansonsten würde eine Group Policy des Active Directory den virtuellen Benutzeraccount nach zum Beispiel 30 Tagen zur Änderung seines Passworts auffordern. Die Option zur Delegation wird notwendig, wenn das Webservice im Namen des aufrufenden Principals beispielsweise auf ein Datenbank-Backend zugreifen müsste.