Connection Profiles

By default NetTools will use the domain the workstation is joined to define the AD it talks to and the user context that NetTools is executed under to provide the credentials used to access the AD.  In most case this is sufficient, however, there are a number of scenario where you might want to connect to different AD or use a different set of credentials, Connection Profiles provide this ability.  

Multiple Connection Profiles can be defined, that can be used to select different domains, specify the domain controller, different credentials, different authentication method, AD paging and page size, or SSL binds.  Once Connection Profiles are defined they can be selected on per feature basis or a Connection Profile can be set as default and that Connection Profile will be used if no server or profile is selected.

If no profiles are defined then NetTools will continue to use the default domain of the workstation and credentials of the user context executing NetTools when connecting the AD.

The Connection Profiles dialog is access via the toolbar:

This is the Connection Profiles dialog

New profiles are created click on the New button, you will be prompted to enter a name for the new profile.  Once a profile is selected the Server and Credentials options will be enabled.
The Remove button will delete the selected profile.
The Default button is used to the selected which profile will be used by default if the Server field on the NetTools test\option is left blank.  If the selected profile is already set to be the default profile, clicking Default again will be cleared as the default.
The Clear Credentials button is used to clear cached passwords, and when a profiles that prompts for a password is used, you will be prompted to provide the password.
The Save button is used to save any changes made to the profile, if you forget to save changes when changing between profiles or closing the dialog you will be prompted to save your changes.

The Server tab defines the connection details to the AD and the connection type to be used. 

The Server field specifies the name of the server that NetTools will connect to.  If the AD being accessed is the same AD as the workstation is joined to, this can be blank and NetTools will use the default AD name resolution to find a domain controller. Or it can be the FQDN of the AD domain and forest, and as a long as name  can be resolved, it will connect.
By default the Port is set to 389, this can be changed to reflect the requirements of the AD, AD LDS or LDAP directory you are connecting to. 
The SSL Bind specifies if the connection will use SSL encryption for the traffic, when SSL Bind is selected the Port will automatically change to 636, however, this can be changed if required.
The Verify Certificate option defines if the server certificate that is used during the bind is validated or not, with this option selected the certificate is validated by the default Microsoft revocation process.  When this option is not selected the certificate is not verified and the certificate is accept without any form of validation, and a certificate with issues will also be accepted. 
The Paging option define if the paging server side control is used when performing queries against the AD. If this option is not selected then the number of items returned will be limited to MaxPageSize entry as defined the Query Policy applied to the domain controller. The Page Size defines the number of records that will be returned in each page request.  It's recommended to leave Paging enabled when connecting to Microsoft AD or AD LDS directories.

The Bind Type specifies the bind method and if credentials are required.
The Current user's credentials option will use the LDAP_AUTH_NEGOTIATE authentication method and the current credentials used to execute NetTools. 
The Bind with Credentials option will bind with the LDAP_AUTH_NEGOTIATE authentication method and use the credentials provided in the Credentials section
The Advanced Bind type option allow you to specify the bind\authentication method that will be used when connecting to the directory.  The available bind types are listed below, some of which may require additional security packages to be installed for them to be used:

LDAP_AUTH_SIMPLE this method requires the DN of the account and password, domain is not required
LDAP_AUTH_DIGEST Digest authentication package
LDAP_AUTH_DPA Distributed password authentication. Used by Microsoft Membership System
LDAP_AUTH_MSN Microsoft Network Authentication Service
LDAP_AUTH_NTLM this method uses NTLM to authenticate against the directory
LDAP_AUTH_SICILY covers package negotiation to MSN servers
LDAP_AUTH_DIGEST this method requires the samaccountname and password
LDAP_AUTH_NEGOTIATE this method requires either, samaccountname or UPN and password, the domain is optional
ANONYMOUS the username and password are not required

The Credentials options are enabled based on the Bind Type selection and provide the ability to specify different Credentials.


NetTools doesn't save passwords to permanent storage, they are only cached in memory for the duration that NetTools is running.  In the Connection Profiles, there is no option to enter the password, if a password is required then the Prompt for Password option must be selected.  Then when the profile is used and a password is required, you will be prompted to provide the password (the dialog below will be displayed).  The password provided is encrypted and stored in memory and the cached password will be used if the profile is used again.  If the password entered causes an invalid credential error when connecting to the server, the cached password is cleared and you will be prompted to enter the password again the next time the profile is used.

When a profile is changed and saved, the cached password associated to the profile is cleared and you will be prompted for the password when the profile is next used.

You can use the Clear Credentials button to clear the password associated to all profiles.

Using Connection Profiles

Once the Connection Profiles have been created, you can select the required profile from the server or domain field dropdown lists on each of the NetTools Options.  The servers or domains that have been saved are displayed first, then under the Profiles tag, the list of profiles are displayed.  If default profile has been setup, then if the server field is left blank then the default profile will be used.  In the screenshot below the Profiles: New, Test, admin, and local are displayed.

The following NetTools options do not uses Connection Profiles:

        • DsGetDcName
        • NetGetDcName
        • LDAP Ping
        • LSA Trust


This is a simple logon test using the LogonUser API to test if a set of credentials are valid.  If the logon is successful then the account's groups and privileges are displayed.  There are number of options to select the type of logon to be performed, this can be used to confirm that user rights have been configured correctly on the local computer.

Logon - Groups
Logon - Privileges

Token Size

This option shows an indicative number of SIDs that will be added to a user's or computer's access token when they authenticate against the the domain. The Base DN defined the start point for the search, if left blank, the entire directory is searched.  There are also a number of options that can be used to limit the items that are returned, by default only the the top 100 entries are displayed, however this can be changed.

Limiting the search to only Groups is a method to determine if there are any groups which have a high number of nested groups, which could impact the size of a user's access token if users are added to the group.

The size column is for reference only, this is the size of the data returned by TokenGroups attribute for the corresponding object, while it can be used as an indication of the resulting token size it is not exact, see the Microsoft article for the formula for calculating the token size.

The right click context menu provides a number of options to investigate the token size further, the Display SID Inheritance option allows you to drill down into the access token to see which items are causing the token bloat.

Background: Windows use a buffer to hold the user's access access token, the size of this buffer varies in size between different versions of Windows, see:  While you can increase the size of the token supported by the OS, there is no way to increase the maximum size supported by IIS prior to version 6.  User who is a member of 100+ groups thy may experience intermittent access to resources, over 300 they will have IIS\Sharepoint issues, over 1015 and the user will not be able to logon.  The use of SID History for migration or consolidations only makes the token size issue worse.  This is quite a good white paper on the issue