Due to the way AD implements this flag, it is not possible to use an LDAP rule. This is an option to be considered for other directory types.

How about allowing people to define the ldap rule for that attribute?

This would be a more generic rule and the same code could be used to map other ldap attributes to user properties, something that many others asked for. clearly outside of the scope of this bug, but is useful to think it more flexible.

/sorins

Hi eliankool, this improvement will be specifically for Active Directory - as stated in the issue title.
As it stands, every directory service implements a disabled flag in their own manner, so there is no one generic standard for all LDAPs. I'd recommend creating a new issue for ApacheDS. Cheers, Helen

Hi Helen,

would this also work for other LDAPs? We're using Apache DS and would be rather flexible which LDAP properties to use...

Thanks,

Elian

Hi everyone, thanks for your patience on this issue. We are currently working on providing this support in Crowd.

We are planning to implement it as an option within the Active Directory configuration, which would be enabled by default for new configs, but off for existing. Conceptually, we would map Crowd's active/inactive flag to AD's active/inactive flag. Any feedback welcome, cheers!

There is a workaround that might be suitable until a full solution is implemented. Set the 'User Object Filter' on the directory in Crowd to:

(&(objectCategory=Person)(sAMAccountName=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

This excludes users who have the UF_ACCOUNTDISABLE flag set, which is the flag that Active Directory sets when you disable an account.

It would be even better if the configuration of any LDAP Directory (not just Active Directory) would allow you to map an attribute in LDAP to the "active" flag of a user account in Crowd. A feature like that would allow anyone using Crowd and LDAP to extend their LDAP schema with a user object that sports such an attribute.

Also allow for scheduled synchronization between Crowd and a Delegated LDAP/AD connector. We have now implemented this our-self but should be core functionality.

Are there plans to incorporate these enhancements in a upcoming release?

A disabled Active Directory user should not be visible to Crowd nor considered during the authentication search.

Hoping that more specific requirements will help in getting this implemented.

Currently the Active Directory LDAP connector for Crowd (as of 2.0.1) does not fully reflect status flags of the underlaying AD directory store.

The following should be changed:

1. Crowd should be extended to support additional flags for user accounts:
   • Password Expired
   • Account Locked out
2. The AD LDAP Connector should correctly set the the flags:
   • Active: account status - active or disabled on AD
   • Password Expired: password expired on AD
   • Account Locked out: Account locked out on AD
3. The AD LDAP Connector should propagate changes back to the AD directory when the flag is changed in crowd.
   • If an account is locked out, and the flag is unchecked in Crowd, then the AD account should be re-enabled (the lockout removed.)
   • If the account is inactive or disabled (flag not set in crowd Active flag) and the flag is checked, the AD account should be set to active.

The password expiry flag is only for display, since the user can change the password to rectify the situation.