none
What practices are being used for Least Privilege Administration in a AD environment? RRS feed

  • Question

  • Hi,

    In my job I am responsible for managing several services important to the operation of our infrastructure but I also perform day-to-day tasks like any other user. As such this is how I work at the moment:

    I logon to my workstation using my everyday domain account (eg DOMAIN\Jason) which has no administrative rights within the domain nor on the local machine. With this I can check email, surf the web, update spreadsheets, etc.

    When I need to administer a particular service, I start the corresponding management console using my personal alternate domain credentials (eg DOMAIN\Admin.Jason) which do have administrative rights for all the services I am responsible for, and from the MMC I can connect to the remote computer running the service and do what I need to.

    If the service in question isn't remotely manageable (eg Data Protection Manager) then I Remote Desktop to the corresponding server using my everyday account (DOMAIN\Jason) and then only elevate the service's admin console using my alternate admin credentials.

    The concern I have with this approach is that when I elevate a management console for one service, it is running with administrative rights for every service that I am responsible for, not just the service being managed, and this feels excessive. So what is a better way to limit the account being used for administrative tasks?

    One possibility is that I could elevate the management console using the local administrator of the server hosting the service (eg REMOTESERVER\Administrator) but then my name is omitted from the audit logs and any changes made are not easily traceable back to me.

    Another possiblity is that I could have my own local account on each server I need to administer (eg REMOTESERVER\Jason) but they would all need different passwords to avoid them accidentally operating like Shadow accounts and managing these accounts would be a chore of its own.

    I can think of a few more ways to solve this issue, each with varying levels of complexity, but I'm curious how others tackle this situation.

    Regards,

    Jason

     

    Monday, December 5, 2011 11:13 PM

Answers

  • Hi Jason,

    Several things spring to mind, although I wouldn't be so forward as to propose them as solutions to your problem for the moment:

    1. If you are running in a Windows 7 - Windows Server 2008 RS environment, perhaps it might be worth reconsidering the separate account strategy in favour of the protection offered by User Account Control and Admin Approval Mode. In AAM you are really only running with elevated privileges when this is specifically requested by the application (and you permit it). Admittedly, MMC will always request elevation, regardless of what you are doing, but at least you will have knowingly granted that privilege. All other processs will still be running with standard user rights (unlike if you were directly logged on with local admin rights on the target machine).

    2. If you feel you need to go down the road with local admin accounts on the target machines, perhaps consider implementing a hopping server or "admin hub" which admins need to connect to first before connecting to the target machines with the generic accounts. That way you can still keep an audit trail by combining the logs of the admin hub and the target machine. There are also a number of solutions out there on the market that allow you to record RDP sessions and the like for compliance audit purposes (e.g. Balabit, ObserveIT or RecordTS).

    3. Perhaps this is stating the obvious, but I feel that it is always a good idea to reduce the scope of the enhanced privileges a user has to the area required to do their job. For example, there is no reason why an application developer should have any enhanced privileges outside of the development environment. Separating development, test and production into clearly distinct enviornments (perhasp using virtualisation) and then ensuring that only thoroughly tested changes are made to production further reduces the number of attack vectors you need to worry about.

    In general, I would say that what you are currently doing is very similar to what I have seen with numerous customers in the past. Of course there is the residual risk of being tricked into using manipulated code, as you point out, but this has also been greatly reduced in Windows 7 and Windows Server 2008 R2 by placing most of the OS files under the ownership of the TrustedInstaller.

    I hope this is of some help to you.

    Regards,

    Oliver


    Oliver Carr CISSP, MCSE:Security, MCT
    • Marked as answer by J Stangroome Friday, December 16, 2011 1:23 AM
    Thursday, December 15, 2011 10:49 AM

