Category Archives: HowTo

How To Display the Meta Data of an AD object

In this post we look at how to use NetTools to display the replication meta data of an AD object.

Displaying the replication meta data of an AD object is a core capability, and it is available as a context menu item throughout NetTools.  See Basics and Meta Data Dialog for more details.

In this post we will look at the two most common scenario, searching and browsing for objects that you want to view the replication meta data.


The search option is best for common AD objects such as users, groups, computers, etc, that are in the default domain context, If you want to view the meta data information for an object that is in the schema, configuration, DNS, or AD LDS (ADAM) partitions, use the browse method below.

To search for an object we can use the quick search field on the toolbar at the top of NetTools.  In the field enter the name of the object you are want to find and click the search button.

In this case we are search for the computer object for w2k19.  The Search screen will be displayed with the results of the search.

Search Results

If you right click on the required item and select the Meta Data menu items, the Meta Data dialog will be displayed.

Meta Data Menu
Meta Data Dialog

For more details on the Search option see User Search

Browsing Method

The advantage of using the browse method, is it allows you to display the meta data for objects that are not in default domain context and wouldn't be found by the search method.  You can browser the required name context, configuration, schema and DNS, or AD LDS (ADAM) partitions.  To use the browse method you need to select the LDAP Browser option under LDAP in the left hand option selection pane.

LDAP Browser

Selecting the required partition from the drop down list in the DN field.

Select partition

You can select one of the root of the partition from the drop down list, or enter the required DN in the field, then click Go.  The view will be populated and you can browse the partition to find your object. You can right click the object in the navigate tree or the list view and select the Meta Data menu item to display the Meta Data of the selected object.

LDPA Browser - Meta Data Menu

This will show the replication Meta Data dialog.

Meta Data Dialog

For more details on the LDAP Browser option see LDAP Browser

How To Troubleshot which GPOs have been applied

Sometime is not immediately obvious where to start when troubleshooting GPO delivery issues.  NetTools provides a number of features that will let confirm the GPO configuration and then verify which GPOs have been applied to the computer and user by reading the results directly from the machine.

To start troubleshooting we need to find the computer in the Active Directory and confirm which GPO will be applied to the machines.  In the quick search box enter the name of the computer that you want to troubleshoot.

Quick Search

In this case we are searching for the W2k19 which is a domain controller, click on the search button.

Search Results

The search results will show all objects that match the search name.  Now if we right click on the required item and select Use With->GPO Allocation from the context menu.

GPO Allocation Menu

The view will change to the GPO Explorer and automatically navigate to the OU that contains the computer object.  It will also display which GPOs have been assigned to the OU.  In this view you can confirm which policies have the links enabled and any WMI filters that have been applied.

GPOs Applied

By clicking a policy the details of the policy are displayed in a split screen, so you can review the settings or configuration without leaving the OU view.  While here check the version numbers of policy on the general tab, if the version number is zero, the policy will not apply as the policy engine will think its empty.


The Inherited Policies tab will show which policies have been inherited down the OU structure and the order in which the policies will be applied. This view also supports the split view capability.  Confirm that the policy you are troubleshooting is listed.

Now if we select the Content tab the list of object that are in the OU are displayed. If there is more than 2000 objects in the OU, you will need to adjust the max entries field to display more.

Find your machine in the list and click on the machines and select GPO Results from the context menu.

GPO Results

This will open a separate window and display what policies have been applied to the machine.  The icons indicate if the policy was successfully applied to the machine or not.  Policies that were successfully applied will have a green indicator, while policies that failed to be applied will have a red indicator.  If you expand the policy item in the list the details why the policy failed to apply will be displayed, items that red indicator that is the reason why the policy was not applied.

For the GPO Results to be displayed the machine must be on and connected to the network.

GPO Results

Once the GPO Result window is populated, using the Quick Search field on the main form, you can now search for the user and repeat the steps to see the GPO Allocation for the user object.  You can to expand the users policies tree in the GPO Results window to see which policies were applied to the user.

