Source:Configuring LDAP/AD Authentication

From SEPsesam
Revision as of 16:38, 8 November 2022 by Jus (talk | contribs) (fixing links)
Other languages:

Template:Copyright SEP AG en

Docs latest icon.png Welcome to the latest SEP sesam documentation version 4.4.3 Beefalo V2/5.0.0 Jaglion. For previous documentation version(s), check LDAP/AD documentation.


Overview

Keep in mind that the LDAP/AD configuration in SEP sesam is version specific. Make sure to follow the appropriate instructions for your specific version.

SEP sesam can be configured to use LDAP (Lightweight Directory Access Protocol) authentication in combination with database-based authentication. This allows SEP sesam to authenticate users against an external LDAP directory (Active Directory, OpenLDAP, NetIQ eDirectory, etc.) in addition to its own database authentication. It provides integration of user and password management together with SEP sesam permissions or access rights granted according to the assigned user types.

As of v. 5.0.0 Jaglion, it is also possible to authenticate users with a signed certificate instead of a user password. For step-by-step procedure, see Configuring Certificate-Based Authentication.

  • Note that setting up LDAP/AD with SEP sesam requires in-depth knowledge of LDAP administration.
  • SEP sesam Active Directory authentication method is not compatible with Azure AD.

How it works

When LDAP authentication sources are configured, the login sequence to SEP sesam is as follows:

  • A user logs in to SEP sesam by entering the appropriate credentials (user name and password).
  • The user name and password are checked against the internal SEP sesam user database.
  • Then the user name and password are checked against the first source in the list. If the user name and password do not match any record, the second/third, etc. source is checked until the first match is found. Then a source directory is queried for user group membership.
  • The groups returned by the directory are compared with the configured external groups in the SEP sesam database. If a user is a member of several groups, he/she can have the permissions of more than one group. In this case, the user is logged in as a member of the group with the highest privileges.
  • Access to SEP sesam is denied if the user is not found, if the user is found but the credentials do not match, or if a user is not a member of a configured authorization group.
Information sign.png Note
  • When SEP sesam authenticates against LDAP, this may result in slower SEP sesam login performance as the LDAP server requires time to establish a network connection and retrieve the data.
  • The login process stops after the first user name match. If there are users with the same login name in different sources, only the first matching user user can log in.

You can enable an SSL connection to your LDAP/AD server to secure LDAP for authentication by importing a public certificate from certificate authorities (CAs) that sign your LDAP server certificate to the Java KeyStore on the SEP sesam Server. For details, see Securing the LDAP connection with LDAPS.

Disabling LDAP/AD sources does not remove your existing LDAP settings. It only disables the SEP sesam integration with that particular LDAP/AD source. You can reenable LDAP/AD authentication at any time by selecting the Enable check box in front of the source definition.

Requirements

  • LDAP or AD user accounts that you intend to use for authentication must already exist within your corporate LDAP/AD before you configure authentication with SEP sesam. The LDAP/AD service must be running (for example, Active Directory, OpenLDAP, NetIQ eDirectory, etc.).
  • SEP sesam Server must have globally enabled authentication. You can set the relevant parameters in the sm.ini file, i.e.
  • [UI] ……………. authEnabled=true auth.db.enabled=true auth.ldap.enabled=true auth.ldap.autocreate=true auth.ad.enabled=true auth.ad.autocreate=true ……………. and activate authentication in the SEP sesam GUI, see Configuring Database-Based Authentication.
  • For the LDAP directory, a user within the respective LDAP tree must have the rights to read the attributes of your LDAP groups.
Information sign.png Note
The SEP sesam Active Directory authentication method is not compatible with Azure AD.

Configuring LDAP authentication

By integrating LDAP and SEP sesam authentication, SEP sesam internal groups are mapped to groups in the LDAP service tree. Members of the LDAP groups are assigned SEP sesam access rights depending on the user type (Admin, Operator, Backup (v. ≥ 5.0.0 Jaglion) or Restore, for details see User Roles and Permissions). SEP sesam then authenticates the users according to both, its own database and against the external LDAP directory.

