LDP.exe for Active Directory - Download, Usage, Tutorial and Examples

Folks,

In a few days, I'll start shedding some light on vital Active Directory Security related matters that I believe most organizations seem to be in the dark about today. Until then, I just wanted to share some simple technical stuff on a few technical topics.


Today's is on LDP.exe,  a helpful free tool from Microsoft that can be used to perform LDAP operations in Active Directory.

LDP.exe

Technically speaking, LDP is a simple Lightweight Directory Access Protocol (LDAP) client that allows users to perform various operations (connect, bind, search, modify, add, delete) against any LDAP-compatible directory, such as and including Active Directory. It can also be used to view replication metadata and Active Directory security descriptors.

In this blog entry, I've covered the following aspects of LDP as succinctly as possible -

1. Where to download LDP from
2. An overview of how to use LDP
3. Connecting to Active Directory using LDP
4. Performing a successful bind in LDP
5. An overview of operations possible with LDP
6. How to view Active Directory contents with LDP
7. How to search Active Directory using LDP
8. How to view Active Directory NT Security Descriptors
9. Ten common LDP usage examples
10. Helpful tips on using LDP 

By the way, this primer shouldn't be new stuff for many folks, but the world's a big place, and so while 1000s of IT personnel likely use LDP, 100s of 1000s of IT personnel, including many cyber security professionals, may have yet to discover LDP.exe.




1. Download LDP.exe

First things first. You can instantly download LDP from here. (Simply locate, then click on LDP Utility.)



Download LDP.exe

Tip - LDP.exe is a nifty tool, especially for Active Directory analysis. However it requires some Active Directory technical knowledge. If you don't want to deal with the technicals, or don't have the time to ramp up on the technicals, and are primarily interested in its search capabilities to perform basic yet essential Active Directory security audits, as an alternative/addition, this free Active Directory Audit Tool could save you a lot time and effort.

2. An Overview of How to Use LDP

LDP.exe is fairly easy to use, but it requires you to have some basic technical background on LDAP, Windows Security etc.

Here's a quick overview of how to use LDP.exe -

1. Connect to an Active Directory domain or Domain Controller, after launching LDP.exe.
2. Perform a successful LDAP bind by authenticating to Active Directory
3. Specify a target Active Directory object as the base DN for permitted operations
4. Perform the desired operations (e.g. search, modify, add, delete, view SD, etc.)
5. Disconnect, when done. 

To help you get started and become acquainted, I've illustrated these steps below step-by-step.




3. Connecting to Active Directory using LDP.exe

Once you've downloaded LDP.exe, just double-click on it to launch it. Then, the first thing to do is connect to Active Directory.

To connect to an Active Directory domain, you launch LDP.exe, then select the Connection item from the application menu on the top to locate and click the Connect option, which displays the Connect dialog box.

LDP Connect

In the Connect dialog box, you specify the Active Directory domain or domain controller you wish to connect to, by entering its complete domain DNS name (e.g. root.local, dc1.root.local etc.), as well as the port you'd like to connect on (389 for LDAP and 3268 for a Global Catalog), and optionally, whether you'd like to use SSL.

LDP Connect Dialog

Once connected, LDP.exe will display the root of the directory data tree on a directory server, i.e. the value of the rootDSE attribute which includes various nuggets of valuable technical information.

LDP displaying rootDSE info

Specifically, rootDSE is an operational attribute that provides helpful information about the Active Directory domain (and domain controller) to which it is connected, such as the current time on the DC, the domain and forest functional levels, the SASL mechanisms supported, the LDAP policies and controls supported, whether the DC is also a Global Catalog etc.

Here's an example of what the rootDSE details look like -

ld = ldap_open("", 389);

Established connection to .

Retrieving base DSA information...

Getting 1 entries:

