• State Verified Answer
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 248 views
  • Users 0 members are here
Options
Related

Override/proxy account minimum permissions

jody gilbert
11 days ago

We've got a subsidiary who have their own forest and IT team, there is a two way trust between the forests and we often add users to security groups from the each others domain.

Currently our service desk can add people from our domain to groups from the other domain via ADUC, but because we haven't added that domain to ARS they cannot use ARS.

I'd like to remove service desk access to ADUC so they can only use ARS, but I need to find a solution for letting them add people to groups from the other domain.

I know I can add the domain with and proxy/override account, my understanding is that account needs to be domain admin in the domain.  I'd prefer not to have a domain admin account in that domain as we do not manage or own it.  Can we provide a minimum set of permissions so that ARS can be used for updating group membership only?

Parents
  • +1 11 days ago

    The override account doesn't need to be DA.  Use the *native* delegation wizard in ADUC to grant your override account the specific rights it needs in the managed AD to perfrom the required task(s).  Problem solved.

  • 0 8 days ago in reply to jody gilbert

    To add to what  said, have a look at https://support.oneidentity.com/active-roles/kb/4323027/active-roles-service-account-minimum-permissions-4323027

    There are a couple of items you need to be aware of when the Managed Domain service account is not a member of Domain Admins

    1) If Active Roles is going to be managing any user accounts in the managed domain, where the users AdminCount attribute is > 0, them you'd need to ensure you want appropriate permissions against <your managed domain>\System\AdminSDHolder, as when AdminCount > 0, inheritence on those objects is blocked, and permissions are granted from AdminSDHolder

    2) For existing objects created before the service account existed (or it was removed from DA), from memory (as its been a while since I saw this) changing native permissions might fail, as the ARS service account is not the owner of the object (and not a DA). If this happens, either change the owner of the object, or perform the change outside Active Roles.

    3) If you need to manage any confidential attributes (bitlocker keys for example), the service account will need to be granted permissions

    4) If you want the service connection point for the Active Roles Administration Service(s) published to the managed domain(s), ensure that permissions are granted as per the KB (Service Publication in Active Directory) above.

    5) If you use fine grained password policies, ensure that the managed domain service account has permissions to read the Password Setting container, and also permissions to read msDs-PasswordSettings of the child items.

    6) If the managed domains has Exchange, don't forget to add the service account to the Recipient Management and Organization Management groups, and also configure exchange to allow the service account to run remote PowerShell

Reply
  • 0 8 days ago in reply to jody gilbert

    To add to what  said, have a look at https://support.oneidentity.com/active-roles/kb/4323027/active-roles-service-account-minimum-permissions-4323027

    There are a couple of items you need to be aware of when the Managed Domain service account is not a member of Domain Admins

    1) If Active Roles is going to be managing any user accounts in the managed domain, where the users AdminCount attribute is > 0, them you'd need to ensure you want appropriate permissions against <your managed domain>\System\AdminSDHolder, as when AdminCount > 0, inheritence on those objects is blocked, and permissions are granted from AdminSDHolder

    2) For existing objects created before the service account existed (or it was removed from DA), from memory (as its been a while since I saw this) changing native permissions might fail, as the ARS service account is not the owner of the object (and not a DA). If this happens, either change the owner of the object, or perform the change outside Active Roles.

    3) If you need to manage any confidential attributes (bitlocker keys for example), the service account will need to be granted permissions

    4) If you want the service connection point for the Active Roles Administration Service(s) published to the managed domain(s), ensure that permissions are granted as per the KB (Service Publication in Active Directory) above.

    5) If you use fine grained password policies, ensure that the managed domain service account has permissions to read the Password Setting container, and also permissions to read msDs-PasswordSettings of the child items.

    6) If the managed domains has Exchange, don't forget to add the service account to the Recipient Management and Organization Management groups, and also configure exchange to allow the service account to run remote PowerShell

Children
  • 0 8 days ago in reply to Stu.Pollock

    Many thanks for the detailed response!

    In our case, the only thing we need to update in the managed domain is group membership and I do not want to update any AdminSDHolders as we do not own the other domain.  This means I think we can get away with minimal permissions for group membership.

    If this changes in the future then we'll review how ARS is used and if it should be used to fully manage everything.