So you’ve got LDAP Link configured, enabled, and working with Vertica, thus synchronizing LDAP users and groups with corresponding Vertica users and roles. You still have to manage users and roles in Vertica that you did not create with LDAP Link. The following graphic shows how your configuration might look.
But there are a few best practices that you should follow to make sure that you don’t accidentally lose any users or data. This blog explains how to keep your LDAP Link service working smoothly.
Before You Enable LDAP Link: Perform a Dry Run
The LDAPLinkDryRun parameter indicates whether or not Vertica should run a test (“dry run”) between the LDAP server and Vertica. A dry runs checks that
- The connection works.
- Parameters are set correctly.
- A lookup on the LDAP server returns the correct results, recorded in ldap_server_response.log
A dry run does not make any changes to your Vertica database.
For best results, set LDAPLinkDryRun to 1 and perform the dry run in a test environment. Doing so improves the chances that you’ll have a seamless synchronization when you ultimately deploy LDAP Link in your production environment.
Avoid Changing Certain Parameters
Do not change either of the following connection parameters between synchronizations:
- LDAPLinkURL: This parameter specifies the LDAP server for the lookup.
- LDAPLinkSearchBase: This parameter specifies the area of the specified LDAP server for the lookup.
Obviously, changing either of these parameters results in a reconfiguration of the user base. If you run a synchronization, and then change one of these parameters, in the next synchronization, the users and roles are marked as Orphaned from LDAP.
Prevent Lost Database Objects
When you remove a user from your LDAP server, on the next sync, LDAP Link drops that LDAP user from the Vertica users. Vertica drops the user using CASCADE, so Vertica also drops any objects (tables, views, etc.) owned by that user. Those database objects are lost and cannot be recovered.
To prevent losing database objects that were owned by a deleted LDAP user, use the GlobalHeirUserName parameter. The GlobalHeirUserName parameter specifies what happens to database objects whose user/owner has been dropped:
- AUTO (the default)Vertica assigns the dbadmin user as the new parent of the database objects. We call this reparenting.
- <username>Vertica assigns the specified user as the new parent of the database objects.
- EmptyVertica does not assign the database objects to any user. If you use this option, the database objects are lost and cannot be recovered. This is the same as executing => DROP USER user_name CASCADE;
Avoid Dropping Users Accidentally
Suppose LDAP Link is synchronizing and doesn’t find any users on the LDAP server. In this situation, LDAP Link drops all LDAP Link-created users from Vertica. This is the expected behavior of synchronization. LDAP Link never deletes non-LDAP users.
To prevent this behavior, set the LDAPLinkStopIfZeroUsers parameter to 1. This parameter specifies that the LDAP Link synchronization should fail if no users are found are found on the LDAP server. Doing so prevents inadvertently dropping legitimate LDAP users in Vertica.
When the synchronization fails, it records an error in vertica.log and adds an entry to the LDAP_LINK_EVENTS system table.
After you have determined why the LDAP server had no users and reconfigured the system properly, set LDAPLinkStopIfZeroUsers to 0 and rerun the synchronization.
Summary of Recommendations
Here’s a summary of the recommendations in this blog.
|GlobalHeirUserName||· AutoReparent objects to dbadmin only when Vertica drops LDAP users.
· usernameReparent objects to username when any users are dropped.
For More Information
If you follow these procedures, you can manage your Vertica database users with LDAP Link without losing users or data. For complete information about LDAP Link, see LDAP Link Service in the Vertica documentation.