Friday February 22, 2008
Friday February 22, 2008 Hey all. Sorry (again) for the lack of blogging, but busy getting ready for new versions of IdM and welcoming our Vaau friends to the good ship Sun.
One question keeps coming up over and over again and think we finally got the straight answer on why the Sun IdM LDAP v3 resource adapter (ours we suspect is based on the OpenLDAP standard) does not work with the LDAP v3 compatible ADAM interface to AD by Microsoft. Logic would make one think that it would. Many customers would surmise that instead of buying two adapters, they could buy one LDAP adapter for directory and then reuse the same adapter to control AD via ADAM ("Gee, its LDAP v3 compliant, Microsoft tells me so"), thus saving the licensing fee on the AD adapter.
The argument always boiled down to MS claiming they were v3 compliant so our adapter must be at fault, but nobody ever answered why there was a problem technically. Think we have determined the answer:
First ADAM is the assumption that it is an LDAP interface of Active Directory that adheres to RFC3377 - an umbrella RFC containing 8 other RFC's to define the LDAP v3 protocol. This was first published in 1999 with Microsoft releasing ADAM on Windows 2003 several years later. One missing element from the RFC was a clear definition of the user objects, so extension RFC2798 was created April 2000 to define InetOrgPerson. Key feature to note here is the inclusion of a 'uid' attribute for user logon, not defined in the core RFC schema. As AD uses a form of distinguished name versus login ID, it did not concern itself with 'uid'.
Statement: at that time, around 2003, Microsoft could claim ADAM to be v3 compliant because it did not include 'uid' which was part of a RFC extension, not part of the core LDAP definition of the v3 RFC family.
When the InetOrgPerson RFC was published, ADAM and AD were already too far along in development to include them, so Microsoft put out an "InetOrgPerson" service kit that basically altered the schema of AD to make it compliant. The kit had to be applied to AD and not everyone did, because in a mostly Microsoft shop, the attributes used by InetOrgPerson were not used by AD in day to day operations.
The ADAM interface at this time would be considered LDAP v3 compliant because it handled all bind requests and responses as defined in RFC3377 and you could extend the schema with the InetOrgPerson toolkit to make the interface compliant with the extension RFC2798 to include InetOrgPerson. Interestingly, we would surmise this would have been most likely a null field, as AD has no use for 'uid' or login id.
Now skip forward to the development of the then Waveset, now Sun IdM LDAP resource adapter. I cannot confirm this (we don't let our code out of the lab), but one would expect us to have used the OpenLDAP project as a code base (or some similar code library which would have been an offshoot of OpenLDAP) somewhere in the 2003/2004 timeframe. That code is kept up to date and included the InetOrgPerson Schema as part of the library, as they wished to be totally compliant to LDAP v3 core and all extensions. And we would have designed the adapter to key off of the 'uid' field as one way to determine account uniqueness. It could be used in standard LDAP, but not in ADAM, which was an LDAP front for AD, which does not use it (at least I don't think it does; don't have an old Windows 2003 server lying around the cave to test).
Now, move forward to 2006, when the LDAP v3 protocol has still not been ratified, but had gone through enough changes in the RFC process they were updated and reissued. RFC4510 replace RFC 3377 as the core umbrella RFC for the LDAP v3 standard. One of the RFC's controlled is RFC4519 LDAP v3 Schema for User Applications. Lo and behold, the 'uid' attribute is no longer in the extension, but in the specification itself.
Statement: upon the release of the 2006 version of the protocol, ADAM would no longer be compliant. Can't be sure if that includes a site that have applied the InetOrgPerson toolkit, but the core ADAM interface, which seems not to have been updated since release in 2003.
Anyway, in order to get our future ADAM resource adapter to work, it appears a change to the AD schema is needed to add the needed fields.
The second reason for it not working is, in order to do ActiveSync on the ADAM interface, we need access to the LDAP transaction log, which is available LDAP directory, but not through ADAM (which uses AD via ASDI). We had to do some work arounds to get the desired functionality of the resource adapter.
Technorati Tags: sun idm identity management software SunIdM IdentityCrisis
One question keeps coming up over and over again and think we finally got the straight answer on why the Sun IdM LDAP v3 resource adapter (ours we suspect is based on the OpenLDAP standard) does not work with the LDAP v3 compatible ADAM interface to AD by Microsoft. Logic would make one think that it would. Many customers would surmise that instead of buying two adapters, they could buy one LDAP adapter for directory and then reuse the same adapter to control AD via ADAM ("Gee, its LDAP v3 compliant, Microsoft tells me so"), thus saving the licensing fee on the AD adapter.
The argument always boiled down to MS claiming they were v3 compliant so our adapter must be at fault, but nobody ever answered why there was a problem technically. Think we have determined the answer:
First ADAM is the assumption that it is an LDAP interface of Active Directory that adheres to RFC3377 - an umbrella RFC containing 8 other RFC's to define the LDAP v3 protocol. This was first published in 1999 with Microsoft releasing ADAM on Windows 2003 several years later. One missing element from the RFC was a clear definition of the user objects, so extension RFC2798 was created April 2000 to define InetOrgPerson. Key feature to note here is the inclusion of a 'uid' attribute for user logon, not defined in the core RFC schema. As AD uses a form of distinguished name versus login ID, it did not concern itself with 'uid'.
Statement: at that time, around 2003, Microsoft could claim ADAM to be v3 compliant because it did not include 'uid' which was part of a RFC extension, not part of the core LDAP definition of the v3 RFC family.
When the InetOrgPerson RFC was published, ADAM and AD were already too far along in development to include them, so Microsoft put out an "InetOrgPerson" service kit that basically altered the schema of AD to make it compliant. The kit had to be applied to AD and not everyone did, because in a mostly Microsoft shop, the attributes used by InetOrgPerson were not used by AD in day to day operations.
The ADAM interface at this time would be considered LDAP v3 compliant because it handled all bind requests and responses as defined in RFC3377 and you could extend the schema with the InetOrgPerson toolkit to make the interface compliant with the extension RFC2798 to include InetOrgPerson. Interestingly, we would surmise this would have been most likely a null field, as AD has no use for 'uid' or login id.
Now skip forward to the development of the then Waveset, now Sun IdM LDAP resource adapter. I cannot confirm this (we don't let our code out of the lab), but one would expect us to have used the OpenLDAP project as a code base (or some similar code library which would have been an offshoot of OpenLDAP) somewhere in the 2003/2004 timeframe. That code is kept up to date and included the InetOrgPerson Schema as part of the library, as they wished to be totally compliant to LDAP v3 core and all extensions. And we would have designed the adapter to key off of the 'uid' field as one way to determine account uniqueness. It could be used in standard LDAP, but not in ADAM, which was an LDAP front for AD, which does not use it (at least I don't think it does; don't have an old Windows 2003 server lying around the cave to test).
Now, move forward to 2006, when the LDAP v3 protocol has still not been ratified, but had gone through enough changes in the RFC process they were updated and reissued. RFC4510 replace RFC 3377 as the core umbrella RFC for the LDAP v3 standard. One of the RFC's controlled is RFC4519 LDAP v3 Schema for User Applications. Lo and behold, the 'uid' attribute is no longer in the extension, but in the specification itself.
Statement: upon the release of the 2006 version of the protocol, ADAM would no longer be compliant. Can't be sure if that includes a site that have applied the InetOrgPerson toolkit, but the core ADAM interface, which seems not to have been updated since release in 2003.
Anyway, in order to get our future ADAM resource adapter to work, it appears a change to the AD schema is needed to add the needed fields.
The second reason for it not working is, in order to do ActiveSync on the ADAM interface, we need access to the LDAP transaction log, which is available LDAP directory, but not through ADAM (which uses AD via ASDI). We had to do some work arounds to get the desired functionality of the resource adapter.
Technorati Tags: sun idm identity management software SunIdM IdentityCrisis
Comments:
Post a Comment:
Comments are closed for this entry.