Configuring LDAP authentication is a two-step process:

  1. Ask your LDAP administrator which LDAP attributes are used for the login name and member value in the LDAP groups or identify the values yourself.
  2. In the SEP sesam GUI, configure an LDAP authentication source and add your LDAP groups to SEP sesam external groups.

OpenLDAP configuration

Step 1: Identify the LDAP parameters and values

  1. In the LDAP browser, enter the DNS name/IP address of your LDAP server, for example, sles11-nfs.jge.home.
  2. Create a (service) user within your LDAP tree or use an existing user with Read permission to the member attribute of groups to ensure that the specified account can read the group memberships of all User accounts in the directory.
  3. OpenLDAP LDAP browser.jpg
  4. Define a container (LDAP tree level) where your groups reside. For example, the base for groups are ou=group,dc=jge,dc=home.
  5. OpenLDAP groups.jpg
  6. Specify the group names; you can use sepadmin, sepoperators and/or seprestore.
  7. Identify all LDAP containers with existing users that will be granted access to SEP sesam.
  8. Identify the unique identifier of your users, for example, ee, jge.

LDAP summary for OpenLDAP example

LDAP server: 					      sles11-nfs.jge.home
LDAP user with read rights of the member attribute:       cn=Administrator,dc=jge,dc=home
LDAP group container/base:			      ou=group,dc=jge,dc=home
LDAP group to be used:                        sepadmin, sepoperators, seprestore
LDAP user container(s)/base(s):		              ou=people,dc=jge,dc=home
LDAP unique identifier:			              uid

Step 2: Configure the LDAP authentication in the GUI

  1. Make sure that database authentication is enabled, as described in Configuring Database-Based Authentication. Then from the SEP sesam GUI menu bar, select Configuration ‐> Permission Management.
  2. Switch to the Sources tab and click the + (plus) button to add a new authentication source.
  3. LDAP new source en.png
  4. In the Authentication Configuration window, select LDAP as a Source Type and specify the values that you have already investigated for OpenLDAP:
    • URL: Specify the LDAP URL for the source directory server instance.
    • User Search Base: Set the pattern which will be used to supply a Distinguished Name (DN) for the user. The pattern name should be related to the root DN. The {0} placeholder will contain the user name.
    • Manager DN: Specify the Distinguished Name (DN) of the service user, which will be used to log in to and request data from the directory service.
    • Password: Define the password used for login to the directory service.
    • The Group base and Group filter options are available only in advanced UI mode (formerly expert GUI mode). To use these options, make sure your UI mode is set to advanced, as described in Selecting UI mode.

    You can also change the SEP sesam permission configuration by changing the URL to ldaps://<ldap server name>:636/. For details on how to secure LDAP for authentication, see LDAP with eDirectory example.

    Click OK.

    LDAP new source filled en.png

  5. Switch to the External Groups tab and click Create New for each external group you want to map to SEP sesam groups: select ADMIN, OPERATOR, BACKUP (v. ≥ 5.0.0 Jaglion) or RESTORE.
    Click OK to map your external LDAP groups to the SEP sesam internal groups. Access to SEP sesam is denied if the LDAP user is not a member of one of the configured authorization groups.
  6. LDAP new external group filled admin en.png

(Micro Focus) NetIQ eDirectory configuration

Step 1: Identify LDAP parameters and values

  1. Log in to iManager as an administrator.
  2. Enter the DNS name/IP address of your eDirectory LDAP server, for example, oes15-srv1.sep.de.
  3. Create a (service) user within your eDirectory tree or use an existing user that has the permission to read users' group.
  4. Define the container where your groups will reside.
  5. IManager.jpg
  6. Specify the group names; you can use sepadmingroup, sepoperatorgroup, sepbackupgroup (v. ≥ 5.0.0 Jaglion), seprestoregroup.
  7. Identify all eDirectory LDAP containers with existing users who will have access to SEP sesam.
  8. EDirectory container.jpg
  9. Identify the unique identifier of your users.
  10. EDirectory identifier.jpg

LDAP summary for eDirectory example:

LDAP server:					        oes15-srv1.sep.de
LDAP user with read rights of the member attribute:	        cn=Admin,o=sep
LDAP group container/base:		                ou=groups,o=sep
LDAP group to be used:			        sepadmingroup, sepoperatorgroup, seprestoregroup						
LDAP user container(s)/base(s):			        ou=users,o=sep; ou=it,o=sep; ou=gurus,ou=it,o=sep							
LDAP unique identifier:				        cn

