URL Check

This option combines the HTTP Headers, IP Geo Location, Ping, Trace Route, WhoIs - Name and WhoIs - IP results in a tabbed view, allowing you to collect and dispaly all the necessary information for a domain or website in a single view.

The results displayed are the same as the individual options.  The result are based on the configuration set on each of the individual options.

HTTP Headers

the HTTP Headers option is used to display the HTTP headers that are returned by website. This provides the ability to check the security settings you have defined on your website.  It also includes an option to Allow Redirects, when this option is not selected, any redirect request is ignore and the original header displayed.  When enabled it will display the final redirection header for the website.

Common examples are websites redirecting the standard to or


The WhoIs option will query the WhoIs servers and return the details of registered name or IP address.  If the Show Referrals option is enable, if a referral is returned, then it will query the returned referral server for the information.

This function using the server for name lookups, and for IP address lookups.  It uses the original RFC services on port 43, some proxy implementation may block this port, in which case NetTools will report a 10060 error.


The Ping option provides a simple and configurable ICMP echo function to ping one or more host simultaneously.  The configuration options include the number of pings to be sent controlled by the Count field, the delay between each ping set by the Delay field and in case of a slow or failed response, how long to wait before continuing, set by the Timeout field.

To add a single host use the Add Entry option on the context menu, if you want to test more than one, copy and paste a list of IP address or name into the pane.

When the Go button is pressed all the hosted are test simultaneously., the passed\failed column will display a indicator to show if the test passed or failed.

IP GEO Location

This option uses the web API services provided by to display the IP geo location information about a specified IP address or name.  The API has usage limits, if you exceed the usage limit of 45 requests per minute you will be block, repeatedly exceeding the limit could see you blocked for up to an hour.

The API provides a basic set of information for the IP address.

Trace Route

The Trace Route option provides the fastest possible trace route function.  Like other Trace Route commands it will report the devices that are transversed with each hop until it to get the final host, and the time taken to get to each hop, with timing based on a user definable number of ICMP pings.  The main difference with this implementation of trace route, is that it doesn't test each hops sequentially, waiting for the previous hop to be tested before moving onto the next hop.  All hops in the route are tested simultaneously, the results are displayed in seconds, rather than minutes.  The number of hops that are tested simultaneously is defined by the Hops field and number of ICMP echo to be preformed is controlled by the Count field, NetTools will attempt to resolve the names of each hops if the Resolve Names option is selected.

In the default configuration, just the host name, either short name, FQDN, or IP and click Go and the results will be displayed.


Trace Route

Compare Objects

The Compare Objects option provides the ability to compare two different objects or view the changes that have been made to a single object.  Once the objects have been compared, there is an option to filter the attributes to only display attributes based on the compare results.

Attributes that have multiple values, have an expand option next to them, when the attribute is expanded, each value in the attribute is compared against the right side attribute and results are display.  

Clicking on the compare icon column header, the one between the left and right values, will display the filter options, selecting one of the filter options will result in only the attributes that match the selected filter being displayed.

Note: with a filter selected, when expanding an attribute, only the value that match the filter will be displayed.

The Compare Options are:

Show All -  all results will be displayed
Don't Match - display only the results that doesn't match
Equal - Only display values that match
Not Equal - Only display values that don't match
Only Left Value Exists - Only display values where the left object has value, while the right object is not set
Only Right Value Exists - Only display values where the left object is not, while the right object has a value
Neither Side Set - Only display values, when neither side has a value set

There are a number of additional right click context menus that provide additional functionality

      • Clear Values -  will clear the attribute cache and the display
      • Hold Left Values - causes the left object's values to be held and when a compare is performed again, the left object's attributes are not update and the previously read values are used
      • Load Values - this option will load a previously saved set of attributes and values.  You can only load the saved attributes and values into the left object
      • Save Values - based on the user selection, either the left or right, the selected object's attributes and values are saved to a file and which can then be reloaded at a later date
      • Compare Values - displays a side by side comparison of the values and highlights the differences.  See section below for more details

