Actually more like an upstream problem. Or two.
Or, another week in the life of a DBA and other duties as assigned
So a few weeks ago a developer at a client of mine reported that some recently deployed code wasn’t working. I tried it and of course it worked for me. That isn’t unusual since I have sysadmin rights on that box. I tried execute as using her ID and it failed. Not uncommon, sometimes in production permissions don’t get promoted the way they should. So I checked her permissions and the permissions of the users actively trying to call the stored procedure. Strangely, they all had the proper permissions, at least as far as I could tell. Then I had that lightbulb insight and realized I had been misinterpreting the error message execute as was giving me. “The server principle “DOMAIN\USerXYZ” is not able to access the database “ImportantDB” under the current security context.”
I realized I had been troubleshooting the wrong problem. It wasn’t that the person didn’t have permissions to execute, it was that no one other than sysadmins had the right to CONNECT to the database. A simple:
GRANT CONNECT SQL
And all was good to go! Or was it? It took us some digging to figure out why this had happened on a production database. Apparently when the database was designed in Dev, the developers had the rights they need to connect, so never thought about who else might need to connect. Apparently they had created it with very limited Grant Connect rights. When the database was moved to production, in this case, with a backup and restore the same lack of rights moved upstream with it.
Now, in the opposite direction, a vendor wanted to send a file to my client in their UAT environment. I fired up the PowerShell script to retrieve the file and decrypt it. The decryption failed. It took me awhile to figure out the problem. The client has a rule that every 2 years we must upgrade our RSA Public Key with them. Ironically, I had just completed the most recent update last month and moved it into production. Apparently though, their rule doesn’t apply to their UAT environment. Which came as sort of a shock to me, since they’re always so insistent on us following their security requirements. Of course beyond the irony of them not following their own rules, the file they had asked we download, wasn’t there.
The PM contacted them and they assured him the file would be there on Friday. Well here it is Tuesday and we’ll see if this time the file is there.
In any case, this time, the problem wasn’t promoting a change from UAT to PROD, but the client’s failure to move a change from PROD to UAT.
Such is life.
So sometimes I’m the creek without the paddle and sometimes I’m down the creek…