InetOrgOrg-Person

Benutzer im Active Directory werden normalerweise als Objekt vom Typ "user" angelegt. Im LDAP-Standard wurde aber Auch ein Object "InetOrgPerson" definiert, welches von verschiedenen Firmen auch immer wieder genutzt wird. Für eine Anmeldung auf einem Windows Client macht es auch keinen großen Unterschied aber woanders schon.

Empfehlung: Bleiben Sie beim Standard "User" und vermeiden Sie "InetOrgPerson"

InetOrg-Person vs User

Ich habe einfach mal zwei Benutzer der unterschiedlichen Typen mit minimalen Stammdaten angelegt und mit LDIFDE exportiert:

Genau betrachtet unterscheiden sich die beiden Objekte nur an einer erweiterten ObjectClass. Das Objekt "inetOrgPerson" ist quasi eine Erweiterung des Objekts "user". Dennoch habe ich auch noch mal das Schema verglichen. Ein Export mit LDIFDE ist ja schnell gemacht

ldifde -f user.txt -d "CN=user, CN=Schema, CN=Configuration, DC=msxfaq, DC=de"
ldifde -f inetorg.txt -d "CN=inetOrgPerson, CN=Schema, CN=Configuration, DC=msxfaq, DC=de"

Interessant ist hier zwar die Felder "MayContain", "systemMayContain" und "systemAuxiliaryClass", welches weitere Subklassen der Properties enthält aber eine genauere Betrachtung kann ich mir ersparen,  wenn Sie das Feld "SubClassOf" anschauen.

Das Objekt "inetOrgPerson" ist eine Unterklasse von "user" und bekommt damit alle anderen Eigenschaften vererbt. Dass iNetOrgPerson zusätzlich noch weitere Eigenschaften über "MayContain" bekommt, ist hier nicht weiter relevant, da dies Felder auch beim "User" eingetragen sind. Insofern frage ich mich, was damals Microsoft sich gedacht hat, diese doppelte Zuweisung bei InetorgPerson zu machen.

Wechsel des Objekts

Wenn Sie bislang mit InetOrgPerson gearbeitet haben und nun doch wieder mit "User" arbeiten wollen,  dann können Sie die Objekte sehr einfach umstellen

Set-ADUser username -Add @{objectClass='inetOrgPerson'}

Wenn Sie aus einem inetOrgPerson wieder ein "User" machen wollen,  entfernen Sie einfach den Eintrag in der "objectClass"

Set-ADUser username -Remove @{objectClass='inetOrgPerson'}

Da stellt sich dann schon die Frage,  warum es zwei fast identische Objekte gibt und wo es knirschen könnte.

Die nun folgende Auflistung sind Probleme,  die ich in meinem Tätigkeitsumfeld selbst bemerkt habe. Sie ist nicht vollständig und wer etwas beitragen möchte,  kann mich gerne anschreiben

LDAP-Suche

Ich kenne viele Programme,  die z.B. nach "Benutzer" suchen. Das kann man mit einem passenden LDAP-Filter sehr einfach regeln,  z.B.

(objectclass=user)

So findet der Filter natürlich beide objektarten,  denn auch die inetOrgPerson hat ja die Objekt-Klasse "user". In der Antwort liefert LDAP aber dann ein Array für diese Feld mit und wenn eine Software nun in dem Feld einfach den letzten Eintrag ausliest,  eil der das Objekt am "genauesten" spezifiziert. Es gibt ja leider kein eigenes Feld, welches den genauen Objekt-Type angibt, so dass ein Entwickler eben diese Aufzählung parsen muss. Nun haben sie aber oben schon gesehen, dass auch ein "Computer" bei einer Suche nach "User" zurückgegeben wird. Natürlich könnte ein Entwickler nun auch noch das Feld "sAMAccountType" mit auswerten, um nur Anmeldekonten zu finden.

Aber nicht alle Entwickler stecken so tief in den Details eines Active Directory und das Feld "sAMAccountType" gibt es auch nicht in einem Notes LDAP-Server oder anderen LDAP-Quellen. Warum daher nicht einfach nachschauen, ob das letzte Elemente in "objectClass" den Inhalt "user" hat.

In den meisten Fällen können Sie sehr gut dann die Computer aus einer Auflistung ausschließen. Dummerweise finden Sie dann auch keine inetOrgUser mehr.

3rd Party Schema-Erweiterungen

Die meisten Hersteller verzichten mittlerweile auf eigene Schema-Erweiterungen des Active Directory und behelfen sich mit bestehenden Feldern. Sehr gerne werden dazu die Exchange Felder genutzt. Wer aber eine Schema-Erweiterung durchführt, muss diese Felder ja auch an die Objekte anbinden.

Hier sollte das Risiko einer Fehlkonfiguration allerdings nicht vorhanden sein, denn eine Erweiterung der Schema-Klasse "user" wird auch auf "inetOrgPerson" wirken, welche ja von "user" abgeleitet ist.

AD Berechtigungen

Aber an anderer Stelle kann es noch zu Problemen kommen. Selbst Microsoft Exchange ist nicht davor gefeit, in diese Falle zu tappen. Neben einer reinen Schema-Erweiterung kann eine Software auch die "Default Berechtigungen" auf Objekte in der Domäne anpacken. Die dort gepflegten ACLs werden sehr gerne bei der Installation von Active Directory integrierten Programmen angepasst. Hier ist inetOrgPerson nicht von User abgeleitet. So hat Exchange vergessen, bei einer Erweiterung der Berechtigungen diese auch auf inetOrgPerson-Objekte zu vergeben und dies auch dokumentiert.

Microsoft rechnet anscheinend nicht damit, dass eine Firma tatsächlich mit "inetOrgPerson" arbeitet. In dem fall bedeutet dies, dass Exchange dann z.B. keine InetOrgPerson-Objekte hinsichtlich von Postfacheigenschaften verwalten konnte. Mittlerweile ist der Bug natürlich korrigiert worden und im Active Directory sehen sie nun die auf beide Objekte vergebenen Berechtigungen:

Das bedeutet aber nicht, dass nicht auch andere Anwendungen in diese Falle tappen.

Office 365 ADSync Kennworte

Wer auch Dienst aus der Office 365 Cloud nutzen,  wird sehr schnell einen Verzeichnisabgleich (Siehe Office 365 Identity Management) mit ADSync installieren. In den Synchronisationsregeln ist auch gut zu sehen,  dass sowohl "User" als auch "InetorgPerson" von ADSync als "person" angesehen und repliziert werden:

Aber das Bild zeigt nicht alles. Über die Funktion Password Hash Sync (PHS) kann ADSync auch die Anmeldung unterstützen,  indem ihre lokalen Kennworte als Hash-Werte auch in die Cloud übertragen werden. Dies funktioniert aber nur für Objekte vom Typ "User"

Password sync is only supported for the object type user in Active Directory. It is not supported for the iNetOrgPerson object type
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization

Sie müssten daher die Konfiguration von ADSync sehr umfangreich anpassen und wie das hinsichtlich Support und Beibehaltung bei Updates aussieht,  steht auf einem anderen Blatt. Sie sollten daher mit Office 365 immer auf "User" setzen.

• Office 365 Identity Management
• Password Hash Sync (PHS)
• Office 365 - ADSync Felder

Weitere Links

• EAS Objekte im AD