Skip navigation
All Places > Blueprint Enterprise > Blog > 2020 > January

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:


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


LDAP Signing

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 are running Blueprint 5.2 SP3 or greater and have implemented Secure Release Here using the Standard Authentication Method, the connection to your domain controller for badge registration and user/password authentication is secure. If your site is using a custom script to access Active Directory (using either Kerberos/NTLM or as an LDAP channel), your script will likely 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.


Nothing spoils a great weekend like a Change Request. And nothing spoils a spoiled weekend faster than running into problems during the Change.


Lately, there has been a rise of failed upgrades to Blueprint Enterprise, largely fueled by improper permissions to the database for the Login Account used for Blueprint operation. This document serves to talk about some common ideas about database ownership in Microsoft SQL, dispel some myths, and ultimately explain how this applies to upgrade events in Blueprint Enterprise.


The 'dbo vs db_owner' Issue

The first part of the confusion stems from "dbo" versus "db_owner" and how SQL addresses each from a security standpoint. The explanation itself contains twists in language, so I will try to be very clear. It has to do with logins versus roles, and a dash of archaic history in the relationship of users and schemas.


What is dbo?

The acronym "dbo" literally means database owner. Each database hosted in SQL Server has to be owned by one (and only one) login, and this login gets aliased to the dbo login. The dbo user (and its aliases) cannot be denied, which means that specific login can do anything they want to within the database. Not the server, just the database.


"dbo" can also mean "schema" and this is where a lot of people get tripped up. Back in the dark ages of SQL Server (version 2000 and lower), creating a login also created a schema for the login, and the two were inseparable. So people who administered databases awhile ago have this idea that "dbo" is almost like the "sa" (system administrator) login, and so balk at the use of database ownership tied to a login. But in version 2005, Microsoft changed that. A schema in SQL Server 2005 and newer is just a collection of objects in the database: tables, indexes, etc. that can be owned and accessed by users, and "dbo" is the default schema when an alternate isn't defined. So if I am a login that can, for example, create a table in a database and I simply run:


Id int,
Type varchar(25),
Description varchar(100)


the object will be placed into the dbo schema, resulting in dbo.MyStuff. The owner of the dbo schema in SQL has a lot of power only because most of the objects in each database are in the dbo schema. If I built a database that had a schema named "Gandalf" and put all of the database objects in that schema, then the owner of the Gandalf schema would have more access in the database than the owner of the dbo schema. But ownership of a schema doesn't imply extended or administrative permissions. You can just see the stuff in the database.


In conversations with database administrators, it is very important to provide the proper context for dbo: are you talking about the schema (collection of objects) or the login (the database owner)?


What is db_owner?

In SQL, db_owner is a fixed database-level role that has explicit permissions within the database. Logins can be added to the db_owner role for the purpose of database administration. According to Microsoft's documentation, logins assigned the db_owner role (whose permissions cannot be changed) to the database are pretty much free to do anything (anything) in the database (again, not the server, just the database). However, membership in the db_owner role does not confer dbo user permissions. And so, any T-SQL script that needs to act under dbo needs to be run as the dbo of the database.


So What Does That Mean for Blueprint?

Operationally (meaning: after installation), the account specified for the databases in the Blueprint Server Configuration utility can happily live as a member of the db_owner fixed role. During an upgrade, however, and to retain backwards compatibility with previous SQL versions, there is a check to ensure that the specified login is also dbo. If there was not, then Blueprint installations on older SQL Server versions would fail, and by doing so, the potential exists to cause failed upgrades, particularly on servers managed by security-conscious database administrators who seek to keep "least privileged" access at all times (and so often change database ownership to restricted domain-based accounts with tight access controls).


Removing the Fault

In almost all cases, Blueprint server upgrades are scheduled events, typically managed as part of a Change Control process. Therefore, within the change control procedure, implement a Database task to temporarily change the dbo alias to the account used by the Blueprint Analyst to access the database:


USE psbprint [psjobs1, psjobs2, psjobs3, psjobs4..., psreports]
sp_changedbowner 'login'


where the action is taken on the various Blueprint databases (in turn) and login is replaced by the login account name. NOTE: in some future version of SQL Server, the sp_changedbowner procedure will be removed. Use ALTER AUTHORIZATION instead:




Then, when the update is complete, the change control procedure gets another Database task to move the dbo alias back to whatever is used for production purposes, using the same syntax/script above. This restores the "least access" privilege.


And That's It!

In sum, being the dbo isn't all bad; its exactly the same as being a member of the db_owner fixed role, without some of the hassle associated with an upgrade. However, with some planning, the upgrade experience can go smoothly; well, except for the ruined weekend part.

When Blueprint Enterprise 5.3 was being developed for release, Microsoft was busy preparing for the release of SQL Server 2019. At the time of our larger push for release readiness, it was decided that we not regression test against this version of Microsoft SQL Server because it added significant (and unplanned) time, and no existing customer in our contact group had any plans to migrate to that version any time soon.


Instead, we opted to allow the installation to continue with a caveat notification that we hadn't fully tested it yet:


Non-tested SQL version notification


and a validation step that continuing was "at risk."


Since then, we have been able to more fully test the operation of Blueprint Enterprise 5.3 with Microsoft SQL Server 2019 and are happy to report that operational events (inserting and updating objects in Blueprint Administrator, data publications, file imports) work as expected.


When the next major version of Blueprint Enterprise is released, this warning screen will be removed when Microsoft SQL Server 2019 is detected.


Earlier Versions of Blueprint Enterprise

Installing Blueprint Enterprise 5.2 and lower to Microsoft SQL Server 2019 are not supported. If an existing Blueprint Enterprise 5.2 or earlier database is migrated to a SQL Server 2019 instance, our expectation is that, operationally, there will be no incident.