Step 2: Configure the LDAP authentication in the GUI

  1. Make sure that database authentication is enabled, as described in Configuring Database-Based Authentication. Then from the SEP sesam GUI menu bar, select Configuration ‐> Permission Management.
  2. Switch to the Sources tab and click the + (plus) button to add an authentication source.
  3. In the Authentication Configuration window, select LDAP as the Source Type and specify the values you have already investigated for eDirectory:
    • URL: Specify the LDAP URL that will be used to connect to the directory service.
    • User Search Base: Set the pattern to be used to provide a Distinguished Name (DN) for the user. The pattern name should be related to the root DN. The {0} placeholder will contain the user name.
    • Manager DN: Specify the Distinguished Name (DN) which will be used to log in to the directory service.
    • Password: Define the password used for login to the directory service.
    • The Group base and Group filter options are available only in advanced UI mode (formerly expert GUI mode). To use these options, make sure your UI mode is set to advanced, as described in Selecting UI mode.

    You can also change the SEP sesam permission configuration by changing the URL to ldaps://<ldap server name>:636/. For details on how to secure LDAP for authentication, see LDAP with eDirectory example.

    Click OK.

    EDir new source filled 01 en.png
    Create an authentication source for each LDAP container where your (SEP sesam) users exist. In our example, there are four different LDAP containers (eDirectory contexts) with users.

    EDir new source ready en.png

  4. Switch to the External Groups tab and click Create for each external group you want to map to SEP sesam groups: select ADMIN, OPERATOR, BACKUP (v. ≥ 5.0.0 Jaglion) or RESTORE.
    Click OK to map your external LDAP group to the SEP sesam internal groups. Then repeat the process for each external group you want to map. You can configure any number of groups. Access to SEP sesam is denied if the LDAP user is not a member of one of the configured authorization groups.
  5. EDir new external group filled admin en.png

Univention UCS OpenLDAP configuration

Step 1: Identify the LDAP parameters and values

Use an LDAP browser and identify all required values. Univention UCS uses a non-standard port for LDAP.

In the following example, the attribute of the groups for members is uniqueMember.

LDAP summary for UCS OpenLDAP example:

LDAP server:			                           majestix.sep.de
LDAP port:	                                           7636
LDAP user with read rights of the member attribute:            uid=ldapreader,cn=users,dc=sep,dc=de
LDAP group container/base:		                   cn=groups,dc=sep,dc=de
LDAP group to be used:			           grp-technik
LDAP user container(s)/base(s):			           ou=2_1_2_consulting,ou=2_1_it,ou=2_user,ou=hk,dc=sep,dc=de							
LDAP unique identifier:				           uid
LDAP attribute for group members:                          uniqueMember 

Step 2: Configure LDAP authentication in the GUI

The configuration procedure is the same as for OpenLDAP or eDirectory, described above.

For example, in the source configuration the LDAP connection is secured by LDAPS, as shown in the following screenshot:

UCS new source filled en.png

Configuring Active Directory (AD) authentication

Information sign.png Note
The SEP sesam Active Directory authentication method is not compatible with Azure AD.

The integration of Active Directory with SEP sesam allows you to use user information from the Active Directory server for authentication on SEP sesam. Once the prerequisites are met, the actual configuration is simple: the first step is to identify your Active Directory containers for user lookup and the AD group names to use. Then configure the AD authentication in the SEP sesam GUI using these values.

The queries for the users go through the AD tree, starting from the defined level down. This means that you can define the base DN at the highest level and the query will search for the user throughout the AD tree. This can be a time-consuming process based on the first match policy; once a match is found, any other possible match is skipped.

SEP sesam then authenticates users against both, its own database and the external AD directory.

Step 1: Identify Active Directory parameters and values

  1. Create a new AD group on the domain controller or use an existing AD group. In our example, we use the AD groups named SEPADMIN and SEPOPERATOR.
  2. AD group names.png
  3. Identify the container(s) where your users reside. In our example, all users exist in OU=Users,OU=MyCompany,DC=ad16,DC=local and in OU=Admin-Users,OU=MyCompany,DC=ad16,DC=local. We want to set the search base DN to enable only the users in these OUs access to SEP sesam.
  4. AD User base DN 01 en.png
  5. Identify the domain extension of the User logon name that a user logs on with. This is especially important in multi-domain environments.
  6. AD User domain.png

