( 22.214.171.124 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
In particular where does the division "LDAP" attribute come from when it doesn't seen to exist in the LDAP RFCs?
Robert Singerse: rsmsingers@xxxxxxxxxxxxxxxx
- 21 Views
- Last Post 3 weeks ago
Hi Robert, I’m not sure what you are asking. Are you wondering about the difference between the schema CN and ldapDisplayName or the difference in the MAY list
of attributes? Clearly Microsoft did not feel compelled to follow the LDAP RFCs to the letter; there are a number of places where they diverge. And of course MS has added many non-X500 attributes and classes. The current definition of organizationalPerson
(below) allows 68 possible contained attributes.
I worked on the AD team and I know that Jim Allchin was concerned that LDAP was too complex and wanted to make it more “user friendly.” There was also a raging
battle (if you can imagine such between a bunch of propeller heads) as to whether the primary API should be LDAP or COM. Last, but certainly not least, was concern for backwards compatibility with NT LSA/SAM. The result though was a muddying of the waters
with COM ADSI wrapping LDAP and many changes from the LDAP spec.
Many people don’t know that the AD LDAP code was actually ported from the Exchange LDAP implementation. The list’s own Don Hacherl came to the AD team from the
Exchange team (with Tim Williams) to do the LDAP port. I’m sure Don would have more insight into these discrepancies.
From the AD schema (on Server 2016):
dSCorePropagationData: 0x0 = ( );
instanceType: 0x4 = ( WRITE );
mayContain (15): msDS-PhoneticDisplayName; msDS-HABSeniorityIndex; msDS-PhoneticCompanyName; msDS-PhoneticDepartment; msDS-PhoneticFirstName; msDS-PhoneticLastName;
msExchUserCulture; employeeNumber; personalPager; telephoneAssistant; businessRoles; employeeType; houseIdentifier; msExchHouseIdentifier; homePostalAddress;
objectClass (2): top; classSchema;
objectClassCategory: 0 = ( 88 );
systemFlags: 0x10 = ( SCHEMABASEOBJECT );
systemMayContain (53): msDS-AllowedToActOnBehalfOfOtherIdentity; x121Address; comment; title; co; primaryTelexNumber; telexNumber; teletexTerminalIdentifier;
street; st; registeredAddress; preferredDeliveryMethod; postalCode; postalAddress; postOfficeBox; thumbnailPhoto; physicalDeliveryOfficeName; pager; otherPager; otherTelephone; mobile; otherMobile; primaryInternationalISDNNumber; ipPhone; otherIpPhone; otherHomePhone;
homePhone; otherFacsimileTelephoneNumber; personalTitle; middleName; otherMailbox; ou; o; mhsORAddress; msDS-AllowedToDelegateTo; manager; thumbnailLogo; l; internationalISDNNumber; initials; givenName; generationQualifier; facsimileTelephoneNumber; employeeID;
mail; division; destinationIndicator; department; c; countryCode; company; assistant; streetAddress;
systemPossSuperiors (3): organizationalUnit; organization; container;
Actually, Tim and I came over with the core directory service, which spoke X/Open XDS and a proprietary MAPI SPI RPC. The LDAP protocol head was grafted on later. AD attributes came from all over the place: some from LDAP RFCs, some from X.500, some from AD internal needs, some from random other Internet specs, some from a need for compatibility with other products. The general philosophy in directory services is that you’re only supposed to look at attributes that you care about. If an object has an attribute that you don’t understand, don’t worry about it and leave it alone. That attitude, however, tends to lead to a proliferation of attributes. I can see that “division” is in Microsoft’s OID space. This means that it didn’t come from X.500 or any LDAP RFC that would have already defined an OID. If Eric doesn’t recognize division as being used by the AD admin tools then my best guess is that it was added at the request of some Microsoft app or Windows feature team, probably for compatibility with an existing non-AD product. We kept the schema definitions in a database and I frequently argued that we needed to add a “who asked for this and why” column to keep track of the proliferating attributes and enable inter-app sharing of definitions, but I never managed to convince the PM(s) in charge of handling schema requests to do so. Don P.S. Since it’s Thanksgiving tomorrow, I should note that I’m still grateful that the rise of Internet protocols in the early/mid 90s killed off talk of a DCOM interface to AD and let us go purely with LDAP. Apologies to those of you who had to figure out what ADSI was doing under the covers.
Thanks for your reply Eric. The issue I actually have is the Azure AD SCIM protocol implementation. It allows you to map AD attributes to corresponding SCIM attributes easily enough but it doesn't allow for custom schemas. So when you extend the LDAP schema
under the application for an attribute like division you can't actually send it. To get Microsoft to fix this you have to post on a web page and hope your request gets enough votes for the product manager to consider it. I'm trying to understand the background
to write a submission that may be compelling enough to have Microsoft acknowledge they are responsible for the issue and do something about it without a popular vote.
By now you’ve probably seen Don’s excellent response. I totally missed the fact that “division” is a may-contain attribute. Like Don says, there was little to
no control over what attributes got added.
My understanding is that MS is trying to “fix” AD with AAD. IOW, simplify, create a different access control model, use RESTful web protocols. I think that is
all fine and good, but as you see there are currently HUGE functionality gaps between AD and AAD. I haven’t used SCIM yet but I’ve been using the Azure and MS Graph APIs for a while now. Their capabilities are downright primitive compared to LDAP, especially
in the searching/filtering realm. AAD allows the definition of custom attributes but the support for them is limited. For example, I don’t know of a way to flow an AD attribute via AAD Connect to a custom AAD attribute. If there was such a capability, then
you could create a “division” attribute in AAD and flow the on-premise value to it. Consequently it would be more useful to have this capability than to request any specific AD attribute be added. If we could modify AAD to our liking, flow on-prem attributes
accordingly, and be able to access them through SCIM and Graph that would solve your problem and provide general utility.
What is the URL of that MS web page? I think I need to do some voting!
You should be able to see my "idea" here https://feedback.azure.com/forums/374982-azure-active-directory-application-requests/suggestions/32356771-add-scim-custom-schema-support-for-user-provisioni
Oddly the list contains ads for brothels and I had to use Chrome to post my "idea" because IE wouldn't work.
I'm all for democratisation of technology but this process actually feels a little silly.
I am not sure that I fully understand the requirement but flowing an (custom) AD attribute to AAD is possible via AAD Connect.