ITAM Authentication Overview

Authentication modules are implemented as library files stored in the Authentication Modules folder within the KeyServer Data Folder. Module selection and the corresponding configuration options are specified in the Web UI under Settings -> Account Setup and Clients. They can also be specified in KeyConfigure under the Config menu using Admin Authentication... and Client Authentication... respectively.  Specific modules for the most part are covered in individual articles, this article is a general overview of the functionality.

Client vs Admin

The same module can be used for both Client and Admin authentication. In this case, the module's connection settings can be entered just once in the client auth setup – then as a convenience, the Copy Client Auth option can be used when setting up the module for Admin Authentication.  However, most sites today are only using Admin auth (Account Setup) as configured in the Web UI as Client auth is not as useful or accessible anymore.

Client authentication refers to the KeyAccess client communicating to the server. It is most often used to automate the placement of client computers into Divisions based on group membership data that is available from an external authentication service (e.g. Active Directory). It can also be used when defining a Policy scope in order to control usage of a product based on client computer or user login credentials/ group membership.

Admin Authentication lets you configure an external authentication service to manage privileged user logons to your TDX ITAM Server. This includes logons using KeyConfigure as well as through the Web portal. Just like the internally defined admin accounts, various configuration options and platform features can be granted based on group membership. It is important to understand this only deals with the authentication, not the authorization in the TDX ITAM Server. For more on permissions, refer to the Admin Access Window and ACL Details Window.

General Options

Note that there are several common fields between modules. There are default accounts and easy assignments for Admin Access to external groups right in the authentication module. If you need more granular control you can still use the Admin Access window to create custom Roles. The most notable option is for Unknown External Logins. The default setting of Community will create Guest level access for any account that is not otherwise linked to a Role via an External Group. Using Create Accounts as Needed will result in a stub account being made in the Server if membership is resolved to a referenced group, and the related Role being applied. Conversely Determine Access on Demand will still resolve the privileges of a linked Role, but will NOT create the local stub account. This can be useful in large environments with full authentication but granular access.

• Assign Divisions automatically - Options for how to handle computers that are connecting for the first time. If you do not use this when you're using a directory system, computers will still need to be manually assigned. Otherwise, if you're using AD for example, this will cause the Division organization to match your OU organization.
  • Create Divisions as Needed - Simply, when a computer connecting for the first time is in a Division (OU) that does not yet exist in KeyServer, make that Division and put the computer in it.
  • Reverse order of parts - This will put the OU structure in reverse order instead of matching the OU tree in AD.
  • Mapping takes precedence over Rules - If you set up Filters to move computers to certain Divisions, you can use this option to dictate how conflicts are handled. That is, force the computer to go to the OU matching the AD location, or allow the KeyServer filter to put the computer somewhere else as an override.
• Unknown External Logins - Offers 3 options when dealing with external account authentication and how we should react when no local account record exists.
  • Create Accounts As Needed - This will make an account in KeyServer marked as external and inherit roles as configured.
  • Disallow Login - This will deny login. You will need to make the external account in KeyServer manually to allow login. This is a double layer of security.
  • Use an Account - This is not listed as an option, you simply see a list of accounts in KeyServer. Creating a "fake" external account and setting it in this option means any unknown external account (that is, no record in KeyServer) will operate as if it was the selected account in regards to assigned privileges. This would allow for example all members of your AD to log in with a "guest" level of access, while admins have assigned roles. With a disabled guest account, this means you now have a fully authenticated system with no public view, and no massive list of user accounts created in KeyServer.
• Establish new LDAP connection for every bind - This option was added to the LDAP and AD modules specifically for the consideration of DUO second factor authentication. It forces a new connection for each communication to ensure the Gateway differentiates between the bind account and the authentication account.

Screenshots of both the client and admin modules are provided in the specific sections to illustrate the different options.

Modules Compared

The table below summarizes some properties of the standard authentication modules.