Example: LDAP summary for Active Directory:

LDAP server:					   ad16-1-dc.sep.de
AD User Domain extension:                          ad16.local
LDAP group container/base:                         cn=groups,dc=sep,dc=de
LDAP group to be used:                     grp-technik 
LDAP user container(s)/base(s):                    ou=2_1_2_consulting,ou=2_1_it,ou=2_user,ou=hk,dc=sep,dc=de

Step 2: Configure AD authentication in the GUI

  1. Make sure that database authentication is enabled, as described in Configuring Database-Based Authentication. Then from the SEP sesam GUI menu bar, select Configuration ‐> Permission Management.
  2. Switch to the Sources tab and click the + (plus) button to add a new authentication source. In the Authentication Configuration window, select AD as the Source Type and specify the required values that you configured earlier, i.e., URL, Domain and User Search Base DN values.
  3. AD new source filled 01 en.png
    Then repeat the process for each AD source you want to add. In our example, two AD sources were added to SEP sesam. AD new source ready en.png
  4. Switch to the External Groups tab and click Create new for each external AD group you want to map to SEP sesam groups: select ADMIN, OPERATOR, BACKUP (v. ≥ 5.0.0 Jaglion) or RESTORE.
  5. Click OK to map your external AD group to the SEP sesam internal groups. You can configure any number of groups. Access to SEP sesam is denied if a user is not a member one of the configured groups. AD new external group filled admin en.png

Managing authentication

The following tips can help you configure and manage your LDAP/AD authentication in combination with SEP sesam:

  • It is possible to mix different authentication sources.
  • The first source is always a SEP sesam internal database.
  • The order of all following authentication sources is determined by the order in the SEP sesam GUI (Permission Management -> tab Sources).
  • You can change the order of the authentication sources by selecting the source entry and moving the rows up and down with the arrows at the bottom of the panel.
  • Auth source sort order en.png
  • You can enable or disable each source by checking the check box in the column Enabled.
  • Auth source enable disable en.png
  • Every user that has logged in is displayed in the SEP sesam GUI: Permission Management -> tab Users.
  • AD and LDAP users are greyed out as it is not possible to manipulate them; the values displayed are for information only.
  • Auth user view en.png
  • AD/LDAP users cannot log in without a working LDAP/AD connection as these users are not valid user objects in the SEP sesam database.

Securing the LDAP connection with LDAPS

SEP sesam uses a Java framework for authentication. As SEP sesam is only a user of the Java virtual machine, you must ensure that the data traffic is secured and that a secure connection is used. This procedure is not part of the SEP sesam configuration. Therefore, the provided steps in this section serve for reference only and are subject to change. Make sure to read your vendor documentation for the most up-to-date steps and further details.

  1. Ask your PKI/Root CA administrator for the public certificate of the Root CA, which is used to sign the certificate of your LDAP server.
  2. Import the public certificate to the Java KeyStore of the Java VM used by the SEP sesam Server by using a Java keytool.
  3. Change the LDAP source protocol in the SEP sesam GUI (Permission Management -> tab Sources) from ldap to ldaps and add the relevant LDAP port.
  4. Restart the RMI service on the SEP Sesam Server by using the following command:
  5. sm_main restart rmi

For detailed information on how to export the Root CA certificate, check the documentation of your Root CA, e.g., Microsoft Certificate Services, Micro Focus eDirectory CA, OpenLDAP, etc.

To import a certificate into the Java KeyStore, use the Java keytool (part of every Java installation). Another way to manage this type of certificate is to use a third party utility for Windows, such as KeyStore Explorer.

Example of securing LDAP with eDirectory

With SEP sesam it is possible to secure LDAP for authentication, however, SEP sesam has to trust the certificate of the LDAP server. You have to import the public certificate of the certification authority (CAs) to the Java KeyStore, which signs your LDAP server certificate. Note that eDirectory works with self-signed certificates (eDirectory tree CA).

