User and Group Mapping in Nexus Repository 2

The LDAP Configuration panel in Nexus Repository Manager OSS contains sections to manage User Element Mapping and Group Element Mapping in the User and Group Settings tab. These configuration sections are located in a separate panel called User and Group Settings in Nexus Repository Manager Pro. This panel provided a User & Group Templates drop-down displayed in Figure 8.3, “User and Group Templates Selection Drop Down” that will adjust the rest of the user interface based on your template selection.

Figure 8.3. User and Group Templates Selection Drop Down

The User Element Mapping displayed in Figure 8.4, “User Element Mapping” has been pre-populated by the Active Directory selection in the template drop-down and needs to be configured as required by your LDAP server. The available fields are:

Base DN

Corresponds to the Base DN containing user entries. This DN is going to be relative to the Search Base, specified in Figure 8.2, “A Simple LDAP Connection and Authentication Setup”. For example, if your users are all contained in ou=users,dc=sonatype,dc=com and you specified a Search Base of dc=sonatype,dc=com, you would use a value of ou=users.

User Subtree

Values are True if there is a tree below the Base DN that can contain user entries and False if all users are contain within the specified Base DN. For example, if all users are in ou=users,dc=sonatype,dc=com this field should be False. If users can appear in organizational units within organizational units such as ou=development,ou=users,dc=sonatype,dc=com, this field should be True.

Object Class

This value defaults to inetOrgPerson which is a standard object class defined in RFC 2798. This Object Class (inetOrgPerson) contains standard fields such as mail, uid. Other possible values are posixAccount or a custom class.

User ID Attribute

This is the attribute of the Object class that supplies the User ID. The repository manager uses this attribute as the User ID.

Real Name Attribute

This is the attribute of the Object class that supplies the real name of the user. The repository manager uses this attribute when it needs to display the real name of a user.

E-Mail Attribute

This is the attribute of the Object class that supplies the email address of the user. The repository manager uses this attribute when it needs to send an email to a user.

Password Attribute

This control is only available in Nexus Repository Manager OSS and replaced by the Use Password Attribute section from Figure 8.5, “Password Attribute” in Nexus Repository Manager Pro. It can be used to configure the Object class, which supplies the password ("userPassword").

Figure 8.4. User Element Mapping

Once the checkbox for Use Password Attribute has been selected, the interface from Figure 8.5, “Password Attribute” allows you to configure the optional attribute. When not configured authentication will occur as a bind to the LDAP server. Otherwise this is the attribute of the Object class that supplies the password of the user. The repository manager uses this attribute when it is authenticating a user against an LDAP server.

Figure 8.5. Password Attribute

The Group Type drop-down displayed in Figure 8.6, “Dynamic Group Element Mapping” and Figure 8.7, “Static Group Element Mapping” determines which fields are available in the user interface. Groups are generally one of two types in LDAP systems - static or dynamic. A static group contains a list of users. A dynamic group is a list of groups to which user belongs. In LDAP a static group would be captured in an entry with an Object class groupOfUniqueNames that contains one or more uniqueMember attributes. In a dynamic group configuration, each user entry in LDAP contains an attribute that lists group membership.

Figure 8.6. Dynamic Group Element Mapping

Dynamic groups are configured via the Member of Attribute parameter. The repository manager inspects this attribute of the user entry to get a list of groups of which the user is a member. In this configuration, a user entry would have an attribute that would contain the name of a group, such as memberOf.

Figure 8.7. Static Group Element Mapping

Static groups are configured with the following parameters:

Base DN

This field is similar to the Base DN field described for User Element Mapping. If your groups were defined under ou=groups,dc=sonatype,dc=com, this field would have a value of ou=groups.

Group Subtree

This field is similar to the User Subtree field described for User Element Mapping. If all groups are defined under the entry defined in Base DN, this field should be false. If a group can be defined in a tree of organizational units under the Base DN, then the field should be true.

