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;
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
New contributor
add a comment |
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
New contributor
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
add a comment |
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
New contributor
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
active-directory windows-server-2016
New contributor
New contributor
New contributor
asked May 15 at 16:18
SubZenoSubZeno
283
283
New contributor
New contributor
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
add a comment |
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
add a comment |
4 Answers
4
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered May 15 at 20:21
SemicolonSemicolon
78536
78536
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered May 15 at 16:34
Evan AndersonEvan Anderson
136k14171313
136k14171313
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered May 15 at 16:25
yagmoth555♦yagmoth555
12.6k31842
12.6k31842
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered May 15 at 21:26
Jim BJim B
23.2k32858
23.2k32858
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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