The following example shows the SEP sesam Linux Server (SLES). To use a secure LDAP connection, you need to export the eDirectory Root CA certificate. Then you have to import it into the Java KeyStore of the SEP sesam Server.

Information sign.png Note
After exporting and importing the public certificate, you may need to restart the SEP sesam Server to get it working properly again.

Step 1: Exporting a public certificate from root ca

Note that iManager must have the latest Micro Focus certificate server plugin and access to work properly.

  1. Launch and log in to iManager.
  2. Select eDirectory Administration -> Modify Object.
  3. Then select Modify object.
  4. Use the magnifying glass to navigate to the container where the <Tree Name> CA object resides and select it. Click OK.
  5. Switch to the Certificates tab.
  6. Select the Self Signed Certificate check box and click Validate.
  7. Select the Self Signed Certificate check box again and click Export.
  8. Clear the Export private key check box and click Next.
  9. Select Save the exported certificate. Note that you can select either File in binary DER format or File in Base64 format.
  10. Save the file and give your certificate a meaningful name that uniquely identifies it, for example, SelfSignCert.der.
  11. Click Close and then OK to export your public certificate.

After the certificate is exported, copy it to the SEP sesam Server.

Step 2: Importing a public certificate into Java KeyStore

If you want to import your certificate into Java KeyStore, you first have to identify (as the root user) the keystore for your Java version by using a command:

find / -iname 'cacerts'
/usr/java/jre1.8.0_144/lib/security/cacerts
/usr/java/jre1.7.0_40/lib/security/cacerts 

As shown in the example above, SEP sesam uses Java 1.8, so the corresponding keystore for this version is /usr/java/jre1.8.0_144/lib/security/cacerts.

The following example shows how to import a public certificate on a Linux server. After the certificate has been exported, it must be visible on the Linux server. Copy the certificate to your SEP Sesam server.

Procedure:

  1. Open a terminal prompt and switch to the root user (hint command: su).
  2. In the terminal prompt, enter keytool and press Enter.
  3. SEP Tip.png Tip
    This should only show a list of commands and options. It only serves to check whether the keytool application is in the path. If not, you should add the Java bin directory to the PATH variable to start the keytool application.
  4. Import the public certificate (for example, SelfSignedCert.b64) into the Java CA KeyStore by using the following command:
  5. keytool -import -alias < ldap server dns name> -keystore <path to Java CA keystore> -file <certificate file> Example: keytool -import -alias ldap.allnet.com -keystore /etc/alternatives/java_sdk/jre/lib/security/cacerts -file /home/admin/SelfSignedCert.b64
    Information sign.png Note
    You will find the Java CA KeyStore file, normally called cacerts, in the <java sdk/jdk>/jre/lib/security directory. It is possible that when the Java code is updated, a cacerts is backed up and replaced by a new version that does not yet contain the manually imported certificate. In this case, the LDAP authentication on the SEP sesam Server is no longer executed.
  6. When prompted for a password, enter changeit.
  7. Accept the certificate import by answering yes and close the terminal prompt.

The certificate has been imported into the keystore and the SEP sesam Server can use SSL for its LDAP authentication.

Command examples
  • In the keytool application, check that the certificate has been properly imported by using the -list command (keytool -list -keystore <keystore filename>).
/usr/java/jre1.8.0_144/bin/keytool -list -keystore /usr/java/jre1.8.0_144/lib/security/cacerts | grep oes15

When prompted for the password, enter changeit.

Output example

Keystore-Kennwort eingeben:  
oes15tree, 07.05.2018, trustedCertEntry,
  • You can check access to the keystore.
/usr/java/jre1.8.0_144/bin/keytool -list -keystore /usr/java/jre1.8.0_144/lib/security/cacerts 

Output example

Keystore-Kennwort eingeben:  

 Keystore-Typ: JKS
 Keystore-Provider: SUN

 Keystore enthält 105 Einträge

 verisignclass2g2ca [jdk], 25.08.2016, trustedCertEntry, 
 Zertifikat-Fingerprint (SHA1): 
 B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D
 digicertassuredidg3 [jdk], 25.08.2016, trustedCertEntry,
 Zertifikat-Fingerprint (SHA1): 
 F5:17:A2:4F:9A:48:C6:C9:F8:A2:00:26:9F:DC:0F:48:2C:AB:30:89
 ….............
  • You can import the CA public certificate (exported from eDirectory) from /tmp/, the file name is oes15tree_public_cert.der.
