When using the central user management sever feature of MpUserX, it is important to know that only the secure version of the protocol is supported LDAPs. The insecure version of it (LDAP) is not supported. The protocol is classified as obsolete and not supported by the main providers (AD from Microsoft).
When a connection is established to a central user management server, the certificate of the server needs to be validated to ensure that the server is a trusted partner. The solution today is to manually import the server certificate into the AR certificate store. The end-user would need to provide the certificate of their AD to the automation team and perform the update to the AR.
The ArCert library and the file transfer system of choice (FTP, USB, CIFS, etc.) can be used to import a new certificate to the certificate store. At this time, it requires some application work to implement the best solution for the machine.
To add some details to the original post, you need to include the certificate of the Certificate Authority (CA) that signs the Active Directory’s (AD) certificate in Automation Runtime (AR).
We have successfully managed to use LDAPS when utilizing a Windows server as the LDAP server. However, we have not been able to establish successful communication between a Linux-based LDAPs server and the PLC PPC80.
In our testing environment, we are using a ubuntu Linux server running a 389 LDAPS server. The server appears to be functioning correctly, as we can log into it using other applications (The same certificates base64 encoded), and the User Location DN is properly configured.
On the PLC side, we’ve verified connectivity using the IcmpPing() function, confirming that we can reach the server both by IP address and DN, which suggests that the HOST configuration is correct.
However, we are still facing issues with establishing communication. Are there any proven projects or procedures that we can follow to resolve this?
Hi @c531152
I had a similar problem with an OpenLDAP-Server on a Docker container, that creates an self-signed certificate.
The clue was to export not only the certificate from the server, but also the trust chain:
The resulting pem file included two or more certificates. After I imported that one in Automation Studio in “Third Party Certificates” the connection to the LDAP server was established.