All replies

  • Hi J Stangroome,

     

    You may access your AD and locate your account and check currently what rights are you holding on.

    Usually for your case i will grant only power user rights access. Power user rights access will be sufficient for you to do the list above task.

    I wouldn't recommend you to have domain admin rights, unless your IT dept manager gives you the green light to such access.

    You may refer to the below link for more information on assigning rights via AD.

     

    http://technet.microsoft.com/en-us/library/cc786285%28WS.10%29.aspx


    Guowen Su
    Cisco Certified Network Associate
    Cisco Certified Internetwork professional - MPLS
    Certified Information Systems Security Professional
    Microsoft Partner Network 2011
    Microsoft Certified Professional
    Microsoft Certified Systems Administrator:Security
    Microsoft Certified Systems Engineer: Security
    Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration
    Microsoft Certified Technology Specialist: Windows 7, Configuring
    Microsoft Certified IT Professional: Enterprise Administrator
    Microsoft Certified IT Professional: Server Administrator
    Certified Ethical Hacker
    Computer Hacking Forensics Investigator
    http://www.microsoft.com/en/sg/default.aspx Our Goal? VERY SATISFIED
    • Proposed as answer by Soh.M Wednesday, December 7, 2011 5:07 AM
    • Unproposed as answer by J Stangroome Wednesday, December 7, 2011 8:23 PM
    • Proposed as answer by Alan Burchill Wednesday, December 7, 2011 10:45 PM
    • Unproposed as answer by J Stangroome Wednesday, December 7, 2011 10:47 PM
    Wednesday, December 7, 2011 5:07 AM
  • Hi Guowen,

    Thanks for your reply but based on your answer I'm not sure I've explained my question well enough.

    Perhaps I need to give a more specific example:

    Let's assume I have a boring 'Domain User' account that I use for day-to-day activities, it is called "DOMAIN\Jason". Let's also assume that my role in the company is to manage both our SMTP servers and our File Servers so the domain administrator has created a second domain account for me, called "DOMAIN\Admin.Jason" and granted this account local Administrator privileges on three servers, "SMTPSERVER1", "FILESVR1", and "FILESVR2".

    If I need to make some changes to our SMTP configuration I would Remote Desktop to SMTPSERVER1 using my low privileged DOMAIN\Jason account and then I would start the SMTP Management Console using my DOMAIN\Admin.Jason account.

    However, let's consider that SMTPSERVER1 has been compromised and the SMTP Management Console executable was replaced with a malicious program. When I run the SMTP console it not only has privileges to modify the SMTP configuration but it also has full Administrative privileges on the two file servers I manage and the malicious program can now spread and cause all sorts of damage.

    One possible way I can think of to mitigate this scenario is this:

    When I need to manage the SMTP server, I use my DOMAIN\Admin.Jason account to remotely create a new local user account on SMTPSERVER1 and give it local administrator privileges. I then use this new account (eg SMTPSERVER1\TempAdmin.Jason) to run the SMTP management console and if the security of the server has been compromised then I limit the potential damage to that server only because the credentials I'm using have no other network access.

    Obviously this approach involves several manual steps each time I need to manage a system I'm responsible for, or would require some scripting to automate. How do others handle this problem?

    Regards,

    Jason


    • Edited by J Stangroome Wednesday, December 7, 2011 11:07 PM Formatting
    Wednesday, December 7, 2011 11:06 PM
  • Hi J,

     

    My recommendation for your scenario will be isolate the particular infected machine disconnect it from network. Clean it first before you connect it back to the production network. I believe if your current server is in production mode. You may want to plan a downtime to fix that. That will be the best advise i can give you for now.

    As for the Domain ACL Privilege.

    You cannot create a local account on your DC. It won't allow you to have local admin account due to current state of the domain controller have been promote with RID master, FSMO roles, Schema Master roles, Infra roles.

    You can still login using your domain admin profile to access the server locally without network connectivity via the cache login, and proceed with isolated cleaning on the infected box.

    Microsoft will not recommend the below fault tolerance.

    • When I need to manage the SMTP server, I use my DOMAIN\Admin.Jason account to remotely create a new local user account on SMTPSERVER1 and give it local administrator privileges. I then use this new account (eg SMTPSERVER1\TempAdmin.Jason) to run the SMTP management console and if the security of the server has been compromised then I limit the potential damage to that server only because the credentials I'm using have no other network access.

    Guowen Su
    Cisco Certified Network Associate
    Cisco Certified Internetwork professional - MPLS
    Certified Information Systems Security Professional
    Microsoft Partner Network 2011
    Microsoft Certified Professional
    Microsoft Certified Systems Administrator:Security
    Microsoft Certified Systems Engineer: Security
    Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration
    Microsoft Certified Technology Specialist: Windows 7, Configuring
    Microsoft Certified IT Professional: Enterprise Administrator
    Microsoft Certified IT Professional: Server Administrator
    Certified Ethical Hacker
    Computer Hacking Forensics Investigator
    http://www.microsoft.com/en/sg/default.aspx Our Goal? VERY SATISFIED
    • Proposed as answer by Soh.M Thursday, December 8, 2011 3:24 AM
    • Unproposed as answer by J Stangroome Thursday, December 8, 2011 3:31 AM
    Thursday, December 8, 2011 3:24 AM
  • "My recommendation for your scenario will be isolate the particular infected machine disconnect it from network. Clean it first before you connect it back to the production network." - I am referring to a hypothetical situation where I logon to a server that has been silently compromised and no one is aware of the security violation yet. 

    "You cannot create a local account on your DC." - I am not suggesting creating a local account on a DC, just on a member server.


    Thursday, December 8, 2011 3:35 AM
  • well state your point clearly then. please give us detail information in order to allow us to assist you further.
    Guowen Su
    Cisco Certified Network Associate
    Cisco Certified Internetwork professional - MPLS
    Certified Information Systems Security Professional
    Microsoft Partner Network 2011
    Microsoft Certified Professional
    Microsoft Certified Systems Administrator:Security
    Microsoft Certified Systems Engineer: Security
    Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Applications Infrastructure, Configuration
    Microsoft Certified Technology Specialist: Windows 7, Configuring
    Microsoft Certified IT Professional: Enterprise Administrator
    Microsoft Certified IT Professional: Server Administrator
    Certified Ethical Hacker
    Computer Hacking Forensics Investigator
    http://www.microsoft.com/en/sg/default.aspx Our Goal? VERY SATISFIED
    Thursday, December 8, 2011 5:45 AM
  • Hi Jason,

    Several things spring to mind, although I wouldn't be so forward as to propose them as solutions to your problem for the moment:

    1. If you are running in a Windows 7 - Windows Server 2008 RS environment, perhaps it might be worth reconsidering the separate account strategy in favour of the protection offered by User Account Control and Admin Approval Mode. In AAM you are really only running with elevated privileges when this is specifically requested by the application (and you permit it). Admittedly, MMC will always request elevation, regardless of what you are doing, but at least you will have knowingly granted that privilege. All other processs will still be running with standard user rights (unlike if you were directly logged on with local admin rights on the target machine).

    2. If you feel you need to go down the road with local admin accounts on the target machines, perhaps consider implementing a hopping server or "admin hub" which admins need to connect to first before connecting to the target machines with the generic accounts. That way you can still keep an audit trail by combining the logs of the admin hub and the target machine. There are also a number of solutions out there on the market that allow you to record RDP sessions and the like for compliance audit purposes (e.g. Balabit, ObserveIT or RecordTS).

    3. Perhaps this is stating the obvious, but I feel that it is always a good idea to reduce the scope of the enhanced privileges a user has to the area required to do their job. For example, there is no reason why an application developer should have any enhanced privileges outside of the development environment. Separating development, test and production into clearly distinct enviornments (perhasp using virtualisation) and then ensuring that only thoroughly tested changes are made to production further reduces the number of attack vectors you need to worry about.

    In general, I would say that what you are currently doing is very similar to what I have seen with numerous customers in the past. Of course there is the residual risk of being tricked into using manipulated code, as you point out, but this has also been greatly reduced in Windows 7 and Windows Server 2008 R2 by placing most of the OS files under the ownership of the TrustedInstaller.

    I hope this is of some help to you.

    Regards,

    Oliver


    Oliver Carr CISSP, MCSE:Security, MCT
    • Marked as answer by J Stangroome Friday, December 16, 2011 1:23 AM
    Thursday, December 15, 2011 10:49 AM