/usr/java/jre1.8.0_144/bin/keytool -import -alias oes15tree -keystore  /usr/java/jre1.8.0_144/lib/security/cacerts -file 
/tmp/oes15tree_public_cert.der

Output example

Keystore-Kennwort eingeben:  
 Eigentümer: O=OES15TREE, OU=Organizational CA
 Aussteller: O=OES15TREE, OU=Organizational CA
 Seriennummer: 21c14e16e79e3e28b6e89a3fbda8091477857741cdbf48bc44d12f70a0a0202060dfa50
 Gültig von: Tue Dec 01 11:12:27 CET 2015 bis: Sun Nov 30 11:12:27 CET 2025
 Zertifikat-Fingerprints:
         MD5:  41:48:73:BD:1C:59:C3:C1:5E:00:6D:11:6B:F4:A2:C7
         SHA1: 49:CB:2B:D5:2C:0B:11:2B:31:00:66:08:0E:CC:F4:D4:9F:61:3E:27
         SHA256: 01:61:BA:80:A1:67:6D:C7:15:9C:01:E5:24:F6:5B:BB:20:90:64:6D:95:A8:56:B2:32:37:CA:23:EF:D5:E6:BB
         Signaturalgorithmusname: SHA1withRSA
         Version: 3

 Erweiterungen: 

 #1: ObjectId: 2.16.840.1.113719.1.9.4.1 Criticality=false
 0000: 30 82 01 B7 04 02 01 00   01 01 FF 13 1D 4E 6F 76  0............Nov
 0010: 65 6C 6C 20 53 65 63 75   72 69 74 79 20 41 74 74  ell Security Att
 0020: 72 69 62 75 74 65 28 74   6D 29 16 43 68 74 74 70  ribute(tm).Chttp
 0030: 3A 2F 2F 64 65 76 65 6C   6F 70 65 72 2E 6E 6F 76  ://developer.nov
 0040: 65 6C 6C 2E 63 6F 6D 2F   72 65 70 6F 73 69 74 6F  ell.com/reposito
 0050: 72 79 2F 61 74 74 72 69   62 75 74 65 73 2F 63 65  ry/attributes/ce
 0060: 72 74 61 74 74 72 73 5F   76 31 30 2E 68 74 6D 30  rtattrs_v10.htm0
 0070: 82 01 48 A0 1A 01 01 00   30 08 30 06 02 01 01 02  ..H.....0.0.....
 0080: 01 46 30 08 30 06 02 01   01 02 01 0A 02 01 69 A1  .F0.0.........i.
 0090: 1A 01 01 00 30 08 30 06   02 01 01 02 01 00 30 08  ....0.0.......0.
 00A0: 30 06 02 01 01 02 01 00   02 01 00 A2 06 02 01 18  0...............
 00B0: 01 01 FF A3 82 01 04 A0   58 02 01 02 02 02 00 FF  ........X.......
 00C0: 02 01 00 03 0D 00 80 00   00 00 00 00 00 00 00 00  ................
 00D0: 00 00 03 09 00 80 00 00   00 00 00 00 00 30 18 30  .............0.0
 00E0: 10 02 01 00 02 08 7F FF   FF FF FF FF FF FF 01 01  ................
 00F0: 00 02 04 06 F0 DF 48 30   18 30 10 02 01 00 02 08  ......H0.0......
 0100: 7F FF FF FF FF FF FF FF   01 01 00 02 04 06 F0 DF  ................
 0110: 48 A1 58 02 01 02 02 02   00 FF 02 01 00 03 0D 00  H.X.............
 0120: 40 00 00 00 00 00 00 00   00 00 00 00 03 09 00 40  @..............@
 0130: 00 00 00 00 00 00 00 30   18 30 10 02 01 00 02 08  .......0.0......
 0140: 7F FF FF FF FF FF FF FF   01 01 00 02 04 14 E1 6E  ...............n
 0150: 79 30 18 30 10 02 01 00   02 08 7F FF FF FF FF FF  y0.0............
 0160: FF FF 01 01 00 02 04 14   E1 6E 79 A2 4E 30 4C 02  .........ny.N0L.
 0170: 01 02 02 02 00 FF 02 01   00 03 0D 00 80 FF FF FF  ................
 0180: FF FF FF FF FF FF FF FF   03 09 00 80 FF FF FF FF  ................
 0190: FF FF FF 30 12 30 10 02   01 00 02 08 7F FF FF FF  ...0.0..........
 01A0: FF FF FF FF 01 01 FF 30   12 30 10 02 01 00 02 08  .......0.0......
 01B0: 7F FF FF FF FF FF FF FF   01 01 FF                 ...........


 #2: ObjectId: 2.5.29.35 Criticality=false
 AuthorityKeyIdentifier [
 KeyIdentifier [
 0000: D3 91 1B 7E 38 C8 A1 05   62 61 22 03 8E 38 AD 12  ....8...ba"..8..
 0010: 6F 43 00 B6                                        oC..
 ]
 ]

 #3: ObjectId: 2.5.29.19 Criticality=false
   CA:true
   PathLen:2147483647
 ]

 #4: ObjectId: 2.5.29.15 Criticality=false
 KeyUsage [
  Key_CertSign
  Crl_Sign
] 

 #5: ObjectId: 2.5.29.14 Criticality=false
 SubjectKeyIdentifier [
 KeyIdentifier [
 0000: D3 91 1B 7E 38 C8 A1 05   62 61 22 03 8E 38 AD 12  ....8...ba"..8..
 0010: 6F 43 00 B6                                        oC..
 ]
 ]

 Diesem Zertifikat vertrauen? [Nein]:  Ja
 Zertifikat wurde Keystore hinzugefügt

