Enterprise LDAP Support for Nexus Repository 2

When an LDAP server fails, the applications authenticating against it can also become unavailable. Because a central LDAP server is such a critical resource, many large software enterprises will install a series of primary and secondary LDAP servers to make sure that the organization can continue to operate in the case of an unforeseen failure. Nexus Repository Manager Pro’s Enterprise LDAP plugin now provides you with the ability to define multiple LDAP servers for authentication. To configure multiple LDAP servers, click on Enterprise LDAP under Security in the main application menu. You should see the Enterprise LDAP panel shown in the following figure:

Figure 8.17. Defining Multiple LDAP Servers in Nexus Repository Manager Pro

From here you can use the Backup Mirror setting for an LDAP repository. This backup mirror is another LDAP server that will be consulted if the original LDAP server cannot be reached. Nexus Repository Manager Pro assumes that the backup mirror is a carbon copy of the original LDAP server and it will use the same user and group mapping configuration as the original LDAP server. Instead of using the backup mirror settings, you could also define multiple LDAP backup mirrors in the list of configured LDAP servers shown in the previous figure. When you configure more than one LDAP server, Nexus Repository Manager Pro will consult the servers in the order they are listed in this panel. If the repository manager can’t authenticate against the first LDAP server, Nexus Repository Manager Pro will move on to the next LDAP server until it either reaches the end of the list or finds an LDAP server to authenticate against.

Figure 8.18. Use Multiple LDAP Servers in a Fail-over Scenario

The feature just described is one way to increase the reliability of your repository manager. In the previous case, both servers would have the same user and group information. The secondary would be a mirror of the primary. But, what if you wanted to connect to two LDAP servers that contained different data?

If you want to connect to two LDAP servers that contain different data, Nexus Repository Manager Pro also provides support for multiple servers and LDAP schemas as described in Support for Multiple Servers and LDAP Schemas.

The same ability to list more than one LDAP server also allows you to support multiple LDAP servers that may or may not contain the same user authentication information. Assume that you had an LDAP server for the larger organization containing all of the user information across all of the departments. Now assume that your own department maintains a separate LDAP server that you use to supplement this larger LDAP installation. Maybe your department needs to create new users that are not a part of the larger organization, or maybe you have to support the integration of two separate LDAP servers that use different schema on each server.

A third possibility is that you need to support authentication against different schema within the same LDAP server. This is a common scenario for companies that have merged and whose infrastructures have not yet been merged. To support multiple servers with different user/group mappings or to support a single server with multiple user/group mappings, you can configure these servers in the Enterprise LDAP panel shown prior. The repository manager will iterate through each LDAP server until it can successfully authenticate a user against an LDAP server.

Figure 8.19. Supporting Multiple LDAP Schemas with Nexus Repository Manager Pro

If you are constantly authenticating against a large LDAP server, you may start to notice a significant performance degradation. With Nexus Repository Manager Pro you can cache authentication information from LDAP. To configure caching, create a new server in the Enterprise LDAP panel, and scroll to the bottom of the Connect tab. You should see the following input field which contains the number of seconds to cache the results of LDAP queries.

Figure 8.20. Setting the LDAP Query Cache Duration (in Seconds)

You will also see options to alter the connection timeout and retry interval for an LDAP server. If you are configuring a number of different LDAP servers with different user and group mappings, you will want to make sure that you’ve configured low timeouts for LDAP servers at the beginning of your Enterprise LDAP server list. If you do this properly, it will take the repository manager next to no time to iterate through the list of configured LDAP servers.

Figure 8.21. Setting the LDAP Connection Timeout (in Seconds)

Once you’ve configured LDAP caching in Nexus Repository Manager Pro, authentication and other operations that involve permissions and credentials once retrieved from an external server will run quickly and efficiently.

If you are configuring your Nexus Repository Manager Pro instance to connect to an LDAP server there is a very good chance that your server follows one of several, well-established standards. Nexus Repository Manager Pro’s LDAP server configuration includes these widely used user and group mapping templates that great simplify the setup and configuration of a new LDAP server. To configure user and group mapping using a template, select a LDAP server from the Enterprise LDAP panel, and choose the User and Group Settings. You will see a User & Group Templates section as shown in the following figure.

Figure 8.22. Using User and Group Mapping Templates

Nexus Repository Manager Pro provides you with the ability to test a user login directly. To test a user login, go to the User and Group Settings tab for a server listed in the Enterprise LDAP panel. Scroll to the bottom of the form, and you should see a button named Check Login.

Figure 8.23. Testing a User Login

If you click on Check Login, you will then be presented with the login credentials dialog shown below. You can use this dialog to login as an LDAP user and test the user and group mapping configuration for a particular server. This feature allows you to test user and group mapping configuration directly and to quickly diagnose and address difficult authentication and access control issues via the administrative interface.

Figure 8.24. Supply a User’s Login Credentials