Every company needs a directory where all user login data is kept. There are two popular technologies for configuring and managing such directories – Windows Active Directory (AD) and Lightweight Directory Access Protocol – that are Harbor-compatible. It means that you can use an LDAP/AD server to add new users to the Container Registry instance and manage existing accounts on the server.
Indeed, you need to set up and configure such a server before you can activate this kind of user authentication in Container Registry. How you do it, depends on your provider. You can look for instructions on the official website of the OpenLDAP project or in the Windows server official documentation.
If you select this authentication mode, then, as a system admin, you will only be able to see a list of users in your Container Registry admin console but you won’t be able to perform any actions with them in the GUI, neither create and delete users nor change and reset their passwords. That all must be done on the LDAP or AD server. For the users, the self-registration option is not available in this mode (and you cannot enable it as an admin).
All entries in an LDAP directory are organized into a structure resembling roots of a tree or a reverted tree. There is a root node – the highest one in the structure – where a few brunches with more nodes originate; other nodes have own brunches, etc.
Each entry – a node – has a unique identifying path, called a distinguished name or DN.
Every time a user submits his credentials, a search is performed inside this structure to match the provided user credentials with an entry and authenticate the user. That’s why you need to keep at hand the following information about your LDAP server to configure it in Container Registry.
LDAP Search DN. This node coincides with the user who has access to the LDAP server which is usually an admin. This parameter should be specified as cn=admin, dc=your-subdomain.container-registry.com where the attribute cn stands for “common name” and dc stands for “domain component”.
LDAP Search Password. Consequently, here you need to enter the password of the user you specified in the previous parameter.
LDAP Base DN. Theoretically, you may use your LDAP server not only for managing Container Registry but also for other applications. In this case, the tree would have nodes/entries that are irrelevant to Container Registry users. Thus, you need to specify a node where the search for the relevant entries should start. This is your subdomain or custom domain in our service. This parameter needs to be specified as dc=your-subdomain.container-registry.com.
LDAP Scope. This parameter specifies the depth of the search in relation to the starting point: the previous parameter. You have a choice between the following values:
LDAP Filter. With this, you can narrow the search down to users or user groups. This will facilitate the search but, more importantly, restricts access to your Container Registry. You can use more than one attribute in the filter, as well as wildcards. A detailed tutorial on writing LDAP filters can be found here.
LDAP UID. Every entry in the LDAP has multiple attributes. The LDAP UID parameter specifies which of the attributes must be used as a key to match the user credentials (of the user who tries to log in to the system) with the entries in the tree. Typically, either the uid or the cn attribute are used.
Optionally, you can create user groups to be able to assign users to projects in bulks in the Container Registry GUI.
Since an LDAP directory is a tree-like structure, it’s naturally hierarchical. Groups are a way to put entities – in our case, users – together independently of that hierarchy. One user can be a member of more than one group.
On the LDAP/AD server, you need to use the memberof attribute of the entries. If you are new to this technology, look into this tutorial that explains how to create groups on the LDAP server and add users into them.
Once you created LDAP groups on the server, you have to configure group settings in the Container Registry GUI as well. You also cannot leave these settings empty if there are groups on your LDAP server.
The parameters are similar to those in the general server configuration.
LDAP Group Base DN. Like LDAP Search DN, it specifies a starting point in the tree structure of nodes/entries with user accounts and other records, with the only difference that this parameter may rather refer to a group or organizational unit name. For the latter, use the ou attribute.
LDAP Group Filter. Like LDAP Filter, it limits the search to certain nodes. First of all, you need to specify that you want to search only within groups and not all other nodes. If you use OpenLDAP, the filter is objectclass=groupOfNames. If you use Active Directory, apply the objectclass=group filter. In addition to that, you can use other LDAP attributes to make your search more precise.
LDAP Group GUID. This parameter specifies which attribute of a node is reserved for the name of the group. Typically, this would be cn.
LDAP Group Admin DN. In this field, you can enter the distinguished name of an LDAP/AD group the members of which will all be granted system admin access rights for your Container Registry instance.
LDAP Group Membership. This is also an attribute of a node but this attribute applies to the nodes holding user accounts. Thus, it specifies which attribute should the search look at to identify of which group the user is a member of. The default node attribute that identifies group membership is memberof.
LDAP Scope. Identical to the LDAP Scope mentioned before but applies to the group nodes.
