Troubleshooting LDAP on the community pod
About this task
If you are having difficulty connecting to a secure LDAP server, perform the following troubleshooting steps.
Procedure
-
Log into the community pod.
-
Confirm that the community pod is receiving the trust store. Look for the
ldaptruststore.p12 file in
/local/notesdata directory.
- If the file is present, continue to the next step.
- If the file is missing, the LDAP secret is not being read properly.
- Confirm that LDAP secret has been created in the correct namespace if using namespaces.
-
Open the values.yaml file and confirm that the
LDAP secret name is specified correctly in the
ldapConfigSecret: "ldap-config-secret"
format.
-
Confirm that the sametime.ini and
UserInfoConfig.xml files are updated.
-
Confirm you have correct configuration details .
-
Confirm TLS is negotiating properly between Sametime and LDAP
- In Sametime 12 only TLS 1.2 is enabled by default. If the LDAP server you are connecting to doesnn't support TLS 1.2, then you need to override the default configuration.
- Sametime connects to LDAP attempting to negotiate TLS with the following
ciphers:
RSA_WITH_AES_256_GCM_SHA384 (0x009D)
RSA_WITH_AES_128_CBC_SHA (0x002F)Support for at least one of the ciphers might need to be added to your LDAP server, such is the case for HCL Domino 12.0.2, for details see Sametime 12.0 TLS required ciphers to connect to Domino 12.0.2 LDAP
- There is a known issue when using a newer version of keytool to create
the trust store, Sametime is unable to read it. To work around the
problem, recreate the trust store with keytool and add the argument:
-J-Dkeystore.pkcs12.legacy
to the command. For more details, see the Sametime unable to read trust store causing LDAP connection to fail article. - To determine if your TLS is not negotiating and finding a common cipher suite enable debug. Start with VP_LDAP_TRACE=1 and ST_TLS_DEBUG=1. See theEnabling Community debug in Kubernetes topic.
-
By default, the community pod connects to LDAP on the pod IP address range, and
the firewall should be configured to permit this traffic. If you are unable to
open up the entire pod IP range to LDAP, consider implementing a network address
translation, or IP Masquerade solution, which will give the traffic from the
pods an IP in a range of your choosing.
An example of this is the Google Kubernetes Engine IP masquerade agent solution. For more information, see the IP masquerade agent Google Cloud topic. Each cloud provider has an unique solution, see your vendor’s documentation for more details.
-
The community pod must resolve the host name of the LDAP server, or you can
configure the IP address instead. If the host name of the LDAP server does not
resolve in DNS, you can configure Host Aliases for the Community pod.
See the Configuring host aliases for Kubernetes deployments article for steps.
-
Netstat is installed on the community pod and can be helpful to understanding
if the connectivity is succeeding or not succeeding.
To use netstat on the community pod enter the command:
Substitute your secure LDAP port number if you are not using port 636.netstat -an | grep 636
-
You might find that the default settings for LDAP are incompatible with your
LDAP implementation and are causing problems
- Sametime 12 connects with multiple connections, the login, resolve and search connections uses the same settings. These settings are configured in the StCommunityConfig.xml, which are pulled from the values.yaml file and sametime-global-secrets. These can be overwritten by the extra-community-configs secret.
- The UserInfo task (business cards) uses different settings. These settings are in the UserInfoConfig.xml file and are also pulled from the values.yaml file and can be overwritten by the extra-community-configs secret.
It is also possible to create a custom java class file to transform the LDAP searches for more efficient requests to LDAP. See Configuring the class file on Kubernetes for more details.