• State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 3496 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARS 7.2 permission model

BojanNS
over 6 years ago

I need explanation of ARS 7.2 permission model - Administration Service account permissions/usage, override accounts permissions/usage and in the end how helpdesk operator permissions are delegated to in order, for instance him/her to be able to create/delete user accounts in certain OU and nothing else. If Administration Service account/override account is given domain admin rights (current state which is completely wrong from security perspective - someone did that long time ago) how that is reflected to helpdesk operators rights to do something? Some practical example would be nice to see too - I am newbie in ARS without anybody to ask here. Admin guide does not go into these details - just high level view I think.

Parents
  • 0 over 6 years ago
    Active Roles has a zero-permissions model. Unless something is configured by an Active Roles Administrator, absolutely no access is granted. Even the Domain is completely hidden.

    Active Roles leverages native Windows authentication processes to confirm a User's identity. Native SID's and identifiers are stored and linked to Access Templates within Active Roles to determine the access which will be granted. The service account/override account then performs that operation on behalf of the delegated trustee. If the native permissions granted to the service account/override account are not sufficient to perform the delegated operation, then it will fail.

    If the Active Roles service account/override account were not a Domain admin, then you would be outside of a supported configuration. It simply is not possible for us to test product functionality with granular permissions in Active Roles. The assumption is broad access.

    It's possible for the software to work in with granular permissions, but it would be completely on you to manually configure the native permissions which the account needs in order to perform the specific management that you want to do. In most cases, the end result would be almost identical to a Domain Admin privilege. I suggest going the other direction - grant the account Domain Admin access, then simply block native access for that particular account to anything that you want to remain off-limits.
Reply
  • 0 over 6 years ago
    Active Roles has a zero-permissions model. Unless something is configured by an Active Roles Administrator, absolutely no access is granted. Even the Domain is completely hidden.

    Active Roles leverages native Windows authentication processes to confirm a User's identity. Native SID's and identifiers are stored and linked to Access Templates within Active Roles to determine the access which will be granted. The service account/override account then performs that operation on behalf of the delegated trustee. If the native permissions granted to the service account/override account are not sufficient to perform the delegated operation, then it will fail.

    If the Active Roles service account/override account were not a Domain admin, then you would be outside of a supported configuration. It simply is not possible for us to test product functionality with granular permissions in Active Roles. The assumption is broad access.

    It's possible for the software to work in with granular permissions, but it would be completely on you to manually configure the native permissions which the account needs in order to perform the specific management that you want to do. In most cases, the end result would be almost identical to a Domain Admin privilege. I suggest going the other direction - grant the account Domain Admin access, then simply block native access for that particular account to anything that you want to remain off-limits.
Children
No Data