Hi all,
We are trying to sync accountExpires attribute of AD and the sync worked for most users except for some. We can’t find a common denominator among the failed users. (In the same OU, some users failed, and some passed). The error we get is this:
[“Error(s) reported back from the IQService - Failed to update attributes for identity CN\u003dLastName\, FirstName,OU\u003dBC_EnhancedLaptop,OU\u003dFCIB Users,DC\u003dWI,DC\u003dFCIB,DC\u003dcom. Access is denied.\n”]
Anyone knows the reason for this? We are currently checking permissions on the service account but the fact that the majority of users passed makes me think the problem lies elsewhere.
Those failed users you are talking about, are they part of domain admins group? Or do they have adminCount - 1 as shown in the screenshot below?
If you don’t see the adminCount or if they are not part of the domain admins group, please go to IDN Search UI, find the account activity for identities with issues. When you click on account activity that failed provisioning, it will show you the details related to sync. For example, it will show previous value, new value its trying to sync, attribute name, etc. Could you please share that information as well.
I don’t have access to our client’s AD but looking at some of those users, they are a mix of full-time employees, contractors, contingent workers, and third-party vendors, unlikely that all of them are admins.
I would not trust the error message, yes it is access denied but maybe for some other attribute. Check if any other attribute is trying to be updated as part of this operation.
If you have access to IQ Service, see the Provisioning plan using Native Rules.
If you have access to IQ Service, try to replicate the same operation using PowerShell, you will get exact error message.
Maybe error is centric to some users, if yes then you need to find out what special about the failed users.
You can ask your AD team, they will have more insights on why it is failing.
We have a similar setup where adminCount was set as 1 for an account in AD and the attribute sync was failing with a reason “Access is denied”. The account was not part of any privileged group and hence we manually cleared the adminCount value.
The same issue continues to persist even after we removed the adminCount value. Any suggestions would be appreciated.
The service account is indeed part of Account Operators AD group and a local administrator on the server. It meets all expectations highlighted in the document. The attribute sync works on all normal users as expected.
The issue is - it throws out an insufficient permission issue when attribute sync is performed on users whose adminCount AD attribute has been manually changed from 1 to 0. Those set of users currently do not have any privileged groups associated with them.
I am still researching what action item needs to be taken so that those set of users can be considered as normal users again.
@siddharth931 you mentioned that you reset the adminCount to 0 but attribute sync still did not work?
Is this immediate or later? The code for AdminSdHolder will run and reset the value back to 1 if the user is still in an admin group. The default is one hour but it can be set to run as frequently as 5 minutes.
There are some notes that indicate that resetting adminCount will not be sufficient as inheritance has been disabled by this same process and must be re-enabled.
We are able to figure out a solution for this. In addition to resetting adminCount to 0 In for those protected accounts which is not part of any privileged group currently, we need to have the User’s Object ACL permissions reset to default in AD
After the ACL permissions are reset, attribute sync started to work as expected
