Source:Configuring LDAP/AD Authentication

From SEPsesam
Revision as of 15:56, 13 January 2021 by Sta (talk | contribs) (Marked this version for translation)
Other languages:

Template:Copyright SEP AG en

Docs latest icon.png Welcome to the latest SEP sesam documentation version 4.4.3 Beefalo V2. 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 way SEP sesam can 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 assigned user types.

  • Note that the setup of LDAP/AD with SEP sesam requires profound 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. Once the first match is found, a source directory is queried about the user group membership.
  • The groups returned by the directory are compared to 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 any configured authorization group.
Information sign.png Note
  • When SEP sesam authenticates against LDAP, it may result in slower SEP sesam login performance as the LDAP server requires time to make a network connection and retrieve the data.
  • The login process stops after the first match of the user name. If there are users with the same login names in different sources, only the first matching user will be able to log in.

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

Disabling LDAP/AD sources does not remove your existing LDAP settings. It only disables SEP sesam integration with this specific LDAP/AD source. You can reenable the LDAP/AD authentication at any time by selecting the check box Enable 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 prior to configuring 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
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 into the LDAP service tree, providing the members of the LDAP groups with SEP sesam access rights depending on the user type (Admin, Operator or Restore). 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 by 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 right 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 one container (LDAP tree level) where your groups reside. For example, 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 member attribute:       cn=Administrator,dc=jge,dc=home
LDAP group container/base:			      ou=group,dc=jge,dc=home
LDAP group which will 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 the 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.
    • Group base and Group filter options are only available if the user interface (UI) mode is set to Expert. This field is NOT visible if the UI mode is set to Basic or Advanced. For details on UI modes, see Selecting UI mode.

    You can also change SEP sesam permission configuration by changing 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 External Groups tab and click Create New for each external group you want to map to SEP sesam groups: select ADMIN, OPERATOR or RESTORE.
    Click OK to map your external LDAP groups to SEP sesam internal groups. Access to SEP sesam is denied if the LDAP user is not a member of any configured authorization group.
  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 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, seprestoregroup.
  7. Identify all eDirectory LDAP containers with existing users that will be granted 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 member attribute:	        cn=Admin,o=sep
LDAP group container/base:		                ou=groups,o=sep
LDAP group which will 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 the 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 authentication source.
  3. In the Authentication Configuration window, select LDAP as a Source Type and specify the values that 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 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) which will be used to log in to the directory service.
    • Password: Define the password used for login to the directory service.
    • Group base and Group filter options are only available if the user interface (UI) mode is set to Expert. This field is NOT visible if the UI mode is set to Basic or Advanced. For details on UI modes, see Selecting UI mode.

    You can also change SEP sesam permission configuration by changing 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 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 External Groups tab and click Create for each external group you want to map to SEP sesam groups: select ADMIN, OPERATOR or RESTORE.
    Click OK to map your external LDAP group to SEP sesam internal groups. Then repeat the procedure 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 any configured authorization group.
  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 member attribute:            uid=ldapreader,cn=users,dc=sep,dc=de
LDAP group container/base:		                   cn=groups,dc=sep,dc=de
LDAP group which will 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 the 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
SEP sesam Active Directory authentication method is not compatible with Azure AD.

The integration of Active Directory with the SEP sesam enables 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: In the first step you have to identify your active directory containers for user searches and the AD groups names that will be used. Then you configure the AD authentication in the SEP sesam GUI by using these values.

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

SEP sesam then authenticates the users according to both, its own database and against 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 will 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 the OU=Users,OU=MyCompany,DC=ad16,DC=local and the 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 User logon name used by a user to log in. 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 which will 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 the AD authentication in the GUI

  1. Make sure that the 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 a Source Type and specify the required values that you have configured before, i.e., URL, Domain and User Search Base DN values.
  3. AD new source filled 01 en.png
    Then repeat the procedure for each AD source you want to add. In our example, two AD sources have been 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 or RESTORE.
  5. Click OK to map your external AD group to SEP sesam internal groups. You can configure any number of groups. Access to SEP sesam is denied if a user is not a member of any configured group. 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 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 any individual 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 displayed values are only of an informative nature.
  • 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 LDAP connection by LDAPS

SEP sesam uses a Java framework for authentication. As SEP sesam is only a user of the Java virtual machine, you have to make sure to secure traffic and use secure connection. This procedure is not part of 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 more details.

  1. Ask your PKI/Root CA administrator for the public certificate of the Root CA used for signing 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.

For importing a certificate to the Java keystore, use the Java keytool (part of every Java installation). Another way to manage this kind of certificate is by using a third party utility for Windows, such as KeyStore Explorer.

Example for securing LDAP with eDirectory

With SEP sesam it is possible to secure LDAP for authentication, however, SEP sesam has to trust the LDAP server certificate. You have to import the public certificate of 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, the eDirectory Root CA certificate needs to be exported. Then you have to import it into the java keystore of the SEP sesam server.

Step 1: Exporting a public certificate from root ca

Note that the iManager must have the latest plugin for the Micro Focus certificate server 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 browse 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. Deselect 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 clearly 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 to Java KeyStore

If you want to import your certificate to Java KeyStore, you first have to identify (as 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, therefore the relevant keystore for this version is /usr/java/jre1.8.0_144/lib/security/cacerts.

The following example shows how to import public certificate on a Linux server. After the certificate was exported, it has to 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 just display a list of commands and options, it's only for checking if the keytool application is in the path. If not, you should add the Java bin directory to the PATH variable to launch the keytool application.
  4. Import the public certificate (for example, SelfSignedCert.b64) into the Java CA KeyStore by using a 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 can find the Java CA KeyStore file which is usually named cacerts in the <java sdk/jdk>/jre/lib/security directory. It is possible that during an update of the Java code, a cacerts is backed up and replaced with a new version which does not yet include the manually imported certificate. In this case, the LDAP authentication on the SEP sesam Server will stop running.
  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
  • Check in the keytool application whether the certificate has been properly imported by using -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 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 if LDAP with eDirectory works properly.

  1. Open iManager and enable LDAP trace.
  2. Enable LDAP trace.jpg
  3. On the shell or 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 correct eDirectory password. In our example for eDirectory, a configured user is sepadmin from the 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