AD: OU for system administrator accountsWindows: Can domain controllers also serve other functions?Windows Active Directory naming best practices?Windows AD dcpromo /demote, who gets the roles?Linux computer (Debian) in a Windows Active Directory Domain, Administrator of AD should have root permission after loginWhat should the order of DNS servers be for an AD Domain Controller and Why?Windows Server 2012 std. - Administrator, and any Admin users cannot change folder/file permissions “enter network password”Adding ENTERPRISE ADMINS On Tree Domains In Active DirectoryUnable to promo secondary domain controllerWhat does a domain controller (DC) use a certificate for?Users can edit AD groups in Windows Explorer “Active Directory Search”

Toxic, harassing lab environment

Why do testers need root cause analysis?

Merge pdfs sequentially

How does the Earth's center produce heat?

How to write numbers and percentage?

Why was this character made Grand Maester?

Is this homebrew "Cactus Grenade" cantrip balanced?

Why A=2 and B=1 in the call signs for Spirit and Opportunity?

Did Game of Thrones end the way that George RR Martin intended?

What is to the west of Westeros?

Is a world with one country feeding everyone possible?

What could be my risk mitigation strategies if my client wants to contract UAT?

What is Orcus doing with Mind Flayers in the art on the last page of Volo's Guide to Monsters?

How to teach an undergraduate course without having taken that course formally before?

Time complexity of an algorithm: Is it important to state the base of the logarithm?

Is there a simple example that empirical evidence is misleading?

Is it normal to "extract a paper" from a master thesis?

Unary Enumeration

Why is unzipped directory exactly 4.0K (much smaller than zipped file)?

What is the limit to a Glyph of Warding's trigger?

Is superuser the same as root?

Is it safe to redirect stdout and stderr to the same file without file descriptor copies?

How does Dreadhorde Arcanist interact with split cards?

Gravitational Force Between Numbers



AD: OU for system administrator accounts


Windows: Can domain controllers also serve other functions?Windows Active Directory naming best practices?Windows AD dcpromo /demote, who gets the roles?Linux computer (Debian) in a Windows Active Directory Domain, Administrator of AD should have root permission after loginWhat should the order of DNS servers be for an AD Domain Controller and Why?Windows Server 2012 std. - Administrator, and any Admin users cannot change folder/file permissions “enter network password”Adding ENTERPRISE ADMINS On Tree Domains In Active DirectoryUnable to promo secondary domain controllerWhat does a domain controller (DC) use a certificate for?Users can edit AD groups in Windows Explorer “Active Directory Search”






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








3















Just a simple question:



Does it make sense create a dedicated OU in Active Directory for system administrators (including domain controller admins)?
Are there drawbacks following this approach?
Is there a good practice in regards?










share|improve this question







New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 1





    It can be helpful to "know" this is an admin account. We use "a-" in front of our admin accounts. Admins use normal account for emails & web browsing and such, and "a-" account to login to servers, do adminy things, etc.

    – uSlackr
    May 15 at 18:57

















3















Just a simple question:



Does it make sense create a dedicated OU in Active Directory for system administrators (including domain controller admins)?
Are there drawbacks following this approach?
Is there a good practice in regards?










share|improve this question







New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 1





    It can be helpful to "know" this is an admin account. We use "a-" in front of our admin accounts. Admins use normal account for emails & web browsing and such, and "a-" account to login to servers, do adminy things, etc.

    – uSlackr
    May 15 at 18:57













3












3








3


1






Just a simple question:



Does it make sense create a dedicated OU in Active Directory for system administrators (including domain controller admins)?
Are there drawbacks following this approach?
Is there a good practice in regards?










share|improve this question







New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











Just a simple question:



Does it make sense create a dedicated OU in Active Directory for system administrators (including domain controller admins)?
Are there drawbacks following this approach?
Is there a good practice in regards?







active-directory windows-server-2016






share|improve this question







New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










share|improve this question







New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








share|improve this question




share|improve this question






New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








asked May 15 at 16:18









SubZenoSubZeno

283




283




New contributor



SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




New contributor