When the left object attributes are held, the text in the DN field turns red, to indicate that the left object values are held.

The default operational behavior of the the compare, is to read the attributes for both objects from the directory before making the compare, however, this behavior changes under the following scenarios:

      • If the left and right object DNs are the same - when the first compare is run, the attributes for both the left and right are populated, however on subsequent compares, if the DNs doesn't change, only the attributes and values of the right object are updated fro the directory and then compared against the previous read attributes and values of the left object
      • If the Hold Left Values context menu is selected, the attributes and values of the left object are held and are not updated on subsequent  running of the compare, until either, the left object DN is changed or the values are cleared
      • If previously saved attributes and values are loaded on the left side

The Compare Values context menu option provides the ability to display the values side by side and the differences between the two values is highlighted.  The Compare Values option supports a number of different compare options. the default option is to double click on an attribute and the Compare Values dialog is displayed with the comparison.  The comparison can also be across two different attributes, or two attributes on the same object.  If two attributes are selected, then left and right values of these attributes are then compared.   When two attributes are selected, there is additional logic used to selected the left and right values to be compared.  

This the logic uses determine which value is used for the comparison. The default logic is that the first item selected is used for the left value, the next is the right value.  However, if the first item doesn't have a left value but has a right value, then the second item is used for the left and first item is used for the right.  If both the selected items don't have left values, then the right value from the first item is used for the left value, this allows attributes in the same object to be compared.  If both the selected items don't have right values, then the left value of the second item is used for the right., this allows attributes in the same object to be compared.   

The default behavior of the compare is to reread the attributes directly from the source objects, so in some case, the result could be different from the results that are displayed when the Compare was first run and results displayed because the attributes have changed.  The Compare Values option has to read directly from the source objects, as a result when the Load Values or Hold Left Values options has been used, the Compare Values option is not available, until the Clear Values option is selected. 

Note: You can't compare the parent item of multi-value items, you must expand the parent item and then compare the members. 

NetTools v1.27.0

Compare Objects  *** New ***
A new option to provide the ability to compare two object, or the changes that have been made on a single object based on a previous snapshot. See Compare Objects

LDAP Browser  *** New ***
I've copied the LDAP Browser feature from the LDAP Search option and now added it as it own item in the left hand pane. See LDAP Browser

AD Properties Dialog
Updated to display AES128 and AES256 encryption options

Attribute Replication
Added option to check attribute replication for objects in the the global catalog context

Find Trustee
Fixed intermittent exception error when checking for ownership permissions

LDAP Search
Added a tab output option, so results from each query is displayed on a new tab
Added enum decodes for msDs-SupportedEncryptionTypes
Updated the conditional attributes function so that meta data information is supported for both variable and results.
    e.g.   Validate;{if: meta.time.unicodepwd == pwdlastset : "Valid" : "Error"}

HowTo: 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 at 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

HowTo: Find Active Accounts

Finding which accounts are active should be simple, however, there are numerous ways to define if an account is active or not.  There is the simple method of checking if the accounts are enable or not, however, things get more complicated quickly after that, i.e. when was the account last used, has the account expired, has the account ever been used.

This article provides a number of sample LDAP queries that can be used to determine if accounts are active or not, or you can combine these queries to generate a more complex query to meet your requirements.  The first part of the article shows fragment of the query and the last section shows how to combine these to create the final query.

Account Enabled
With AD an account is active based on a value stored in UserAccountControl attribute, however, the attribute uses bit logic to represent a number of different values, so you can't check for a specific value.  Details of the attribute can be here. The second bit of the UserAccountControl indicates if the account is enabled or not,  when not set (0) the account is active, when set (2) the account is disabled.  Using Matching Rule OID we can check the status of the individual bits in the attribute.  i.e. (useraccountcontrol:1.2.840.113556.1.4.802:=2).  The NetTools substitutions simplifies the entry of matching rules with a single character. See Substitutions.

