Skip to main content


 

Symptoms


1) If account is disabled in AD, what values should it have in Enabled and Resolved fields of Identity table? It is not very clear what Enabled and resolved values mean.

2) You may notice that number of records in Identity table with Resolved=0 and Enabled=1 if way greater that the number of active accounts in AD. Is it normal situation or there are some issues with synchronization of Identity table?
 

Diagnoses


(1) When you disable user in AD he gets Enabled = 0 and Resolved and ContainersResolved flags will be set to 1 in case they were resolved previously.

When you delete user in AD he also gets Enabled = 0 and Resolved and ContainersResolved flags will be set to 1 in case they were resolved previously.

As soon as identity record becomes disabled auto refresh process won't be trying to resolve disabled user anymore, but still if some process or UMUser SmO will try to use disabled user K2 will try to resolve this user again and depending on his status in add either resolving user or logging an error, for example 64007 for deleted AD accounts. Specifically for deleted AD records resolution attempts K2 logs "Identity does not appear to be discoverable or does not exist."

When Identity table record cannot be resolved via provider/source system it becomes disabled (Enabled=0) in table + values for ExpireOn are being set to current time + configurable cache timeout.

Presence of Enabled flag in Identity table for user which has been disabled in AD can be explained that table just contains cached value which has not been updated.

(2) The fact that Identity table has more records than number of active accounts in AD is expected as this table also contains entries for AD groups, SharePoint users and groups as well as roles. When objects being deleted in source providers (AD, SharePoint) they remain in identity table with Disabled=1 flag. This is expected behavior.

Enabled=0 means that user is disabled in AD or has been deleted or could not be returned from the provider. However it is never truly permanent, once record is disabled auto refresh won?t try to resolve it again, but if the user is enabled/recreated in AD again and a request (like login to K2 or send a mail to the user account through a mail event etc) comes in to resolve it, it will be set it back to Enabled.

Resolved=1 means that all the user properties have been returned and cached ? email, manager, description etc. Manager is the important one as request to get this property is the request that takes the longest time. When the user is set to Resolved, all properties have been retrieved including manager. As an example, if you would request a group?s membership, it will return a bunch of users and cache them, but if the users have never been requested directly, the users will have Resolved=0 and Enabled=1. If you then requesting the user directly through something like UMUser-GetUserDetails, then the user will be retrieved with all his properties and it will set Resolved=1.

If you ever get Enabled=0 and Resolved=0, it means that a direct request for the user was made (like UMUSer-GetUserDetails) but the user didn?t exist at all at any stage.
 

Resolution

See details above. Keep in mind that updating of content of your identity cache depend on availability of your external providers (e.g. AD DS). Also specific user managers being improved with each new release of K2 to better handle pulling data from external systems, so it is always good idea to run current version of product when your business requirements allow that.




 
Be the first to reply!

Reply