In my opinion, an underrated and nifty method of permission management – bundling permissions alongside a stored procedure using certificate signing. This method enables sensitive permissions to be localised to an object, protected against unintentional changes, whether accidental or malicious, and overall for users to be empowered with access outside of their login’s permission scope. Below, I will demonstrate and explore this method of controlled permission granting.
Credit here goes to Erland Sommarskog for introducing me to this method. A write-up of his relating to this topic can be found at https://www.sommarskog.se/grantperm.html – Section 5 “Using Certificates to Package Server-Level Permissions”. I’d highly recommend a read of Erland’s SQL content.
Take a scenario in which you have a junior member of a DBA team. You’d like them to own a credential rotation process for your estate’s SQL logins and be able to self-serve this task. Without utilising certificate signing, this would require ALTER ANY LOGIN at the very least, and maybe even CONTROL SERVER if the login is a member of sysadmin (think, break-glass accounts etc.). However, with certificate signing, we’re able to avoid those potentially egregious permissions.
At a high level, we need:
- Certificate
- A Login created from the Certificate
- The elevated permissions are applied to this Login
- A Login created from the Certificate
- Stored Procedure
- This stored procedure is signed by the Certificate
- User Login
- This login/user has
EXECUTEpermission on the Stored Procedure
- This login/user has
Demonstration T-SQL
/*~ ================================================================ DEMO: Certificate signing to facilitate credential rotation ================================================================~*/USE master;GO-- -------------------------------------------------------------- 1. Create a mock application login-- ------------------------------------------------------------CREATE LOGIN ApplicationAPI WITH PASSWORD = 'Str0ngInitial!Pwd';GO-- -------------------------------------------------------------- 2. Create a mock login for our DBA individual-- ------------------------------------------------------------CREATE LOGIN ImARealDBA WITH PASSWORD = 'AnotherStr0ngPwd!';CREATE USER ImARealDBA FOR LOGIN ImARealDBA;GO-- Create a role for the junior DBACREATE ROLE Role_JuniorDBA;ALTER ROLE Role_JuniorDBA ADD MEMBER ImARealDBA;GO-- -------------------------------------------------------------- 3. Create the stored procedure that performs the password-- rotation-- ------------------------------------------------------------CREATE OR ALTER PROCEDURE dbo.usp_RotateLoginPassword @LoginName SYSNAME, @NewPassword NVARCHAR(128)ASBEGIN SET NOCOUNT ON; DECLARE @sql NVARCHAR(MAX); SET @sql = N'ALTER LOGIN ' + QUOTENAME(@LoginName) + N' WITH PASSWORD = ' + QUOTENAME(@NewPassword, ''''); EXEC sp_executesql @sql; PRINT 'Password successfully rotated for login: ' + QUOTENAME(@LoginName);END;GO-- -------------------------------------------------------------- 4. Create a certificate and a certificate-based login that-- holds the elevated permission (ALTER ANY LOGIN, CONTROL SERVER)-- ------------------------------------------------------------CREATE CERTIFICATE PasswordRotationCert ENCRYPTION BY PASSWORD = 'CertPassw0rd!' WITH SUBJECT = 'Certificate for signing password rotation SP';GO-- Create a login from the certificateCREATE LOGIN Cert_PasswordRotation FROM CERTIFICATE PasswordRotationCert;GO-- Grant the elevated, normally-dangerous permission to the CERT LOGIN onlyGRANT ALTER ANY LOGIN TO Cert_PasswordRotation;GRANT CONTROL SERVER TO Cert_PasswordRotationGO-- -------------------------------------------------------------- 5. Sign the stored procedure with the certificate-- This is the step that "packages" the elevated permissions-- with the proc's execution context-- ------------------------------------------------------------ADD SIGNATURE TO dbo.usp_RotateLoginPassword BY CERTIFICATE PasswordRotationCert WITH PASSWORD = 'CertPassw0rd!';GO-- -------------------------------------------------------------- 6. Grant EXECUTE on the proc to the Junior DBA role (not the-- underlying ALTER ANY LOGIN or CONTROL SERVER permission)-- ------------------------------------------------------------GRANT EXECUTE ON dbo.usp_RotateLoginPassword TO Role_JuniorDBA;GO/*~ ================================================================ TEST: Impersonate SupportUser and rotate the password ================================================================~*/EXECUTE AS LOGIN = 'ImARealDBA';-- Confirm ImARealDBA does NOT have ALTER ANY LOGIN directlySELECT HAS_PERMS_BY_NAME(NULL, NULL, 'ALTER ANY LOGIN') AS DirectPermission;-- Expect: 0-- But CAN successfully execute the signed procedureEXEC dbo.usp_RotateLoginPassword @LoginName = 'ApplicationAPI', @NewPassword = 'BrandNewR0tatedPwd!';REVERT;GO/*~================================================================ CLEANUP================================================================DROP PROCEDURE IF EXISTS dbo.usp_RotateLoginPassword;DROP LOGIN Cert_PasswordRotation;DROP CERTIFICATE PasswordRotationCert;DROP ROLE Role_JuniorDBA;DROP USER ImARealDBA;DROP LOGIN ImARealDBA;DROP LOGIN ApplicationAPI;================================================================ ~*/
As can be seen via the demonstration, [ImARealDBA] is able to execute the stored procedure and successfully change a login’s password, all without having ALTER ANY LOGIN or CONTROL SERVER themselves. Furthermore, should [ImARealDBA] have ALTER permissions on the procedure and want to nefariously amend it with, say, SHUTDOWN WITH NOWAIT, they would be met with a rather unfortunate result; the stored procedure is no longer signed after it has been altered – it must be re-signed with the certificate first.
To preempt what some might think – no, don’t give the certificate sysadmin rights just because it’s easiest. Think Principle of Least Privilege. Equally, always use a certificate per use-case, not one overarching certificate used everywhere. All it takes is the certificate’s password to be in the wrong hands!
Using Brent Ozar’s First Responder Kit? This method is a great way to package permissions that those SPs require to run end-to-end, whilst allowing administrative personnel to utilise them to their full potential for analysis, planning or troubleshooting. Detailed in https://www.brentozar.com/askbrent/ under “How to Grant Permissions to Non-DBAs”.


