Management of Users

Users can be created both manually and automatically through SAML2 authentication. To begin the process:

1. Create User Folders: First, establish folders within the Users module to organize users. This requires a user template with the code “admin.”
2. Add Users: With the template in place, you can start adding users:
   1. Open the Permissions view from the Administration UI.
   2. Select “Users and roles” in the tree pane.
   3. Click “New folder” in the display menu. 
   4. After you have named the folder, assigned permissions, and saved the folder, it appears in the Permissions tree pane.
   5. Next, add the admin template as an allowed template, enter a code for the folder, and save again.

Manual Creation of Users

To manually create a user:

1. Navigate to the appropriate folder.
2. Select "New user" to open the Efecte User view.
3. Give the new user a name. 
4. Fill in the required information (if any).
5. Click Save.

The information about the new user appears in the ESM content area, and the name of the new user appears under the active folder in the permissions tree pane

Automatic Management of Users

Automatic user creation, updating, and deletion can be orchestrated using the Efecte Provisioning Engine (EPE) by using an Orchestration-node within the workflows. Refer to the EPE documentation for comprehensive details.

User Specific Settings

User-specific settings allow customization of authentication methods and interface preferences, including language and time zone. These settings are unique to each user.

Click Settings in the display menu to open the User settings view:

User Specific Security Settings

• Authentication Method: Choose between ID/password (Other), LDAP AD-based, or SAML2 authentication. Each method has its specifics regarding user ID matching and role assignment.
  • a.    If Other authentication method is selected, then ESM user can be authenticated either locally with user ID/password stored in database or with NTSM authentication with user ID stored in database or with user ID retrieved through LDAP interface.
  • Typically, LDAP authentication uses Windows Active Directory. You need to specify the LDAP settings (usually, LDAP servers) under Pluggable authenticator settings section of the platform settings (editable via Administration > Maintenance > Edit settings). 
    • NOTE! If LDAP authentication is used, the user’s Efecte user ID must match an existing user ID in the LDAP system, and LDAP must be added as the first value in the auth.chain platform setting. The user-specific LDAP setting configured in the User Specific Security Settings view can be overridden with auth.chain platform setting. 
    • If other authentication methods (i.e., database or ntlm) are listed in the auth.chain value prior to LDAP, authentication will first be attempted using them, regardless of the setting in the user’s Security Settings view. 
    • If LDAP is missing from the auth.chain value, LDAP authentication will never be attempted, regardless of the setting in the user’s security settings view.
  • When SAML2 authentication is enabled, then the roles of an ESM user are assigned according to the roles identified inside of the SAML2 messages. 
    • When SAML2-authentication is used, then it is not possible to assign roles in the ESM Administration UI to a user manually but only through the SAML2 message. 
    • NOTE! External IDs identifying the roles must be mapped to ESM roles in the role editor view.
• ESM User ID and Password: For local authentication, specify the user ID and password.
  • Note that only the root user is allowed to modify user IDs.
• ESM User Level: Options include:
• Normal - View, edit, and delete templates, folders, and data cards as determined by the user role permissions.
• Read-only - Read data cards as determined by the user role permissions.
• Root - unlimited rights to ESM data and data maintenance, without any user role restrictions. 
  • Use the root user level carefully, as it is exceptionally powerful.

User’s Time Zone Settings

Enabling multiple.timezone.support allows users to set their preferred time zone, enhancing the global usability of ESM.

Authentication Method

You can select whether to authenticate users based on user ID/password (Other), LDAP AD-based authentication (LDAP), or SAML2-authentication (SAML2).

Automatic Creation of Users with SAML2

SAML2 authentication facilitates automatic user creation based on attribute information within SAML2 messages, assigning roles and user levels accordingly. This shifts user management (with the exception of root users) to the identity provider, like Efecte Identity Management (EIM) or Secure Access (ESA).

Note, that in case SAML2 –based authentication is used for user, the whole role management must be handled through the EIM or ESA. Even if authentication method is changed manually to LDAP, added new roles to user, the authentication will be changed back to SAML 2.0 at the next login in case where the EIM or ESA sends the user level information.

Configuring SAML2-based Authentication

To utilize SAML2-based authentication:

1. Adjust the authentication chain in platform settings to include SAML2.
2. Configure the identity provider to send required attributes by Shibboleth.
   1. §roles - list of roles as string separated by ';' character.
   2. esm_userLevel - ossible values Root, Normal, Readonly, NoAccess.
   3. esm_email - For creating person, required.
   4. esm_firstName - For creating person, optional.
   5. esm_lastName - For creating person, optional.
