Hi,

I thought that this may be of interest for the community here. I have created a prototype code to process "native" Active Directory schema with Directory API:

https://github.com/Evolveum/connector-ldap/blob/feature/ad-native-schema/src/main/java/com/evolveum/polygon/connector/ldap/ad/AdSchemaLoader.java
https://github.com/Evolveum/connector-ldap/blob/feature/ad-native-schema/src/main/java/com/evolveum/polygon/connector/ldap/ad/AdSchemaManager.java

For those of you who are not aware of those AD "peculiarities", AD provides an somehow-standard LDAP-like schema definition. But this leaves a lot to be desired. E.g. it does not provides any means to work with objectCategory, which is quite essential if you want to get any decent performance of your AD server. (Un)fortunately, there is another form of AD schema which is, quite surprisingly, not standard. What I have done is to write a code to parse that proprietary form of the schema and load it into modified Directory API SchemaManager. Then the API can work with the same in the same way as it works with standard LDAP schema.

First tests suggest that this may work. Once I manage to stabilize and test the code, I will most likely contribute that directly to Directory API, as this may be useful also for other people. But that will be most definitely after the 2.0 release of the API.

Current structure of Directory API, especially the schema-processing parts (SchemaLoader, SchemaManager) is not ideal for this particular kind of abominations. However, I have managed to make it work just with a few minor changes in SchemaLoader and SchemaManager. Those classes would deserve much tender loving care. But the current code seems to work and the rework of SchemaLoader and SchemaManager is currently not my priority. E.g. dependency of the API on MINA is something that bothers me much more.

--
Radovan Semancik
Software Architect
evolveum.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to