SubZeno is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









  • 1





    It can be helpful to "know" this is an admin account. We use "a-" in front of our admin accounts. Admins use normal account for emails & web browsing and such, and "a-" account to login to servers, do adminy things, etc.

    – uSlackr
    May 15 at 18:57












  • 1





    It can be helpful to "know" this is an admin account. We use "a-" in front of our admin accounts. Admins use normal account for emails & web browsing and such, and "a-" account to login to servers, do adminy things, etc.

    – uSlackr
    May 15 at 18:57







1




1





It can be helpful to "know" this is an admin account. We use "a-" in front of our admin accounts. Admins use normal account for emails & web browsing and such, and "a-" account to login to servers, do adminy things, etc.

– uSlackr
May 15 at 18:57





It can be helpful to "know" this is an admin account. We use "a-" in front of our admin accounts. Admins use normal account for emails & web browsing and such, and "a-" account to login to servers, do adminy things, etc.

– uSlackr
May 15 at 18:57










4 Answers
4






active

oldest

votes


















5














As noted in other responses it can be good for GPO linking -- though I would never make this configuration change solely for that purpose.



Also noted, Active Directory does a have "a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts", but this safeguard only deals with user accounts that a members (directly or indirectly) of the Protected Groups (Domain Admins, Server Operators, Account Operators, Backup Operators, etc.; full list here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory). I propose that the sdProp process - while beneficial - is just one layer of protection for Active Directory security, and that it is insufficient to be relied upon as the sole layer of securing sensitive security principals.



While this is a great feature of Active Directory, the problem is that if the (at times, nebulous) best practices are being followed, these groups will be mostly empty. Also by choosing to adhere to best practices it necessarily follows that several custom groups must be created and used to secure different access in the environment - groups with admin access to workstations, groups with admin access to servers, groups with admin access to Exchange, groups with admin access to the virtualization environment, groups with admin access to shared file systems, groups with admin access to other applications and other LDAP-integrated applications, services, and devices; groups that are delegated access to Active Directory itself.



Several of these groups should be treated with as much reverence as "Domain Admins" or any of the other groups detailed in the link -- and sdProp/adminSDHolder does not support the inclusion of additional groups - only the exclusion of (at my last check) 4 of the pre-defined groups.



In order to properly and easily achieve delegation of management of these groups, these groups should be kept in a separate OU to which access can either be delegated, or remain as the default with Domain Admins retaining sole access to modify the groups' memberships. Since this OU is essentially required to secure the discussed groups, it logically follows that members of these groups (the dedicated secondary, tertiary, even quartenary administrative accounts for various users) should also exist in this location.






