Fewer words strike fear into the hearts of IT than "Windows patch" and "security advisory" do. And for good reason: it means that there is a potential out there for a previously-unknown defect, and there is enough information on its impact now that An Official Statement has been released. So break out the planner and figure out when the next maintenance window happens, 'cuz a change is gonna come. This all starts in earnest March 2020, but you can do it now (manually).
What Is Microsoft Security Advisory ADV190023?
Simply, Microsoft has found a need to plug yet another security hole in their implementation of LDAP. According to a Microsoft article related to the advisory ("2020 LDAP Channel Binding and LDAP Signing Requirements for Windows"), "There is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities." So let's break this down, because how you interface Blueprint with LDAP (if you do at all) makes all of the difference in the world in how you approach this. The master article is found here: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
First, if you are using unencrypted LDAP (LDAP, TCP 389; ldap://blah:389 connections) for your applications and choose to bypass/override this upgrade, then none of this matters. Except that you probably shouldn't be using unencrypted LDAP in the first place, because you are passing credentials in clear-text over a channel that 100% of "off the Internet" packet sniffers can pick up and use. If you're not careful, however, and still using LDAP connections, you may end up with "LDAP_SERVER_DOWN" messages.
If you're using an encrypted LDAP connection (LDAPS, TCP 636; ldaps://blah:636 connections) for your applications, a Microsoft Update in March 2020 is going to require signing and a channel binding token (CBT) for secured connections to LDAP.
LDAP Channel Binding
Channel Binding is a method of securing the TLS connection by using token binding. Without getting too technical, in traditional TLS, the client, like a web browser, presents a bearer access token to the server that basically says "Hi, it's me, and I'm authenticated!" and the web server accepts it without much fanfare. It's secure, but it is easy for another system to impersonate the bearer token and hijack the session for malicious intent. Using token binding (for now) is more secure (see https://connect2id.com/learn/token-binding for a good explanation), and so in March 2020, once your clients are all updated, you can update your servers and your LDAPS connections will be happy as a clam.
This just means that the LDAP connection is secured (using LDAPS). Once the updates to domain controllers or Lightweight Directory Services servers are done, an unsigned LDAP connection will be refused unless the server is explicitly configured to not require it...and that is going to be either a manual, per server, effort, or through Group Policy.
Am I At Risk?
Act Now! to check if your systems are at risk. Microsoft has provided an excellent document to determine if unsecured LDAP is hitting your domain controllers. Implement the registry changes and then look for Event ID 2886 and 2887 in the Directory Services log within Event Viewer. Event ID 2889 (also covered in the Microsoft document) lists the systems making the calls, so that you can determine where the call is coming from.
If you do find that a Blueprint Enterprise server is at the root of an unsecured LDAP call, contact Pharos Technical Support and log an incident for assistance right away. In most cases, the resolution is to simply convert the LDAP call into LDAPS, but other changes may also be necessary.
The Impact to Blueprint Enterprise Operation
If your Blueprint Enterprise Collectors and Analyst are configured for LDAP integration, it's a good idea to get ahead of the change and convert them to LDAPS now. By default, if you have implemented Secure Release Here, the connection to your domain controller for badge registration and user/password authentication is not secure. This will be remedied in an upcoming (March 2020) update to Blueprint Enterprise 5.3; contact your reseller or Pharos Account Manager if you'd like to move from the default method to a secured script. If your site is using a custom script to access Active Directory (using either Kerberos/NTLM or as an LDAP channel), your script will need to be modified to convert it to a signed connection.
That's half of the battle (NOTE: make sure your certificates are in order). Then, as you implement the March 2020 updates, operations should persist successfully provided the client environment is updated prior to the servers (in this case, your Blueprint Enterprise servers are clients, even if they also happen to be domain controllers). If you maintain those LDAP connections and the updates to Microsoft AD and LDS servers are deployed, functions that rely on LDAP (authentication via user name and password at secured devices, logging into Pharos Print Center, and Unauthenticated Print Scout clients; HRLDAP imports for user information) will fail, requiring last minute connection reconfigurations and emergency operating system updates.