Checking if LDAP with eDirectory works properly

If you have problems with authentication, check that LDAP is working properly with eDirectory.

  1. Open iManager and enable LDAP trace.
  2. Enable LDAP trace.jpg
  3. On the shell or in iMonitor, use ndstrace and enable only LDAP trace.
  4. LDAP trace output.jpg
  5. Log in to SEP sesam GUI as a user from a mapped group with the correct eDirectory password. In our example for eDirectory, a configured user is sepadmin from the group ou=it,o=sep.

Output example for ndstrace (successfull)

New TLS connection 0x13ae5880 from 192.168.x.x:58610, monitor = 0xcc357700, index = 488
Monitor 0xcc357700 initiating TLS handshake on connection 0x13ae5880
DoTLSHandshake on connection 0x13ae5880
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0x13ae5880
DoBind on connection 0x13ae5880
Bind name:cn=sepadmin,ou=users,o=sep, version:3, authentication:simple
Failed to resolve full context on connection 0x13ae5880, err = no such entry (-601)
Failed to authenticate full context on connection 0x13ae5880, err = no such entry (-601)
Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x13ae5880
Monitor 0xcc357700 found connection 0x13ae5880 ending TLS session
DoTLSShutdown on connection 0x13ae5880
Monitor 0xcc357700 found connection 0x13ae5880 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0xcc357700 initiating close for connection 0x13ae5880
Server closing connection 0x13ae5880, socket error = -5871
Connection 0x13ae5880 closed
New TLS connection 0x13ae5880 from 192.168.x.x:58612, monitor = 0xcc357700, index = 488
Monitor 0xcc357700 initiating TLS handshake on connection 0x13ae5880
DoTLSHandshake on connection 0x13ae5880
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0x13ae5880
DoBind on connection 0x13ae5880
Bind name:cn=sepadmin,ou=it,o=sep, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0x13ae5880
DoSearch on connection 0x13ae5880
Search request:
        base: "cn=sepadmin,ou=it,o=sep"
        scope:0  dereference:3  sizelimit:0  timelimit:0  attrsonly:0
        filter: "(objectClass=*)"
        no attributes
nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
Empty attribute list implies all user attributes
Sending search result entry "cn=sepadmin,ou=it,o=sep" to connection 0x13ae5880
Sending operation result 0:"":"" to connection 0x13ae5880
DoUnbind on connection 0x13ae5880
Connection 0x13ae5880 closed
New TLS connection 0x13ae5880 from 192.168.x.x:58613, monitor = 0xcc357700, index = 488
Monitor 0xcc357700 initiating TLS handshake on connection 0x13ae5880
DoTLSHandshake on connection 0x13ae5880
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0x13ae5880
DoBind on connection 0x13ae5880
Bind name:cn=ldapuser,o=sep, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0x13ae5880
DoSearch on connection 0x13ae5880
Search request:
        base: "ou=groups,o=sep"
        scope:2  dereference:3  sizelimit:0  timelimit:0  attrsonly:0
        filter: "(member=cn=sepadmin,ou=it,o=sep)"
        attribute: "cn"
        attribute: "objectClass"
        attribute: "javaSerializedData"
        attribute: "javaClassName"
        attribute: "javaFactory"
        attribute: "javaCodeBase"
        attribute: "javaReferenceAddress"
        attribute: "javaClassNames"
        attribute: "javaRemoteLocation"
 nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
 Sending search result entry "cn=seprestoregroup,ou=groups,o=sep" to connection 0x13ae5880
 Sending search result entry "cn=sepoperatorgroup,ou=groups,o=sep" to connection 0x13ae5880
 Sending search result entry "cn=sepadmingroup,ou=groups,o=sep" to connection 0x13ae5880
 Sending operation result 0:"":"" to connection 0x13ae5880
 DoUnbind on connection 0x13ae5880
 Connection 0x13ae5880 closed

Output example for ndstrace (unsuccessfull, wrong password)

New TLS connection 0x167e9180 from 192.168.1.11:59405, monitor = 0xcc357700, index = 485
Monitor 0xcc357700 initiating TLS handshake on connection 0x167e9180
DoTLSHandshake on connection 0x167e9180
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0x167e9180
DoBind on connection 0x167e9180
Bind name:cn=sepadmin,ou=users,o=sep, version:3, authentication:simple
Failed to resolve full context on connection 0x167e9180, err = no such entry (-601)
Failed to authenticate full context on connection 0x167e9180, err = no such entry (-601)
Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x167e9180
Monitor 0xcc357700 found connection 0x167e9180 ending TLS session
DoTLSShutdown on connection 0x167e9180
Monitor 0xcc357700 found connection 0x167e9180 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0xcc357700 initiating close for connection 0x167e9180
Server closing connection 0x167e9180, socket error = -5871
Connection 0x167e9180 closed
New TLS connection 0x167e9180 from 192.168.1.11:59408, monitor = 0xcc357700, index = 485
Monitor 0xcc357700 initiating TLS handshake on connection 0x167e9180
DoTLSHandshake on connection 0x167e9180
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0x167e9180
DoBind on connection 0x167e9180
Bind name:cn=sepadmin,ou=it,o=sep, version:3, authentication:simple
Failed to authenticate local on connection 0x167e9180, err = failed authentication (-669)
Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x167e9180
Monitor 0xcc357700 found connection 0x167e9180 ending TLS session
DoTLSShutdown on connection 0x167e9180
Monitor 0xcc357700 found connection 0x167e9180 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0xcc357700 initiating close for connection 0x167e9180
Server closing connection 0x167e9180, socket error = -5871
Connection 0x167e9180 closed
New TLS connection 0x167e9180 from 192.168.1.11:59409, monitor = 0xcc357700, index = 485
Monitor 0xcc357700 initiating TLS handshake on connection 0x167e9180
DoTLSHandshake on connection 0x167e9180
BIO ctrl called with unknown cmd 7
Completed TLS handshake on connection 0x167e9180
DoBind on connection 0x167e9180
Bind name:cn=sepadmin,ou=gurus,ou=it,o=sep, version:3, authentication:simple
Failed to resolve full context on connection 0x167e9180, err = no such entry (-601)
Failed to authenticate full context on connection 0x167e9180, err = no such entry (-601)
Sending operation result 49:"":"NDS error: failed authentication (-669)" to connection 0x167e9180
Monitor 0xcc357700 found connection 0x167e9180 ending TLS session
DoTLSShutdown on connection 0x167e9180
Monitor 0xcc357700 found connection 0x167e9180 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0xcc357700 initiating close for connection 0x167e9180
Server closing connection 0x167e9180, socket error = -5871
Connection 0x167e9180 closed