Account is disabled          (useraccountcontrol|=2)    
Account is enabled           (!useraccountcontrol|=2)

Account Expired
Accounts can be set to automatically expire after a specified date, after which point the user will no longer be able to logon.  The date is stored in the AccountExpires attribute, this attribute uses a 64 bit integer to store the date.  To add to the complexity the attribute can contain more than just a date, it might not be set, or contains a 0 (zero), or 9223372036854775807 then account is not set to expire.  So a query check for expiry has to check for all the possible values to confirm if the account is active or not. Again the use of substitutions can simplify the entry of the Int64 date. 

Account Expired            (&(!accountExpires={-1:})(!accountExpires=0)(accountExpires<={idate:now})) 
Account not Expired     (|(!accountExpires=*)(accountExpires={-1:})(accountExpires=0)(accountExpires>={idate:now}))  

Last Logon
Most account audits state that if an account has not been used to a set period of time, the account should be consider inactive.  The last time the user logs on is stored in the LastLogon attribute, however this attribute is not replicated between domain controllers, so using this attribute you have to collect the LastLogon attribute from all domain controllers to determine the last logon.  There is another attribute that is replicated between domain controllers called LastLogonTimeStamp, however this attribute has a specific replication cycle which means that it may not contain the most recent logon date (more details here), but is usually close enough for most cases.  Again this attribute uses a 64 bit integer to store the date.

Not logged on for 60 days        (lastlogontimestamp<={idate:now-60})
Logged on in the last 30 days   (lastlogontimestamp>={idate:now-30})

Password Changes
In some cases the logonTime or the LastLogonTimeStamp will not be updated when a users logs on, these are normally associated to LDAP Simple binds or access through SharePoint.  another method to determine if an account is still being used to check the last time the user's password was changed, this assumes that an account password expires.

Password change in the last 60 days     (pwdlastset>={idate:now-60})

Unused New Accounts
In this scenario an account is created but has not used since it was created.  The queries that is used to find these accounts depends on user provisioning process and which query should be used, if the user is required to change their password at first logon (scenario 1), or not (scenario 2).  If the user is required to change their password, then we check to see when the password was changed, if not, we check if the lastlogontimestamp has been set.

Scenario 1
Not used in the last 60 days            (&(whencreated>={zdate:now-60})(pwdlastset=0))
has been used in the last 60 days    (&(whencreated>={zdate:now-60})(pwdlastset>={idate:now-60}))

Scenario 2
Not used in the last 60 days                          (&(whencreated>={zdate:now-60})(!lastlogontimestamp=*))
Created in the last 60 days and been used    (&(whencreated>={zdate:now-60})(lastlogontimestamp=*))

Type of Accounts and indices
When creating queries it's best to create a query that limits the number of object that need to be searched and the number of attributes that are returned.  Building a query using attributes that are indexed will increase the performance of the query, reduce the load on the server executing the query, and reduce the amount of network traffic generated (See this Microsoft article for details). Some of the queries shown above use attributes that are not indexed, so using these queries in the format show could be very inefficient.  Limiting the queries to only search for specific object types will significantly increase the performance of the query, i.e only look at user account or computer accounts and the more indices that are used the better. 

Users account               (&(objectCategory=user)(&objectclass=user))
Computer Accounts      (&(objectCategory=computer)(&(objectclass=computer))

Combined Queries
This section shows a number of the above query fragments combination to create the full query:

Find active user accounts:

Find disabled user accounts

Find active accounts, that have not expired

Find all inactive accounts, including expired, password not changed or logon in the last 60 days
(&(objectCategory=user)(objectclass=user) (!useraccountcontrol|=2)(lastlogontimestamp<={idate:now-60})(pwdlastset>={idate:now-60})(&(!accountExpires={-1:})(!accountExpires=0)(accountExpires<={idate:now})))

See Favorites for more examples