IdStory Identity Manager

Please note the importance of the attribute UserAccountControl: https://msdn.microsoft.com/en-us/library/ms680832(v=vs.85).aspx
This attribute holds, if the account is enabled, password required, etc.
The old AD connector from OpenICF set this attribute automatically - IdM sent "__ENABLE__", "__PASSWORD_EXPIRED__" etc. and the connector computed the value of UserAccountControl.

Alena Peterová wrote:

Please note the importance of the attribute UserAccountControl: https://msdn.microsoft.com/en-us/library/ms680832(v=vs.85).aspx

• if the connector gets the value of "userAccountControl", it uses this value
• the value is also updated according to additional attributes:
  • \__ENABLE__: for setting ACCOUNTDISABLE flag. Default value of the flag is false (accounts are enabled by default)
  • \__PASSWORD__: after changing the password it sets the flag PASSWD_NOTREQD = false
  • PasswordNeverExpires: for setting DONT_EXPIRE_PASSWORD flag

Also there is an interesting note about the attribute \__PASSWORD_EXPIRED__ (in LDAP this is pwdLastSet=0 and means "user must change password after logon"):
"Encountered problems when processing change password at the same time as setting expired. It would be set to expired, but the change would clear that. So we must ensure that expired comes last."

Please note that the old connector does Create operation in two steps - first it creates only simple account, then it sets all other attributes and also password.

so i fixed this issue: i remove pwd and userAccountControl from create method (because UAC cannot be enabled, when AD account does not have pwd), so after identity in AD is created, update with pwd and UAC is called. In this memthod I set UAC to 512 (normal enabled account ) as default.

there is one issue. when there is exception in update (- mistake in password policies or UAC -) there will be newly created account in AD, but idm does not know about it and retry of this provisioning will drop on already existing exception. this should not happen often and only, when AD system is being set up. i firstly add in catch deleting of this new user in AD, but i found out, that it could be dangerous, so any ideas what is better in this case?

Patrik Stloukal wrote:

so i fixed this issue: i remove pwd and userAccountControl from create method (because UAC cannot be enabled, when AD account does not have pwd), so after identity in AD is created, update with pwd and UAC is called. In this memthod I set UAC to 512 (normal enabled account ) as default.

Is there some option to disable user accounts by the connector? If not, we will need some attribute "__ENABLE__" or "__DISABLE__" which will set UAC accordingly.

there is one issue. when there is exception in update (- mistake in password policies or UAC -) there will be newly created account in AD, but idm does not know about it and retry of this provisioning will drop on already existing exception. this should not happen often and only, when AD system is being set up. i firstly add in catch deleting of this new user in AD, but i found out, that it could be dangerous, so any ideas what is better in this case?

I see the only option to make it configurable (deleting of the incomplete new user). It's dangerous to delete new users, when AD creates home directories for new users. Otherwise it is safe. So the administrator has to decide...