Active Directory changes in March 2020

[AdamWoodland]

Hi ClearSCADA Administrators!

See https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirem...

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

[SGA_Mountford_D · Accepted solution]

Hi Adam,

Thanks for your post!

Was curious what we should actually be checking with our customer ClearSCADA systems?

Are servers using LogonUser for external authentication going to be affected?

Cheers!

[BevanWeiss · Accepted solution]

Hey Dave,

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

https://gist.github.com/magnetikonline/0ccdabfec58eb1929c997d22e7341e45

[SGA_Mountford_D · Accepted solution]

Thanks Bevan; appreciate the speedy response!

[AdamWoodland]

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.

[Swindel]

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.

[BevanWeiss]

@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].