3. Map ESM roles to those identified through SAML2 in the role editor.

Role mapping in the role editor view:

Configuring NTLM Authentication (On-premise)

Applicable only for on-premise installations, NTLM authentication allows users to log in with their Windows credentials. 

Note! This applies only for on premise ESM installations. 

If ESM is configured to use NTLM HTTP Authentication, users can log into ESM with their Windows credentials without the need to re-enter the user name and password (once they are logged on to their Windows workstation). NTLM HTTP Authentication is a challenge/response protocol: the server sends challenge to the client (i.e. browser), and the server and client responds over the HTTP.

ESM supports both NTLMv1 and NTLMv2 protocols. The older v1 protocol is not anymore recommended to be used and doesn't even work with the default settings of newer Windows workstations and servers. ESM supports the older protocol version for backwards compatibility.

With setting auth.sso.use.fully.qualified.account.name ESM can be configured to compare Windows username to ESM username using fully qualified account name (DOMAIN\username). This configuration works with all SSO authentications: NTLMv1, NTLMv2 and Kerberos. This requires that ESM users have their User IDs in format DOMAIN\username.

How to use NTLM Authentication in ESM:

1. Users must have the same username in Windows domain and ESM.
2. NTLM must be configured as one of the authentication methods. 
   1. This can be done by adding the value negotiate or NTLM (for NTLMv1) to the setting auth.chain (from Administration > Maintenance > Edit settings) – for example, auth.chain = negotiate, database. This example configuration enables NTLMv2 authentication for ESM and makes it the first authentication method that will be tried.
      

      Note:

      The most common configuration values are database; LDAP, database; and negotiate, LDAP, database. If both NTLM and negotiate are configured at the same time, only negotiate will be used. 
      Negotiate (or NTLM) needs to be the first option in list, if it will be used. Otherwise 1) if the primary log-in method is successful, NTLM authentication will also be carried out, but it is never used in ESM, or 2) if the primary log-in method fails, log-in seems to succeed with any password, as NTLM authentication will be used as a fallback but no notification of this is shown.

       
3. For NTLMv1 only: Domain controllers must be configured. For example, if users could belong to one of the domains SALES and DEVEL, the domain controllers for both domains must be given. This is done by adding the following lines to the platform settings:
   1. auth.ntlm.SALES.domaincontroller = salesdc.mycompany.com
   2. auth.ntlm.DEVEL.domaincontroller = develdc.mycompany.com
   3. The general form of this setting is auth.ntlm.<NetBIOS name of the domain>.domaincontroller. 
      1. Please note that NetBIOS name is only a portion of a fully qualified domain name – for example, sales.mycompany.com is a fully qualified domain name, and SALES is the NetBIOS name of the domain.) The value of the setting is a DNS name, a fully qualified domain name or an IP-address of the domain controller of the respective domain.
         

         Note:

         There can also be multiple domaincontrollers. In such a case, the first domaincontroller is configured as auth.ntlm.DOMAIN.domaincontroller and the subsequent domaincontrollers as: auth.ntlm.DOMAIN.domaincontroller.1, auth.ntlm.DOMAIN.domaincontroller.2 and so forth.

          

For NTLMv1 only: Note that the setting auth.ntlm.defaultdomaincontroller should be configured too (it is located under the Pluggable authenticator settings section of the platform settings). The value of the setting is a DNS name, a fully qualified domain name or an IP-address of the domain controller. This setting is used if the browser does not send information about the domain or the domain is not known. The problematic case is where an IE user is coming from an unknown domain. If the default domain controller is not configured, the IE thinks that the NTLM negotiation is not finished and it will not send the user name and password from the login form to the ESM server. That is, the authentication will always fail.

Browser support for NTLM HTTP Authentication

Microsoft Internet Explorer will negotiate NTLM HTTP authentication transparently. Once IE has negotiated NTLM HTTP authentication, it will proactively renegotiate the NTLM for POST requests for all content associated with the server. This means the IE will renegotiate every time it needs to send POST data to ESM (e.g. data card saving). It is possible to change the IE's behavior but it requires editing Windows registry.

For the NTLM authentication to function as intended, IE Security Settings need to be configured in the following way:

1. ESM URL must be configured as a trusted site in IE (from Internet Options > Security > Trusted sites > Sites > Advanced).
2. The Logon option in IE security settings must be set to either “Automatic logon only in Intranet zone” or “Automatic logon with current username and password” (from Internet Options > Security > Trusted sites > Custom Level…).

