FAQ - KIT-Active Directory
Wenden Sie sich anschließend an die für das KIT-AD zuständigen SCC-Mitarbeiter unter Angabe Ihrer OE und Ihres Admin-Kontos, damit das Admin-Konto über die Mitgliedschaft in <OE>-Admins die notwendigen Rechte erhält.
Wenn Sie von Ihrem lokalen PC aus administrieren möchten, benötigen Sie die Remoteserver-Verwaltungstools (RSAT) von Microsoft. Diese erhalten Sie über das Download Center von Microsoft.
- Relevantes für Migration
- KIT-AD Administrationsguide
- Design Guide KIT-AD
- SCC Admin-Tools
- IDM-Objekte können nicht in diesen Bereich verschoben werden.
- Das IDM kann keine Objekte in diesen Bereich provisionieren, daher kann bspw. die Gruppenverwaltung (GV) nicht benutzt werden.
Jetzt ist das KIT-AD aber nicht autoritativ für personenbezogene Benutzerkonten und -gruppen. Diese Objekte werden vom zentralen KIT-IDM-System in das KIT-AD provisioniert. Diese Objekte dürfen daher im KIT-AD nicht gelöscht werden!
Desweiteren ist es wichtig, dass allen im KIT-AD angelegten Objekten ein überschneidungsfreier Namensraum zur Verfügung steht. Daher muss jedes Objekt mit dem OE-Kürzel beginnen. Für Einrichtungen mit langen OE-Kürzeln müssen individuelle Lösungen gefunden werden.
- Sie dürfen keine vom IDM verwalteten Benutzer oder Gruppen löschen!
- Alle von Ihnen angelegten Objekte müssen zwingend mit Ihrem OE-Kürzel beginnen, z. B. SCC-Mitarbeiter.
- Rechnername: kit-ad.scc.kit.edu
- Port: 636
- Protokoll: LDAP SSL
Der Konfiguration für Mailclients wie Thunderbird ist unter
https://www.scc.kit.edu/dienste/8318.php
dokumentiert.
An Windows-Clients, die nicht in die zentrale Domäne kit.edu integriert sind, aber das AD zur Authentifizierung nutzen, müssen nach Einschalten des LDAP-Signings angepasst werden.
Dies geht entweder über das Setzen eines Registry-Keys:
Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap wird der Wert ldapclientintegrity gesetzt (Typ: REG_DWORD - Daten oder Wert: 2)
Alternativ kann dies über die Richtlinien für lokalen Computer eingestellt werden:
Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Lokale Richtlinien - SicherheitsoptionenRichtlinie: "Netzwerksicherheit: Signaturanforderung für LDAP-Clients"
Wert: "Signatur erforderlich"
Das ist aber falsch und entspricht im Allgemeinen nicht dem im DNS veröffentlichten FQDN des Rechners. Dieser lautet üblicherweise <hostname>.<oe>.kit.edu. Diese Abweichung zwischen AD-Domänenname und Rechner-Domänenname nennt man einen "disjoint namespace".
Die richtige Vorgehensweise wäre daher, vor dem Domänenbeitritt auf den Clients in den erweiterten Systemeinstellungen das Primäre DNS-Suffix korrekt einzutragen und es bei einer Domänenmitgliedschaftsänderung nicht ändern zu lassen. Das funktioniert aber mit Windows 7 nicht zuverlässig. Stattdessen erhält man die Fehlermeldung "Fehler beim Ändern des DNS-Namens für die primäre Domäne dieses Computers...".
Daher empfehlen wir grundsätzlich, das Primäre DNS-Suffix über eine Gruppenrichtlinie (GPO) zu setzen.
Als Vorlage für eine eigene GPO können Sie die GPO des SCC mit dem Namen "SCC-DNS-SetPrimaryDNSSuffix_scc.kit.edu" verwenden.
Damit diese GPO auch funktioniert, muss der Client berechtigt sein, den ServicePrincipalName (SPN) seines eigenen Computerobjektes zu verändern. Das kann ein Client standardmäßig nicht. Hierzu müssen Sie sich an die für das KIT-AD zuständigen SCC-Mitarbeiter wenden, die über das Active Directory Attribut "msDS-AllowedDNSSuffixes" die für SPNs zulässigen DNSSuffixe steuern können.
Beachten Sie, dass im Falle einer GPO in den erweiterten Systemeinstellungen der Clients weiterhin die alten Werte angezeigt werden. Das ist aber lediglich ein kosmetisches Problem und hat keinen Einfluss auf die Funktion.
Desweiteren wirkt die GPO oftmals erst nach dem zweiten Reboot. Sie können den Erfolg entweder in den Eigenschaften des Computerobjektes im AD überprüfen oder am Client mittels ipconfig /all.
- KIT\Domain Users
- NT AUTHORITY\Authenticated Users
- NT AUTHORITY\INTERACTIVE
Über Gruppenrichtlinien hat man jetzt mind. zwei Möglichkeiten:
- Das "Login"-Recht einschränken (GPO: Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / User Rights Assignment / Allow log on locally)
- Die Mitgliedschaft der lokalen Benutzer- und Administratorengruppen explizit regeln (GPO: Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Groups)
Wenn man nicht möchte, dass sich jeder KIT-Benutzer anmelden darf, dürfen die Gruppen "KIT\Domain Users" und "NT AUTHORITY\Authenticated Users" nicht mehr enthalten sein.
Vor einiger Zeit gab es einen Patch von Microsoft für die DCs, dessen Auswirkung wir erst jetzt merken.
Ein bereits verwendetes Computerkonto muss nun zunächst gelöscht und dann neu angelegt werden (s. u.).
Das Neuanlegen des Computerkontos und die Aufnahme des Rechners müssen mit demselben Administrator-Konto erfolgen.
Wenn Sie nun ein Computer in das AD aufnehmen möchten, müssen Sie folgendermaßen vorgehen:
- Bitte gehen Sie im AD in die OU, in der das Computerkonto landen soll.
- Dann erstellen Sie hier zunächst ein neues Computerkonto
- Achten Sie darauf, dass im unteren Teil - dort steht automatisch immer "Domänen Admins" - Ihre Admingruppe <OE>-Admins angegeben wird.
- Erst jetzt gehen Sie an den Rechner und nehmen ihn in die Domäne auf.
Gruppen (sogenannte GV-Gruppen oder auch Zentrale Gruppen genannt), die über die Gruppenverwaltung (GV) angelegt wurden, haben im KIT-AD eine Zugriffsbeschränkung. Damit soll verhindert werden, dass sich Eigenschaften der Gruppe ohne Wissen der GV ändern. Für die Zentralen Gruppen ist die GV autoritativ. Änderungen (hierzu gehört auch das Löschen) an Zentralen Gruppen dürfen ausschließlich über die GV erfolgen.
"department","description","displayName","gidNumber","givenName",
"mail","sAMAccountName","sn","uidNumber","userPrincipalName",
"physicalDeliveryOfficeName","telephoneNumber",
"extensionAttribute1","extensionAttribute2","extensionAttribute3",
"extensionAttribute4","extensionAttribute5","extensionAttribute6",
"extensionAttribute7","extensionAttribute8","extensionAttribute9",
"extensionAttribute10","extensionAttribute11","extensionAttribute12",
"extensionAttribute13","extensionAttribute14","extensionAttribute15"
Desweiteren werden folgende Sicherheitseinstellungen mit einem DENY-Recht versehen:
"User-Account-Restrictions","WriteDacl","WriteOwner"
"User-Force-Change-Password","User-Change-Password"
"description","gidNumber","member","mail","sAMAccountName",
"extensionAttribute1","extensionAttribute2","extensionAttribute3",
"extensionAttribute4","extensionAttribute5","extensionAttribute6",
"extensionAttribute7","extensionAttribute8","extensionAttribute9",
"extensionAttribute10","extensionAttribute11","extensionAttribute12",
"extensionAttribute13","extensionAttribute14","extensionAttribute15"
Desweiteren werden folgende Sicherheitseinstellungen mit einem DENY-Recht versehen:
"WriteDacl","WriteOwner"
Dort hat jeder OU-Admin Schreib- und Leserechte. Der OU-Admin der Empfänger-OU kann sich das Objekt also nach Absprache mit Ihnen aus Checkpoint Charlie in seine eigene OU verschieben.
- HKLM / Software / Microsoft / Windows NT / Current Version / ProfileList
Der Eintrag "Default" kann auf einen UNC-Pfad gesetzt werden, z. B. auf \\\server\profile\default.
Diese Registry-Einstellung wiederum kann man per GPO verteilen:
- Computer Configuration / Preferences / Windows Settings / Registry
Preface
Diese Anleitung wurde exemplarisch für Debian/Ubuntu erstellt. Grundsätzlich sollte sie aber auch für andere Distributionen funktionieren.
Verwendet werden insbesondere OpenLDAP-Bibliotheken und MIT-Kerberos. Bei abweichenden Umgebungen (z.B. Heimdal-Kerberos) können größere Anpassungen nötig werden.
Es ist in diesem Ansatz nicht erforderlich, Desktop-Systeme in die KIT-Umgebung aufzunehmen.
Es ist möglich, die Anbindung rein mit LDAP durchzuführen und auf Kerberos zu verzichten, allerdings wird die Kerberos-Anbindung empfohlen, z.B. um später einfacher über das CIFS-Protokoll auf zentrale Dateifreigaben zugreifen zu können.
Diese Konfiguration setzt auf NSS-LDAP und PAM-KRB5 als kleinsten gemeinsamen Nenner. Aktuellere Ansätze wie z.B. SSSD sollten jedoch ebenfalls in Betracht gezogen werden und bieten ggf. Vorteile wie z.B. Offline-Caching beim Einsatz auf einem Notebook.
Softwareinstallation:
Unter Debian/Ubuntu werden die nötigen Packete wie folgt installiert.
„aptitude install libnss-ldap libpam-krb5 krb5-user ntp nscd“
Namensauflösung
Die Datei Namensauflösung wird in der Regel über die Datei „/etc/resolv.conf“ konfiguriert, aktuell z.B. wie folgt:
search oe.kit.edu kit.edu
nameserver 141.52.3.3
nameserver 129.13.64.5
Konfiguration Kerberos
Konfigurationsdateien:
/etc/krb5.conf
[libdefaults]
default_realm = KIT.EDU
#krb4_config = /etc/krb.conf
#krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forward = true
forwardable = true
proxiable = true
# Aktuelle Systeme verwenden sichere Mechanismen, die z.B. auf AES und SHA beruhen
# Unter Umständen können noch Betriebssysteme im Einsatz sein, die AES/SHA nicht unterstützen.
# In diesen Fällen muss ggf. explizit der Einsatz schwacher Verschlüsselung zugelassen werden.
# Sinnvollerweise sollten jedoch die eingesetzen Betriebssysteme aktualisiert/ertüchtigt werden.
#allow_weak_crypto = 1
#default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
#default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
#preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
#[realms]
# KIT.EDU = {
# kdc = kit-dc-20.kit.edu:88
# admin_server = kit-dc-20.kit.edu:749
# kpasswd_server = kit-dc-20.kit.edu:464
# default_domain = kit.edu
# }
[logging]
default = SYSLOG:INFO:DAEMON
Test
>> kdestroy
>> klist
Zeigt die Fehlermeldung „klist: No credentials cache found“ oder ähnlich.
>> kinit ab1234
Fragt das Kennwort für das Konto „ab1234“ ab und liefert keine Fehlermeldung.
>> klist
Zeigt jetzt Informationen zum vorhandenen Ticket für „ab1234∂KIT.EDU“ an.
Konfiguration LDAP
Voraussetzung: Proxyuser
Um das KIT-LDAP einzubinden wird ein Zugang über einen Proxyuser benötigt. Dazu kann ein entsprechendes Musterticket erstellt werden oder Sie können sich direkt mit einer signierten E-Mail an patrick.hagen∂kit.edu wenden. Dabei geben Sie auch den Zweck an sowie den Umfang der erforderlichen Daten, damit ggf. eine serverseitige Filterung eingerichtet werden kann.
Konfiguration /etc/ldap.conf
uri ldaps://kit-ldap-01.scc.kit.edu kit-ldap-02.scc.kit.edu/
base ou=unix,ou=IDM,dc=kit,dc=edu
ldap_version 3
binddn cn=xxx,ou=ProxyUser,ou=idm,dc=kit,dc=edu
bindpw xxxxxx
nss_base_passwd ou=People,ou=unix,ou=IDM,dc=kit,dc=edu?sub?uidnumber=*
nss_base_shadow ou=People,ou=unix,ou=IDM,dc=kit,dc=edu?sub?uidnumber=*
nss_base_group ou=Groups,ou=unix,ou=IDM,dc=kit,dc=edu nss_map_attribute
gecos displayName
ssl yes
Test
>> ldapsearch -x „(uid=ab1234)“
Liefert Informationen zum Konto „ab1234“
Absicherung von /etc/ldap.conf
Die Konfigurationsdatei enthält die Zugangsdaten, mit denen der Proxyuser auf den LDAP-Dienst zugreifen kann und muss daher angemessen geschützt werden. Per Default wird diese Datei jedoch als „Lesbar für alle Nutzer“ eingerichtet, da jeder Nutzer Konten und Gruppen auflösen muss.
Die Dateirechte können jedoch auf „lesbar für root“ eingeschränkt werden, wenn man zusätzlich den mit root-Rechten laufenden Dienst „nscd“ installiert.
Auflösung von Unix-Konten bzw. Einrichtung von NSS
Konfiguration /etc/nsswitch.conf
passwd: compat ldap
group: compat ldap
shadow: compat ldap
Tests:
>> getent passwd ab1234
dies sollte einen gültigen Eintrag für den User „ab1234“ liefern
>> getent group OE-Users-IDM
Ausgabe der Gruppe „OE-Users-IDM“
Einrichtung Authentifizierung bzw. PAM
Diese Konfiguration ist komplex und fehleranfällig. Insbesondere können Fehler dazu führen, dass eine Anmeldung ohne oder mit ungültigem Kennwort möglich wird. Deshalb sind gründliche Tests erforderlich und die Konfiguration sollte möglichst nicht direkt, sondern über von den Distributionen bereitgestellte Tools erfolgen. Unter Debian/Ubuntu z.B. über pam-auth-update
Stand: 2014-03-27
Basierend auf einer Anleitung von: Jürgen Engelmann