Source: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 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.
Note | |
|
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.
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:
- 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.
- 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 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.
- Define one container (LDAP tree level) where your groups reside. For example, 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 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
- 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.
- 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.
- 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.
- 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.
(Micro Focus) NetIQ eDirectory configuration
Step 1: Identify LDAP parameters and values
- Log in to iManager as 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, seprestoregroup.
- Identify all eDirectory LDAP containers with existing users that will be granted 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 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
- 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.
- Switch to the Sources tab and click the + (plus) button to add authentication source.
- 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.
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.
- 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.
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:
Configuring Active Directory (AD) authentication
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
- 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.
- 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.
- Identify the domain extension of User logon name used by a user to log in. 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 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
- 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.
- 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.
- 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. 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.
Then repeat the procedure for each AD source you want to add. In our example, two AD sources have been 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 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 any individual 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 displayed values are only of an informative nature.
- 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.
- Ask your PKI/Root CA administrator for the public certificate of the Root CA used for signing 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.
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.
- Launch and log in to iManager.
- Select eDirectory Administration -> Modify Object.
- Then select Modify object.
- Use the magnifying glass to browse 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.
- Deselect 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 clearly 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 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:
- 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 a following command: 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
- When prompted for a password, enter changeit.
- Accept the certificate import by answering yes and close the terminal prompt.
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. |
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. |
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.
- Open iManager and enable LDAP trace.
- On the shell or iMonitor use ndstrace, and enable only LDAP trace.
- 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