4 4 3 Grolar:Configuring LDAP/AD Authentication

From SEPsesam
Jump to: navigation, search
Other languages:
Deutsch • ‎English

Copyright © SEP AG 1999-2018. All rights reserved.

Any form of reproduction of the contents or parts of this manual is allowed only with the express written permission from SEP AG. When compiling and designing user documentation SEP AG uses great diligence and attempts to deliver accurate and correct information. However, SEP AG cannot issue a guarantee for the contents of this manual.

Docs latest icon.png Welcome to the latest SEP sesam documentation version 4.4.3 Grolar. For previous documentation version(s), check documentation archive.

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).

Information sign.png 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).

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

  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 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.
  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 and note all LDAP containers with existing users, which should be granted to use SEP sesam.
  8. 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

  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 and note all eDirectory LDAP containers with existing users, which should be granted to use SEP sesam.
  8. EDirectory container.jpg

  9. Identify and note 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

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).

  1. 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.
  2. Select Enable LDAP checkbox and click OK.
  3. Enable LDAP.jpg

    Information sign.png 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.
  4. 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.
    LDAP restart.jpg
  5. 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/.
  6. Configure LDAP.jpg

    Information sign.png 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.
  7. 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.
  8. Add external group.jpg

You can configure any number of groups. The screenshot below shows all configured groups from OpenLDAP and NetIQ eDirectory examples.
Configured external groups.jpg

Configuring AD authentication

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.

  1. 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.
  2. 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.
  3. Select Enable Active Directory check box and click OK.
  4. Enable AD.jpg

    Information sign.png 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.
  5. 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.
    LDAP restart.jpg
  6. 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.
  7. Configure AD.jpg

    Information sign.png Note
    An AD URL must begin with the protocol prefix ldap://.
  8. 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.
  9. External groups AD.jpg

  10. 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.
  11. Authentication login.jpg

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.

  1. Launch and log in to iManager.
  2. Select eDirectory Administration -> Modify Object.
  3. Then select Modify object.
  4. Select the magnifying glass to browse to the container where the <Tree Name> CA object resides and select it. Click OK.
  5. Switch to Certificates tab.
  6. Select Self Signed Certificate check box, and click Validate.
  7. Select Self Signed Certificate check box again, and click Export.
  8. Deselect 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 or descriptive 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 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:

  1. Open a terminal prompt and switch to the root user (hint: su (substitute user) command).
  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 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.
  4. Import the public certificate (for example, SelfSignedCert.der) 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 have the manually imported certificate yet. 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 anc close the terminal prompt.

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.

  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