share|improve this answer






























    4














    The Real Answer(tm) is something like: Uhh-- maybe, depending on what you're trying to accomplish. Tell us more about why you're thinking about doing this and we can give you a more specific answer. What are you trying to actual accomplish?



    There is no specific best practice that I'm aware of. Active Directory has a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts. You don't have a major risk of opening up "Domain Admins" or other privileged group membership simply by placing privileged accounts into an OU.



    If you're looking to do this simply for visual organization you should read-up on using queries in "Active Directory Users and Computers". You can make "views" of Active Directory objects that look virtually any way you can think of.



    If you goals go beyond visual then you need to think about a variety of concerns.



    The physical structure of domain partition of an Active Directory (the OU structure) is best structured to facilitate Delegation of Control first, and Group Policy deployment second.



    If this proposed separation is based on a Delegation of Control concern then you'd do well to read up on adminSDHolder, sdProp, and how permissions for privileged accounts works in AD.



    If you're talking about controlling Group Policy application then, sure, put the accounts in an OU. (Heck, put 'em in two.) There's still an "it depends on what you're trying to accomplish" component to that, too. Are you looking for an easy way to segregate user Group Policy for a class of users? Filtering GPOs with group membership might accomplish the same thing you're looking for and could prevent you from needing to "repeat yourself" by linking common GPOs in multiple locations (or, worse, duplicating the same settings in multiple GPOs).



    The nature of your question makes me think you should probably take a look at some Active Directory design documentation (like https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning), too.






    share|improve this answer






























      1














      To keep it simple; yes it add value, I don't see any drawback.



      The goal in such scenario is if your organization use a lot users group policy.



      As a dedicated OU allow you to isolate the administrator's account from all the users GPO easily.






      share|improve this answer






























        1














        Yes, you will need to do so in order to set the proper policies on them. See https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access for details on what exactly those policies should be.






        share|improve this answer























          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "2"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );






          SubZeno is a new contributor. Be nice, and check out our Code of Conduct.









          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f967411%2fad-ou-for-system-administrator-accounts%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          4 Answers
          4






          active

          oldest

          votes








          4 Answers
          4






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          5














          As noted in other responses it can be good for GPO linking -- though I would never make this configuration change solely for that purpose.



          Also noted, Active Directory does a have "a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts", but this safeguard only deals with user accounts that a members (directly or indirectly) of the Protected Groups (Domain Admins, Server Operators, Account Operators, Backup Operators, etc.; full list here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory). I propose that the sdProp process - while beneficial - is just one layer of protection for Active Directory security, and that it is insufficient to be relied upon as the sole layer of securing sensitive security principals.



          While this is a great feature of Active Directory, the problem is that if the (at times, nebulous) best practices are being followed, these groups will be mostly empty. Also by choosing to adhere to best practices it necessarily follows that several custom groups must be created and used to secure different access in the environment - groups with admin access to workstations, groups with admin access to servers, groups with admin access to Exchange, groups with admin access to the virtualization environment, groups with admin access to shared file systems, groups with admin access to other applications and other LDAP-integrated applications, services, and devices; groups that are delegated access to Active Directory itself.



          Several of these groups should be treated with as much reverence as "Domain Admins" or any of the other groups detailed in the link -- and sdProp/adminSDHolder does not support the inclusion of additional groups - only the exclusion of (at my last check) 4 of the pre-defined groups.



          In order to properly and easily achieve delegation of management of these groups, these groups should be kept in a separate OU to which access can either be delegated, or remain as the default with Domain Admins retaining sole access to modify the groups' memberships. Since this OU is essentially required to secure the discussed groups, it logically follows that members of these groups (the dedicated secondary, tertiary, even quartenary administrative accounts for various users) should also exist in this location.






          share|improve this answer



























            5














            As noted in other responses it can be good for GPO linking -- though I would never make this configuration change solely for that purpose.



            Also noted, Active Directory does a have "a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts", but this safeguard only deals with user accounts that a members (directly or indirectly) of the Protected Groups (Domain Admins, Server Operators, Account Operators, Backup Operators, etc.; full list here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory). I propose that the sdProp process - while beneficial - is just one layer of protection for Active Directory security, and that it is insufficient to be relied upon as the sole layer of securing sensitive security principals.



            While this is a great feature of Active Directory, the problem is that if the (at times, nebulous) best practices are being followed, these groups will be mostly empty. Also by choosing to adhere to best practices it necessarily follows that several custom groups must be created and used to secure different access in the environment - groups with admin access to workstations, groups with admin access to servers, groups with admin access to Exchange, groups with admin access to the virtualization environment, groups with admin access to shared file systems, groups with admin access to other applications and other LDAP-integrated applications, services, and devices; groups that are delegated access to Active Directory itself.



            Several of these groups should be treated with as much reverence as "Domain Admins" or any of the other groups detailed in the link -- and sdProp/adminSDHolder does not support the inclusion of additional groups - only the exclusion of (at my last check) 4 of the pre-defined groups.



            In order to properly and easily achieve delegation of management of these groups, these groups should be kept in a separate OU to which access can either be delegated, or remain as the default with Domain Admins retaining sole access to modify the groups' memberships. Since this OU is essentially required to secure the discussed groups, it logically follows that members of these groups (the dedicated secondary, tertiary, even quartenary administrative accounts for various users) should also exist in this location.






            share|improve this answer

























              5












              5








              5







              As noted in other responses it can be good for GPO linking -- though I would never make this configuration change solely for that purpose.



              Also noted, Active Directory does a have "a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts", but this safeguard only deals with user accounts that a members (directly or indirectly) of the Protected Groups (Domain Admins, Server Operators, Account Operators, Backup Operators, etc.; full list here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory). I propose that the sdProp process - while beneficial - is just one layer of protection for Active Directory security, and that it is insufficient to be relied upon as the sole layer of securing sensitive security principals.



              While this is a great feature of Active Directory, the problem is that if the (at times, nebulous) best practices are being followed, these groups will be mostly empty. Also by choosing to adhere to best practices it necessarily follows that several custom groups must be created and used to secure different access in the environment - groups with admin access to workstations, groups with admin access to servers, groups with admin access to Exchange, groups with admin access to the virtualization environment, groups with admin access to shared file systems, groups with admin access to other applications and other LDAP-integrated applications, services, and devices; groups that are delegated access to Active Directory itself.



              Several of these groups should be treated with as much reverence as "Domain Admins" or any of the other groups detailed in the link -- and sdProp/adminSDHolder does not support the inclusion of additional groups - only the exclusion of (at my last check) 4 of the pre-defined groups.



              In order to properly and easily achieve delegation of management of these groups, these groups should be kept in a separate OU to which access can either be delegated, or remain as the default with Domain Admins retaining sole access to modify the groups' memberships. Since this OU is essentially required to secure the discussed groups, it logically follows that members of these groups (the dedicated secondary, tertiary, even quartenary administrative accounts for various users) should also exist in this location.






              share|improve this answer













              As noted in other responses it can be good for GPO linking -- though I would never make this configuration change solely for that purpose.



              Also noted, Active Directory does a have "a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts", but this safeguard only deals with user accounts that a members (directly or indirectly) of the Protected Groups (Domain Admins, Server Operators, Account Operators, Backup Operators, etc.; full list here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory). I propose that the sdProp process - while beneficial - is just one layer of protection for Active Directory security, and that it is insufficient to be relied upon as the sole layer of securing sensitive security principals.



              While this is a great feature of Active Directory, the problem is that if the (at times, nebulous) best practices are being followed, these groups will be mostly empty. Also by choosing to adhere to best practices it necessarily follows that several custom groups must be created and used to secure different access in the environment - groups with admin access to workstations, groups with admin access to servers, groups with admin access to Exchange, groups with admin access to the virtualization environment, groups with admin access to shared file systems, groups with admin access to other applications and other LDAP-integrated applications, services, and devices; groups that are delegated access to Active Directory itself.



              Several of these groups should be treated with as much reverence as "Domain Admins" or any of the other groups detailed in the link -- and sdProp/adminSDHolder does not support the inclusion of additional groups - only the exclusion of (at my last check) 4 of the pre-defined groups.



              In order to properly and easily achieve delegation of management of these groups, these groups should be kept in a separate OU to which access can either be delegated, or remain as the default with Domain Admins retaining sole access to modify the groups' memberships. Since this OU is essentially required to secure the discussed groups, it logically follows that members of these groups (the dedicated secondary, tertiary, even quartenary administrative accounts for various users) should also exist in this location.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered May 15 at 20:21









              SemicolonSemicolon

              78536




              78536























                  4














                  The Real Answer(tm) is something like: Uhh-- maybe, depending on what you're trying to accomplish. Tell us more about why you're thinking about doing this and we can give you a more specific answer. What are you trying to actual accomplish?



                  There is no specific best practice that I'm aware of. Active Directory has a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts. You don't have a major risk of opening up "Domain Admins" or other privileged group membership simply by placing privileged accounts into an OU.



                  If you're looking to do this simply for visual organization you should read-up on using queries in "Active Directory Users and Computers". You can make "views" of Active Directory objects that look virtually any way you can think of.



                  If you goals go beyond visual then you need to think about a variety of concerns.



                  The physical structure of domain partition of an Active Directory (the OU structure) is best structured to facilitate Delegation of Control first, and Group Policy deployment second.



                  If this proposed separation is based on a Delegation of Control concern then you'd do well to read up on adminSDHolder, sdProp, and how permissions for privileged accounts works in AD.



                  If you're talking about controlling Group Policy application then, sure, put the accounts in an OU. (Heck, put 'em in two.) There's still an "it depends on what you're trying to accomplish" component to that, too. Are you looking for an easy way to segregate user Group Policy for a class of users? Filtering GPOs with group membership might accomplish the same thing you're looking for and could prevent you from needing to "repeat yourself" by linking common GPOs in multiple locations (or, worse, duplicating the same settings in multiple GPOs).



                  The nature of your question makes me think you should probably take a look at some Active Directory design documentation (like https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning), too.






                  share|improve this answer



























                    4














                    The Real Answer(tm) is something like: Uhh-- maybe, depending on what you're trying to accomplish. Tell us more about why you're thinking about doing this and we can give you a more specific answer. What are you trying to actual accomplish?



                    There is no specific best practice that I'm aware of. Active Directory has a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts. You don't have a major risk of opening up "Domain Admins" or other privileged group membership simply by placing privileged accounts into an OU.



                    If you're looking to do this simply for visual organization you should read-up on using queries in "Active Directory Users and Computers". You can make "views" of Active Directory objects that look virtually any way you can think of.



                    If you goals go beyond visual then you need to think about a variety of concerns.



                    The physical structure of domain partition of an Active Directory (the OU structure) is best structured to facilitate Delegation of Control first, and Group Policy deployment second.



                    If this proposed separation is based on a Delegation of Control concern then you'd do well to read up on adminSDHolder, sdProp, and how permissions for privileged accounts works in AD.



                    If you're talking about controlling Group Policy application then, sure, put the accounts in an OU. (Heck, put 'em in two.) There's still an "it depends on what you're trying to accomplish" component to that, too. Are you looking for an easy way to segregate user Group Policy for a class of users? Filtering GPOs with group membership might accomplish the same thing you're looking for and could prevent you from needing to "repeat yourself" by linking common GPOs in multiple locations (or, worse, duplicating the same settings in multiple GPOs).



                    The nature of your question makes me think you should probably take a look at some Active Directory design documentation (like https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning), too.






                    share|improve this answer

























                      4












                      4








                      4







                      The Real Answer(tm) is something like: Uhh-- maybe, depending on what you're trying to accomplish. Tell us more about why you're thinking about doing this and we can give you a more specific answer. What are you trying to actual accomplish?



                      There is no specific best practice that I'm aware of. Active Directory has a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts. You don't have a major risk of opening up "Domain Admins" or other privileged group membership simply by placing privileged accounts into an OU.



                      If you're looking to do this simply for visual organization you should read-up on using queries in "Active Directory Users and Computers". You can make "views" of Active Directory objects that look virtually any way you can think of.



                      If you goals go beyond visual then you need to think about a variety of concerns.



                      The physical structure of domain partition of an Active Directory (the OU structure) is best structured to facilitate Delegation of Control first, and Group Policy deployment second.



                      If this proposed separation is based on a Delegation of Control concern then you'd do well to read up on adminSDHolder, sdProp, and how permissions for privileged accounts works in AD.



                      If you're talking about controlling Group Policy application then, sure, put the accounts in an OU. (Heck, put 'em in two.) There's still an "it depends on what you're trying to accomplish" component to that, too. Are you looking for an easy way to segregate user Group Policy for a class of users? Filtering GPOs with group membership might accomplish the same thing you're looking for and could prevent you from needing to "repeat yourself" by linking common GPOs in multiple locations (or, worse, duplicating the same settings in multiple GPOs).



                      The nature of your question makes me think you should probably take a look at some Active Directory design documentation (like https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning), too.






                      share|improve this answer













                      The Real Answer(tm) is something like: Uhh-- maybe, depending on what you're trying to accomplish. Tell us more about why you're thinking about doing this and we can give you a more specific answer. What are you trying to actual accomplish?



                      There is no specific best practice that I'm aware of. Active Directory has a safeguard (adminSDHolder and sdProp) to prevent Delegation of Control activities from compromising privileged accounts. You don't have a major risk of opening up "Domain Admins" or other privileged group membership simply by placing privileged accounts into an OU.



                      If you're looking to do this simply for visual organization you should read-up on using queries in "Active Directory Users and Computers". You can make "views" of Active Directory objects that look virtually any way you can think of.



                      If you goals go beyond visual then you need to think about a variety of concerns.



                      The physical structure of domain partition of an Active Directory (the OU structure) is best structured to facilitate Delegation of Control first, and Group Policy deployment second.



                      If this proposed separation is based on a Delegation of Control concern then you'd do well to read up on adminSDHolder, sdProp, and how permissions for privileged accounts works in AD.



                      If you're talking about controlling Group Policy application then, sure, put the accounts in an OU. (Heck, put 'em in two.) There's still an "it depends on what you're trying to accomplish" component to that, too. Are you looking for an easy way to segregate user Group Policy for a class of users? Filtering GPOs with group membership might accomplish the same thing you're looking for and could prevent you from needing to "repeat yourself" by linking common GPOs in multiple locations (or, worse, duplicating the same settings in multiple GPOs).



                      The nature of your question makes me think you should probably take a look at some Active Directory design documentation (like https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ad-ds-design-and-planning), too.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered May 15 at 16:34









                      Evan AndersonEvan Anderson

                      136k14171313




                      136k14171313





















                          1














                          To keep it simple; yes it add value, I don't see any drawback.



                          The goal in such scenario is if your organization use a lot users group policy.



                          As a dedicated OU allow you to isolate the administrator's account from all the users GPO easily.






                          share|improve this answer



























                            1














                            To keep it simple; yes it add value, I don't see any drawback.



                            The goal in such scenario is if your organization use a lot users group policy.



                            As a dedicated OU allow you to isolate the administrator's account from all the users GPO easily.






                            share|improve this answer

























                              1












                              1








                              1







                              To keep it simple; yes it add value, I don't see any drawback.



                              The goal in such scenario is if your organization use a lot users group policy.



                              As a dedicated OU allow you to isolate the administrator's account from all the users GPO easily.






                              share|improve this answer













                              To keep it simple; yes it add value, I don't see any drawback.



                              The goal in such scenario is if your organization use a lot users group policy.



                              As a dedicated OU allow you to isolate the administrator's account from all the users GPO easily.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered May 15 at 16:25









                              yagmoth555yagmoth555

                              12.6k31842




                              12.6k31842





















                                  1














                                  Yes, you will need to do so in order to set the proper policies on them. See https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access for details on what exactly those policies should be.






                                  share|improve this answer



























                                    1














                                    Yes, you will need to do so in order to set the proper policies on them. See https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access for details on what exactly those policies should be.






                                    share|improve this answer

























                                      1












                                      1








                                      1







                                      Yes, you will need to do so in order to set the proper policies on them. See https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access for details on what exactly those policies should be.






                                      share|improve this answer













                                      Yes, you will need to do so in order to set the proper policies on them. See https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access for details on what exactly those policies should be.







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered May 15 at 21:26









                                      Jim BJim B

                                      23.2k32858




                                      23.2k32858




















                                          SubZeno is a new contributor. Be nice, and check out our Code of Conduct.









                                          draft saved

                                          draft discarded


















                                          SubZeno is a new contributor. Be nice, and check out our Code of Conduct.












                                          SubZeno is a new contributor. Be nice, and check out our Code of Conduct.











                                          SubZeno is a new contributor. Be nice, and check out our Code of Conduct.














                                          Thanks for contributing an answer to Server Fault!


                                          • Please be sure to answer the question. Provide details and share your research!

                                          But avoid


                                          • Asking for help, clarification, or responding to other answers.

                                          • Making statements based on opinion; back them up with references or personal experience.

                                          To learn more, see our tips on writing great answers.




                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function ()
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f967411%2fad-ou-for-system-administrator-accounts%23new-answer', 'question_page');

                                          );

                                          Post as a guest















                                          Required, but never shown





















































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown

































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown







                                          Popular posts from this blog

                                          Get product attribute by attribute group code in magento 2get product attribute by product attribute group in magento 2Magento 2 Log Bundle Product Data in List Page?How to get all product attribute of a attribute group of Default attribute set?Magento 2.1 Create a filter in the product grid by new attributeMagento 2 : Get Product Attribute values By GroupMagento 2 How to get all existing values for one attributeMagento 2 get custom attribute of a single product inside a pluginMagento 2.3 How to get all the Multi Source Inventory (MSI) locations collection in custom module?Magento2: how to develop rest API to get new productsGet product attribute by attribute group code ( [attribute_group_code] ) in magento 2

                                          Category:9 (number) SubcategoriesMedia in category "9 (number)"Navigation menuUpload mediaGND ID: 4485639-8Library of Congress authority ID: sh85091979ReasonatorScholiaStatistics

                                          Magento 2.3: How do i solve this, Not registered handle, on custom form?How can i rewrite TierPrice Block in Magento2magento 2 captcha not rendering if I override layout xmlmain.CRITICAL: Plugin class doesn't existMagento 2 : Problem while adding custom button order view page?Magento 2.2.5: Overriding Admin Controller sales/orderMagento 2.2.5: Add, Update and Delete existing products Custom OptionsMagento 2.3 : File Upload issue in UI Component FormMagento2 Not registered handleHow to configured Form Builder Js in my custom magento 2.3.0 module?Magento 2.3. How to create image upload field in an admin form