From OpenDCIM Wiki
Revision as of 10:38, 28 March 2018 by Scott (Talk | contribs) (LDAP Integration)

Jump to: navigation, search

LDAP Integration

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).