Home
Join

67 Replies

  • I think mistake #1 happens all the time.  I know this is a Windows thread, but it reminds me of Ubuntu.  Obviously Linux has the same rule, do not run as root.  Ubuntu doesn't even allow it, but what it taught me when I was brand new to all things Linux was to simply type "sudo" in front of every command to make sure it works.  I don't know why I find that so funny. 

    Spice (10) flagReport
    Was this post helpful? thumb_up thumb_down
  • Thanks for the write up. My experience has been setting up Active Directory in a test environment only and I don't do any management on our DCs so my knowledge is limited but I would ask for some clarification on #4.

    "all daily administration should take place on protected administrative machines"  I assume the advice is to remote in for access. I use RDP from my PC to check IP leases and to change passwords for users.  Perhaps a dedicated workstation would be a better choice.

    Could you expand some on this, please:

    "As best practices suggest, domain controllers should only run the roles required for domain services (which include the DNS role, but never use DC for DNS; always point it at another DC)"

    Again, thanks for the write up, these keep me sharp.

    Spice (8) flagReport
    2 found this helpful thumb_up thumb_down
  • Having too many damn GPO's with no descriptive titles or notes. The same goes with service accounts. That's my biggest pet peeve. 

    Spice (31) flagReport
    5 found this helpful thumb_up thumb_down
  • Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    Spice (15) flagReport
    0 of 1 found this helpful thumb_up thumb_down
  • You mean we should change the password from 12345 to something more secure.

    https://www.youtube.com/watch?v=_JNGI1dI-e8

    Spice (16) flagReport
    2 found this helpful thumb_up thumb_down
  • Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    It's 2017 - don't do anything logged IN to a/the DC. Use RSAT on a secured workstation, and connect to the DC (via DNS, DHCP) as needed. https://www.microsoft.com/en-us/download/details.aspx?id=45520

    Spice (6) flagReport
    0 of 2 found this helpful thumb_up thumb_down
  • David_CSG wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    It's 2017 - don't do anything logged IN to a/the DC. Use RSAT on a secured workstation, and connect to the DC (via DNS, DHCP) as needed. https://www.microsoft.com/en-us/download/details.aspx?id=45520

    That doesn't explain how or why managing AD directly on a domain controller is a bad practice.

    Spice (8) flagReport
    0 of 1 found this helpful thumb_up thumb_down
  • Evan7191 wrote:

    David_CSG wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    It's 2017 - don't do anything logged IN to a/the DC. Use RSAT on a secured workstation, and connect to the DC (via DNS, DHCP) as needed. https://www.microsoft.com/en-us/download/details.aspx?id=45520

    That doesn't explain how or why managing AD directly on a domain controller is a bad practice.

    I believe that he is talking about physically logging into the server.  As in walking up to the rack and logging in.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down
  • Evan7191 wrote:

    David_CSG wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    It's 2017 - don't do anything logged IN to a/the DC. Use RSAT on a secured workstation, and connect to the DC (via DNS, DHCP) as needed. https://www.microsoft.com/en-us/download/details.aspx?id=45520

    That doesn't explain how or why managing AD directly on a domain controller is a bad practice.

    Let me turn the question around: Why do you/would you need to ?

    From a high-level perspective, this is platform-agnostic: Minimize end-user ("GUI") level access to and use of any server. 

    Spice (1) flagReport
    0 of 1 found this helpful thumb_up thumb_down
  • Sudonym wrote:

    Evan7191 wrote:

    David_CSG wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    It's 2017 - don't do anything logged IN to a/the DC. Use RSAT on a secured workstation, and connect to the DC (via DNS, DHCP) as needed. https://www.microsoft.com/en-us/download/details.aspx?id=45520

    That doesn't explain how or why managing AD directly on a domain controller is a bad practice.

    I believe that he is talking about physically logging into the server.  As in walking up to the rack and logging in.

    Or logging into it directly via RDP: Post-installation, there should be zero need to except in the most extreme and rare cases.

    Spice (1) flagReport
    0 of 1 found this helpful thumb_up thumb_down
  • David_CSG wrote:

    Evan7191 wrote:

    David_CSG wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    It's 2017 - don't do anything logged IN to a/the DC. Use RSAT on a secured workstation, and connect to the DC (via DNS, DHCP) as needed. https://www.microsoft.com/en-us/download/details.aspx?id=45520

    That doesn't explain how or why managing AD directly on a domain controller is a bad practice.

    Let me turn the question around: Why do you/would you need to ?

    From a high-level perspective, this is platform-agnostic: Minimize end-user ("GUI") level access to and use of any server. 

    Turning the question around doesn't clarify the situation.  I never said that I need to log into a DC directly to manage AD.  My point is that the article should be able to explain why a supposed bad practice is bad, especially if their recommendation does not conform with the developer's or vendor's own recommendations for best practices.

    Also, RSAT has nothing to do with minimizing end-user access to a DC.  I can use role-based permissions and group policies to restrict who can access AD, whether it is through RSAT or RDP into a DC.

    Spice (12) flagReport
    2 found this helpful thumb_up thumb_down
  • Well, you're picking/making an argument that I wasn't. You could also control and/or limit access via firewall(s) and VLANS, but that's not what was being discussed.

    0 of 4 found this helpful thumb_up thumb_down
  • David_CSG wrote:

    Well, you're picking/making an argument that I wasn't. You could also control and/or limit access via firewall(s) and VLANS, but that's not what was being discussed.

    I wasn't trying to change the argument.  I must have misunderstood.  What did you mean by "From a high-level perspective, this is platform-agnostic: Minimize end-user ("GUI") level access to and use of any server. "

    Was this post helpful? thumb_up thumb_down
  • Think of it this way, the fewer times you log onto a computer/server directly, the less it has to work to process information, write logs, go through the login process etc., the better. And by directly, I mean from a terminal or RDP, anything where you actually log in to that server. Use RSAT or other remote management methods whenever possible to avoid "touching" the server.

    Bonus: iOS app "AD Assist" will allow you to manage most things AD from your iPhone. Super convenient.


    Spice (4) flagReport
    1 found this helpful thumb_up thumb_down
  • Just to add to the list, there are typical mistakes like exposing sensitive data in AD, not delegating enough or over-delegating, not protecting AD objects.You can read more on that in a very similar article that we have.

    Also, there's not automating onboarding and offboarding procedures. Technically it's not a mistake, but taking into account the modern day technology, it's hard to justify not having any automation at all. 

    We provide user provisioning and deprovisioning automation with Adaxes, but even if you don't have such a solution, you can at least automate importing new users via CSV.

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • Some considerations:
    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack

    1 found this helpful thumb_up thumb_down
  • Gary Glenn wrote:

    Think of it this way, the fewer times you log onto a computer/server directly, the less it has to work to process information, write logs, go through the login process etc., the better. And by directly, I mean from a terminal or RDP, anything where you actually log in to that server. Use RSAT or other remote management methods whenever possible to avoid "touching" the server.

    Bonus: iOS app "AD Assist" will allow you to manage most things AD from your iPhone. Super convenient.


    Using your cell phone to manage AD on a production server does not feel very secure, to me anyhow. 

    I think that managing AD and other services from a secured workstation is a good practice because it allows you to administer with an account that had AD admin rights that does NOT need to have rights to remote logon with the server; in large organizations you can even delegate specific things to specific accounts making breaches even more difficult.  

    In a small environment, it may not really make much sense to separate these functions, however.

    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down
  • In respect of #6, last time I looked the favoured best practice IS to set a users password to never expire, as long as it's suitably complex (e.g. a passphrase) and to force reset on breach.

    There's another thread about this somewhere else.  I'll try and find it.

    Spice (14) flagReport
    Was this post helpful? thumb_up thumb_down
  • A good list, except for " Never set a user’s password to never expire.". Enforced password changes aren't a good idea, and more often than not leads to reduced security.

    Far better to configure the account lockout policy to lock after 5 incorrect attempts, and to auto-unlock after 10 minutes. This effectively breaks any brute-force attack against an account. Additionally, obviously you should set up alerts for failed logins, so you can take action early.

    Spice (13) flagReport
    2 of 6 found this helpful thumb_up thumb_down
  • Active Directory controls access to  critical systems and data, so is the ultimate target for hackers because it holds the keys to your entire kingdom.

    I would add this another informative resource containing few steps one can take to ensure and avoid the risk of active directory - https://www.lepide.com/blog/top-10-risks-to-active-directory-security/ 

    0 of 1 found this helpful thumb_up thumb_down
  • jhTech86 wrote:

    I think mistake #1 happens all the time.  I know this is a Windows thread, but it reminds me of Ubuntu.  Obviously Linux has the same rule, do not run as root.  Ubuntu doesn't even allow it, but what it taught me when I was brand new to all things Linux was to simply type "sudo" in front of every command to make sure it works.  I don't know why I find that so funny. 

    Totally agree with you on mistake #1

    0 of 1 found this helpful thumb_up thumb_down
  • Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    Performing any task on a DC that can be performed remotely with other tools is always best practice. Why even log onto a DC if you don't need to?

    Spice (1) flagReport
    0 of 1 found this helpful thumb_up thumb_down
  • dimforest wrote:

    Having too many damn GPO's with no descriptive titles or notes. The same goes with service accounts. That's my biggest pet peeve. 

    FREAKING PREACH, MY DUDE.

    Spice (7) flagReport
    Was this post helpful? thumb_up thumb_down
  • Gary Glenn wrote:

    Think of it this way, the fewer times you log onto a computer/server directly, the less it has to work to process information, write logs, go through the login process etc., the better. And by directly, I mean from a terminal or RDP, anything where you actually log in to that server. Use RSAT or other remote management methods whenever possible to avoid "touching" the server.

    Bonus: iOS app "AD Assist" will allow you to manage most things AD from your iPhone. Super convenient.


    OMG I love AD Assist! I am traveling from one school building to the next so it's awesome that I can reset a password or disable or enable PC's without having to run back to my desk or even to the nearest PC. I don't have to carry around a laptop or chromebook with me everywhere either.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down
  • Tekgeek1fy wrote:

    dimforest wrote:

    Having too many damn GPO's with no descriptive titles or notes. The same goes with service accounts. That's my biggest pet peeve. 

    FREAKING PREACH, MY DUDE.

    Yes, this definitely should have made the list. Documentation and diagrams should be there as well, though they may fit #3... they weren't specifically cited. 

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • Not putting proper descriptions on AD groups is another common mistake that can become a real pain.

    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down
  • I've practiced and enforced #1 in some form or fashion for many years, even at home. No one, including myself, surfed the Internet or had a profile with admin rights. Used to piss my kids off that they couldn't download and install crap. When they complained as teenagers, I told them they were welcome to get a job and pay for their own Internet connection, then they could do what they wanted, but as long as they were on my network, tough. They were more than welcome to ask me to install stuff.

    I never had any virus infections, or had to clean out malware/adware like Bonzai Buddy or Comet Cursor or the like at home. Unlike some friends, who kept caving in to their kids demands for the admin password. After the 3rd time of cleaning out the PC (it took 3 to 4 hours the thing was so infected) I told him I would have to start charging him, because I kept having to clean out the same crap and more, all due to his kids ignoring his requests not to install things like Comet Cursor and Bonzai Buddy, and his ignoring my recommendation to not give them the admin password. 

    The same has applied to work environments where I've had control. At work, our normal profiles are not domain admins, and we each have our own domain admin account that we use when needed. 

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • jhTech86 wrote:

    I think mistake #1 happens all the time.  I know this is a Windows thread, but it reminds me of Ubuntu.  Obviously Linux has the same rule, do not run as root.  Ubuntu doesn't even allow it, but what it taught me when I was brand new to all things Linux was to simply type "sudo" in front of every command to make sure it works.  I don't know why I find that so funny. 

    I used to do this too, but live and learn, now I only do it in front of commands I know need it, and if I'm not sure, I try to run the command normally and if it fails out then I sudo it, reminds me of an xkcd:

    this one actually:

    https://xkcd.com/149/

    Spice (4) flagReport
    Was this post helpful? thumb_up thumb_down
  • CTMorseJr wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    Performing any task on a DC that can be performed remotely with other tools is always best practice. Why even log onto a DC if you don't need to?

    I understand that using RSAT is better and can be more efficient, but that doesn't mean that logging into a DC to administer AD is bad practice.  

    I'm not trying to say that we should log into domain controllers directly.  I'm saying that we shouldn't label a method as "bad practice" unless and until we can explain why it is bad.

    Spice (8) flagReport
    Was this post helpful? thumb_up thumb_down
  • I find another thing is that people figure with AD that the machines themselves are risk free. Many organizations figure the machines are either not going to have issues, or if they do, they can be replaced. Which is true but time consuming.

    I fought hard to have backups of the machines. We use Rollback Rx and Drive Cloner, which works well. I can still swap out machines, but usually downtime is only a few seconds to 10 min tops depending on the issue.

    Was this post helpful? thumb_up thumb_down
  • Evan7191 wrote:

    I understand that using RSAT is better and can be more efficient, but that doesn't mean that logging into a DC to administer AD is bad practice.  

    I'm not trying to say that we should log into domain controllers directly.  I'm saying that we shouldn't label a method as "bad practice" unless and until we can explain why it is bad.

    You are correct if we cannot explain why we shouldn't label it as "bad practice" and technically there is not, IMHO, a anything really wrong about using RDP and not RSAT.

    Where the issue does come up is that most people will not change back and forth while using RDP. When you use RSAT or remote Power Shell you are stopping yourself from accidentally surfing the web or downloading something directly onto the server. It is the same reason you use a regular login and elevate to make some changes. Another good reason would be time saving. I can add/remove user's and manage my server faster through remote PowerShell and RSAT than you can with RDP. You combine this with the Server Manager in Windows 2012+ and it is much easier than RDP and you never run the risk of accidentally downloading bad things to the server.

    I hope this helps you understand why best practice is to not log into servers. Sometimes you will have to and it is not the end of the world, it just shouldn't be your "go to" method of working on the server.

    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down
  • Huw3481 wrote:

    In respect of #6, last time I looked the favoured best practice IS to set a users password to never expire, as long as it's suitably complex (e.g. a passphrase) and to force reset on breach.

    There's another thread about this somewhere else.  I'll try and find it.

    Found it.

    https://community.spiceworks.com/topic/post/7401255

    As part of https://community.spiceworks.com/topic/2092618-great-tip-from-on-the-o365-admin-portal

    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down
  • I'm mostly all in on #4, with one question and one exception... I'll get back to those.

    There are very few AD tasks which I don't routinely do from Powershell. All the tools you need to manage AD are available on a workstation with RSAT installed. This means there are zero reasons to perform those tasks at the server. If there is even 1 reason to NOT login to the server, the NOT argument wins. If you can't think of at least one reason not to, I don't think I want you anywhere near my servers.

    That said, in the real world sometimes logging in to the server is more conventient and that convenience is worth more than the potential downsides. So sometimes, I do it. But I know that when I do, I'm doing a wrong thing to satisfy my laziness. This doesn't make it not the wrong thing to do.
    On to my question: #4 includes the statemtent "never use DC for DNS; always point it at another DC". I read this as "Don't use a domain controller for DNS. Instead, use a domain controller." I don't know how to make sense of that.

    As for the exception, it's when setting permissions on very large folders. Whether you do this from powershell or Windows Explorer, you'll be stuck waiting for the ACL's to be written on every single object. I have things to do at my PC, so this can run somewhere else. (As an aside, this wasn't a problem way back when in Netware, because of the way permission inheritance was handled by the OS and file system. If any software engineers above my pay grade want to argue about why MS made design decisions that lead to me having to wait 10-30 minutes for ACL's to be written, go ahead. It would be a fun read.)

    Mistake #5, on the other hand, I have to say no to. With on-premise AD synched to Office365 for email, deleting an AD account deletes the O365 account. Yes, things can be set up so that the mailbox is still recoverable after the account is deleted. But what if John Smith quits, and a different John Smith is hired a year later? The solutions to that problem all have different, even worse problems. I disable accounts and set the password to a something random. But I keep them in AD for up to as long as the litigation hold policy is in effect.

    Group Policies without notes about purpose or function suck. Group Policy Manager does not have any place to put notes or comments on a policy. Another problem which is a result of poor design.

    Spice (4) flagReport
    1 found this helpful thumb_up thumb_down
  • Spice (5) flagReport
    1 found this helpful thumb_up thumb_down
  • The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    I hadn't heard about Adaxes before, so I would have assumed that they copied from Netwrix. However, Adaxes post is from last year, so ... :-)

    0 of 1 found this helpful thumb_up thumb_down
  • Kevin6814 wrote:

    I used to do this too, but live and learn, now I only do it in front of commands I know need it, and if I'm not sure, I try to run the command normally and if it fails out then I sudo it, reminds me of an xkcd:

    this one actually:

    https://xkcd.com/149/

    HAH...that xkcd is perfect!   I have gotten around it myself as well, only using it after being told to make my own sandwich.  Admittedly, I am equally as likely to run other linux versions as root, and run windows as admin (at home).  99 times out of 100 when I am messing with linux it is just for fun/learning.  So, if I nuke the HDD on accident, it really doesn't matter to me.  I am basically the only one using my home Windows pc, so I am almost always running as admin there.  If something happens, ill just reinstall the OS and start from scratch.

    I think I might take the inspiration of xkcd and add sudo to my daily life verbally.  Seems like a good way to confuse most people and get a laugh out of it.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down
  • michaelmcnally wrote:

    On to my question: #4 includes the statemtent "never use DC for DNS; always point it at another DC". I read this as "Don't use a domain controller for DNS. Instead, use a domain controller." I don't know how to make sense of that.



    I think the article means that a domain controller should not be set to use itself as its primary DNS server for lookup.  The DC should use another DC as the primary DNS server for lookup in the IP config.

    This is another example of the article saying not to do something without explaining clearly what it means or why it shouldn't be done.

    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down
  • dimforest wrote:

    Having too many damn GPO's with no descriptive titles or notes. The same goes with service accounts. That's my biggest pet peeve. 

    Yes! This drives me nuts!!

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • Evan7191 wrote:

    CTMorseJr wrote:

    Evan7191 wrote:

    Can someone explain how #4 (managing AD directly on a domain controller) is bad practice?  Microsoft's own list of best practices for managing Active Directory does not mention this.  Microsoft actually recommends using a jump server to remote into domain controllers for managing active directory.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    Performing any task on a DC that can be performed remotely with other tools is always best practice. Why even log onto a DC if you don't need to?

    I understand that using RSAT is better and can be more efficient, but that doesn't mean that logging into a DC to administer AD is bad practice.  

    I'm not trying to say that we should log into domain controllers directly.  I'm saying that we shouldn't label a method as "bad practice" unless and until we can explain why it is bad.

    If you look at (probably most) a Sec+ study guide, this falls under a basic precaution of minimizing certain kinds of risks associated with a GUI/login session on a critical piece of infrastructure. By and large - done right - there should be little if any need to ever log into a DC via RDP. 

    As I posted earlier in this discussion, Microsoft actually does specifically talk about some specific reasons to avoid logging into a domain controller here:

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/securing...

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • petersaraby wrote:

    I hadn't heard about Adaxes before, so I would have assumed that they copied from Netwrix. However, Adaxes post is from last year, so ... :-)

    Well, if you haven't yet heard of us, maybe you would like to check out what we have to offer in terms of Active Directory management (#SPOILERALERT: there's a lot to see). 

    Onboarding/offboarding automation, web interface for AD tasks, approvals, RBAC, script orchestration, Exchange and Office 365 management and automation, password self-service, AD cleanup and there's so much more.

    And in case you like to play with the product instead of just reading about it, you can always go for a 30-day trial. You can just download it and try (no contacting sales first or other bureaucracy), no stupid restrictions in terms of user count, functionality and it can be extended up to 90 days if needed. 

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • I just went through a webinar for Skyport Systems and they discussed utilizing a "Red Forest" which also means Enhanced Security Admin Environment (ESAE).

    https://social.technet.microsoft.com/wiki/contents/articles/37509.what-is-active-directory-red-fores...

    After going through it, I had to go stand in a corner and shake because I was scared.

    Was this post helpful? thumb_up thumb_down
  • MISTAKE 1# already happend to me. I will change it know.

    Was this post helpful? thumb_up thumb_down
  • petersaraby wrote:

    The only other place where I found a mention of managing active directory on a domain controller is bad practice is this Adaxes blog post from 2016:

    http://www.adaxes.com/blog/five-mistakes-made-with-active-directory-management.html

    In fact, some passages in this Netwrix post are identical to some passages in the Adaxes blog post, as if one copied from another.

    I hadn't heard about Adaxes before, so I would have assumed that they copied from Netwrix. However, Adaxes post is from last year, so ... :-)

    Frankly speaking that is the first time I see Adaxes post :) 

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down
  • What is the benefit from deleting disabled accounts? Why not just keep them disabled?

    Spice (4) flagReport
    Was this post helpful? thumb_up thumb_down
  • Sebastian7766 wrote:

    What is the benefit from deleting disabled accounts? Why not just keep them disabled?

    1. You keep your AD clean.

    2. Such accounts will not be used as backdoors, leaving old disabled accounts poses a greater security risk than getting rid of them. If it's not there, it can't be exploited.

    3. The price for some software can depend on a quantity of users in Active Directory, if the user is gone forever why should you pay for him?

    But that is not a call to delete the account asap, leave it in disabled state for 30-90 days and then delete it, if it is not needed. 

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down
  • "but never use DC for DNS; always point it at another DC"... 

    WHAT!?  Every DC in our domain is also a DNS server... me and thousands of other SysAdmins must've been doing it all wrong all these years, lol.  What am I missing here?

    Was this post helpful? thumb_up thumb_down
  • Shuey wrote:

    "but never use DC for DNS; always point it at another DC"... 

    WHAT!?  Every DC in our domain is also a DNS server... me and thousands of other SysAdmins must've been doing it all wrong all these years, lol.  What am I missing here?

    Assuming 3 DCs,

    Manually set the DNS servers for DC1 to be DC2 and DC3.
    Manually set the DNS servers for DC2 to be DC1 and DC3.
    Manually set the DNS servers for DC3 to be DC1 and DC2.

    Don't let a DC reference itself.

    That's what Netwrix are trying to say.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down
  • Huw3481 wrote:

    Shuey wrote:

    "but never use DC for DNS; always point it at another DC"... 

    WHAT!?  Every DC in our domain is also a DNS server... me and thousands of other SysAdmins must've been doing it all wrong all these years, lol.  What am I missing here?

    Assuming 3 DCs,

    Manually set the DNS servers for DC1 to be DC2 and DC3.
    Manually set the DNS servers for DC2 to be DC1 and DC3.
    Manually set the DNS servers for DC3 to be DC1 and DC2.

    Don't let a DC reference itself.

    That's what Netwrix are trying to say.

    Whew!  Thanks for clarifying Huw!  That's how we have ours setup - I just misunderstood the way it was originally worded ;).

    Was this post helpful? thumb_up thumb_down
  • I thought setting Domain Controllers to use themselves as one of the DNS servers was best practices from Microsoft:

    https://technet.microsoft.com/en-us/library/dd378900(WS.10).aspx

    Spice (1) flagReport
    1 found this helpful thumb_up thumb_down

Read these next...