[midPoint] Active Directory Administrative Status

[Radovan Semancik]

Ah, yes. You are right.

I had another look at the code. There is actually a support for reading 
the administrative status. The account will be considered enabled if if 
((userAccountControl & AdConstants.USER_ACCOUNT_CONTROL_DISABLED) == 0) 
and disabled otherwise, where USER_ACCOUNT_CONTROL_DISABLED = 0x0002;

I completely forgot that I have ever written this code :-) ... but if I 
haven't completely lost my last sense of binary maths then the account 
should be seen as disabled for value 514(dec). So it should work for you 
and I have no idea why it does not work.

Please feel free to experiment with the connector code. This code is in  
AdSchemaTranslator.extendConnectorObject(...) starting at line 147. 
Maybe if you add some logging there then you can figure out what's going on.

-- 
Radovan Semancik
Software Architect
evolveum.com



On 09/15/2016 07:24 PM, Florin. Stingaciu wrote:
> Hey Radovan,
>
> Thanks for the detailed response. However, something does bug me. For 
> some users that get disabled via the userAccountControl attribute 
> (value 514), the user will consequently be disabled in midPoint, 
> however for some users it does not even though the userAccountControl 
> attribute has the same value.
>
> Do you have ideas why this could be the case?
>
> Alternatively, are there any examples in your wiki or github on how I 
> could conditionally map a value from a particular attribute to 
> administrativeStatus? I haven't been able to find much.
>
> Thanks,
> -F
>
> On Thu, Sep 15, 2016 at 4:10 AM, Radovan Semancik 
> <radovan.semancik at evolveum.com <mailto:radovan.semancik at evolveum.com>> 
> wrote:
>
>     Hi,
>
>     The AD/LDAP connector is indeed using the userAccountControl
>     attribute and maps the values to administrativeStatus. However
>     userAccountControl attribute is tricky. It is binary attribute,
>     each bit corresponding to a separate flag (that's Microsoft's idea
>     of proper LDAP support). Therefore supporting that well is not
>     entirely straightforward. When I was developing the AD/LDAP
>     connector I have implemented just the very minimal support that we
>     needed at that time. I knew quite well that the code that handles
>     the userAccountControl will eventually need to be rewritten
>     anyway. So I haven't spent any more time that was absolutely
>     necessary. The priorities have changed since then .... and that
>     means that the support for properly reading and decoding
>     userAccountControl is still missing. I have just created Jira to
>     finish it:
>
>     https://jira.evolveum.com/browse/MID-3400
>     <https://jira.evolveum.com/browse/MID-3400>
>
>     However, because of our current priorities this will need a
>     subscriber's "vote" or an explicit sponsoring to get implemented.
>     Or (as always) connector code is on github and we will gladly
>     accept contributions.
>
>     Yet, there is a workaround. If you set configuration property
>     rawUserAccountControlAttribute to true then the connector will do
>     no logic on the userAccountControl and you can do all the
>     necessary logic in midPoint mappings.
>
>     -- 
>     Radovan Semancik
>     Software Architect
>     evolveum.com <http://evolveum.com>
>
>
>
>     On 09/14/2016 09:38 PM, Florin. Stingaciu wrote:
>>     Hello,
>>
>>     We are syncing all of our users from an Active Directory
>>     instance. When a user is disabled two things happen:
>>
>>     1. The Dn of the user changes from cn=username,ou=people to
>>     cn=username,ou=disabled_accounts
>>
>>     2. The userAccountControl changes from 512 to 514 indicating the
>>     user is disabled
>>
>>     I use an import user accounts task daily to ensure any people who
>>     left the company are disabled, however I just noticed that for
>>     some users when they get disabled in active directory, midPoint
>>     won't disabled them even though they both have the
>>     userAccountControl entry set to 514 making me think that midPoint
>>     uses a different attribute to test the Account Status on the AD
>>     resource.
>>
>>     Here's my activation setting:
>>
>>              <activation>
>>                 <administrativeStatus>
>>                    <inbound/>
>>                 </administrativeStatus>
>>              </activation>
>>
>>     Any help would be greatly appreciated.
>>
>>     Thanks,
>>     -F
>>
>>
>>     _______________________________________________
>>     midPoint mailing list
>>     midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>     http://lists.evolveum.com/mailman/listinfo/midpoint
>>     <http://lists.evolveum.com/mailman/listinfo/midpoint>
>     _______________________________________________ midPoint mailing
>     list midPoint at lists.evolveum.com
>     <mailto:midPoint at lists.evolveum.com>
>     http://lists.evolveum.com/mailman/listinfo/midpoint
>     <http://lists.evolveum.com/mailman/listinfo/midpoint> 
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160915/b8211456/attachment.htm>