ITAM Auth - Active Directory

Active Directory

Sites that use Active Directory can use this module to give the TDX ITAM Server access to the AD names and passwords. All group membership information defined in the Active Directory domain will be available to the TDX ITAM Server for use in controlling application access, auto-populating divisions, and authenticating admin logins. To use this authentication module, you should already be familiar with the basics of Active Directory configuration and maintenance.

Because the TDX ITAM Server must access information directly from Active Directory, this authentication module can only be used from a Windows host computer that is itself a member of the domain forest you want to authenticate against. If your server runs on MacOS or Linux, and you wish to access your users and groups data in Active Directory, consider using the Kerberos or LDAP authentication modules. In any case, KeyConfigure running on Mac or Windows can be used to set up or maintain the Authentication settings without any domain membership requirement.

This section describes basic use of the Active Directory authentication module. For more detailed instructions and screenshots you can refer to the Active Directory Integration — Admin Authentication and Active Directory Integration — Client Authentication pages.

In order for the TDX ITAM Server to be able to access the names and passwords, it must operate with the user right “Run as part of the operating system”. This advanced user right can be enabled via the User Manager program. If your TDX ITAM Server runs as a service in the LocalSystem account, that account already has the necessary user rights.

Note that in a standard AD structure with the KeyServer service running under the system account, no configuration is necessary in most of this module. We will simply be able to use the machine membership in the domain to make queries. You need only select your client mapping issues, the other options will not be needed. In more complex structures of child domains and changes to security defaults, you may need to attend to these other options.

Click here for detailed information on possible configuration options.

Enter the name(s) of the domain(s) from which users will be authenticated in the NT Domain List field. If you leave this field blank, the local domain of the TDX ITAM Server machine is used. Users may specify the domain they belong to when they login using the standard notation: DOMAIN\name. If the user does not provide a domain, all domains listed in the authentication module configuration dialog will be searched in the order given.

There are four options for password verification:

  1. Passwords not required - With this option, users will not be prompted for passwords. The current user name of the computer login account is assumed to be correct and authentic, and will be used when checking group memberships.
  2. Use Secure Authentication - Users will be prompted for their password by KeyAccess when it logs on to the TDX ITAM Server. To take advantage of “single sign-on” when available, choose the Kerberos (or NTLM) authentication option instead.
  3. Use NTLM Authentication - NTLM Authentication supports “single sign-on” for Windows OS versions – Windows 98 , Windows NT 4, and better. These operating systems retain authenticated user account login information so that KeyAccess can make use of the previously validated credentials without itself prompting for a password. For Mac or Linux clients (or old KeyAccess versions), this option falls back to the Secure Authentication behavior – users will be prompted by KeyAccess for a password when it logs on to the TDX ITAM Server.
  4. Use Kerberos Authentication - With correctly configured Kerberos access to Active Directory, this authentication module can support “single sign-on” for KeyAccess running on Windows, Macintosh, and Linux. You will need to specify a Principal and setup some configuration options on the Windows server in order to allow the TDX ITAM Server to use Kerberos (more details later).

Access can be restricted to members of a particular group, as well. If a group name is specified in the “Restrict to Group” field, access will only be granted to users who enter their correct name and password and who also belong to this group.

With the Active Directory module, Active Directory group definitions are accessible to the TDX ITAM Server but groups defined in the Local computer operating system are not. If you want to also include Local OS groups, you should instead use the “Windows NT” authentication module. Note: with or without any authentication module, groups defined within the TDX ITAM Server itself are always accessible.

Typically, group membership is determined based on the name of the user who is logged in to the TDX ITAM Server. In addition, the Active Directory authentication module can check for group membership based on the name of the computer from which the user is logged in. To enable this option, check the option "Check Computer Members". This option must be enabled in order to use the "Assign Division automatically" option for Client Authentication.