Object Class

This value defaults to groupOfUniqueNames which is a standard object class defined in RFC 4519. This default (groupOfUniqueNames) is simply a collection of references to unique entries in an LDAP directory and can be used to associate user entries with a group. Other possible values are posixGroup or a custom class.

Group ID Attribute

Specifies the attribute of the Object class that specifies the Group ID. If the value of this field corresponds to the ID of a role, members of this group will have the corresponding privileges. Defaults to cn.

Group Member Attribute

Specifies the attribute of the Object class which specifies a member of a group. A groupOfUniqueNames has multiple uniqueMember attributes for each member of a group. Defaults to uniqueMember.

Group Member Format

This field captures the format of the Group Member Attribute and is used by the repository manager to extract a username from this attribute. For example, if the Group Member Attribute has the format uid=brian,ou=users,dc=sonatype,dc=com, then the Group Member Format would be uid=$username,ou=users,dc=sonatype,dc=com. If the Group Member Attribute had the format brian, then the Group Member Format would be $username.

If your installation does not use Static Groups, you can configure LDAP Integration to refer to an attribute on the User entry to derive group membership. To do this, select Dynamic Groups in the Group Type field in Group Element Mapping.

Once you have configured the User & Group Settings you can check the correctness of your user mapping by pressing the Check User Mapping button visible in Figure 8.7, “Static Group Element Mapping”.

Nexus Repository Manager Pro offers a button Check Login to check an individual users login.

Press the Save button after successful configuration.

When mapping users and groups to an Active Directory installation, try the common configuration values listed in Table 8.2, “User Element Mapping Configuration for Active Directory” and Table 8.3, “Group Element Mapping Configuration for Active Directory”.

Table 8.1. Connection and Authentication Configuration for Active Directory

Table 8.2. User Element Mapping Configuration for Active Directory

Table 8.3. Group Element Mapping Configuration for Active Directory

When mapping users and groups to LDAP entries of type posixAccount, try the common configuration values listed in Table 8.4, “User Element Mapping Configuration for posixAccount” and Table 8.5, “Group Element Mapping Configuration for posixGroup”.

Table 8.4. User Element Mapping Configuration for posixAccount

Table 8.5. Group Element Mapping Configuration for posixGroup

Once User & Group Mapping has been configured, you can start verifying how LDAP users and groups are mapped to roles. If a user is a member of an LDAP group that has a Group ID corresponding to the ID of a role, that user is granted the appropriate permissions in the repository manager.

For example, if the LDAP user entry in uid=brian,ou=users,dc=sonatype,dc=com is a member of a groupOfUniqueNames attribute value of admin, when this user logs into the repository manager, he/she will be granted the administrator role if the Group Element Mapping is configured properly. To verify the User Element Mapping and Group Element Mapping, click on Check User Mapping in the LDAP Configuration panel directly below the Group Element Mapping section; Figure 8.8, “Checking the User and Group Mapping in LDAP Configuration” shows the results of this check.

Figure 8.8. Checking the User and Group Mapping in LDAP Configuration

In Figure 8.8, “Checking the User and Group Mapping in LDAP Configuration”, LDAP Integration locates a user with a User ID of "brian" who is a member of the "admin" group. When "brian" logs in, he will have all of the rights that the admin role has.

If you are unable to map all of the roles to LDAP groups, you can always augment the role information by adding a specific user-role mapping for an external LDAP user in the repository manager. In other words, if you need to make sure that a specific user in LDAP gets a specific role and you don’t want to model this as a group membership, you can add a role mapping for an external user in the repository manager.

The repository manager keeps track of this association independent of your LDAP server. It continues to delegate authentication to the LDAP server for this user. The repository manager will continue to map the user to roles based on the group element mapping you have configured, but it will also add any roles specified in the User panel. You are augmenting the role information that the repository manager gathers from the group element mapping.

