AD Group Sync failing when Members were moved to a different OU

[Tobias]

Hello,

 

we're using the build Versions 9400 (test) and 9381 (live).

There still seems to be an issue with the AD Group synchronizsation in both builds.

 

When one user is moved to a different OU, the sync for the group fails. When starting the sync manually I'm redirect to the default "An Error Has Occurred" - Site. The Error Console shows the following information:
 

Quote

Build No '9400' - There is no such object on the server. , StackTrace = at System.DirectoryServices.AccountManagement.ADStoreCtx.LoadDirectoryEntryAttributes(DirectoryEntry de) at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.MoveNextMemberEnum() at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.MoveNext() at System.DirectoryServices.AccountManagement.FindResultEnumerator`1.MoveNext() at uRM=.gR8=.RRk=(String hx8=, String iB8=, String iR8=, String ih8=, String ix8=) at uRM=.gR8=.8hk=(Object kx8=, EventArgs lB8=) at Telerik.Web.UI.RadListBox.RaiseEvent(Object eventKey, EventArgs e) at Telerik.Web.UI.RadListBox.OnSelectedIndexChanged(EventArgs e) at System.Web.UI.Page.RaiseChangedEvents() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

 

The AD Group debug function in the Security Groups menu also ends ends in an error.

 

Moving deactivated users to a different OU is a standard process in our company, so we cannot simply move users to their original OU.

 

Is this issue already being invested or any workaround available?

 

 

Thank you very much and best regards

Tobias

[support]

Hi Tobias,

 

As we do not look at OU's at all for our synchronization process, and only Security Groups, we can only assume moving to a different OU is changing permissions on those Security Groups.

 

For the Privileged Account Credential you are using in Passwordstate for the AD sync process, can you check what security groups it is in, and compare against permissions on the OU and Security Group you are synchronizing? It looks like Priv Account might not have enough permissions, and you will need to test elevating it's access i.e. try the Account Operators group, and if that does not work, test with the Domain Admins group - just as a test to prove if it's permission related or not.

Regards

Click Studios

[Tobias]

Hi support-team,

 

it is indeed some kind of a permission problem. I added the privileged account to the domain admin group and in worked just fine.

 

I've created a workaround by adding the required permissions to the OU to the privileged user.

 

This is a new issue, however. All applications I know interpret users they cannot read as non-existent, so this might still be worth investing on your side.

The whole synchronization process crashes for any group where members are present to which the privileged user has no read-permission. For the purpose of synchronizing groups I'd say that those users can simply be ignored which I suppose was the case before one of the latest builds.

I cannot say exacly when the synchronization started failing because we only noticed it last friday. I can only say that this issue exists in build 9381 and 9400.
 

Thank you and best regards

Tobias

[support]

Hello Tobias,

 

This synchronization process has not changed for a long time, so we do not believe the upgrade is related in any way. As it's failing because it does not have permission to an object, we would expect customers would want to know about this, instead of just ignoring the object.

Regards

Click Studios

[Tobias]

The problem is that I got no warning that some process or syncing groups was failing and it took a lot of time to find out the root cause.

 

If you expect that customers will want to know about this, I'd recommend a specific and more visible error message that the synchronization fails because of this. Not even the error console shows this error if the sync fails in background. This error however may be worth a notification 🙂

 

Best regards

Tobias

[support]

Sure, thanks Tobias.

 

We have tried in the past to replicate this issue, so we could add a notification, but we can never seem to get it to fail, even when the Priv Account is only in the Domain Users security group.

Regards

Click Studios

[Tobias]

Hi support-team,

 

to reproduce the issue please try the following:

1. open the active directory users and computers and select the OU you wish to restrict the access to

2. right click on the OU and select properties... -> Security

3. open the "Advanced" menu

4. add the privileged user account (principal), set Type to "deny" and Applies to "this object and all descendant objects"

 

Then you should be able to reproduce this issue.

 

Best regards

Tobias

 

PS/FYI: we move disabled user accounts to a OU with restricted access before we delete them because some applications simply ignore the "disabled" status in the AD. By moving them to a OU where other "privileged accounts" have no read-access we have a workaround for those applications.

[support]

Thanks Tobias - we'll test with that.

 

For these other applications, is it worth also logging a support ticket with them, asking them to honour the disabled status, just like we do?

Regards

Click Studios