For more details on the information displayed in the GPO Results window see the GPO Viewer page

How To: Display what members were removed from a group

Features shown are only available in NetTools v1.29.11 or later

In this post we look at how to show which members, i.e. users, computers, groups etc, have been removed from a group.  Within NetTools this is a simple task using the AD Properties dialog, the Members tab shows the current members of the group and also which objects have been removed and when, as shown in the screenshot below.

To understand how NetTools is able to display this information, we need to look at the msDS-ReplValueMetaData attribute for the group. This attribute contains the details of the metadata for each value of an attribute for the object. We can view the details of the attribute in the Meta Data dialog, which can be opened from the AD Properties dialog using the Meta Data button or from the various context menus within Nettools.

Here is the Meta Data dialog for the same group shown above, the top section of the dialog shows the details of the msDS-ReplAttributeMetaData attribute used to store the replication details for the attributes of the object, the lower section shows the meta data details from the msDS-ReplValueMetaData attribute showing the replicated values for attributes that have Object (DN-DN) data types, i.e. member.

In this example you can see the list of changes that have be made to the member’s attribute of the object, each change to the member attribute is listed as a separate line, the line includes a Originated, Create and Delete time columns.  The Create and Delete columns are used to record when an item was added or removed from the attribute.  When an item is added, only the created time is populated, and then when the item is subsequentially removed both the create and delete times are set. The created time still exists to ensure that the AD replication is consistent.  NetTools AD Properties dialog will enumerate the msDS-ReplValueMetaData entries and display the entries that have the deleted time set in the Removals section of the Member tab.

Also See:
NetTools Basics
NetTools AD Properties Dialog
How Group Changes Works
Display when members were added or removed from a group

How To: Dump the Active Directory Database

Sometimes when troubleshooting it could be useful to dump the contents of the AD database, this can then be used to confirm an object exists, or to retrieve the DNT of an object, which will enable other troubleshooting activities, or just being a bit geeky and wanting to look under the hood.

In this post we will be looking at the RootDSE Modify Operations.  There are a number of RootDSE Modify Operations that are available which provide advanced operations on the domain controllers.  The full list of available modifiers is available here.

We will be looking at the DumpDatabase operator which allows us to dump the contents of the AD to a single text file.  The dump file will be written to the NTDS folder on the domain controller.  By default this is %systemroot%\NTDS with the file name of NTDS.dmp.

Note: as this is going to dump every object in the AD database, make sure you have sufficient space available on the volume hosting the NTDS directory on the selected domain controller before running this query.

By default the dump file contains the following fields:


We can also specify additional attributes to be included in the dump file, however some security sensitive fields can't be included i.e. passwords.  We are going to use one of the NetTools predefined queries to complete this task.  This task can be completed on the domain controller itself or executed remotely, you just need domain admin rights on the domain controller to run the query. 

In NetTools select the LDAP Search option in the left hand pane under the LDAP section

As the AD database dump query is an update query we need to complete a few extra steps to run the query:

      1. Click on the Populate button
      2. Select the AD: RootDSE Modify - Dump Database from the list of Favorites
      3. Click on the More button to display the more options
      4. Uncheck the Preview option
      5. Click Go
      6. Confirm that you want to run the query

Once the query is complete the ntds.dmp will be created in the NTDS directory on the domain controller specified in the Server field. The query is configured to include the description and cn attributes in the dump file, you can specify additional attributes if required, the entry in the speech marks on the Attributes field needs to be updated with a space-separated list of attributes.  If a security sensitive attribute is specified the dump file will contain an error message that the attribute was not found.   

One of the limitations of the database dump, is that it will limit the number of characters that are returned per field, so if you are trying to dump the contents of a long binary field i.e. NTSecurityDescriptor the field will be truncated.

Here is a sample of the database dump: 

How To: Retrieve BitLocker Passwords

