locked
how to prevent someone which has obtaind domain admin credentials connect to main DC via mmc console remotle? RRS feed

  • Question

  • hi all

    i have deployed a writable DC in my company main site and a RODC in branch office . but my concern is if someone in branch obtain domain admin credentials , he can connect to main DC via mmc console .

    is there any method to prevent anyone from connectting to a DC via mmc consoles remotely ? (mybe via local DC's windows firewall ? )  which port numbers does mmc consoles use ? can i deny incoming traffic to this ports in Local DC windows firewall ?

    thanks in advance

    Thursday, November 17, 2011 8:01 AM

Answers

  • You can restric that persons access to mmc only on that DC or RODC through GPO. Lets say you create the policy to disable mmc fo that user, either link that policy to the RODC OU and in security filtering choose to apply only on the computer account (object) and enable loopback policy (replace mode).

    More here:

    http://support.microsoft.com/kb/231287

    http://technet.microsoft.com/en-us/library/cc782810(WS.10).aspx


    MCTS...
    Thursday, November 17, 2011 1:24 PM
  • Hi John,

     

    Thanks for posting here.

     

    Ok , first at all it is really horrible if leak domain admin credentials. This mean we're exposing all our system to unauthorized users and will never expect to happen in future J

    As a workaround we can set IPsec and define few policies and rules to do the restriction on that server. Because only computers with correct credential will be able granted permission to access via remote Administration tools.

     

    Chapter 13 - Internet Protocol Security and Packet Filtering

    http://technet.microsoft.com/en-us/library/bb727017.aspx

     

    Thanks.

     

    Tiger Li


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, November 18, 2011 6:27 AM
  • I agree on creating an IPSec policy for connectivity, however one caveat I see with that it may prevent normal domain authentication and logon.

    If someone is gaining the domain admin credentials somehow, and you know who that person is, I believe the company should have some sort of TOS terminating the individual.

    Also, one must ask themselves, how is this person getting the credentials? Is one of your other domain admins giving it to him/her? If this is the case, where there are more than one individual involved, then it's a conspiracy, and that would get a bit more complicated.

    I would believe to change the domain admin password frequently would be one measure to prevent this, and only give the domain admin to a select one or two people.

    A best practice is that if other users require domain admin acccess, it should be done by creating two accounts for the user, one a plain-Jane Domain User account that has a mailbox, etc, to do their day to day tasks, and an "admin" account that is in the Domain Administrators group which will only be used for admin purposes, using the Run-As, etc. And the default domain Administrator account credentials will be kept secretive between one or two people, that's it. This way the default account will not be misused.

    On top of that, you would enable auditing to keep track of who is using their domain admin rights and privledges. So if the default domain admin credentials are kept privvy to one or two users, then you know if the default Administrator account comes up in an audit from a specific IP address at that remote location, then you would look at those two users and ask them if they did something from that IP address in the audit log. If they didn't, then you ask them if they were giving the credentials away.

    If the user in question at the remote location is finding this info out some other way with some sort of app such as L0phtcrack or Rainbow Crack, sniffing, etc, then a software restriction policy, and putting in place a way of tracking what software is on all users machines, such as using SCCM.

    It all comes down to how strong is the security policy in the infrastructure. For something as simple as someone gaining the domain admin credentials, if the security policy has all the above in place, then it will be easy to figure it out, and you'll know who to hand that pink termination pink slip to.

    Ace

     

    Late Edit - here are some auditing links:

    Audit logon events: Security Configuration Editor; Security Services, Jan 21, 2005
    If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on ...
    http://technet.microsoft.com/en-us/library/cc787567.aspx

    Audit logon events
    If you are auditing successful Audit account logon events on a domain controller, then workstation logons do not generate logon audits. ...
    http://technet.microsoft.com/en-us/library/cc976395.aspx

    Audit account logon events
    http://technet.microsoft.com/en-us/library/cc787176(WS.10).aspx 

    Auditing failed logon events and account lockouts
    http://technet.microsoft.com/en-us/library/cc671957(WS.10).aspx

    How to Enable Success Logon Event Logging Dec 1, 2008
    To enable success logon event logging using a local security policy ...
    In the results pane, double-click Audit logon events and ensure that ...
    http://technet.microsoft.com/en-us/library/cc431373.aspx

    HOW TO: Audit Active Directory Objects in Windows Server 2003
    You can access this policy setting through the Domain Controllers organizational unit. To audit user access to Active Directory objects, configure the Audit ...
    http://support.microsoft.com/kb/814595

    Active Directory Domain Services (AD DS) Auditing Step-by-Step Guide, May 8, 2009
    This new auditing feature also applies to Active Directory
    http://technet.microsoft.com/en-us/library/cc731607(WS.10).aspx

     

    more...

    How To use Software Restriction Policies in Windows Server 2003
    http://support.microsoft.com/kb/324036

    Creating a Software Restriction Policy in Windows Server 2008
    http://www.itechtalk.com/thread1912.html

    Best Practice Guide for Securing Active Directory Installations
    Jan 23, 2009 – Best Practice Guide for Securing Active Directory Installations · Scope of This Guide · Chapter 1: Planning In-Depth Active Directory Security ...
    http://technet.microsoft.com/en-us/library/cc773365(v=ws.10).aspx

    Download: Best Practice Guide for Securing Active Directory ...
    Jan 23, 2009 – This guide contains best practices for securing Active Directory installations. ... for maintaing the security of their Active Directory environment.
    http://ww.microsoft.com/download/en/details.aspx?id=16755

    Software Metering in Configuration Manager
    http://technet.microsoft.com/en-us/library/bb694169.aspx


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, November 18, 2011 6:29 PM

All replies

  • RODC has local administrators ,no need to give give domain admin credential to RODC users. he can perform all the task needed without domain admin credentials.

    EDIT:

    Here u can find more about RODC

    http://technet.microsoft.com/en-us/library/cc753223(WS.10).aspx#bkmk_separation

     

    Renato Kurti CCNA,MCP,MCTS,MCITP

    • Edited by Renato Kurti Thursday, November 17, 2011 8:23 AM
    Thursday, November 17, 2011 8:16 AM
  • RODC has local administrators ,no need to give give domain admin credential to RODC users. he can perform all the task needed without domain admin credentials.

    EDIT:

    Here u can find more about RODC

    http://technet.microsoft.com/en-us/library/cc753223(WS.10).aspx#bkmk_separation

     

    Renato Kurti CCNA,MCP,MCTS,MCITP

     

    thanks Renato  but you didn't pay attention to my question.  i asked if someone obtained domain admin credentials ( illegally ) ,now how to prevent anyone from connectting to a DC via mmc consoles remotely ?

    Thursday, November 17, 2011 8:59 AM
  • ohh sorry is worste that i thought

    this post may help

    http://technet.microsoft.com/en-us/library/dd759202.aspx#BKMK_gp

    Renato


    Renato Kurti CCNA,MCP,MCTS,MCITP
    Thursday, November 17, 2011 9:58 AM
  • Hello John,

    What I would use in your case would be mmc access restriction through Group Policy. Create a GPO in witch you enable/disable/configure access to certain snapins and link it to that site/OU.

    http://technet.microsoft.com/en-us/library/cc738954(WS.10).aspx

    The settings for mmc should be in User Configuration\Administrative Templates\Windows Components\Microsoft Management Console.

    The link below should give you an ideea about configuring mmc access through GPO:

    http://technet.microsoft.com/en-us/library/cc709697.aspx


    MCTS...
    Thursday, November 17, 2011 10:17 AM
  • Hello John,

    What I would use in your case would be mmc access restriction through Group Policy. Create a GPO in witch you enable/disable/configure access to certain snapins and link it to that site/OU.

    http://technet.microsoft.com/en-us/library/cc738954(WS.10).aspx

    The settings for mmc should be in User Configuration\Administrative Templates\Windows Components\Microsoft Management Console.

    The link below should give you an ideea about configuring mmc access through GPO:

    http://technet.microsoft.com/en-us/library/cc709697.aspx


    MCTS...

    thank you renato and marius ,  but my conditions is in such a way that i can't force any limitation to that persons computer ( for example i can't prevent him from acessing MMC consoles ) , so i need a method to do in my central DC. i should do any required settings in my DC , i mean how protect my DC to prevent others to connect it via MMC Console ?

    thank you very much

     

     

    Thursday, November 17, 2011 12:47 PM
  • Your DC is 2008 or 2008 R2?

    U like to remove even remote desktop to him to?

    what are ur credential,domain admin?enterprise admin?

    still not clear what ur asking.

    if u locked him out from remote administration u will lock anyone else(incuding you) so u have to make all configuration and check the logs only if u are in front of the DC.

    can u explain a bit more the situation,  if someone obtained domain admin credentials ( illegally ) as u sayd before u have to disable that acc if u have other domain admin acc.

     


    Renato Kurti CCNA,MCP,MCTS,MCITP

    • Edited by Renato Kurti Thursday, November 17, 2011 1:12 PM
    Thursday, November 17, 2011 1:01 PM
  • You can restric that persons access to mmc only on that DC or RODC through GPO. Lets say you create the policy to disable mmc fo that user, either link that policy to the RODC OU and in security filtering choose to apply only on the computer account (object) and enable loopback policy (replace mode).

    More here:

    http://support.microsoft.com/kb/231287

    http://technet.microsoft.com/en-us/library/cc782810(WS.10).aspx


    MCTS...
    Thursday, November 17, 2011 1:24 PM
  • Hi John,

     

    Thanks for posting here.

     

    Ok , first at all it is really horrible if leak domain admin credentials. This mean we're exposing all our system to unauthorized users and will never expect to happen in future J

    As a workaround we can set IPsec and define few policies and rules to do the restriction on that server. Because only computers with correct credential will be able granted permission to access via remote Administration tools.

     

    Chapter 13 - Internet Protocol Security and Packet Filtering

    http://technet.microsoft.com/en-us/library/bb727017.aspx

     

    Thanks.

     

    Tiger Li


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, November 18, 2011 6:27 AM
  • I agree on creating an IPSec policy for connectivity, however one caveat I see with that it may prevent normal domain authentication and logon.

    If someone is gaining the domain admin credentials somehow, and you know who that person is, I believe the company should have some sort of TOS terminating the individual.

    Also, one must ask themselves, how is this person getting the credentials? Is one of your other domain admins giving it to him/her? If this is the case, where there are more than one individual involved, then it's a conspiracy, and that would get a bit more complicated.

    I would believe to change the domain admin password frequently would be one measure to prevent this, and only give the domain admin to a select one or two people.

    A best practice is that if other users require domain admin acccess, it should be done by creating two accounts for the user, one a plain-Jane Domain User account that has a mailbox, etc, to do their day to day tasks, and an "admin" account that is in the Domain Administrators group which will only be used for admin purposes, using the Run-As, etc. And the default domain Administrator account credentials will be kept secretive between one or two people, that's it. This way the default account will not be misused.

    On top of that, you would enable auditing to keep track of who is using their domain admin rights and privledges. So if the default domain admin credentials are kept privvy to one or two users, then you know if the default Administrator account comes up in an audit from a specific IP address at that remote location, then you would look at those two users and ask them if they did something from that IP address in the audit log. If they didn't, then you ask them if they were giving the credentials away.

    If the user in question at the remote location is finding this info out some other way with some sort of app such as L0phtcrack or Rainbow Crack, sniffing, etc, then a software restriction policy, and putting in place a way of tracking what software is on all users machines, such as using SCCM.

    It all comes down to how strong is the security policy in the infrastructure. For something as simple as someone gaining the domain admin credentials, if the security policy has all the above in place, then it will be easy to figure it out, and you'll know who to hand that pink termination pink slip to.

    Ace

     

    Late Edit - here are some auditing links:

    Audit logon events: Security Configuration Editor; Security Services, Jan 21, 2005
    If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on ...
    http://technet.microsoft.com/en-us/library/cc787567.aspx

    Audit logon events
    If you are auditing successful Audit account logon events on a domain controller, then workstation logons do not generate logon audits. ...
    http://technet.microsoft.com/en-us/library/cc976395.aspx

    Audit account logon events
    http://technet.microsoft.com/en-us/library/cc787176(WS.10).aspx 

    Auditing failed logon events and account lockouts
    http://technet.microsoft.com/en-us/library/cc671957(WS.10).aspx

    How to Enable Success Logon Event Logging Dec 1, 2008
    To enable success logon event logging using a local security policy ...
    In the results pane, double-click Audit logon events and ensure that ...
    http://technet.microsoft.com/en-us/library/cc431373.aspx

    HOW TO: Audit Active Directory Objects in Windows Server 2003
    You can access this policy setting through the Domain Controllers organizational unit. To audit user access to Active Directory objects, configure the Audit ...
    http://support.microsoft.com/kb/814595

    Active Directory Domain Services (AD DS) Auditing Step-by-Step Guide, May 8, 2009
    This new auditing feature also applies to Active Directory
    http://technet.microsoft.com/en-us/library/cc731607(WS.10).aspx

     

    more...

    How To use Software Restriction Policies in Windows Server 2003
    http://support.microsoft.com/kb/324036

    Creating a Software Restriction Policy in Windows Server 2008
    http://www.itechtalk.com/thread1912.html

    Best Practice Guide for Securing Active Directory Installations
    Jan 23, 2009 – Best Practice Guide for Securing Active Directory Installations · Scope of This Guide · Chapter 1: Planning In-Depth Active Directory Security ...
    http://technet.microsoft.com/en-us/library/cc773365(v=ws.10).aspx

    Download: Best Practice Guide for Securing Active Directory ...
    Jan 23, 2009 – This guide contains best practices for securing Active Directory installations. ... for maintaing the security of their Active Directory environment.
    http://ww.microsoft.com/download/en/details.aspx?id=16755

    Software Metering in Configuration Manager
    http://technet.microsoft.com/en-us/library/bb694169.aspx


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, November 18, 2011 6:29 PM
  • You could implement ipsec between your clients and DC but I dont think its recommended by Microsoft.

    IPSec scenarios that are not recommended

    When using IPSec authentication and data protection features, the policy management model in Windows 2000, Windows XP, and Windows Server 2003 family lends itself best to server-to-server and client-to-server scenarios where one end-point has a static address. In large network deployments, when policy involves dynamic addresses at both end–systems, and in some mobility cases, policy management complexity can make IPSec deployment difficult. Because of this, IPSec is not recommended for use as follows:

    • Securing communication between domain members and their domain controllers. Because of the complexity of the IPSec policy configuration and management required for this scenario, using IPSec to secure communication between domain members and their domain controllers is not recommended.

    • Securing all traffic in a network. Configuring IPSec communications between all client computers and all servers in order to secure many or all computers in a network is difficult. IPSec cannot negotiate security for multicast and broadcast traffic. Traffic from real-time communications, applications that require ICMP, and peer-to-peer applications might be incompatible with IPSec. For these reasons, using IPSec to secure all traffic in a network is not recommended.

    Additionally, the IPSec protocol and implementation has characteristics that require special consideration in other scenarios:

    • Securing traffic over wireless 802.11 networks. IPSec policies are not optimized for configuration for mobile clients. Because of this, IPSec is not recommended as the only method to secure traffic sent over wireless 802.11 networks. Instead, it is recommended that you use IEEE 802.1X authentication. 802.1X enhances security and ease of deployment by providing support for centralized user identification, authentication, dynamic key management, and accounting. In cases where clients roam between access points on the same network, IPSec can be used in combination with 802.11 and 802.1x. In cases where roaming causes the client IP address to change, IPSec security associations become not valid and new security associations are renegotiated.

    • Using IPSec in tunnel mode for remote access VPN connections. Using IPSec in tunnel mode is not recommended for remote access VPN scenarios. Instead, use L2TP/IPSec or PPTP for remote access VPN connections.


    MCTS...
    Saturday, November 19, 2011 12:30 PM
  • Hi Marius,

     

    Setting IPsec is a possible workaround to secure the management, epically the remote management via MMC in the scenario that John assumed. And you are exactly right it is not a good idea to secure all communications between domain members and domain controllers.

     

    There are many paragraphs in the link below that discussed the firewall settings about remote management via MMC might help to develop good methods to secure our server:

     

    http://technet.microsoft.com/en-us/library/dd184088.aspx

     

    Thanks.

     

    Tiger Li


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Saturday, November 19, 2011 1:39 PM