Once the user and group mapping has been configured, click on the Users link under Security in the main menu. The Users tab contains all of the configured users for this repository manager instance as shown in Figure 8.9, “Viewing All Configured Users”. A configured user is a user in a repository manager realm or an External User that has an explicit mapping to a role. In Figure 8.9, “Viewing All Configured Users”, you can see the three default users in the default realm plus the brian user from LDAP. The brian user appears because this user has been mapped to an internal role.

Figure 8.9. Viewing All Configured Users

The list of users in Figure 8.9, “Viewing All Configured Users” is a combination of all of the users in the default realm and all of the External Users with role mappings. To explore these two sets of users, click on the All Configured Users drop-down and choose Default Realm Users. Once you select this, click in the search field and press Enter. Searching with a blank string in the Users panel will return all of the users of the selected type. In Figure 8.10, “All Default Realm Users” you see a dialog containing all three default users from the default realm.

Figure 8.10. All Default Realm Users

If you wanted to see a list of all LDAP users, select LDAP from the All Configured Users drop-down shown in Figure 8.9, “Viewing All Configured Users” and click on the search button (magnifying glass) with an empty search field. Clicking search with an empty search field will return all of the LDAP users as shown in Figure 8.11, “All LDAP Users”.

Figure 8.11. All LDAP Users

To add a mapping for an external LDAP user, you would click on the All Configured Users drop-down and select LDAP. Once you’ve selected LDAP, type in the user ID you are searching for and click the search button (magnifying glass icon to right of the search field). In Figure 8.12, “Search LDAP Users”, a search for "brian" yields one user from the LDAP server.

Figure 8.12. Search LDAP Users

To add a role mapping for the external user brian shown in Figure 8.12, “Search LDAP Users”, click on the user in the results table and drag a role from Available Roles to Selected Roles as shown in Figure 8.13, “Mapping the Deployment Role to an External User”. In this case, the user "brian" is mapped to the Administrative group by virtue of his membership in an "admin" group in the LDAP server. In this use case, an administrator would like to grant Brian the Deployment Role without having to create a LDAP group for this role and modifying his group memberships in LDAP.

Figure 8.13. Mapping the Deployment Role to an External User

The end result of this operation is to augment the Group-Role mapping that is provided by the LDAP integration. You can use LDAP groups to manage coarse-grained permissions to grant people administrative privileges and developer roles, and if you need to perform more targeted privilege assignments in the repository manager you can map LDAP users to roles with the techniques shown in this section.

Nexus Repository Manager OSS and Nexus Repository Manager Pro make it very straightforward to map an external role to an internal role. This is something you would do, if you want to grant every member of an externally managed group (such as an LDAP group) a certain privilege in the repository manager. For example, assume that you have a group in LDAP named svn and you want to make sure that everyone in the svn group has administrative privileges. To do this, you would click on the Add.. drop-down in the Roles panel as shown in Figure 8.14, “Selecting External Role Mapping in the Role Management Panel”. This drop-down can be found in the Roles management panel which is opened by clicking on Roles in the Security menu.

Figure 8.14. Selecting External Role Mapping in the Role Management Panel

Selecting External Role Mapping under Add… will show you a dialog containing a drop-down of External Realms. Selecting an external realm such as LDAP will then bring up a list of roles managed by that external realm. The dialog shown in Figure 8.15, “Selecting an Externally Managed Role to Map to an Internal Role” shows the external realm LDAP selected and the role "svn" being selected to map to a role.

Figure 8.15. Selecting an Externally Managed Role to Map to an Internal Role

Once the external role has been selected, the repository manager creates a corresponding role. You can then assign other roles to this new externally mapped role. Figure 8.16, “Mapping an External Role to an Internal Role” shows that the "SVN role from LDAP" is being assigned the Administrator role. This means that any user that is authenticated against the external LDAP Realm who is a member of the svn LDAP group will be assigned a role that maps to the Administrator role.

Figure 8.16. Mapping an External Role to an Internal Role