Module	Groups	"True" SSO	Assign Divisions
Single Password	No	❌	❌	✅	✅	✅
Text Authent	Group membership can be defined in the authent.txt text file	❌	❌	✅	✅	✅
Kerberos	Group membership defined in the LDAP directory can be made accessible	❌	❌	✅	✅	✅
LDAP	Group membership defined in the LDAP directory is accessible	❌	✅	✅	✅	✅
Windows NT	Group membership defined in each NT domain or in Active Directory	Conditional	✅	✅
Active Directory	Group membership defined in Active Directory is accessible	Conditional	✅	✅
OIDC Methods	Group membership defined in the directory is accessible	✅	❌	✅	✅	✅
SQL	Group membership defined in the SQL database is accessible	❌	❌	✅
CAS	No	✅	❌	✅	✅	✅
Unix	Group membership defined in the Unix system is accessible	❌	❌		✅	✅

• Disabled. The authentication feature is disabled, so Administrative accounts can only be defined internally within the TDX ITAM Server using the Admin Access window. Client group membership (used for scope limitations) can still be defined based on network location or computer id but not based on any other data source.
• Single Password. Users become authenticated by typing in a password, which you choose. The password is the same for all TDX ITAM Server users. This module does not define any groups. This is only available for client auth, not admin.
• Text Authent. User names, passwords, and groups are specified in a text file. A user becomes authenticated by typing a correct name and password. Users may be members of multiple groups, and thereby gain access to policies.
• Kerberos. To gain access to the TDX ITAM Server, users must authenticate with a Kerberos server. Kerberos does not directly support groups but can be access group data from LDAP. This authentication module requires a Kerberos server on your network.
• LDAP. To gain access to the TDX ITAM Server, users must type their name and password as it exists on the specified LDAP server. Once authenticated, users can be given access to policies based on membership in groups defined on the LDAP server.
• Windows NT. To gain access to the TDX ITAM Server, users must type their name and password as it exists in the specified NT Domain, Active Directory, or on the Windows NT computer that is running the TDX ITAM Server. Once authenticated, users can be given access to policies based on their membership in groups as defined in the authentication database. For most purposes, this module has been superseded by the Active Directory module. This authentication module is only available if the TDX ITAM Server is hosted on Windows NT, although clients on all platforms are supported.
• Active Directory. Typically sites using Active Directory are configured so that users and computers authenticate to active directory at computer logon. Using the Active Directory module, either for Client or Admin authentication, the credentials verified at logon are relayed to the TDX ITAM Server without requiring authentication a second time. When used for Client authentication, in addition to being available for Policy scopes, this module can automatically populate Divisions based on AD organizational units. This authentication module is only available if the TDX ITAM Server is hosted on Windows, although clients on all platforms are supported.
• SQL. User names, passwords, and groups are defined in a database that supports SQL. This authentication module is only available if the TDX ITAM Server is hosted on Windows, although clients on all platforms are supported.
• CAS. This module is useful for taking advantage of CAS's single sign-on functionality when configuring Admin authentication for the TDX ITAM UI. Logons through KeyConfigure can also use CAS authenticated accounts if your CAS service supports the REST API.
• Unix. To gain access to the TDX ITAM Server, users must type their name and password as it is defined on the Unix computer running the KeyServer process. Once authenticated, users can be given access to policies based on their membership in groups as defined in the authentication database. This authentication module is only available if the TDX ITAM Server is hosted on MacOS or Linux, although clients on all platforms are supported. Linux, and MacOS can use PAM to relay the unix authentication from a broad variety of authentication service choices (e.g. LDAPv3). When the TDX ITAM Server is hosted on MacOS, Apple's Open Directory architecture is also available for authentication.

Disabled

When no other module is chosen, or when a module that you choose can not load, authentication defaults to the Disabled method. With Client Authentication is disabled, the TDX ITAM Server authenticates every user so groups based on user names are not available. With Admin Authentication disabled, only internally defined KeyConfigure administrative logons are available.

Single Password

Single Password is so named because it maintains one global password for all users of the TDX ITAM Server. This password can be up to eight characters in length, and can contain any characters. Users must type the password exactly as you entered it, including the upper and lower cases of each letter. Users who know this password are given full access to the TDX ITAM Server, regardless of their names.

As with the Disabled module, there are no user based groups defined by this module so the Assign Divisions option for clients is meaningless. But you could allow guests logons for some group – perhaps a group defined by location. This module is useless for Admin Authentication since internal admin account and password credentials can already be defined from the Admin Access window.