So today I broke something. While prepping to bring our disaster recovery SQL servers in line with their production counterparts, I was going through the servers and adding linked servers that were enabled on the main production servers but not enabled/existing on their DR counterparts. It seemed simple enough, especially since most of our linked servers are using pass through authentication of the user’s windows domain credentials to connect. HOWEVER, in a handful of cases we are using SQL Server logins for the security context of linked servers.
The problem arose when I attempted to add a linked server, using a SQL Server login/password. I had the wrong password (it was wrong in our password management application.. but that is another story entirely). I added the linked server without incident since SQL Server doesn’t confirm the provided credentials before creating the linked servers. Consequently, when I added the linked server with the wrong password, and then attempted to open the linked server in Management Studio a few times, the SQL Server login on the target server was locked out. This resulted in a chain reaction as several production applications were using that login for their normal security context.
Needless to say, internal customers started complaining about security errors coming from a core business application “all of a sudden”.
As soon as I saw the emails, I knew it had something to do with me and what I was working on. I checked the SQL Error log on the server in question and saw the obvious set of failed login attempts followed by a stream of locked out login error messages. A bonehead move to be sure, but when I tried to unlock the account in management studio, I was told that I had to provide the password to the alter login screen if I wanted to unlock the account. Sigh… not a real problem, more of an annoyance… or so I thought. When I went in to our password management application, of course, the sql login information was NOT there.
The fastest way to get the cow out of the ditch was to disable the account policy on the SQL login first, and THEN unlock it using SSMS’s login properties window.
So i had to execute this simple command:
ALTER LOGIN <mybadloginname> WITH CHECK_POLICY = OFF;
Disabling the CHECK_POLICY prevented SQL Server from trying to apply the Domain level controls on AD accounts and I was able to unlock the SQL Login after that.
We decided as a rule to leave CHECK_POLICY=OFF for a handful of SQL Server logins in our environment to avoid the scenario of a sloppy (but good intentioned) admin causing a critical SQL Server login to get locked out due to a misconfiguration.