FAQ - KIT-Active Directory

Ich bin ITB und möchte das KIT-AD benutzen. Was muss ich tun?
Wir empfehlen Ihnen, sich für die Administration des KIT-AD ein eigenes Admin-Konto erstellen zu lassen, siehe https://www.scc.kit.edu/dienste/8253.php.

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.
Wie kann ich das KIT-AD verwalten?
Zum einen können Sie die vom SCC bereitgestellten Windows Remote Desktop Services nutzen.
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.
Wo finde ich weitere Informationen zum KIT-AD?
Ich bin kein ITB, möchte aber auch das KIT-AD benutzen. Bekomme ich einen eigenen Bereich?
Projektgruppen, die keiner OE zugeordnet werden können, können nach Absprache einen eigenen Bereich erhalten. Für einen solchen Bereich gelten jedoch folgende Einschränkungen:
  • 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.
Wie müssen meine Rechner, meine Benutzerkonten, etc. im KIT-AD heißen?
Das KIT-AD wird von allen Organisationseinheiten des KIT genutzt. Da die Objektnamen im Active Directory flach sind, muss organisatorisch sichergestellt werden, dass keine Namensgleichheiten auftreten. Daher müssen die Namen aller AD-Objekte grundsätzlich mit dem OE-Kürzel beginnen.
Was darf ich denn im KIT-AD alles machen?
Grundsätzlich können Sie das AD so nutzen, wie Sie es bisher gewohnt waren. Sie dürfen also Benutzer, Gruppen, Computer oder auch Gruppenrichtlinien erstellen und verwalten.

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.
Was darf ich denn im KIT-AD explizit nicht machen?
  • 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.
Mit dem Recht, diese Objekte zu verschieben, haben Sie zwar automatisch auch das Lösch-Recht, aber Sie dürfen dieses Recht nicht nutzen.
Wie greife ich per LDAP auf das KIT-AD zu?
Das KIT-AD kann per LDAP wie folgt angesprochen werden:
  • 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.

Welche lokale Einstellung zur Erhöhung der Netzwerksicherheit sind nötig?

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 - Sicherheitsoptionen
Richtlinie: "Netzwerksicherheit: Signaturanforderung für LDAP-Clients"
Wert: "Signatur erforderlich"
Meine Rechner stehen mit den falschen FQDNs im AD.
Standardmäßig erhält ein Rechner mit dem Domänenbeitritt ein PrimaryDNSSuffix, dass dem Namen der AD-Domäne entspricht. In unserem Fall also kit.edu. Der im AD veröffentlichte FQDN des Rechners wäre also <hostname>.kit.edu.

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.
Gibt es einen WINS-Server?
Nein.
Bekomme ich einen eigenen DC?
Einen RODC gibt es ausschließlich in gut begründeten Ausnahmefällen.
Darf ich Drucker im KIT-AD publizieren?
Ja.
Darf ich Gruppenrichtlinien verwalten?
Ja.
Darf ich einen eigenen DHCP-Server im AD veröffentlichen?
Nur nach Absprache mit uns. Das SCC bietet ebenfalls einen DHCP-Dienst an und in den meisten Fällen ist der Betrieb eines institutseigenen DHCP-Dienstes nicht notwendig.
Gibt es einen DFS-Server?
Nein.
Wie kann ich steuern, wer sich an meinen Rechnern anmelden darf?
Standardmäßig sind in der Gruppe der lokalen Benutzer folgende Gruppen enthalten, die damit auch über die Möglichkeit der lokalen Anmeldung verfügen:
  • 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.

Wie nehme ich einen Computer in das AD auf? 

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.​
Warum darf ich manche Gruppen im KIT-AD nicht ändern?
Sie können nur Gruppen ändern, die Sie auch explizit im KIT-AD angelegt haben.

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.
Welche Eigenschaften von IDM-Konten sind im KIT-AD schreibgeschützt?
IDM-Konten (hierzu gehören alle vom IDM-System autoritativ verwalteten Benutzerkonten, z. B. Mitarbeiter-Konten, Gäste-und-Partner-Konten, Service-Konten, Admin-Konten, etc.) erhalten einen Schreibschutz für folgende LDAP-Attribute:

"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"
Welche Eigenschaften von GV-Gruppen sind im KIT-AD schreibgeschützt?
GV-Gruppen erhalten folgenden Schreibschutz:

"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"

 

Wie verschiebe ich ein AD-Objekt in eine andere OU?
Wenn Sie in der Ziel-OU keine Schreibrechte haben, verschieben Sie das Objekt in die OU=Checkpoint Charlie, DC=KIT, DC=EDU.

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.
Wie kann ich meinen Benutzern ein Standardprofil (Default User Profile) vorgeben?
Es gibt in der Registry einen Ort, an dem definiert wird, woher das Default User Profile genommen wird:
  • 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
Anbindung von Desktopsystemen auf Basis von Unix/Linux an die KIT-Umgebung

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