Access denied in ARS console

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?

  • These related links popped up on the site as I was reading your post. In addition to any nuggets you find there ... Is your account still in a group identified as administrators of the ARS system?

    Is console access affected from a console installed at your desktop / or an ARS admin service host itself? If remote - I've encountered RPC issues in the past related to firewall changes in the office. I had to work with the firewall team to clear that one up.
  • In reply to dyannic:


    Thanks for replying. The problems occur on the ARS admin server itself, not a remote console. I also checked the DCOM settings and all seems well there as well. I'm still digging and I've been on this for several hours since yesterday afternoon.
  • In reply to DJ:

    Another thought ...
    Do you have the ARS interfaces up and running? Does your access work there?
    If so - in the help/About pop-up, does it still how your role as Administrator?
    If the service account proxy still works - then it may be your admin access ...
    Have you checked your team group membership? and confirmed that group is still still listed as 'Administrator' in the EDM registry settings?

    the web 'about' page should show you're connected as such ...
    Role: ActiveRoles Administrator
  • In reply to dyannic:

    I can logon to the ARS console and see everything but I can't make any changes without receiving an access denied message.

    I checked the "about" page in Web Interface it lists my role as: ActiveRoles Administrator.

    I also verified in the registry that my group is listed as DSAdministrators.

    And this is what's so strange: everything looks as it should but we still cannot make modifications, neither with the ARS service account or our individual admin accounts.
  • In reply to DJ:

    I won't presume - and will ask the basic question ... have you restarted the ars service to reset your proxy connections to the domain - and see any startup messages from the service itself? I occasionally see the notice that logon as a service needs to be granted ... and that right has been set for evah. I've seen my share of delegated access weirdness ... but not as ARS admin at the console.
  • In reply to dyannic:

    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.

  • In reply to DJ:

    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.