[midPoint] Active Directory quirks

[Radovan Semancik]

Hi,

Thank you for pointing that out. AD is indeed really strange LDAP 
server. I have made a quick documentation update. However, there is a 
lot of things that could be done to make life with AD easier. E.g.

1. We could implement ability to expand resource schema directly in 
midPoint schemaHandling. Then the configuration of connector operational 
attributes may not be needed.

2. There is indeed a lot to be documented about AD behavior. Even though 
this is technically not a "midPoint problem" but rather a "Microsoft 
problem", I would gladly document all that I know. I see that this is 
needed. But this task takes time and it needed to be prioritized. 
MidPoint (platform) subscription would be a significant motivation to 
prioritize this task.

3. That userAccountControl is really tricky attribute. Very non-LDAPish. 
There is a plan to support all the bits of userAccountControl in the 
connector. That would be perhaps the most convenient way. But again, 
there needs to be motivation to prioritize this task. In the meantime 
the rawUserAccountControlAttribute was requested by midPoint subscriber 
as a method that works for them. So here it is.

4. Actually, all the configuration properties of LDAP and AD connectors 
are reasonably well documented. However, the documentation is integrated 
with connector source code. E.g.:
https://github.com/Evolveum/connector-ldap/blob/master/src/main/java/com/evolveum/polygon/connector/ldap/AbstractLdapConfiguration.java
This method makes perfect sense for connector developers. If the 
documentation is bundled with the source code then there is a good 
chance that it stays reasonably up to date.
It would be really nice to automatically generate human-readable 
documentation out of this. It is perfectly feasible. But once again, 
this task was not selected as a priority by any midPoint platform 
subscriber.

MidPoint is a comprehensive software product in itself. And with all the 
connectors, plug-ins and customizations it is in fact quite a big living 
ecosystem. There are too many things that require attention of our team. 
And we have to prioritize the tasks. Therefore if you want to influence 
future of midPoint there are two good ways to do it: contribution or 
platform subscription.

-- 
Radovan Semancik
Software Architect
evolveum.com



On 08/15/2018 12:02 AM, Andrew Morgan wrote:
> I ran into a few Active Directory quirks when setting up the 
> AdLdapConnector (v1.6).  I think the wiki documentation could be 
> improved.
>
> First, I tried to map an attribute named "legacyExchangeDN", but 
> midPoint gave me an error because it isn't in the "user" objectclass:
>
> com.evolveum.midpoint.util.exception.SchemaException: Definition of 
> attribute legacyExchangeDN not found in object class 
> {http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}user 
> as defined in definition of 
> resource:724ba798-90cd-4c5a-bdf7-2ea7f1f6de3b(midPoint AD DEV)
>
> This attribute is allowed on user objects by Active Directory due to 
> the weird way AD adds auxiliary objectclasses.  The wiki page 
> (https://wiki.evolveum.com/display/midPoint/Active+Directory+with+LDAP+connector) 
> mentions this under "Active Directory LDAP Strangeness":
>
> "The objects can easily have attributes that are not defined in any 
> object classes that they have. E.g. a normal user (the user object 
> class) may have attribute info. If such extra attributes are used in 
> your AD instance then the best way is to define them explicitly in 
> Resource Schema Handling."
>
> I couldn't find any mention how to define them on the Resource Schema 
> Handling wiki page.  However, I found the workaround in MID-3379 
> (https://jira.evolveum.com/browse/MID-3379), which says to define it 
> as an oeprational attribute in the connector configuration.  This works:
>
> <icfcldap:operationalAttributes>legacyExchangeDN</icfcldap:operationalAttributes> 
>
>
> It would be nice if the note under "Active Directory LDAP Strangeness" 
> explicitly said this.
>
>
> Second, I wanted direct control over the userAccountControl attribute 
> so that I can create an AD account that is initially disabled, even 
> though the midPoint user is enabled.  I couldn't figure out how to do 
> this using administrativeStatus.  I was getting a strange error 
> message like "unable to map integer to boolean" when I adding an 
> outbound mapping for userAccountControl.  I eventually discovered this 
> connector configuration to disable the special handling of 
> userAccountControl:
>
> <icfcldap:rawUserAccountControlAttribute>true</icfcldap:rawUserAccountControlAttribute> 
>
>
> It would be great if there was documentation (wiki?) for all the 
> possible settings on the connectors.  I found this setting by 
> searching the mailing list and reading the source code of the connector.
>
> Thanks,
>
> Andy Morgan
> Systems Administrator, Identity & Access Management
> Information Services | Oregon State University
> 541-737-8877 | is.oregonstate.edu
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint