4 4 3 Grolar:Configuring LDAP/AD Authentication
Overview
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.
When LDAP authentication is enabled, the login sequence to SEP sesam is as follows:
- A user logs in to SEP sesam by entering the appropriate credentials (username and password).
- If LDAP and/or AD authentication is enabled in SEP sesam and users are mapped accordingly, then SEP sesam user database will contain both, local users and users imported from the LDAP/AD directory. LDAP/AD authentication then allows users to log in to SEP sesam according to their entry in the LDAP/AD directory and the user mapping information.
- If both, LDAP and AD authentication are enabled, SEP sesam checks AD first and if the user cannot be found it also checks LDAP.
- Access to SEP sesam is denied if the user is not found, or if a user is not a member of configured authorization groups.
Note that disabling LDAP/AD does not remove your existing LDAP settings. It only disables SEP sesam integration with LDAP. You can enable LDAP/AD authentication again at any time by selecting the check box Enable LDAP/AD (see step 2).
Note | |
When using LDAP authentication, SEP sesam authenticate against LDAP which may result in delay and slower SEP sesam login performance because the LDAP server requires time to make a network connection and retrieve the data. |
You can enable SSL connections to your LDAP/AD server to secure LDAP for authentication by importing a public certificate of certification authorities (CAs) which signs your LDAP server certificate to the Java keystore on the SEP sesam Server. For details, see Example for securing LDAP with eDirectory.
Note that the setup of LDAP/AD with SEP sesam requires profound knowledge of LDAP administration.
Requirements
- LDAP or AD (whichever you intend to use for authentication) already exists in your organization environment and its service is running (for example, Active Directory, OpenLDAP, NetIQ eDirectory, etc.).
- SEP sesam Server with enabled database authentication (authEnabled parameter set as true in the sm.ini file).
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 will be 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). Consequently, SEP sesam will authenticate users against the external LDAP directory in addition to its own database authentication.
Configuring LDAP authentication is a two step process: The administrator has to configure users on the LDAP server (in our examples, OpenLDAP and NetIQ eDirectory) and then enable LDAP authentication under the Permission Management in GUI.
OpenLDAP configuration
- 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 MemberOf right to ensure that the specified account can read the group memberships of all User accounts in the domain. This user can attach other users to the relevant group.
- 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 and note all LDAP containers with existing users, which should be granted to use SEP sesam.
- Identify and note 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
(Micro Focus) NetIQ eDirectory configuration
- 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 and note all eDirectory LDAP containers with existing users, which should be granted to use SEP sesam.
- Identify and note 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
Enabling LDAP in GUI
After you configure users on the LDAP server (OpenLDAP or NetIQ eDirectory), you may enable LDAP authentication under the Permission Management in GUI to map external groups to SEP sesam internal groups (Admin, Operator or Restore).
- In the GUI, from the menu bar select Configuration ‐> Permission Management. Note that the database authentication has to be enabled. For details, see Configuring Database-Based Authentication.
- Select Enable LDAP checkbox and click OK.
- After enabling LDAP authentication and confirming your action, SEP sesam GUI will restart automatically. You have to restart GUI client manually for the changes to take effect.
- Switch to LDAP tab and enter the values which you obtained during configuration of OpenLDAP or eDirectory, as shown in the screenshot for eDirectory below. You can also change SEP sesam permission configuration by changing URL to
ldaps://<ldap server name>:636/
. - 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 groups to SEP sesam internal groups. Note that access to SEP sesam is denied if the LDAP user is not a member of configured authorization groups.
Note | |
To enable or disable LDAP authentication, you only have to (de)select the relevant check box. Note that clicking the button Deactivate Authentication will deactivate SEP sesam database-based authentication together with any other enabled (LDAP/AD) authentication method. |
Note | |
If you have configured multiple user base containers, you have to enter their names followed by a comma, for example, cn={0},ou=users,o=sep;cn={0},ou=it,o=sep;cn={0},ou=gurus,ou=it,o=sep. |
You can configure any number of groups. The screenshot below shows all configured groups from OpenLDAP and NetIQ eDirectory examples.
Configuring AD authentication
Note | |
SEP sesam Active Directory authentication method is not compatible with Azure AD. |
The process of configuring AD authentication is much simpler than configuring LDAP authentication. You only need to enable Active Directory under the Permission Management in GUI to map AD external groups to SEP sesam internal groups (Admin, Operator or Restore). Consequently, SEP sesam will authenticate users against the external AD directory in addition to its own database authentication.
- Create a new AD group on the domain controller or use an existing AD group. In this example, we created a new AD group named SEPADMIN and added some specific AD user to this group. We want to use this AD group for SEP sesam admin access.
- In the GUI, from the menu bar select Configuration ‐> Permission Management. Note that the database authentication has to be enabled. For details, see Configuring Database-Based Authentication.
- Select Enable Active Directory check box and click OK.
- After enabling AD authentication and confirming your action, SEP sesam GUI will restart automatically. You have to restart GUI client manually for the changes to take effect.
- Switch to the AD tab and enter URL of the Active Directory domain controller and a Domain to configure the connection to the AD directory server.
- Switch to External Groups tab and click Create for each external AD group you want to map to SEP sesam groups: select ADMIN, OPERATOR or RESTORE. You can configure any number of groups.
Click OK to map your external AD groups to SEP sesam internal groups. - Reopen the SEP sesam GUI and log in with an AD user. Only AD users who are members of the specified AD group can log in to SEP sesam. Note that access to SEP sesam is denied if the AD user is not a member of the configured authorization groups or if the AD user is disabled.
Note | |
To enable or disable AD authentication, you only have to (de)select the relevant check box. Note that clicking the button Deactivate Authentication will deactivate SEP sesam database-based authentication together with any other enabled (LDAP/AD) authentication method. |
Note | |
An AD URL must begin with the protocol prefix ldap://. |
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 a public certificate of certification authorities (CAs) which signs your LDAP server certificate to the Java keystore on the SEP sesam Server. Note that eDirectory works with self-signed certificates (eDirectory tree CA).
The following example shows SEP sesam Linux Server (SLES). To use the OpenLDAP client securely on SLES, the eDirectory certificate needs to be exported. Then you have to import it to SEP sesam.
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.
- Select the magnifying glass to browse to the container where the <Tree Name> CA object resides and select it. Click OK.
- Switch to Certificates tab.
- Select Self Signed Certificate check box, and click Validate.
- Select Self Signed Certificate check box again, and click Export.
- Deselect 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 or descriptive 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 have to first 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, so the appropriate keystore for this version is /usr/java/jre1.8.0_144/lib/security/cacerts.
The following example shows how to import public certificate on the Linux server with running Teaming server software. After the certificate was exported, it has to be visible on the Linux server. You can accomplish this by drive mapping/mounting, or by copying the files locally.
Procedure:
- Open a terminal prompt and switch to the root user (hint: su (substitute user) command).
- In the terminal prompt, enter keytool, and press Enter.
- Import the public certificate (for example, SelfSignedCert.der) 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 anc close the terminal prompt.
Tip | |
This should just display a list of commands and options which are needed for checking if the keytool application is in the path. If not, you should add or change the path in the Java bin directory 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 have the manually imported certificate yet. 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.
Commands examples
- You can check in the keytool application if the certificate has been imported properly 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 the password, enter changeit.
Output example
Keystore-Kennwort eingeben: oes15tree, 07.05.2018, trustedCertEntry,
- You can check acces 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/, a 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