Without making any changes to ARS, this afternoon we started getting access denied error in the consoles when we attempt to perform any tasks. Even accounts with full access to the ARS console get access denied. Our ARS service account is a member of the domain account operators group and has been for several years. I checked the effective permissions in AD on a user object. The ARS service account has full control on that object. Yet when I try to update that object in any way in the ARS console I get an access denied message. However, this failed access does not show up in the native Active Directory security logs. So it appears there is something within the console itself that is generating the error.
The connection point cannot be created / update (EDM event error 2505). Under AD container System - Aelita - Enterprise Directory Manager there are no connection objects for the ARS servers even though the ARS account has full control permissions on this container. It's as if ARS just is not reaching the DCs but in the console the service connects to the DC's without a problem.
I verified the ARS service account permissions work by running ADUC as the service account and resetting the password for a test user. I then ran the ARS console as the ARS service account and was unable to reset the same user's password. I get an "Administrative Policy" error (see image).
Does this behavior sound familiar to anyone?
In reply to dyannic:
In reply to dsj37:
Yeah I've restarted the service and rebooted several times. I get an error in the EDM log, error message 2505 indicating the ARS server is unable to create the service connection point because of access denied. This error does not show up in my test environment does not exhibit the same behavior.
For those who are still interested we finally found the problem with the help of Quest support. Somehow, and we're still not sure how this happened, one of our programmers who does not have any level of ARS admin rights managed to change the Managed Domain properties to use an override account for accessing the domain instead of the ARS service account. See below. Unfortunately he's on vacation so we can't asked what he did. But we verified without doubt that his account made the change and he DOES NOT have the necessary permissions to do so.
So if you are ever in a situation where you're getting access denied permissions across the board even for full ARS administrators, check your managed domain settings to make sure an override account has not been configured.