Enportal/5.5/admin/user administration/ldap configuration: Difference between revisions
imported>Jason.nicholls |
imported>Jason.nicholls No edit summary |
||
Line 237: | Line 237: | ||
== LDAP With SSL == | == LDAP With SSL == |
Revision as of 10:13, 7 October 2014
Overview
For organizations with an existing directory service it's possible to configure enPortal to use this service for user authentication, role assignment, and retrieval of additional user data.
Lightweight Directory Access Protocol (LDAP) is a common protocol used by many directory services and enPortal provides out-of-the-box support for these. Refer to the Supported LDAP Servers section below for more details.
For more information in general about authentication domains, users, and roles refer to the Provisioning documentation. Understanding how the default provisioning model works before trying to configure LDAP will make things easier.
Supported LDAP Servers
Product | Support Pass Change | Legacy | Notes |
---|---|---|---|
Microsoft Active Directory (AD) | yes | - | |
OpenLDAP | yes | - | |
Sun ONE Directory Server | yes | yes | replaced by Sun Java System Directory Server |
Managing LDAP
This section covers actually managing the LDAP repository, that is setting up connection information, managing LDAP authentication domains, and managing LDAP role assignment.
With LDAP configured managing and assigning content is performed on LDAP domains, users, and roles as per normal through the enPortal user interface.
To access the LDAP configuration you must be logged in as an administrator and navigate to Advanced -> Explore System -> LDAP Repositories as shown in the screenshot below:
LDAP Repositories
LDAP Repositories encapsulate the connection and authentication information to talk to the directory service. enPortal supports multiple repositories although typically there is just one.
To create a new repository click the top-level LDAP Repository entry in the Explorer tree. You can also right-click and select New Repository. Fill out the fields as described in the table below and click the Save button to save the repository.
Field | Description |
---|---|
LDAP Repository Name | Unique name for this repository, it is used internally and must be unique. After creating the repository this name cannot be changed. |
LDAP Repository URL | The connection URL for the directory server, typically of the form ldap://directory_server:389 or ldaps://directory_server:636 for secure LDAP. enPortal also supports failover and multiple connection URLs can be entered here separated by spaces. |
Factory | Do not change this unless instructed by support. |
Connection Timeout | Optional and only applicable in the case where failover (multiple connection URLs) is configured. This represents the timeout waiting on a directory server response before failing over to the next configured. The value is in milliseconds and if not set defaults to 10,000 (10 seconds). |
LDAP Authentication User | The distinguished name (DN) of a user with permission to query the LDAP server. If unspecified the anonymous account will be used. This account should have read-only access to the information needed for synchronization of users and roles. For example: cn=Manager,dc=edgeti,dc=com |
Password | The password for the LDAP Authentication User |
Admin Access | This should be left un-checked. By default the UI provides protection against modifying LDAP managed authentication domains and roles as changes from the UI would only be temporary until the next LDAP synchronization. Enabling admin access removes this UI restriction. |
Authentication Type | Do not change this unless instructed by support. |
LDAP Role Adapters
LDAP Role Adapters are used to map users to roles within enPortal. To create a new LDAP Role Adapter right-click on the ldap repository to be used and select New Role Adapter. To edit an existing adapter, right-click on the adapter and select Edit Adapter. Make sure to click the Save button when complete.
Field | Description |
---|---|
Fully qualified portal role | Unique enPortal role name which is used as a base for the roles read in by the adapter. For example: /myLDAProles. This cannot be changed after creating the adapter. |
Search Base | Identifies a unique node in the directory server to perform the search for LDAP groups. For example: ou=Groups,dc=edgeti,dc=com |
Search Scope | Determines the scope of the search - just search within the search base (One Level) or recursively search children objects (Recursive). |
Search Filter | The search may contain results that should be mapped to enPortal and the search filter can be used to exclude search results. See below the Role Class' already filters the results for only matching classes. |
Role ID attribute key | This represents the LDAP attribute which is the name for the role, for example: cn. |
Role Class | Only objects of this class are used, for example posixGroup or groupOfUniqueNames. |
Domain/User assignment attribute key | This LDAP attribute is what's used to assign users into the role - i.e. the usernames. For example: memberUid or uniqueMember. |
Maximum roles | By default 0 indicates no limit. When first configuring LDAP it may be useful to place a specific limit on large directory services to avoid issues when performing synchronisation until the base, scope, and filtering is fine tuned to only return the desired results. |
Search Timeout | By default 0 indicates no limit. Similar to above. |
LDAP Domain Adapters
LDAP Domain Adapters are used to map users within a directory service to users in enPortal. To create a new LDAP Domain Adapter right-click on the ldap repository to be used and select New Domain Adapter. To edit an existing adapter, right-click on the adapter and select Edit Adapter. Make sure to click the Save button when complete.
The configuration for domain adapters is split into the following 3 sections:
General
Field | Description |
---|---|
Name | This is a unique name for this domain adapter. Users who are a member of this authentication domain are required to enter this on the login page along with their username and password. In other words, the name is visible to end-users. It is not possible to change this name after creating the domain adapter. |
Default Role | Optional field to automatically assign a role to users in this domain. Can be left blank. Alternatively a Role Adapter can be configured to map users to roles, or both. |
Session Expiry | This can be used to override the system default inactivity timeout for users within this domain. |
Session Extension | Used in conjunction with above to extend a session when a user is active in the system. |
Pluggable Authenticator | enPortal ships with a number of authenticators depending on the directory server type. The default setting should work in the generic case but the following alternatives are available:
|
Authentication Type | Do not change this unless instructed by support. |
Search
Field | Description |
---|---|
Search Base | Identifies a unique node in the directory server to perform the search for LDAP users. For example: ou=People,dc=edgeti,dc=com |
Search Scope | Determines the scope of the search - just search within the search base (One Level) or recursively search children objects (Recursive). |
Search Filter | The search may contain results that should be mapped to enPortal and the search filter can be used to exclude search results. See below the User Class already filters the results for only matching classes. |
User ID Attribute key | This represents the LDAP attribute which is the name for the user, for example: uid. |
User Class | Only objects of this class are used, for example inetOrgPerson. |
Maximum Users | By default 0 indicates no limit. When first configuring LDAP it may be useful to place a specific limit on large directory services to avoid issues when performing synchronisation until the base, scope, and filtering is fine tuned to only return the desired results. |
Search Timeout | By default 0 indicates no limit. Similar to above. |
Post
Field | Description |
---|---|
Remove UID Prefix | For cases where LDAP usernames include prefix characters that should be removed before creating enPortal User Names. |
Remove UID Suffix | For cases where LDAP usernames include suffix characters that should be removed before creating enPortal User Names. For example: the LDAP username may be jadams@company.com and setting this field to @company.com would result in an enPortal User Name of jadams. |
Synching enPortal and LDAP
Once you have created enPortal Domain and Role adapters that are mapped to LDAP, you may want to execute a command to load Users from LDAP into enPortal.
There are two approaches for creating Users in enPortal from an external LDAP repository:
- Lazy Load - This is an on-demand approach. When a User logs in to enPortal, enPortal queries LDAP for the User's information and then loads it into enPortal.
- LDAP Sync - The LDAP Sync command is run by the enPortal administrator. It copies some or all of the Users and/or Roles from LDAP into enPortal as a batch process. It can be run one time on a new system, and can also be run at regular intervals, if desired.
- Advantages of using LDAP Sync
- The enPortal administrator can see all of the Users in the enPortal user interface.
- The enPortal administrator can provision content to Users in the enPortal user interface.
- Advantages of using LDAP Sync
Perform the following steps to run LDAP Sync:
- Log in to enPortal as an administrator
- Under the Advanced tab, select Explore System
- Click on the /Explorer/Directory/system/LDAPSync channel
- Select the appropriate parameters for the sync
- Roles - Check the Roles box to only sync Roles but not Users. This can be useful in the case where you are using the Lazy Load method for loading Users, but you want to configure the Roles to have the appropriate assignments of Content, Look and Feel, etc.
- Update / Create / Delete - Check one of these boxes to identify what type of sync to run:
- Update - run the creation and deletion syncronization scripts
- Create - run only the creation synchronization scripts; will create in enPortal any new objects that are found in LDAP but not in enPortal
- Delete - run only the deletion synchronization scripts; will delete from enPortal any objects that are found in enPortal but not in LDAP
- Enter the name of the Repository which you want to sync. It must match the name of a Repository under the LDAP Repositories section.
- Click “Start” to run the sync
Avoiding Sync Count Overload Issues
Of the options outlined above, it is generally recommended to sync the Roles and then use an on-demand sync to load users as they log in to the system. However, in some cases you may want to do a full sync of all users from LDAP into enPortal or AppBoard. In this case, care needs to be taken as it is not uncommon for LDAP to have settings that will timeout a large sync or disallow the synching of a large number of users at one time.
Perform the following steps to sync all users in a controlled manner:
- Edit the file [INSTALL_HOME]\config\custom.properties. Create the file if it does not already exist for another purpose.
- Add the following line:
- ldap.pagingSupported=true
- Save the file
- Re-start enPortal/AppBoard
- Re-run the LDAP Sync
Any sync commands will now use the count limits on the domain adapter and role adapter to run a set of queries that will retrieve a limited set of items on each query. This will avoid trying to sync all of the users at one time, which can cause the issues noted above.
LDAP With SSL
In some cases, an LDAP server will require a SSL connection. enPortal supports using LDAP with SSL. To incorporate SSL into the LDAP solution, perform the following two additional steps:
- Specify ldaps:// and secured port in the connection details defined in the LDAPRepository that is registered.
- Add the cert to the cacerts file in JAVA_HOME/lib/security (where JAVA_HOME is the Java runtime that enPortal is configured to run with). Some details on how to do this can be found at http://docs.oracle.com/javaee/1.4/tutorial/doc/Security6.html.
Session Variables from LDAP
Sometimes you will want to pull in user information that was provisioned in LDAP. The goal is to have AppBoard/enPortal pass these settings from LDAP to the back-end application or data source filters.
You can define any number of variables to pull in from the user's LDAP context. Here's how you can pull in the: 'email', 'phone', and 'branch' values.
- Edit [INSTALL_HOME]/webapps/enportal/WEB-INF/custom.properties
- Add a line for each variable to pull from the user's LDAP context prefixed with ldap.userInfo., in this example:
- ldap.userInfo.email
- ldap.userInfo.phone
- ldap.userInfo.branch
The following syntax shows how these variables can be accessed via SHIM expressions:
- email: ${shim:session.var.userInfo.key.email}
- phone: ${shim:session.var.userInfo.key.phone}
- branch: ${shim:session.var.userInfo.key.branch}