If the KeyServer process runs in a Domain Account, you can leave the Host, Login and Password fields in this dialog blank. If however KeyServer was installed to run as Local System (the default), you will need to enter Login and Password values here. In that case, you should enter the DNS host name or IP address of the Active Directory server, as well as the name and password of an object on the server that has permissions to check group memberships (this means the object must have read rights to the “member” attribute of a group object). The object must either be qualified with the NT domain, as in "DOMAIN\accountname", or must be in one of the domains listed in the "NT Domain List". This account must be defined in Active Directory. It cannot be defined locally on the computer running the TDX ITAM Server. It does NOT have to have admin level privileges.

If your Active Directory server runs only in “native” mode and not “mixed” mode, this authentication module cannot retrieve the list of groups from the server. However, you can still use the groups on your AD server simply by typing them into the Scope field in any policies. The group name must be entered as it appears on the AD server (just the group name, not the fully qualified name). After entering a group name in a policy be sure to test launch a program in that policy under an account that is a member of the group so you can be sure that the group name was typed correctly.

When specifying group names in Policy Detail windows, you can “qualify” the group name with a domain name using the standard notation: DOMAIN\name. This tells KeyServer to look only in that Domain Group for the user. If the group is unqualified (i.e., no Domain is given), then KeyServer will look in each listed domain for a group of that name, and if the group exists, it will be checked for the user.

Active Directory allows for "nested groups", where if group A is a member of group B, then all members of group A are also members of group B. This feature can simplify management of users and groups with Active Directory, but it is also more computationally intensive for programs to check for group membership. Therefore, support for nested groups is disabled by default in this authentication module. If you use nested group in your Active Directory, you can enable KeyServer support for them by checking the "Use Nested Group Check" option. Lastly, the "AD Login" account described above must have sufficient permission to read the "memberOf" attribute for users and groups.

In order to use the “Kerberos Authentication” option, you will need to do some additional configuration:

  1. Create an account in Active Directory which will run the KeyServer process - e.g. “KeyServer”
  2. In the Services control panel on the computer running KeyServer, edit the KeyServer service and configure it to Log On as the account you have just created
  3. On the domain controller (where the Active Directory is installed), register a Service Principal Name for the account you made, using the setspn command, e.g.: 
    setspn -A KeyServer/DOMAIN.ORG KeyServer
  4. In the KeyConfigure Authentication dialog, fill in the Principal field with the string you used for the setspn command, but with an '@' character instead of a '/' - e.g. “KeyServer@DOMAIN.ORG”

 

Client Mapping

You can use OUs to determine what division to place a computer in. Within these modules you can choose between using the first, last, or all OUs for divisions.
For example, if a computer has the distinguished name (dn) "cn=computername,ou=sales,ou=northeast,dc=company,dc=com", then:

  • Use first OU would result in a division name of "sales"
  • Use last OU would result in a division name of "northeast"
  • Use all OUs would result in a division name of "sales.northeast"

Note that computers must be in OU containers in order to be mapped to a division. The default configuration of Active Directory places most computers into the Computers container, which is not an OU container. You must create OU containers in your Active Directory and place computers into these containers in order for them to be mapped to Divisions within KeyServer. Otherwise the computers will remain in the Uncategorized Division.

Generally you will want to enable Allow Guest Logon for members of all groups so that client machines have open access to the server. If you wanted to force directory authentication to establish a server session, this could be changed, but that is a rare use case.

The final set of checkboxes in this dialog allows the Administrator to specify how the automatic assignment occurs. The parent option for Assign Divisions automatically is needed to actually enable the mapping, otherwise nothing happens from the above settings.

  • The Now button (added in 7.8.0.1) allows an on demand movement of all Computers to their proper Division based on OU. This prevents having to wait for all the computers to get a session to self organize.
  • Create Divisions as needed is highly recommended unless there is a use case for wanting to manually make the divisions the computers will be automatically placed in. If the needed division does not exist, the computer will be Uncategorized despite the mapping choices above.
  • Reverse order of parts is also highly recommended as it will result in a folder structure when using all OUs for the mapping that matches the structure in Active Directory Users and Computers. Remember that the actual structure in command line is reverse from the UI, this option matches that.
  • Finally, Mapping takes precedence over Rules determines how custom Rules are handled in conjunction with OU mapping. If for example you wanted to use Rules to augment the default mapping from AD, you could disable this option.
Print Article