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.
I’m not talking about central user management itself. I know that’s been around forever. But the option to use unencrypted LDAP must be fairly new. It was always said that this would never be available, that only LDAPS could be used.
In the documentation, this setting option is completely ignored as well — not a single word about it.
LDAP is an option available with the latest mapp Services version 6.4. We have added this option, since some customers had issues to set LDAPS up. Or their server did not support LDAPS.
And since we are offering LDAPS primarily, customer can decide to set it up in a “unsecure” way on their own risk. With LDAP.
We did not make any description in Help, since it should be pretty straghtforward, and we are planning to introduce LDAP with StartTLS with version 6.5 and at that time everything will be fully documented.