If you have configured BitLocker to store the recovery keys in AD, you can use NetTools to retrieve the BitLocker Recovery Key.  With NetTools the process to retrieve the recovery key is really simple.

Select the User - Search option in the left hand pane and make sure that the Return Users Only is deselected, and then complete the following steps:

  1. Enter the name of the computer
  2. Click Go
  3. Open the AD Properties for the computer

Select the BitLocker tab

Select the Recovery Key ID that is displayed on the BitLocker Recovery screen

Note: the BitLocker tab will only be displayed if msFVE-RecoveryInformation object exist on the computer object and you have the rights to read the object 

How To: Retrieving gMSA Password Details

Group Managed Service Account provide accounts that automatically manage password changes, for more details see this article.

This article covers how to use NetTools to view the details of the Group Managed Service Accounts (gMSA) and also view the current and previous password for the accounts.  The gMSAs are stored in the domain partition in the Managed Service Accounts OU.   The Easiest way to retrieve the password is to use the AD Properties dialog, which allows you to copy the password to the clipboard, however to be able to view the password the account retrieving the password must be specified in the msDS-GroupMSAMembership attrtibute of the Group Managed Service Account.

The details in the Password section of the dialog are stored in the msDS-ManagedPassword and msDS-ManagedPasswordId attributes of the object, these can be returned in LDAP Search, however, it does require a specific setup of LDAP Search to return the details as they are protected attributes.

If you create a basic LDAP query you will receive the following error:

In order to retrieve the password details the connection must be encrypted for the attribute details to be return. To encrypt the connection you must use the LDAP Session Options to enable encryption.  The screenshot below shows the steps to complete the configuration.

  1. Click on the Session Options buttons at the end of the server field
  2. Check the tick box for the LDAP_OPT_ENCRYPT option
  3. Double click on the item to configure the option
  4. Change the setting to On and click OK and close the Session Options dialog

Once the Session Option are configured and encryption is enabled on the connection the details of the attribute are returned.

How To: Troubleshoot AD LDAPS Connection Issues

In this article we cover how to troubleshoot bind issues when connecting to Active Directory using LDAPS.  Typically when a LDAPS connection fails, very little information is provided on the reason for the failure. We will look at using NetTools to help troubleshoot the bind process and identify the reason for the LDAPS bind failure.

There are a few troubleshooting options available, including bypassing the standard certificate revocation process, display the certificate chain with the details of the revocation process and finally displaying the certificate that is installed on the servers used for the connection.

We will use the LDAP Search option in NetTools to test the LDAPS connection. For details on the SSL option see here.