>> Dn:

 1> currentTime: 06/17/2016 22:27:47 Pacific Standard Time;

 1> subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=root,DC=local;

 1> dsServiceName: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=root,DC=local;

 5> namingContexts: DC=root,DC=local; CN=Configuration,DC=root,DC=local; CN=Schema,CN=Configuration,DC=root,DC=local; DC=DomainDnsZones,DC=root,DC=local; DC=ForestDnsZones,DC=root,DC=local;

 1> defaultNamingContext: DC=root,DC=local;

 1> schemaNamingContext: CN=Schema,CN=Configuration,DC=root,DC=local;

 1> configurationNamingContext: CN=Configuration,DC=root,DC=local;

 1> rootDomainNamingContext: DC=root,DC=local;

 29> supportedControl: 1.2.840.113556.1.4.319 = ( LDAP_PAGED_RESULT_OID_STRING ); 1.2.840.113556.1.4.801 = ( LDAP_SERVER_SD_FLAGS_OID ); 1.2.840.113556.1.4.473 = ( LDAP_SERVER_SORT_OID ); 1.2.840.113556.1.4.528 = ( LDAP_SERVER_NOTIFICATION_OID ); 1.2.840.113556.1.4.417 = ( LDAP_SERVER_SHOW_DELETED_OID ); 1.2.840.113556.1.4.619 = ( LDAP_SERVER_LAZY_COMMIT_OID ); 1.2.840.113556.1.4.841 = ( LDAP_SERVER_DIRSYNC_OID ); 1.2.840.113556.1.4.529 = ( LDAP_SERVER_EXTENDED_DN_OID ); 1.2.840.113556.1.4.805 = ( LDAP_SERVER_TREE_DELETE_OID ); 1.2.840.113556.1.4.521 = ( LDAP_SERVER_CROSSDOM_MOVE_TARGET_OID ); 1.2.840.113556.1.4.970 = ( LDAP_SERVER_GET_STATS_OID ); 1.2.840.113556.1.4.1338 = ( LDAP_SERVER_VERIFY_NAME_OID ); 1.2.840.113556.1.4.474 = ( LDAP_SERVER_RESP_SORT_OID ); 1.2.840.113556.1.4.1339 = ( LDAP_SERVER_DOMAIN_SCOPE_OID ); 1.2.840.113556.1.4.1340 = ( LDAP_SERVER_SEARCH_OPTIONS_OID ); 1.2.840.113556.1.4.1413 = ( LDAP_SERVER_PERMISSIVE_MODIFY_OID ); 2.16.840.1.113730.3.4.9 = ( LDAP_CONTROL_VLVREQUEST ); 2.16.840.1.113730.3.4.10 = ( LDAP_CONTROL_VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( LDAP_SERVER_ASQ_OID ); 1.2.840.113556.1.4.1852 = ( LDAP_SERVER_QUOTA_CONTROL_OID ); 1.2.840.113556.1.4.802 = ( LDAP_SERVER_RANGE_OPTION_OID ); 1.2.840.113556.1.4.1907 = ( LDAP_SERVER_SHUTDOWN_NOTIFY_OID ); 1.2.840.113556.1.4.1948; 1.2.840.113556.1.4.1974; 1.2.840.113556.1.4.1341; 1.2.840.113556.1.4.2026; 1.2.840.113556.1.4.2064; 1.2.840.113556.1.4.2065; 1.2.840.113556.1.4.2066;

 2> supportedLDAPVersion: 3; 2;

 16> supportedLDAPPolicies: MaxPoolThreads; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn; MaxNotificationPerConn; MaxValRange; ThreadMemoryLimit; SystemMemoryLimitPercent;

 1> highestCommittedUSN: 1651102;

 4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;

 1> dnsHostName: DC1.root.local;

 1> ldapServiceName: root.local:dc1$@ROOT.LOCAL;

 1> serverName: CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=root,DC=local;

 5> supportedCapabilities: 1.2.840.113556.1.4.800 = ( LDAP_CAP_ACTIVE_DIRECTORY_OID ); 1.2.840.113556.1.4.1670 = ( LDAP_CAP_ACTIVE_DIRECTORY_V51_OID ); 1.2.840.113556.1.4.1791 = ( LDAP_CAP_ACTIVE_DIRECTORY_LDAP_INTEG_OID ); 1.2.840.113556.1.4.1935; 1.2.840.113556.1.4.2080;

 1> isSynchronized: TRUE;

 1> isGlobalCatalogReady: TRUE;

 1> domainFunctionality: 4;

 1> forestFunctionality: 4;

 1> domainControllerFunctionality: 4;

-----------

You are now connected to an Active Directory domain controller.




4. Performing a successful LDAP Bind

Once connected, the next step is to perform a successful bind i.e. to authenticate yourself to the Active Directory.

To perform a successful bind, you select the Connection item from the application menu on the top to locate and access the Bind option, which displays the Bind dialog box.

LDP Bind

In the Bind dialog box, you enter your credentials then click on OK. You can enter your credentials in various formats (e.g. UPN, <domain>\<samAccountName> etc.). If you're logged in using a domain user account and are connecting to an Active Directory domain to which a trust path exists from your domain, the simplest way to bind is to use the Bind as currently logged on user option.

LDP Bind Dialog Box

If successfully authenticated, LDP will indicate so by displaying an Authenticated as DN:<identity> line in the right pane.

Successful LDP Bind

You have now successfully completed a bind and are ready to perform operations against Active Directory.




5. Possible Active Directory Operations with LDP.exe

With LDP.exe, you can perform the following operations against Active Directory -

1. View Active Directory contents
2. Search Active Directory
3. View Active Directory Security Descriptors
4. View Active Directory Replication Metadata
5. View the Enterprise Tree
6. Create, delete and modify Active Directory content

In this blog entry, I will focus on illustrating how to view Active Directory content, perform Active Directory searches and view Active Directory security descriptors, as these are the most common usage scenarios.

Tip - If you're looking to fulfill advanced Active Directory security analysis/audit needs, such as to audit privileged user access in Active Directory, determine effective permissions in Active Directory etc. you may find this helpful.

6. Viewing Active Directory Contents using LDP.exe

Once you have performed a successful bind, you can perform various operations against Active Directory, and one of the most common ones is to view Active Directory contents, such as to view all attributes on a specific user account.

To do so, you select the View item from the application menu on the top to locate and click on the Tree option.

LDP Tree Option

Clicking on the Tree option displays the Tree dialog box, which is used to specify the distinguished name (DN) of the Active Directory object (/base of tree) you wish to view or focus on. By default, the Tree dialog box presents a few options including the domain root of the target domain, as well as the roots of the Configuration and Schema partitions of the target forest.

LDP Tree Specification Dialog Box

The domain root of the target domain is generally a good place to start, so simply select it and click OK.

When you do so, LDP.exe will display the root of the domain in the left pane.

Domain Root displayed in LDP.exe

A single-click on an object in the left pane will display the attributes (and their values) present on that object, in the right pane. A double-click will expand and display, in the left pane, the tree rooted at that object.

In this manner, once you know the DN of an object, such as that of a specific organizational unit (OU), a domain user account, a domain computer account, an NTDS Settings object, a SiteLink object, a Schema class/attribute object etc. that you are interested in, you can use the Tree dialog box to enter that object's DN and have LDP focus on that object.

Tip - The quickest way to find the DN of almost any object in Active Directory without requiring any technical knowledge is by using the inbuilt Search utility of this free tool.

7. Searching Active Directory using LDP.exe

Once you have specified a target object, you can perform a variety of operations on it. For instance, you can perform an LDAP search rooted at that object in Active Directory.

To do so, in the left pane, simply locate the object that you wish to have as the base of your search, then right-click on it, to view a set of available options, one of which should be Search.

Accessing Search in LDP.exe

Tip - Note that alternatively, you can also access the Search dialog box by selecting the General option from the application menu and then clicking on Search.

Selecting the Search option will open the Search dialog box. In this dialog box you basically need to specify the search filter and its scope. To specify the filter, you need to enter a valid LDAP filter, and to specify the scope, you simply choose from amongst, Base, One-Level or Sub-Tree.

LDP Search Dialog

 

In some cases, you'll also want to click on the Options button to be able to specify and set various options such as Time limit, Size limit, Timeout (s), Timeout (ms), Page size, Search Call Type, Sort Keys and Controls etc. as well as the list of attributes that you would like to have retrieved.

LDP Search Options Dialog

By default, LDP.exe will retrieve and display all attributes on all objects that meet the criteria of the specified LDAP filter.

If you're only interested in a subset of attributes, you can specify them using the Attributes text-box. Additionally, if you merely require a summary listing of the objects (i.e. no attributes to be returned), simply enter a . (i.e. a period) in the Attributes box.

Setting LDP Search Options to obtain a Summary listing
(when set, no attributes will be retrieved or returned)

Due to lack of time, I'm not going to delve into the various details of Sort Keys and Controls, but there's sufficient info out on MS TechNet that can help you learn more about their details and uses.

 

When you click OK, LDP.exe will perform the specified search for you and display the results in the right navigation pane.

Search Results Retrieved and Displayed in LDP.exe

Note that if you had specified that only the DNs be returned (i.e. no attributes), the results would look like the following.

Search Results (List of Objects Only; No Attributes)

In general, in order to be able to perform a variety of searches, you'll want to gain familiarity with how to define LDAP filters.

Tip - The quickest way to search for Active Directory content and perform Active Directory security audits without requiring any technical knowledge is to use the inbuilt Search utility of this free Active Directory audit tool.

8. Viewing Active Directory Security Descriptors using LDP.exe

LDP can also be used to view the NT Security Descriptors of Active Directory objects. The NT Security Descriptor contains / specifies the object's Owner, Group, ACL and SACL. Most IT professionals seek to do so to fulfill a variety of Active Directory cyber security analysis needs, such as those outlined in the 10 Helpful Time and Effort Saving Pointers section below.

Tip - You may find that one of the easiest and quickest ways to view, analyze and dump/export Active Directory security permissions and access control lists (ACL) is by using this AD acldump tool.

Consider the following Active Directory object. Lets see how to use LDP to view its NT Security Descriptor.

LDP focused on a specific Active Directory object

 

 

To view the NT Security Descriptor of an Active Directory object, you right-click on the object, then select Advanced then select Security Descriptor. 

Accessing the Security Descriptor Dialog in LDP

Doing so will display the Security Descriptor dialog box, which additionally presents two options -

Security Descriptor Dialog Box

1. SACL - If selected, LDP will additionally* retrieve the object's SACL.
2. Text dump - If selected, LDP will dump the security descriptor as text in the right pane.

* To view the SACL, you'll need to be effectively granted the Manage auditing and security log user right in the resulting Group Policy applicable to that domain controller (typically the default Domain Controller policy).

You specify these options as required, and then click OK. When you do so, LDP.exe will retrieve and display the Security Descriptor of the target object.

By default, the security descriptor is displayed in a special Security Descriptor dialog box.

Security Descriptor on an Active Directory Domain User Account Object

If the text dump option is selected, the security descriptor is displayed in text format in the right navigation pane.

NT Security Descriptor Text Dump in LDP.exe

Here's a partial text dump of an NT Security Descriptor of an Active Directory object -

Security Descriptor:
Security Descriptor:SD Revision: 1
SD Control:  0x8c14
  SE_DACL_PRESENT
  SE_SACL_PRESENT
  SE_DACL_AUTO_INHERITED
  SE_SACL_AUTO_INHERITED
  SE_SELF_RELATIVE
Owner: ROOT\Domain Admins [S-1-5-21-393905754-1721216372-3318422012-512]
Group: ROOT\Domain Admins [S-1-5-21-393905754-1721216372-3318422012-512]
DACL:
 Revision      4
 Size:         2532 bytes
 # Aces:       53
 Ace[0]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000010
   ACTRL_DS_READ_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Account Restrictions - 4c164200-20c0-11d0-a768-00aa006e0529
  Object Ace Sid:   ROOT\RAS and IAS Servers [S-1-5-21-393905754-1721216372-3318422012-553]
 Ace[1]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000010
   ACTRL_DS_READ_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Logon Information - 5f202010-79a5-11d0-9020-00c04fc2d4cf
  Object Ace Sid:   ROOT\RAS and IAS Servers [S-1-5-21-393905754-1721216372-3318422012-553]
 Ace[2]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000010
   ACTRL_DS_READ_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Group Membership - bc0ac240-79a9-11d0-9020-00c04fc2d4cf
  Object Ace Sid:   ROOT\RAS and IAS Servers [S-1-5-21-393905754-1721216372-3318422012-553]
 Ace[3]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000010
   ACTRL_DS_READ_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Remote Access Information - 037088f8-0ae1-11d2-b422-00a0c968f939
  Object Ace Sid:   ROOT\RAS and IAS Servers [S-1-5-21-393905754-1721216372-3318422012-553]
 Ace[4]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000030
   ACTRL_DS_READ_PROP
   ACTRL_DS_WRITE_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  userCertificate - bf967a7f-0de6-11d0-a285-00aa003049e2
  Object Ace Sid:   ROOT\Cert Publishers [S-1-5-21-393905754-1721216372-3318422012-517]
 Ace[5]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  44 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000010
   ACTRL_DS_READ_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  tokenGroupsGlobalAndUniversal - 46a9b11d-60ae-405a-b7e8-ff8a58d456d2
  Object Ace Sid:   BUILTIN\Windows Authorization Access Group [S-1-5-32-560]
 Ace[6]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  44 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000030
   ACTRL_DS_READ_PROP
   ACTRL_DS_WRITE_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  terminalServer - 6db69a1c-9422-11d1-aebd-0000f80367c1
  Object Ace Sid:   BUILTIN\Terminal Server License Servers [S-1-5-32-561]
 Ace[7]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  44 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000030
   ACTRL_DS_READ_PROP
   ACTRL_DS_WRITE_PROP
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Terminal Server License Server - 5805bc62-bdc9-4428-a5e2-856a0f4c185e
  Object Ace Sid:   BUILTIN\Terminal Server License Servers [S-1-5-32-561]
 Ace[8]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  40 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000100
   ACTRL_DS_CONTROL_ACCESS
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Change Password - ab721a53-1e2f-11d0-9819-00aa0040529b
  Object Ace Sid:   Everyone [S-1-1-0]
 Ace[9]
  Ace Type:  0x5 - ACCESS_ALLOWED_OBJECT_ACE_TYPE
  Ace Size:  40 bytes
  Ace Flags: 0x0
  Object Ace Mask:  0x00000100
   ACTRL_DS_CONTROL_ACCESS
  Object Ace Flags: 0x1
   ACE_OBJECT_TYPE_PRESENT
  Object Ace Type:  Change Password - ab721a53-1e2f-11d0-9819-00aa0040529b
  Object Ace Sid:   NT AUTHORITY\SELF [S-1-5-10]

 ... 

 Ace[50]
  Ace Type:  0x0 - ACCESS_ALLOWED_ACE_TYPE
  Ace Size:  36 bytes
  Ace Flags: 0x12
   CONTAINER_INHERIT_ACE
   INHERITED_ACE
  Ace Mask:  0x000f01ff
   DELETE
   READ_CONTROL
   WRITE_DAC
   WRITE_OWNER
   ACTRL_DS_CREATE_CHILD
   ACTRL_DS_DELETE_CHILD
   ACTRL_DS_LIST
   ACTRL_DS_SELF
   ACTRL_DS_READ_PROP
   ACTRL_DS_WRITE_PROP
   ACTRL_DS_DELETE_TREE
   ACTRL_DS_LIST_OBJECT
   ACTRL_DS_CONTROL_ACCESS
  Ace Sid:   ROOT\Enterprise Admins [S-1-5-21-393905754-1721216372-3318422012-519]
 Ace[51]
  Ace Type:  0x0 - ACCESS_ALLOWED_ACE_TYPE
  Ace Size:  24 bytes
  Ace Flags: 0x12
   CONTAINER_INHERIT_ACE
   INHERITED_ACE
  Ace Mask:  0x00000004
   ACTRL_DS_LIST
  Ace Sid:   BUILTIN\Pre-Windows 2000 Compatible Access [S-1-5-32-554]
 Ace[52]
  Ace Type:  0x0 - ACCESS_ALLOWED_ACE_TYPE
  Ace Size:  24 bytes
  Ace Flags: 0x12
   CONTAINER_INHERIT_ACE
   INHERITED_ACE
  Ace Mask:  0x000f01bd
   DELETE
   READ_CONTROL
   WRITE_DAC
   WRITE_OWNER
   ACTRL_DS_CREATE_CHILD
   ACTRL_DS_LIST
   ACTRL_DS_SELF
   ACTRL_DS_READ_PROP
   ACTRL_DS_WRITE_PROP
   ACTRL_DS_LIST_OBJECT
   ACTRL_DS_CONTROL_ACCESS
  Ace Sid:   BUILTIN\Administrators [S-1-5-32-544]
SACL:
 Revision      4
 Size:         252 bytes
 # Aces:       5
 Ace[0]
  Ace Type:  0x7 - SYSTEM_AUDIT_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x92
   CONTAINER_INHERIT_ACE
   INHERITED_ACE
   FAILED_ACCESS_ACE_FLAG
  Object Ace Mask:  0x00000100
   ACTRL_DS_CONTROL_ACCESS
  Object Ace Flags: 0x3
   ACE_OBJECT_TYPE_PRESENT
   ACE_INHERITED_OBJECT_TYPE_PRESENT
  Object Ace Type:  Reset Password - 00299570-246d-11d0-a768-00aa006e0529
  Inherited object type: user - bf967aba-0de6-11d0-a285-00aa003049e2
  Object Ace Sid:   Everyone [S-1-1-0]
 Ace[1]
  Ace Type:  0x2 - SYSTEM_AUDIT_ACE_TYPE
  Ace Size:  20 bytes
  Ace Flags: 0x52
   CONTAINER_INHERIT_ACE
   INHERITED_ACE
   SUCCESSFUL_ACCESS_ACE_FLAG
  Ace Mask:  0x00050000
   DELETE
   WRITE_DAC
  Ace Sid:   Everyone [S-1-1-0]
 Ace[2]
  Ace Type:  0x7 - SYSTEM_AUDIT_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x52
   CONTAINER_INHERIT_ACE
   INHERITED_ACE
   SUCCESSFUL_ACCESS_ACE_FLAG
  Object Ace Mask:  0x00000100
   ACTRL_DS_CONTROL_ACCESS
  Object Ace Flags: 0x3
   ACE_OBJECT_TYPE_PRESENT
   ACE_INHERITED_OBJECT_TYPE_PRESENT
  Object Ace Type:  Reset Password - 00299570-246d-11d0-a768-00aa006e0529
  Inherited object type: user - bf967aba-0de6-11d0-a285-00aa003049e2
  Object Ace Sid:   Everyone [S-1-1-0]
 Ace[3]
  Ace Type:  0x7 - SYSTEM_AUDIT_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x5a
   CONTAINER_INHERIT_ACE
   INHERIT_ONLY_ACE
   INHERITED_ACE
   SUCCESSFUL_ACCESS_ACE_FLAG
  Object Ace Mask:  0x00000020
   ACTRL_DS_WRITE_PROP
  Object Ace Flags: 0x3
   ACE_OBJECT_TYPE_PRESENT
   ACE_INHERITED_OBJECT_TYPE_PRESENT
  Object Ace Type:  gPLink - f30e3bbe-9ff0-11d1-b603-0000f80367c1
  Inherited object type: organizationalUnit - bf967aa5-0de6-11d0-a285-00aa003049e2
  Object Ace Sid:   Everyone [S-1-1-0]
 Ace[4]
  Ace Type:  0x7 - SYSTEM_AUDIT_OBJECT_ACE_TYPE
  Ace Size:  56 bytes
  Ace Flags: 0x5a
   CONTAINER_INHERIT_ACE
   INHERIT_ONLY_ACE
   INHERITED_ACE
   SUCCESSFUL_ACCESS_ACE_FLAG
  Object Ace Mask:  0x00000020
   ACTRL_DS_WRITE_PROP
  Object Ace Flags: 0x3
   ACE_OBJECT_TYPE_PRESENT
   ACE_INHERITED_OBJECT_TYPE_PRESENT
  Object Ace Type:  gPOptions - f30e3bbf-9ff0-11d1-b603-0000f80367c1
  Inherited object type: organizationalUnit - bf967aa5-0de6-11d0-a285-00aa003049e2
  Object Ace Sid:   Everyone [S-1-1-0]
Security for "CN=Satya Nadella,OU=IT Admin Accounts,OU=IT,OU=Newport Beach,OU=USA,OU=Americas,OU=Corp,DC=root,DC=local"
-----------

 

Helpful Tip - If you need to dump/export Active Directory ACLs, or easily and quickly analyze them, the easiest and fastest way to do so is by using this AD acldump tool.

In this manner you can view and analyze Active Directory security descriptors using LDP.exe.





9. Some Common LDP.exe Uses

The following snapshots illustrate some common uses of LDP.exe.

1. Viewing the domain root object and its attributes (e.g. lockoutObservationWindow) -

Domain Root Object

2. Enumerating all domain user accounts that have a specific term in their Title (e.g. *Cloud*) -

All domain user accounts with the word Cloud in their title

Tip - If you need to generate reports such as List of all active, stale, expired, locked, executive, administrative user accounts in a domain/OU etc. or export this data to a CSV file, or generate a PDF report, the easiest way to do is by using this AD audit tool.

3. Viewing the AdminSDHolder object and the NT Security Descriptor protecting it - 

The AdminSDHolder object

Tip - If you need to find out who has what effective permissions/access on any object in Active Directory (e.g. administrative accounts, groups etc.), the only way to accurately do is by using this Active Directory Effective Permissions Calculator.

 

4. Viewing the Domain Controllers OU and its NT Security Descriptor -

ACL on the Domain Controllers OU

Tip - If you need to find out exactly who can control and manage the security on the Domain Controllers OU, or change the Group Policies (GPOs) linked to it, this tool can help you do so, instantly and accurately.

5. Viewing the Schema partition and its contents -

Schema Partition Root Object

Tip - If you need to know exactly who can modify an existing class or attribute definition in your Active Directory Schema, or extend your Schema, this tool can help you find this out, instantly and accurately.

6. Viewing the Configuration partition and its contents -

Configuration Partition Root Object

Tip - If you need to know exactly who can modify critical content in your Configuration partition, such as creating, modifying or deleting Sites, Subnets, Sitelinks, IP Transports, NTDS Settings objects, Query Policies etc., this tool can help you find this out, instantly and accurately.

7. Viewing Replication Metadata on an object -

Replication Metadata

8. Using Looking up Security Identifiers (SIDs) using the SID Lookup capability -

Looking up Account SIDS using LDP.exe

Tip - If you need to lookup accounts SIDs, or find Active Directory domain user accounts, computer accounts or security groups based on criteria such as their name, title, operating system, manager etc., one of the easiest ways to do so is by using the inbuilt object search utility of this free Active Directory audit  tool.

9. Requesting the ACLs on all domain user accounts -

NT Security Descriptor on multiple Active Directory objects

Tip - If you need to dump the ACLs of multiple Active Directory objects (e.g. all objects in domain, all admin users, all executives, all security groups etc.) into a CSV file, the easiest way to do so is by using this tool.

10. Enumerating all security principals that belong to a specific group, such as the IT Team security group -

Retrieving all security principals that belong to a specific group

Tip - Although LDP can enumerate direct group memberships, it is unable to enumerate and display the complete, flattened out membership of a specific group, or the list of all groups to which a user belongs. If you need to fulfill either of these needs, here is the easiest way to do so. 

In this manner, LDP.exe can be used to query Active Directory content and analyze various operational and security aspects.




10. Some Helpful Tips When Using LDP.exe

Here are some helpful tips when using LDP.exe -

1. You can clear the contents of the right pane by using Ctrl-N.
2. You can copy contents from the right pane by right-clicking and using Select All, then Copy.
3. You can export the data from the right pane by using the Save-As option.
4. You can increase the buffer size for the number of rows displayed in the right pane by modifying the value for the Number of Lines setting in the Buffer Size section of General Options. The default value is 512.

LDP.exe General Options
 

In general, as you gain familiarity with the tools, you'll likely discover similar helpful tips.




10 Helpful Time and Effort Saving Pointers

If you've read this far, you're likely an IT professional focused on Active Directory or Cyber Security. If so, not only is your time valuable, you know that high-value cyber security insight into your Active Directory is paramount to your organization's security.

You may also likely know not just the benefits of LDP, but also its limits. Specifically, while there's much you can do with it, there also a lot you cannot do with it. For instance, many needs listed below cannot be fulfilled with LDP.exe or most tooling.

If you value your time, you'll find the following pointers helpful, because they're the quickest and easiest ways to accomplish and fulfill a variety of Active Directory focused search, privileged access/user audit and cyber security analysis needs -

1. How to instantly perform an Active Directory security audit

2. How to instantly enumerate Active Directory group memberships

3. How to instantly find out what security groups a user belongs to

4. How to instantly view list of SIDs in another user's account (i.e. whoami for another user)

5. How to instantly identify users with large token sizes (i.e. tokensz for another user)

6. How to instantly view/analyze Active Directory ACLs  (i.e. like dsacls, 10x better)

7. How to instantly dump Active Directory ACLs/permissions

8. How to instantly analyze Active Directory permissions

9. How to instantly determine effective permissions on Active Directory objects

10. How to instantly audit delegations / privileged user access in Active Directory

The first time I used LDP.exe was about 16 years ago. If you've spent even 1/10th of the time I've spent on Active Directory security, I think you'll find these pointers could help you and your organization save 1000s of hours of valuable time.

I hope you've found this little intro to LDP to be useful and I wish you all the best as you proceed to look under the hood and increase your knowledge in the vast subject that is Microsoft Active Directory.

Best wishes,
Sanjay

Time to Help the World Better Understand Active Directory Security

Folks,

As you may know, Microsoft Active Directory is the very foundation of cyber security at over 85% of all organizations worldwide.

For those who may not know, not a proverbial leaf moves in a Microsoft based IT world without Active Directory being involved.


At Paramount Defenses, over the last decade, we've had over 10,000 of the world's most important and prominent government and business organizations from over 160 countries knock at our doors, (completely unsolicited of course.)

We've thus had the opportunity to learn about just how much most organizations seem to know about Active Directory Security.

Based on what we've seen so far, we worry.

Thus, in the interest of global security, we have arrived at the conclusion that organizations worldwide need help understanding the profound importance of Active Directory Security, so in days to come, we're going to help them out.


Starting July 04, 2016, you can expect us some movement on this blog. (To the wise, a hint is enough.)

Best wishes,
Sanjay


PS: Between now and July 04, 2016, I'll also cover a few low-key items on this blog because they need to be addressed.

Good Presentation on Modern Day Active Directory Attacks (Red Vs Blue) at Black Hat USA 2015 but seems to have missed the #1 Attack Vector

Folks,

As you may know, Black Hat USA 2015 is currently being held in Las Vegas, and I believe there was a certain presentation titled Red vs Blue: Modern Active Directory Attacks Detection and Protection by a certain Mr. Sean Metcalf.

[ Now of course, if you know what we do at Paramount Defenses, then you know that if we wanted, we could easily have stolen anybody's thunder at Black Hat. However, when you have thousands of organizations from across a 150 countries worldwide knocking at your doors every month, you just don't have the time or the need to present at conferences. ]

 That said, as seen below, there (rightfully) was quite a bit of interest in this Active Directory Security focused presentation.

After all, given that Active Directory is the foundation of cyber security at over 85% of all business and government organizations across the world today, no one should be surprised by the interest this topic and presentation may have garnered.

For those who may not know this yet, 100% of all major recent cyber security breaches (E.g. Snowden, Target, JP Morgan, Sony, Anthem, the OPM Breach) involved the compromise and misuse of just ONE  Active Directory privileged user account.


However, what surprises me is to see that even cyber security experts don't seem to know much about certain aspects of this critically important area of cyber security. The short of it is that if your Active Directory is compromised, you're proverbially finished, and the easiest way that a perpetrator could use to compromise your Active Directory wasn't even mentioned in this presentation at Black Hat!

Specifically, I don't know what Mr. Sean Metcalf's background is, and perhaps he's an expert at attack vectors involving Kerberos tickets, but I was really surprised to find that in a presentation in August 2015 at Black Hat 2015 USA that is on Modern Day Active Directory Attacks, there is no mention of the #1 of all Active Directory attack vectors that could allow perpetrators to instantly compromise the account of any or all Active Directory Privileged Users without so much so as knowing how to spell the word HASH, let alone capturing a hash, or for that matter obtaining and using Kerberos tickets regardless of their type (Golden/Bronze/Whatever.)

Not ONE mention. Nada. Zero!  Seriously, I'm not sure if its funny or scary.


Perhaps I should share a little something about Active Directory Security for all cyber security professionals out there...

...with the right tooling, ANYONE with access to a domain-joined computer could easily find an Active Directory privilege escalation path leading to virtually any privileged user account of choice, within minutes, and once such a path has been found, with minimal computer security know-how, he/she could gain administrative privilege within minutes, WITHOUT having to go through all the pain involved in sophisticated hash and/or Kerberos ticket capturing/replay/blah-blah attacks.

Unfortunately its too damn easy - http://www.paramountdefenses.com/privileged-access-insight.html

(That attack vector is Active Directory Privilege Escalation based on the identification and exploitation of unauthorized access grants in Active Directory deployments aka "Reset the Password" (RtP).)

Fortunately, its 100% mitigatable.

If you want to see how vulnerable your own domain user account or that of a colleague, such as a Domain Admin is, you can do so, our compliments by using the world's most advanced cyber security penetration testing tool, Gold Finger Mini (Its Free.)

Pass-the-Hash (PtH), Golden Tickets, Silver Tickets etc. etc. are so yesterday and lame.

Alright now, if you'll excuse me, I'll get back to work.

Best wishes,
Sanjay.

PS: A humble word of advice to all Active Directory Security Gurus out there - you may want to ramp up your Active Directory Security skills. Here's a good starting point.

How to Identify & Minimize Privileged Users/Accounts in Active Directory

Folks,

As former Microsoft Program Manager for Active Directory Security, I have shared helpful guidance below on how organizations can correctly and quickly search for and identify privileged users in their Active Directory in a simple 3-step process, and how they can minimize the number of privileged users in their Active Directory deployments, and adequately protect them.

But first, some quick background, below.

• Note 1: If you just want to skip to the technical details, here are direct links that provide step-by-step guidance on how to identify privileged users in Active Directory and how to minimize privileged users in Active Directory environments.


• Note 2: All information (images and content) in this blog entry, including specific guidance, is copyrighted.

White House Orders U.S. Federal Agencies to Minimize Number of Privileged Users

In light of the recent OPM data breach at the U.S. Federal Government, the White House has ordered all U.S. Federal agencies to "tighten policies and practices for privileged users, including minimizing the number of people in this category."

The White House issued this directive because in all likelihood, perpetrators first gained access to a non-privileged domain user account in OPM's Active Directory, then engaged in Active Directory Privilege Escalation to compromise an Active Directory privileged user account, and then used this Active Directory privileged account to gain access to millions of SF-85 & SF-86 forms.

In essence, if the compromise of a single privileged user account can cause such colossal damage, then in order to reduce the attack surface, it is only logical that the  #1 action organizations can take is to minimize the number of privileged user accounts.

However, before an organization can minimize privileged users, it needs to be able to correctly identify them, and accuracy is paramount, because, as the OPM breach has shown,  a perpetrator only needs to compromise one inadequately protected / vulnerable privileged account to inflict colossal damage.

Thus, the step-by-step guidance below is to help organizations correctly identify all privileged users in their Active Directory.




The Entire U.S. Federal Government runs on Active Directory

There are over 600 U.S Federal Agencies in the U.S. Government, and at the foundation of their cyber security lie their Active Directory deployments. For instance, the the U.S. Capitol, the CIA, FBI, DoD, DHS, DoT etc. all run on Active Directory.

Consequently, by privileged users, the White House is technically referring to Active Directory Administrative Accounts, because in Active Directory environments, all privileged users are stored in, managed in and protected by Active Directory.




Active Directory Privileged User Accounts - Holders of  the Proverbial "Keys to the Kingdom"

In Active Directory environments, all privileged accounts are stored in, protected by and managed in the Active Directory itself, and they get their system-wide access privileges by virtue of membership in various Active Directory Administrative Groups.

Thus, technically speaking, all members of all Active Directory Administrative Groups hold the proverbial "Keys to the Kingdom."

Examples of some default Active Directory Administrative Groups include the Administrators (Built-in Admins) group, the Enterprise Admins group, the Domain Admins group, the Server Operators Group, the Account Operators group etc.

Unfortunately, in so many organizations, there is still a misconception that the list of privileged users in Active Directory environments is restricted to those accounts that are members of the Enterprise Admins of the Domain Admins groups.

In reality, the Enterprise Admins and Domain Admins Groups are merely the Tip of the Iceberg.

The complete list of all groups in Active Directory that are privileged/administrative in nature, can be found in the Privileged Access Hierarchy section of the Active Directory Privileged Users reference.





How to Correctly Identify Privileged Users in Active Directory

It is of utmost importance to ensure that every single privileged user account in Active Directory is correctly identified, because as evidenced by the OPM hack, the compromise of a single privileged user account can result in colossal damage.

Complete step-by-step guidance on how to accomplish this objective (i.e. how to correctly identify privileged users in Active Directory) can be found here i.e. at how to identify privileged users in Active Directory. What follows is a shortened reproduction.

In order to correctly identify privileged users in Active Directory, an organization simply needs to identify all Active Directory accounts that fall under three levels of privileged access -

• Level 1 (Immediate Direct Access) - Each Active Directory domain account that is directly or indirectly a member of every group that is listed in (or falls under the criteria of) the Privileged Access Hierarchy

• Level 2 (Immediate Indirect Access) - Each Active Directory domain account that has - 
• i. Sufficient effective permissions to be able to modify the membership of every group that is listed in the Privileged Access Hierarchy.
• ii. Sufficient effective permissions to be able to modify the security permissions protecting every group that is listed in the Privileged Access Hierarchy.

• Level 3 (Non-immediate (30-seconds away) Indirect Access) - For each account identified in Levels 1 and 2 above, identify each Active Directory domain account that has -
• i. Sufficient effective permissions to be able to reset the account's password
• ii. Sufficient effective permissions to be able to set the Password-not-required flag. Alternatively, if smartcards are in use, uncheck the Smart card is required for interactive logon option.
• iii. Sufficient effective permissions to be able to modify the security permissions protecting the account.

Kindly note that it is imperative to ensure that every security group listed in the Privileged Access Hierarchy is taken into account AND that effective permissions are correctly determined on all involved Active Directory administrative accounts and groups.




Three Helpful Tools

As indicated above, it is extremely important to ensure that the list of all privileged users in Active Directory is correctly identified.

The steps outlined above are essential for correctly fulfilling this need. However, they do involve performing advanced analysis (e.g. complete nested group membership enumeration and true effective permissions determination) which can be time-consuming and prone to error when attempted manually on numerous objects.

(Note for advanced IT Pros: PowerShell scripts, LDAP searches based on admincount etc. are not going to be sufficient.)

However, with the right tools, the steps outlined above can be easily accomplished, within a matter of minutes, thus substantially reducing the amount of time and effort involved in the correct identification of privileged user accounts.

Here are three tools that can be very helpful in accomplishing the above steps -

1. Active Directory Group Membership Reporting Tool - Report #2 of this tool View the complete nested group membership of an Active Directory security group can help instantly enumerate the complete membership of any Active Directory group, including all privileged (i.e. administrative) security groups identified in the Privileged Access Hierarchy, as required for the adequate and complete fulfillment of Level 1 requirement above.

2. Active Directory Effective Permissions Calculator - Report #1 of this tool, Who has what Effective Permissions on an Active Directory object can help fulfill the effective permissions/access calculation/audit needs required for Level 2 (i and ii) and Level 3 (i, ii and iii) requirement above, one Active Directory object at a time, on every relevant Active Directory security group and account.

3. Active Directory Administrative Access and Delegation Audit Tool - Multiple reports of this tool can be used to instantly fulfill the effective permissions/access calculation/audit needs required for Level 2 (i and ii) and Level 3 (i, ii and iii) requirement above, on all Active Directory privileged and non-privileged accounts and groups in a single assessment and one mouse-click, in minutes.

In addition, you can always use Report #1 Who can reset my account's password and Report #2 Who can reset a colleague's password of this free tool to instantly identify exactly how many users can reset a specific user's password, including yours, and that of any colleague (e.g. a Domain Admin, an Enterprise Admin, the CIO etc.).




A Real-World Example on the Importance of Levels 2 and 3 Above

The importance of ensuring that all Level 2 and 3 accounts above are identified is perhaps best understood with an example.

Last week one of our Technical Specialists was assisting the Director of IT of a multi-billion dollar organization identify privileged users in their Active Directory deployment, upon their request.

Their chief Network Admin (i.e. an "Enterprise Admin") had reported that the organization only had 7 Enterprise Admin accounts.

However, when together we proceeded to determine effective permissions on the Enterprise Admin security group, we found that 35 additional individuals had the ability to change the membership of the Enterprise Admins group. In other words, the total number of individuals who had Enterprise Admin level access was actually 42 (7 + 35), not 7.

Similarly, when we determined effective permissions/access on that specific Network Admin's account (i.e. the one who was on the call and was an Enterprise Admin), we found that 47 individuals had sufficient effective permissions/access to be able to reset the password of that Network Admin's domain user account. In other words there were at least 47 additional individuals who could instantly (i.e. at the touch of a button) elevate their privilege to be that of an Enterprise Admin if they wanted to.

In this manner, we proceeded to follow the steps outlined above, enumerating all Level 1, 2and 3 users based on the Privilege Access Hierarchy and identified 227 individuals who effectively had privileged (system-wide administrative) access. In contrast, the total number of individuals based solely on the default administrative group memberships was 36.

Thus, by including Levels 1 and 2, they identified 191 additional privileged (system-wide administrative) users in their network.

In each case (group membership change and password reset), these individuals were already sufficiently privileged (i.e. had sufficient delegated administrative access in Active Directory) to be able to elevate their privilege to that of an Enterprise Admin, at a button's touch, i.e. they already had the effective access needed to perform these sensitive tasks.

This real-world example illustrates why it is not sufficient to merely enumerate the number of membership of default Active Directory administrative groups when trying to determine the number of individuals that have privileged access. It is very important, and in fact paramount to ensure that not just Level 1, but also Level 2 and 3 accounts are accurately identified.




A Quick Note on the Importance of Effective Permissions

In the process of identifying Level 2 and Level 3 accounts, you will most likely need to determine effective permissions/access on various accounts and groups, In this regard, I just wanted to add that the importance of determining effective permissions / effective access, and doing so accurately, cannot be overstated. Specifically, here are 3 important aspects to be aware of -

1. It is very important to know that there is a substantial difference between identifying "who has what permissions" and "who has what effective permissions". The two are NOT the same. There is a world of a difference between the two. Merely identifying "who has what permissions" is insufficient and is bound to provide inaccurate and misleading results.
   
   For example, consider a situation wherein a user John Doe, a helpdesk operator may be denied Reset Password permissions via an inherited ACE in the ACL of a Domain Admin's account.
   
   Now, just because there is a permission denying John Doe Reset Password, does not in fact mean that John Doe cannot in fact reset the Domain Admin's account's password. There could be another explicit permission allowing the Outsourced Contractors group All Extended Rights, and assume that the HQ Onsite Contractors is be a member of this group, and finally that John Doe is a member of the HQ Onsite Contractors group. In other words, in addition to there being a direct Deny (inherited) permission for John Doe, there is also an indirect Allow (explicit) permission that applies to John Doe. 
   
   As a result, because an explicit allow permission will always override an inherited deny permission, in effect, John Doe will in fact be able to reset the Domain Admin's password.
   
   As illustrated in this example, if you were merely looking at "Who has what permissions", you would falsely arrive at the conclusion that John Doe cannot reset the Domain Admin's account's password. However if you had been looking for "Who has what effective permissions", you would have rightly arrived at the conclusion that John Doe can in fact reset the Domain Admin's account's password. 

2. If you utilize a tool to determine effective permissions/access in Active Directory, it is of utmost importance to ensure that whatever tool you wish to utilize delivers accurate results and is trustworthy.
   
   Accuracy is paramount because a single inaccuracy can mean the difference between being secure and being vastly vulnerable. As recently brought to our attention by one of our customers, an example of one such tool that is substantially inaccurate can be found here.
   
   Trustworthiness is also very important, because you most likely wouldn't want software written in say Russia or China being run or deployed in your production environment. A few simple questions that you can ask to assess the trustworthiness of any such tool can be found here.



3. If you utilize a tool to determine effective permissions/access in Active Directory, you'll ideally want to use a tool that can accurately identify and reveal the list of all users that have a given effective permission/access combination, as opposed to a tool wherein you need to enter the identity of every user in your domain one user at a time to manually arrive at a list of all the users that have a given specific set of effective permissions on a given object, or on multiple objects. (If your organization has even 1,000 users and computers in its Active Directory forest, you wouldn't want to enter 1,000 names each time you need to determine effective permissions.)