Internet Explorer security settings for NTLM authentication:

Mozilla and Mozilla-based browsers such as Firefox support NTLM HTTP authentication, but will always prompt the user for credentials. However, it is possible to configure Mozilla-based browsers to perform NTLM negotiation transparently: 

1. Start the browser.
2. Write about:config to address bar.
3. Edit the preference network.automatic-ntlm-auth.trusted-uris: The value of this preference is a comma-separated list of URL prefixes or domains. Add the URL prefix for your ESM server, for example, http://efecteserver.

This change can also be done to a Mozilla configuration file for easier deployment.

Configuring Kerberos Authentication (On-premise Only)

For the widest possible client support and best security, Kerberos authentication can be used. The downside with Kerberos is, that while it is the most secure authentication option, it's also the most difficult to get working properly. For most cases where there are only Windows workstations, NTLMv2 should be more than enough and is much easier to get working. 

With setting auth.sso.use.fully.qualified.account.name ESM can be configured to compare Windows username to ESM username using fully qualified account name (DOMAIN\username). This configuration works with all SSO authentications: NTLMv1, NTLMv2 and Kerberos. This requires that ESM users have their User IDs in format DOMAIN\username.

How to configure Kerberos Authentication in ESM

1. Users must have the same username in Windows domain and ESM.
2. Negotiate must be configured as one of the authentication methods. This can be done by adding the value negotiate to the setting auth.chain (from Maintenance > Edit settings) – for example, auth.chain = negotiate, database. This example configuration enables Kerberos negotiate authentication for ESM and makes it the first authentication method that will be tried.
3. Change value of platform setting negotiate.protocol to Negotiate. Please note that changes to this setting will not take effect until ESM service is restarted.

If you want to run ESM service with some other user than Local System, you need to disable the need for Kerberos pre-authentication for that user in Active Directory and create a Service Principal Name (SPN) for it that matches the server where ESM is run. Here's an example of the SPN: HTTP/efecteserver.domain.com.

Browser configuration for Kerberos authentication is the same as for NTLM in Internet Explorer. In Firefox, the setting where the ESM server needs to be added is network.negotiate-auth.trusted-uris.

LDAP Authentication with Multiple Domains (On-premise Only)

Authentication from multiple domains can be enabled by setting value of platform setting auth.ldap.multidomain.enabled to true. 

LDAP urls must be given using settings auth.ldap.host.uri.DOMAIN where word DOMAIN must be replaced with the actual name of the domain. This setting can have multiple values separated by comma. Example: auth.ldap.host.uri.SALES= ldap://dc1:3268,ldap://dc2:3268

All the domain controllers that are used here need to have Global Catalog (GC) enabled (default port for it is 3268). GC is needed because we don't have base DNs defined for the domains and only GC allows searches without it. Users logging into ESM must give their username in format DOMAIN\username.

Servlet Authenticator

Servlet authentication can be set up through specific platform settings, enabling login control based on Active Directory groups and the automatic creation of user accounts in ESM based on servlet authentication.

• servlet.auth.admin.ad.group - Name of the AD group that allows admin users to log in to ESM. Multiple groups are supported. The values should be separated with commas.
• servlet.auth.create.users - If the user account doesn't exist already, it will be created. Default value true.
• servlet.auth.person.groups.attribute.code - Group attribute code on "person template" that contains a reference to "Active Directory Group" template.
• servlet.auth.person.template.code - Template code that has personal information.    
• servlet.auth.person.uid.attribute.code - Group attribute code on "person template" that contains a string for user id in Active Directory.
• servlet.auth.person.user.attribute.code - Group attribute code on "person template" that contains a reference to Efecte User template.
• servlet.auth.user.ad.group - Name of the AD group that allows normal users to log in to ESM. Multiple groups are supported. The values should be separated with commas.
• servlet.auth.user.folder.code - Folder code of a Permissions-tree folder where new user will be created.
• servlet.auth.user.name.attribute.code - Group attribute code on "User"-template that contains a string for the username.    
• servlet.auth.user.person.attribute.code - Group attribute code on "User"-template that contains a reference to Person-template.
• servlet.auth.user.readonly.roles - Admin role name, that will be given to users, who are recognized as read-only users. 
  • Those don't belong to "servlet.auth.user.ad.group" or "servlet.auth.admin.ad.group". 
    • If this setting is blank, users who don't belong to either of those roles cannot log in.    
• servlet.auth.user.roles - Admin role name, that will be given to users, who are recognized as normal users. See "servlet.auth.user.ad.group".