Troubleshooting Steps

    Check a Certificate is Installed

    First, we want to confirm that there is a certificate installed on the domain controller and its being used for the LDAPS.  These tests can be performed remotely or on the domain controller being tested.

    In the server field enter the FQDN of the domain controller, and then select the SSL Bind option, port 636 will be appended to the end of the server name, you will then need to uncheck the Verify Certs and click Go.

    If the connection works and there are no bind errors are returned, then a certificate is installed on the domain controller and Active Directory is using it for LDAPS.

    If you do receive a connection failure error:

    Here are a few checks to determine why the certificate is not being used.

        • Check name resolution and the FQDN can be resolved, see DsGetDCName
        • Use the DC Resolution feature to confirm the port is not blocked
        • On the domain controller check the Directory Services eventlog for event id 1220, Source: ActiveDirectory_DomainService, which means that AD was unable to find a suitable certificate to use.
        • To confirm that a certificate is available, open MMC on the domain controller and add the Certificates snap-in, select Service Account and select Active Directory Domain Services. Check under the NTDS\Personal, Certificates and confirm that a certificate is listed.
        • If the certificate exists:
              • Check the certificate has the private key
              • Confirm that the Enhanced Key Usage includes Server Authentication (
              • Open the certificate and confirm on the Certification Path tab that the certificate is trusted
        • If no certificate is listed, check your certificate delivery mechanism, or manually install a suitable certificate.

    Verify the Certificate

    If the first test worked, then we now repeat the test but with the Verify Certs option selected, this time the standard Windows certificate revocation process will check the certificate, if this fails, then the connection will also fail. Select Verify Certs and click Go.

    2020-08-30 21_56_43- - Remote Desktop Connection

    If you receive the following error, Error: ldap_sslinit failed with error: Error: (0x51) Cannot contact the LDAP server, then the Windows revocation process has identified an issue with the certificate and this has caused the connection to fail.

    Common Certificate Issues

    To help identify what has caused the issue with the certificate, if we select the select the Display Results option, which will display the results of certificate revocation process.

    2020-09-01 12_52_48- - Remote Desktop Connection

    Here are a couple of common examples of the errors that can occur.  In these examples the test domain controller has a self-signed certificate and means only one certificate is shown in the certificate chain in the examples.  If your domain controller has a certificate that has been issued by a root CA or an intermediate CA, your certificate chain will have multiple certificates, in this case each of these would be display and tested.  At the end of the certificate chain output if an issue has been found, an ERR: message will be displayed.

    FQDN of the server doesn’t match the certificate

    In this example the server name that has been entered does not match the subject or SAN, in the output the subject and SAN are displayed and an ERR message is returned stating that Certificate name does not match the host name

    Multiple Certificate Errors

    In this example the certificate chain has three errors: 1- the certificate has expired, 2 – the certificate is not trusted, 3 – the entered server name does not match the subject or SAN in the certificate

    This is output for a certificate that has passed the certificate revocation process

    Display the Certificate

    We also have the option to display the certificate in the normal Certificate dialog, by selecting the Display Cert option, the certificate will be displayed, and we can look at the additional properties of the certificate. NetTools will pause until the certificate dialog is closed.

    In the dialog you can also confirm that the certificate is trusted by the local machine by viewing the Certification Path tab.

    During a logon attempt, the user’s security context accumulated too many security IDs.

    This error occurs when the user's access token exceeds 1015 entries, and at which point the user is blocked from logging on with the above error.  The user’s access token contains an entry for each group the user is a member of, either directly or through nested groups. On top of the entries that are added by group membership, a number of additional entries are added by the system.

    There are a number of reasons that can cause this issue, the two most common are nested groups and migration or more specifically the use of SID History. 

    A complex nested group configuration can cause the number of groups assigned to the increase very quickly.  Due to the nesting, the user could only be a member of handful of groups but due to the nesting the actual number of SIDs in the user’s access token can exceed 1015 entries.  

    The other common cause of this issue is a domain migration using SID History, when SID History is used the user’s access token can double in size, so a user who’s access token contains only 600 groups before migration, it can exceed the 1015 limit post migration, preventing the user from logging on.

    The Token Size option in NetTools allows you to scan domain and report the number of SIDs in the user’s access token. See Token Size.  This report can be tailored to report on specific objects, i.e. trying to find groups that have a high number of nested groups.

    The screenshot below shows that Aaron's access token has exceed the 1015 limit and will not be able to log on. While Abby has only 1006 SID in her access token, and it will depend on the number of additional SIDs that are added to her access token by the workstation when she logs on, which will determine if she will see the error or not.

    Bree from the screenshot above, is shown as having 405 SIDs in her access token, looking at the memberof details of her account it shows that she is only a member of 4 groups, nearly all the SIDs are coming from nested groups.

    If we use the Display SID Inheritance option from the context menu on her account in the list, we can see the high SID count is a result of Group4 and Group5, both of which have 200 nested groups.  Obviously this is a test environment and in a production environment the number of groups and their distribution will be different, but from the Token Size List dialog we can see which groups are causing the problem, we can also drill down further by double clicking on an entry in the list, which will display the SID Inheritance for that item, in this case Group5.

    Another method to see the nested group membership for a user is to use the Group Inheritance option,  The simplest way to access this option is to use the Resolver window.  For the selected object in the list, select the Add to Resolver from the content menu, this will display the Resolver window and add the user we are interested in.

    Once added to the Resolver window select Use With -> Group Inheritance ->MemberOf from the context menu

    This will display the nested groups details in a tree view to allow you to see visually the nested group membership.

    So this has shown you how you can identify which groups have caused the problem, but unfortunately there is no magic fix, in the case of nested groups, you will just need to reduce the number of groups in the user access token, this could be as simple as removing some of the groups that are no longer needed or could require a complete redesign of your groups and resource allocation. 

    In the case of SID history causing the token bloat, the only way to resolve this one is to remove the SID History from the domain, and manage the resulting cleanup, as SID History normally still exists post migration because someone was too scared to remove it.

    How To: Retrieve LAPS Password

    Local Administrator Password Solution (LAPS) is a Microsoft component that provides automatic management of the local administrator passwords on domain joined machines, details on LAPS can be found here

    In this article we will show how to use NetTools to display the password that LAPS has assigned to the local administrator account on workstations or servers. With NetTools it is very simple to retrieve the LAPS password, from the Users - Search enter the name of the machine of which you want to retrieve the LAPS password, make sure that the Return Users Only option is deselected and click Go.

    In the dialog select the LAPS tab.

    Note: the LAPS tab will only be displayed if the computer object has a password set and you have rights to read the ms-Mcs-AdmPwd attribute.

    How To: Check that a user has actually changed their password

    This is in response to a query raised on maillist about how to check if a user has actually changed their password and not just toggled the pwdlastset attribute to make it look like they have changed their password.   When a user changes their password a number of attributes are updated as a result of the password change, these include dbcspwd, lmpwdhistory, ntpwdhistory, pwdlastset, supplementalcredentials, and unicodepwd.  To be able to determine if the password has actually been changed, we have to look at the meta data for the object and check the last change date of the unicodepwd attribute, which contains the hash of the user’s password. 

    NetTools provides a couple of ways to view the meta data of an object, via Meta data dialog, running an LDAP query, or in this use case the Last Logon, will display all the details required.

    For a single user the Last Logon option will display both the pwdlastset and change date for the unicodepwd in the meta time column. This screenshot shows the results of a normal account password change, both the pwdlastset and meta time are the same.

    For this user the pwdlastset has been toggled, and it shows that the pwdlastset and meta data times don't match

    You can view the meta data on an object via the Meta Data Dialog, this option is provided throughout NetTools as a context menu option called Meta Data.  The easiest place to demonstrate this on the User Search option, search the account in question and then right click on the user and select Meta Data from the right click context menu.

    This shows an account that has had it's password changed. 

    This shows that the pwdlastset has changed but the other attributes have not changed, which is caused by the pwdlastset being toggled.

    The above options are for single accounts, but it is also possible in to check multiple accounts at once.  The LDAP Search option includes an option to return meta data as if it's an attribute of the object.  This is done using the meta option in the attributes field.  We can use an Input Mode of the LDAP Search to provide a list of the samaccountnames to check.

    In this example we are checking the details of the five user accounts, and it shows that user1 meta data doesn't match the pwdlastset date and time.

    Here is the favorite for the above query, see Favorites on how to import 

    [PwdLastSet Meta Data]
    Attributes=meta.time.unicodepwd, pwdlastset

    With the introduction of v1.27, there is new query option that can be used to simplify this task.  In v1.27 the conditional attributes have been extended to support meta data queries.  This means we can do the checking in the query itself without any additional post query work.

    [PwdLastSet Meta Data] 
    Server= BaseDN=##default 
    Attributes=samaccountname, Pwd_Change;{if:meta.time.unicodepwd;date!=pwdlastset:"Invalid":"Valid"} 


    Related Articles
    User Search
    LDAP Search
    LDAP Search Input Mode
    Meta Data Dialog
    Troubleshoot account lockouts