How to Minimize Privileged Users in Active Directory and Adequately Protect Them.

With executive support and trustworthy guidance, organizations can minimize the number of privileged users in Active Directory.

 

To help organizations worldwide reduce the likelihood of a security breach involving the compromise and subsequent misuse of a privileged user account, as well as to help them mitigate the risk posed by Active Directory Privilege Escalation, at Paramount Defenses, we have provided trustworthy guidance on how to minimize privileged users in Active Directory environments, here.

 

 

Additional Information

To help organizations worldwide reduce the likelihood of a security breach involving the compromise and subsequent misuse of a privileged user account, we have also provided valuable information on the impact of compromise of a privileged user, on the attack surface that organizations need to defend, on the attack vectors that are commonly used by perpetrators, and on the various sources of threat, including insiders and APTs, as well as on Active Directory Security.

You are welcome to use this information towards evaluating and enhancing your organizations security posture. Start here.



Summary

As evidenced by the OPM breach, the compromise of a single privileged user account can result in colossal damage. In order to reduce risk, it is thus of utmost importance that organizations correctly identify all existing privileged users in their Active Directory, quickly minimize this number down to a bare minimum, and adequately protect them. The guidance provided above is designed to help organizations accomplish this objective quickly and reliably.


Should you have any questions or thoughts, feel free to leave a comment. I will do my best to answer them, time permitting.


Best wishes,
Sanjay

PS: Standard disclaimer: The use of any information provided above is subject to the disclaimer provided on this page.

PS2: Incidentally, if you liked this, I think you'll like this too.