You can configure an LDAP sync connector to import users and user groups from a Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server.
In the configuration, you specify whether the users that are imported via the sync connector are authenticated against the LDAP server. If you do not want to use the back-end LDAP server as the authentication source, the users can still be imported from LDAP but authenticated against an AD server for the domain to which the Tanium Server is joined or the local accounts on the Tanium Server host computer (Windows). Deployments with the Tanium Appliance can use the local authentication service or a pluggable authentication module (PAM). Consult your technical account manager (TAM) for details.
Only users assigned the Administrator reserved role can see and use the Configuration pages, including the LDAP Sync configuration page.
- The Tanium Server initiates a connection to the back-end LDAP server. The standard port for LDAP is 389. The standard port for LDAPS is 636. In the LDAP sync configuration, you can specify whatever port your LDAP server listens on for its inbound LDAP traffic. Network security must be configured to allow this traffic.
- You must know the base distinguished name (DN), IDs, and filter expressions for the users and user groups you want to import.
- The LDAP server must allow the LDAP sync connector user to query the LDAP server using the configured filter expression(s).
- Go to Configuration > LDAP Sync.
- Click Add Server to display the Server Configuration page.
- Complete the settings using the guidance provided in Table 1.
- Click Show Preview to Continue and review the users and groups to be imported.
- Save the configuration.
Synchronization occurs automatically every 5 minutes.
When user and user group updates are synchronized from the LDAP server:
- Users are added or deleted.
- User groups are added or deleted and group members might be added or deleted.
You can clone an LDAP sync configuration, change the user domain, base DN, and other LDAP query fields, and then save the configuration. Configuration cloning enables you to quickly add connections for multiple domains or multiple groups (The LDAP query does not return subgroups, so you must create sync connection configurations for each subgroup you want to import.)
When you delete an LDAP server configuration:
- Users and user groups are no longer updated from the LDAP server.
- Users and user groups that had been imported are deleted from Tanium at the next sync time (within 5 minutes).
Disabling a configuration and deleting a configuration have the same effect. Delete the configuration when you no longer want that information saved in the Tanium Server.
You can export the configuration to an XML file and import a signed XML file into the same or different Tanium Server. You might do this, for example, to share the connection information when troubleshooting the LDAP query with your LDAP administrator.
- From any Authoring, Content Sets, or Roles page, click the Export to XML link in the top right.
- In the Export Content selection box, select the LDAP item and click Export.
- Enter a file name or use the default and click OK.
- From any Authoring, Content Sets, or Roles page, click the Import from XML link in the top right.
- Browse to and select the configuration file and click Import.
You must use KeyUtility.exe to sign XML files before you import them. You must also copy the public key for the key that signed the XML file to the Tanium Server keys folder. When you import content, the Tanium Server verifies the signature on the imported content against its store of content signing key files. See Signing content XML files.
Users and user groups are synchronized (imported) from the external LDAP server every 5 minutes. Each connector populates a set of configuration objects. It is therefore possible to create multiple configuration objects for a single real user. For example, if a user john.doe is created manually with the Tanium Console user editor, imported from LDAP Server 1, and imported from LDAP Server 2, there will be three user configurations for john.doe.
Consequently, if you delete a user configuration that was created manually, but the user still matches the LDAP sync filter, a configuration for the user remains in the Tanium Console. If you delete, in the Tanium Console, a user configuration that was imported, it will be re-created upon the next synchronization.
Tanium recommends the following practices to avoid unexpected issues:
- Plan to do some work on the back-end LDAP server to create LDAP user groups that correspond with the Tanium user groups you want to create and the users you want to associate with Tanium access.
- Plan to manage Tanium access by managing the back-end LDAP server configuration, not the front-end Tanium Console configuration. For example, the best way to on-board and off-board users is by adding them to a group that is imported or deleting them from a group that is imported.
- Be sure to control access to the back-end LDAP server configuration so that LDAP administrators who are not familiar with your Tanium deployment cannot make changes that affect it.
- Maintain at least one user in the Users configuration that is not populated by the LDAP sync connector. This configuration should be assigned the Administrator reserved role and can be used to log into the Tanium Console and re-configure the LDAP sync connector in case it fails. Some organizations provision multiple admin users outside of the LDAP sync connector for this reason.
- Be careful when you delete user configurations. As you transition from manually-created users to imported users, you probably want to clean up the apparent duplicates. However, the john.doe configuration that was created manually and the john.doe configuration that was imported have different object IDs. For example, let's say the first john.doe has object ID 2, and the second john.doe has object ID 3. The Tanium Console objects—such as scheduled actions, saved questions, Tanium Connect objects, solution plugins, or solution module services—that were created by the john.doe user that has object ID 2 do not also belong to the user with object ID 3. If you delete the john.doe configuration that has ID 2, you must be ready to re-create the configuration objects that run under that ID. See the user management topic for details.
Last updated: 2/14/2018 8:10 AM | Feedback