Hi ClearSCADA Administrators!
Microsoft is fixing a bug in LDAP functionality in Active Directory to block insecure LDAP in March 2020. If you have your ClearSCADA set up to externally authenticate users using just "LDAP" against a domain controller, and not using "LDAP SSL", you may find after this update if applied your ClearSCADA users may not be able to log in. I have a ticket raised with support so someone can hopefully take a closer technical look at the possible impact to ClearSCADA.
I strongly recommend you review the Microsoft advisory on how to resolve the issue and refer to websites such as https://evotec.xyz/four-commands-to-help-you-track-down-insecure-ldap-bindings-before-march-2020/ to help identify which systems may have an issue (which I am yet to personally test those scripts, use at own risk).
Solved! Go to Solution.
LogonUser and LDAPS/LDAP SSL won't be affected by this.
It will primarily affect systems which are authenticating against a 'remote' domain, one which the ClearSCADA / Geo SCADA Expert server may actually not be a member of.
However.... there have been a few clients that had issues in the early days with LogonUser around domain authentication timeouts.
I think maybe one in the west.... They may still be configured to use LDAP instead of LogonUser.
For almost all customers, it should be possible to just use LogonUser.
LDAPS/LDAP SSL is annoying, not just a tick box on Windows AD servers.
SI plan would be, for each customer server, check in Server Configuration if it's set to LDAP, if it is, then prepare a testing window to convert it across to LogonUser. Change Standby Server LDAP->LogonUser, restart, and test a Windows Authentication logon to the Standby server (i.e. Client Connection settings set to prefer Standby). If it all works, then perform the same on the current Main server.
If the system is configured to use LDAP against a remote domain. Then the hoop jumping to get LDAPS will be required.
Here's a pretty good guide
Yeah, what Bevan said 🙂
Regarding validating ClearSCADA (and anything else on the system you may manage) I don't think you should be checking the product as such, you should be checking your domain logs to see what is triggering any entry. That last link has info on what logging you need to set (not enabled by default) and then what to parse in your domain logs to identify sources.
For example some network devices, PLCs and RTUs support LDAP authentication and may be affected if not using SSL/TLS.
The logging only appears every 24 hours so its a case of set it going and wait a day or two.
In addition I can say that this type of protection through Active Directory can be further secured by using 2FA through universal protection tokens then adfs sso can be used very conveniently and simply and most importantly reliably. After all, the same Microsoft has support for azure adfs in providing security.
@Swindel The idea of MFA via the ADFS mechanism does sound good, although I've never tried this myself.
How does it interact with LDAPS? Is it possible at all?
Or does it need to utilise the native LogonUser of a Domain Authenticated computer?
I've only seen the MFA utilised against a RADIUS configuration, and not LDAP/AD on its own, in this particular context.
I have seen custom GINA setups to enforce an MFA token entry for 'native' AD logon, but this is not something that GeoSCADA supports (since it doesn't support the GINA plugins for the second factor) [as far as I'm aware].
Discuss challenges and get support in energy and automation with 30,000+ experts and peers.
Over 10,000+ support articles are available to help you find answers to your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!