1 / 82

Securing Active Directory

Securing Active Directory. Jimmy Andersson Principal Advisor Q Advice AB jimand@qadvice.com. Agenda. AD Design (overview) DNS Design (overview) GPO Security Settings Understanding the Schema Securing Active Directory. AD Design. Step 1: Understand your requirements

jace
Download Presentation

Securing Active Directory

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Securing Active Directory Jimmy Andersson Principal Advisor Q Advice AB jimand@qadvice.com

  2. Agenda • AD Design (overview) • DNS Design (overview) • GPO Security Settings • Understanding the Schema • Securing Active Directory

  3. AD Design • Step 1: Understand your requirements • Political autonomy • Divisions of organization with autonomous IT • Operational isolation • Isolate extranet from intranet systems • Legal/regulatory isolation

  4. AD Design • Step 2: Understand your ability to control service admins and limit physical placement of DCs • Cannot prevent malicious service admins from controlling services or accessing data in any domain in forest • Consider the ramifications of the coerced administrator scenario • An admin may be trustworthy, but what if they are legally (or otherwise) compelled to act against the best interest of the organization?

  5. AD Design • Step 3: Select appropriate directory structure based on requirements • Windows Server 2003 Deployment Guide http://www.microsoft.com/downloads/details.aspx?familyid=6cde6ee7-5df1-4394-92ed-2147c3a9ebbe&displaylang=en

  6. AD Design • In practice, single forest with OUs for delegation is best model • All service admin handled by single, globally trusted team • Data admins get OUs • Geographic domains for partitioning of replication, as necessary • If OU is insufficient  create separate forest(s) • If need service autonomy or isolation • If no globally trusted service admin team

  7. AD Design • Domain boundary • Boundary when considering management • Replication control • Domains do not provide complete isolation from malicious service admins • Forest boundary • Only true security boundary • Provide complete isolation and autonomy

  8. AD Design • A dedicated forest root domain • Does not provide additional security • Benefits include: • Reduce likelihood of non-malicious error by Enterprise Admins by clearly separating from Domain Admins of operational domains • Never becomes obsolete • Enables easy transfer of forest ownership • Removing EA from child domains • Does not block access by malicious forest root service admins

  9. AD Design • Extranet scenario • Forest(s) for computers in intranet • Separate forest for servers in extranet • “Isolate secret project” scenario • One large corporate forest for day-to-day • Separate forest with separate accounts, computers, and network for secret project

  10. AD Design • Decentralized IT scenario • Division A, division B both with own IT budget and staff • Divisions used to having admin control • Central CIO office recommends policy, but in practice cannot dictate or enforce • What do you do? • One forest, central runs root, divisions get domains? • One forest per division?

  11. DNS Design (overview)

  12. Single Namespace • Simple design – BUT risk external exposure of namespace and SRV records • Potentiall complex set of permissions to update and manage DNS zone information • SRV records are intermingled with all resource records in the organization

  13. Delegated Namespace • Subzone of public namespace is delegated to AD • Segregates AD SRV records from pub available records • Management of specific portion of DNS

  14. Internal Namespace • Alleviates concerns over who will manage AD portion of DNS • Can hamper the scalability of AD

  15. Segmented Namespace • Allows same namespace for AD both int and ext but not same DNS infrastructure • Allows isolation of AD DNS infrastructure • Preserve public scalability • Most likely manual replication of entries

  16. AD Integrated Zones • Secure Dynamic Update • DNS records as AD Objects • Zone transfer security • IPSec between Client and Server (covered by Thomas Lee later today) • DNS Cache

  17. AD Integrated Zones Secure Dynamic Update • The third option; only allows secure dynamic updates • DNS Server will forward attempt to AD • Change will be compared to the DACL on the zone obj and to the resource record (if it exists) • Change only occur if computer has necessary permissions

  18. AD Integrated Zones DNS records as AD Objects • Resource records stored as AD obj • Security can be configured as your organization requires

  19. AD Integrated Zones Zone transfer security • Std default zone transfer  records sent as clear text • Req additional config to secure connection between DNS Servers • DNS zones stored as AD int obj  AD replication is used to transfer zone updates • AD replication is automatically encrypted by using RPC encryption by default

  20. AD Integrated Zones Protecting the DNS Cache • If server is not authoritative for the RR it will check cache before it queries other servers • Cache pollution: an attacker adds entries into the cache to redirect clients • Enable Secure Cache Against Pollution option on the server • If enabled, inspects response from another server to determine whether referenced names are pollution attempts Referral record to different namespace might not be cached even if it’s valid.

  21. GPO Security Settings Understanding the affects of implementation Examples of Compatibility Issues That May Occur

  22. Shut down system immediately if unable to log security audits 1/2 • Windows 2000:may stop logging events before the specified size is reached. This bug is fixed in Windows 2000 Service Pack 4 (SP4) • Windows 2000, Windows Server 2003:may stop responding and then may spontaneously restart if the log is full and if an existing event log entry cannot be overwritten • Microsoft Network Client for MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003:Non-administrators who try to log on to a domain will receive the following error message: • Your account is configured to prevent you from using this computer. Please try another computer • Windows 2000:On Windows 2000-based computers, non-administrators will not be able to log on to remote access servers, and they will receive an error message that is similar to the following: • Unknown user or bad password

  23. Shut down system immediately if unable to log security audits 2/2 • Windows 2000:On Windows 2000 domain controllers, the Intersite Messaging service (Ismserv.exe) will stop and will not be able to be restarted • Windows 2000:Active Directory replication will fail, and an "Access Denied" message will appear if the security event log is full • Microsoft Exchange 2000:Will not be able to mount the information store database, and event 2102 will be registered in the event log • Outlook, Outlook Web Access:Non-administrators will not be able to access their mail through Microsoft Outlook or through Microsoft Outlook Web Access, and they will receive a 503 error

  24. LDAP server signing requirements • Simple binds will fail, and you will receive the following error message: • Ldap_simple_bind_s() failed: Strong Authentication Required • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003:Some AD admin tools will not operate correctly against DCs that are running Windows 2000 pre-SP3 when NTLM authentication is negotiated • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003:Some AD admin tools that target DCs that are running versions of Windows 2000 pre-SP3 will not operate correctly if they are using IP addresses (example, "dsa.msc /server=x.x.x.x" where x.x.x.x is an IP address) • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003:Some AD admin tools that target domain controllers that are running versions of Windows 2000 pre-SP3 will not operate correctly

  25. LDAP client signing requirements • Enabling the LDAP client signing requirements setting is a risky configuration. If you set the server to require LDAP signatures, you must also configure LDAP signing on the client. Not configuring the client to use LDAP signatures will prevent communication with the server; this will cause user authentication, Group Policy settings, logon scripts, and other features to fail.

  26. Require strong (Windows 2000 or later) session key • Windows NT 4.0:On Windows NT 4.0-based computers, resetting secure channels of trust relationships between Windows NT 4.0 and Windows 2000 domains with NLTEST fails with "Access Denied" error message: • The trust relationship between the primary domain and the trusted domain failed

  27. Digitally encrypt or sign secure channel data (always) 1/2 • Windows 2000:Will not be able to join Windows NT 4.0 domains and will receive the following error message: • The account is not authorized to log in from this station • Windows NT 4.0:Windows NT 4.0 domains will not be able to establish a down-level trust with a Windows 2000 domain and will receive the following error message: • The account is not authorized to log in from this station • Existing down-level trusts may also not authenticate users from the trusted domain. Some users may have difficulty logging on to the domain, and they may receive an error message that states that the client cannot find the domain • Microsoft Network:Microsoft Network clients will receive one of the following error messages: • Logon failure: unknown username or bad password • There is no user session key for the specified logon session

  28. Digitally encrypt or sign secure channel data (always) 2/2 • Windows XP:Clients that are joined to Windows NT 4.0 domains will not be able to authenticate logon attempts and may receive the following error message, or the following events may be registered in the event log: • Windows cannot connect to the domain either because the domain controller is down or is otherwise unavailable or because your computer account was not found • Event 5723: The session setup from computer ComputerName failed to authenticate. The name of the account referenced in the security database is ComputerName. The following error occurred: Access is denied. • Event 3227: The session setup to the Windows NT or the Windows 2000 domain controller Server Name for the domain Domain Name failed because Server Name does not support signing or sealing the Netlogon session. Upgrade the domain controller, or set the RequireSignOrSeal registry entry on this computer to 0

  29. Domain Member: Digitally sign communications (always) • Windows NT 4.0:Not able to reset the secure channel of a trust between a Windows Server 2003 domain and a Windows NT 4.0 domain by using NLTEST or NETDOM, and you will receive an "Access Denied" error message • Windows XP:Copying files from Windows XP clients to Windows 2000-based servers and to Windows Server 2003-based servers may take more time • You will not be able to map a network drive from a client with this setting enabled, and you will receive the following error message: • The account is not authorized to log in from this station

  30. Microsoft Network Client: Digitally sign communications (always) • Windows 95:Without the DS Client installed, fail logon authentication and receive the following error message: • The domain password you supplied is not correct, or access to your logon server has been denied • Windows NT 4.0:Client pre-SP 3 will fail logon authentication and will receive the following error message: • The system could not log you on. Make sure your username and your domain are correct, then type your password again • The following clients are incompatible with the Microsoft network server: Digitally sign communications (always) setting: • Apple Computer, Inc., Mac OS X clients • Microsoft MS-DOS network clients (for example, Microsoft LAN Manager) • Microsoft Windows for Workgroups clients • Microsoft Windows 95 clients without the DS Client installed • Microsoft Windows NT 4.0-based computers without SP3 or later installed • Novell Netware 6 CIFS clients • SAMBA SMB clients that lack support for SMB signing

  31. Network access: Allow anonymous SID/Name translation • Windows NT 4.0:Computers in Windows NT 4.0 resource domains will display the "Account Unknown" error message in ACL Editor if resources, including shared folders, shared files, and registry objects, are secured with security principals that reside in account domains that contain Windows Server 2003 domain controllers

  32. Network access: Do not allow anonymous enumeration of SAM accounts • SMS: Network Discovery will not be able to obtain operating system information and will write "Unknown" in the OperatingSystemNameandVersion property. • Windows 95, Windows 98: Clients will not be able to change their passwords. • Windows NT 4.0: Member computers will not be able to be authenticated. • Windows 95, Windows 98: will not be able to be authenticated by Microsoft domain controllers. • Windows 95, Windows 98: Users on Windows 95-based and Windows 98-based computers will not be able to change the passwords for their user accounts.

  33. Do not allow anonymous enumeration of SAM accounts and shares 1/3 • Windows NT 4.0:When RestrictAnonymous is enabled • Windows NT 4.0:Adding users or global groups from trusted Windows 2000 domains to Windows NT 4.0 local groups in User Manager will fail with the following error message: • There are currently no logon servers available to service the logon request • Windows NT 4.0:Not able to join domains during setup or by using the domain join user interface • Windows NT 4.0:Establishing a down-level trust with Windows NT 4.0 resource domains will fail with the following error message when RestrictAnonymous is enabled on the trusted domain: • Could not find domain controller for this domain • Windows NT 4.0:Users who log on to Terminal Server computers will map to the default home directory instead of the home directory that is defined in User Manager for domains

  34. Do not allow anonymous enumeration of SAM accounts and shares 2/3 • Windows NT 4.0:BDCs will not be able to start the Net Logon service, obtain a list of backup browsers, synchronize the SAM from Windows 2000 or from Windows Server 2003 DCs in the same domain • Windows 2000:Member computers in Windows NT 4.0 domains will not be able to view printers in external domains if the No access without explicitly anonymous permissions setting is enabled in the local security policy of the client computer • Windows 2000:Domain users will not be able to add network printers from AD; however, they will be able to add printers after they select them from the tree view • Windows 2000:ALC Editor will not be able to add users or global groups from trusted Windows NT 4.0 domains • ADMT version 2:Password migration for user accounts that are migrated between forests with ADMTv2 will fail • Outlook clients:The global address list will appear empty to Microsoft Exchange Outlook clients

  35. Do not allow anonymous enumeration of SAM accounts and shares 3/3 • SMS:Network Discovery will not be able to obtain the operating system information. Therefore, it will write "Unknown" in the OperatingSystemNameandVersion property of the SMS DDR property of the discovery data record (DDR) • SMS:When you use the SMS Administrator User Wizard to browse for users and for groups, no users and no groups will be listed • SMS:When you are using the Network Discovery feature in SMS 2.0 and in Remote Client Installation with the Topology, client, and client operating systems network discovery option turned on, computers may be discovered but may not be installed

  36. LanManager authentication level • Windows 2000:If a Windows 2000 domain with NTLMv2 Level 2 or later is trusted by a Windows NT 4.0 domain, Windows 2000-based member computers in the resource domain may experience authentication errors. • Windows 2000:Windows 2000 clustering does not authenticate a joining node if both nodes are part of a Windows NT 4.0 Service Pack 6a (SP6a) domain.

  37. Understanding the Schema

  38. Attributes • Represents the possible properties that can be used in object classes • Defined one time and reused for each object class which they are associated

  39. Object Classes • Collections of attributes that can be instantiated to create objects, some are mandatory others are optional • Based on X.500 1993 specification for DS that defines hierarchal structure of classes. • X.509 requires that object classes be assigned to one of the following categories: • Structural • Abstract • Auxiliary

  40. Structural Classes • Creating objects in Active Directory • Can be used in defining the structure of the directory • Derived from either an abstract class or another structural class • Its definition can include any number of auxiliary classes

  41. Abstract Classes • Templates to derive new structural classes • Can’t be instantiated in the directory (objs can’t belong to an abstract class only; each obj must also belong to some non-abstract subclass) • Can be derived from an existing abstract class • Provide attributes for subordinate classes (subclasses) • Subclasses contain all mandatory and optional attributes of the class from which it derived from (superclass), in addition to those attributes specific to the class itself

  42. Auxiliary Classes • Contain a list of attributes • Can’t be instantiated in the directory • Can be derived from existing aux classes • Adds the aux class’s attributes to the definition of a structural or abstract class

  43. Mandatory Top Optional Class Derivation objClass X New

  44. Securing Active Directory

  45. Security Descriptor • All objects and their properties have SDs • Control access to objects and values of the obj’s attributes • Includes a discretionary access control list (DACL) • Includes a system access control list (SACL) • Includes obj’s ownership data SecurityDescriptor Header Owner SID Group SID DACL ACEs SACL ACEs

  46. Security Descriptor • The nTSecurityDescriptor attribute holds the SD as a binary blob • Can be viewed and translated using LDP • LDP translates the blob to Security Descriptor Definition Language (SDDL) format • The simplest way is to view the ACL via the security UI • The UI doesn’t always show the “truth”!

  47. View SD through LDP

  48. Setting the Security Descriptor objectGUID of deleted objects container

  49. Dssec.dat • File that filters the “visible” attributes to which one can control permissions in the GUI • Editing allows exposing of additional attributes, e.g., UserAccountLockout

  50. %SystemRoot%\System32\dssec.dat [serviceInstance] @=7 adminDescription=7 adminDisplayName=7 [user] aCSPolicyName=7 adminCount=7 allowedAttributes=7 allowedAttributesEffective=7 allowedChildClasses=7 [volume] adminDescription=7 adminDisplayName=7 allowedAttributes=7 allowedChildClassesEffective=7 ………………… Displayedattributescontrolled by dssec.dat ………………… Do NOT display attribute in Permissions field UI Security Tab No entry or = 0: display read/write = 1: display write = 2: display read

More Related