LDAP

GIANT WARNING MESSAGE THAT MOST PEOPLE SEEM TO IGNORE

If you simply want to authenticate your users against an LDAP directory (including Active Directory), but continue to control the privileges granted to them within the openDCIM GUI, then you need to use one of the Apache AUTHN/AUTHZ modules for that. This is not the place to find documentation for that, as it has been answered ad nauseum elsewhere.

The LDAP integration built into openDCIM will require you to manipulate groups, as each distinct role within the RBAC model requires that it map out to a group. You may no longer change the privileges of users within the openDCIM GUI if you use the built-in LDAP integration, as that now becomes a function of your directory service. If you don't have the ability to make those changes, or have influence within your organization to make those changes happen - and continue to happen with each and every user that you add to openDCIM - then you need to walk away, and use AUTHN/AUTHZ integration, as stated above.

Changing Existing Installations from Apache to LDAP Authentication

If you are already running openDCIM that is an older version than 4.2, it is suggested that you simply make no changes to the authentication configuration until after you upgrade to version 4.2. From that point the LDAP configuration screens can easily be configured by a user with SiteAdmin privileges and in case you get them wrong, you can flip back and forth between LDAP and Apache authentication via your config file.

New Installations

Step 1 - Watch the YouTube video that I made showing how to do a new installation with LDAP. Step 3 - Profit!

LDAP Configuration

As of version 18.02, a new login_ldap.php file has been provided that retains backwards compatibility, but has a bit more sanity checks involved in order to work better with both Windows and Samba AD.

opendcim LDAP config:

Base DN: dc=domain,dc=tld Base Search: (&(objectClass=group)(member:1.2.840.113556.1.4.1941:=CN=%userid%,CN=Users,DC=domain,DC=tld))

This is LDAP_MATCHING_RULE_IN_CHAIN so you can grant access to opendcim for groups containing final users. For easier user management. Supported since samba 4.5.

Bind DN: YOURDOMAIN%userid%

User Search: (|(sAMAccountName=%userid%))

SiteAccess: cn=DCIM_SiteAccess,ou=SW_permissions,dc=domain,dc=tld

Where SW_permissions is OU and DCIM_SiteAccess is group granting access to openDCIM.

Prior instructions (designed for openLDAP)

There are several attributes related to LDAP that you can configure. Most are simply entering in site specific Distinguished Names that relate to the various access rights within openDCIM.

Server: Any valid LDAP uri should work

Base DN: If you're not sure what this means, you should find someone within your organization that is familiar with your LDAP setup. This refers to the domain within the LDAP server that you are formulating your queries.

Base Search: This parameter was introduced in version 4.3 to work with AD. This is the search string that tells the LDAP client how to look up the user. Active Directory Users - the following has been reported as the string to use (replace the parts in italics with your site specific information):

(&(objectClass=group)(member=CN=%userid%,OU=User Location,DC=yourdomain,DC=org))

Bind DN: The distinguished name that we will use for binding to the LDAP server. Note the use of %userid% in the default value - that section will be replaced by the UserID that is entered by users.

User Search: This is the search term used to look up the user so that we can retrieve their first name, last name, and email address. Active Directory Users - the following has been reported as the string to use:

(|(sAMAccountName=%userid%))

LDAP Session Expiration: The maximum amount of time that a user may remain logged in. This is not an idle time expiration - it is a maxmimum time from login until expiration. If you leave this at 0, the session will remain active until the browser is closed or the user explicitly logs out.

Why isn't there a service account used to bind to the LDAP server?

Service Accounts are used when an application needs to log in to the LDAP server with an elevated privilege level that allows the application to browse the attributes and group memberships of accounts other than the one currently logged in. openDCIM takes a very conservative approach to security and assumes that if you are using LDAP to manage your user rights, then openDCIM has no need to view or modify that kind of information.

Group Membership

There are entries relating to each of the access rights within the openDCIM application. Once a user logs in, the system will query the LDAP server to get a list of group memberships, and any groups that match a given DN will grant the corresponding access right.

Rights are only checked at the initial login, so any changes made on the LDAP server would not take effect until the user logs out. Also any changes made to the database for a user record will be overwritten upon the next login (other than Phone, Email, and APIKey).

I Refuse to Read Everything Else Because I Want To Integrate With Active Directory Even Though Those Other Things Are Relevant

Over the years, we've learned that there are people who understand AD very well, and who can read the information above, and know exactly what to do. Then there are others who know that they have Active Directory in their organization and that they can authenticate against it, but then don't understand why things don't work the way they want them to because they didn't read all of the disclaimers above. Don't be those people. It's ok to be in between - to know that it will take some work, but that you don't quite know what to do. Yes, I'm preaching, because for some reason, a lot of folks seem to think it's openDCIM's problem that those users (not truly admins) don't know their internal AD structures.

Also, WHY NO SERVICE ACCOUNT? Because you don't actually need one. We don't care who else is in the directory - only the user that is trying to log in. Service Accounts are needed if you need to generate a list of valid users (which we aren't).

Base Search - Your base search must match elements that AD has for users. In our example, (|(userprincipalname=%userid%)(cn=%userid%)) is an OR query for the userprincipalname (often referred to as UPN) or the common name equal to whatever your login name is

Bind DN - Your BindDN has to be valid for your specific installation. If you want to just login as the email address you just need to put %userid% here and not a fully qualified ldap string, if you want to use a short name instead of the long you can do %userid%@ad.wilpig.org, but a full ldap string will work, too as long as you have all your elements right. For our test environment, CN will not work because my test user is “Open DCIM” (and spaces in the bind DN are not allowed) for the cn even though the login name is dcim so our LDAP string would look like “CN=Open DCIM,OU=openDCIM,DC=ad,DC=wilpig,DC=org” to make that work. you can also use "ad\%userid%" with ad being the name of the domain.

In general you should be able to take the values from the config page, put them into their corresponding locations in the command below and if you get a login, they will work.

ldapsearch -x -b "<Base DN>" -D "<Bind DN>" -h <LDAP Server URI> -W '<User Search>'