5 1 0:Configuring LDAP/AD Authentication
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.
Note | |
|
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.
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:
- 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.
- 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
- In the LDAP browser, enter the DNS name/IP address of your LDAP server, for example, sles11-nfs.jge.home.
- 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.
- Define a container (LDAP tree level) where your groups reside. For example, the base for groups are ou=group,dc=jge,dc=home.
- Specify the group names; you can use sepadmin, sepoperators and/or seprestore.
- Identify all LDAP containers with existing users that will be granted access to SEP sesam.
- 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
- 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.
- Switch to the Sources tab and click the + (plus) button to add a new authentication source.
- 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.
- 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.
(Micro Focus) NetIQ eDirectory configuration
Step 1: Identify LDAP parameters and values
- Log in to iManager as an administrator.
- Enter the DNS name/IP address of your eDirectory LDAP server, for example, oes15-srv1.sep.de.
- Create a (service) user within your eDirectory tree or use an existing user that has the permission to read users' group.
- Define the container where your groups will reside.
- Specify the group names; you can use sepadmingroup, sepoperatorgroup, sepbackupgroup (v. ≥ 5.0.0 Jaglion), seprestoregroup.
- Identify all eDirectory LDAP containers with existing users who will have access to SEP sesam.
- Identify the unique identifier of your users.
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
- 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.
- Switch to the Sources tab and click the + (plus) button to add an authentication source.
- 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.
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.
- 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.
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:
Configuring Active Directory (AD) authentication
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
- 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.
- 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.
- Identify the domain extension of the User logon name that a user logs on with. This is especially important in multi-domain environments.
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
- 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.
- 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.
- 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. 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.
Then repeat the process for each AD source you want to add. In our example, two AD sources were added to SEP sesam.
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.
- You can enable or disable each source by checking the check box in the column Enabled.
- 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.
- 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.
- 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.
- Import the public certificate to the Java KeyStore of the Java VM used by the SEP sesam Server by using a Java keytool.
- Change the LDAP source protocol in the SEP sesam GUI (Permission Management -> tab Sources) from ldap to ldaps and add the relevant LDAP port.
- Restart the RMI service on the SEP Sesam Server by using the following command:
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.
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.
- Launch and log in to iManager.
- Select eDirectory Administration -> Modify Object.
- Then select Modify object.
- Use the magnifying glass to navigate to the container where the <Tree Name> CA object resides and select it. Click OK.
- Switch to the Certificates tab.
- Select the Self Signed Certificate check box and click Validate.
- Select the Self Signed Certificate check box again and click Export.
- Clear the Export private key check box and click Next.
- Select Save the exported certificate. Note that you can select either File in binary DER format or File in Base64 format.
- Save the file and give your certificate a meaningful name that uniquely identifies it, for example, SelfSignCert.der.
- 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:
- Open a terminal prompt and switch to the root user (hint command: su).
- In the terminal prompt, enter keytool and press Enter.
- Import the public certificate (for example, SelfSignedCert.b64) into the Java CA KeyStore by using the following command:
- When prompted for a password, enter changeit.
- Accept the certificate import by answering yes and close the terminal prompt.
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. |
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
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. |
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.
- Open iManager and enable LDAP trace.
- On the shell or in iMonitor, use ndstrace and enable only LDAP trace.
- 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 (successful)
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 (unsuccessful, 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
See also
About Authentication and Authorization – Configuring Database-Based Authentication – Configuring Certificate-Based Authentication - User Roles and Permissions – Using Access Control Lists