Why won't this Azure SQL Stored Procedure execute? - sql

Question

I can't figure out why this won't execute.
Created the SP with:
CREATE PROCEDURE [dbo].[sp_custom_addADUser]
#userNameParam NVARCHAR(255)
AS
CREATE USER [#userNameParam]
FROM EXTERNAL PROVIDER
WITH DEFAULT_SCHEMA = dbo;
ALTER ROLE testRole ADD MEMBER [#userNameParam]
I have GRANT EXECUTE ON dbo.sp_custom_addADUser permissions:
|role_name| user_name |
|---------|--------------------|
|testRole |myname#mycompany.com|
|name |ObjectType |PermissionType |permission_name|state_desc|ObjectType|SchemaName|ObjectName|
|--------|-------------|----------------|---------------|----------|----------|----------|----------|
|testRole|DATABASE_ROLE|OBJECT_OR_COLUMN|EXECUTE|GRANT|SQL_STORED_PROCEDURE|dbo|sp_custom_addADUser|
From SSMS, execute the SP by passing it the string: someone#mycompany.com (actual user).
Error is:
Msg 15007, Level 16, State 6, Procedure dbo.sp_custom_addADUser, Line 12 [Batch Start Line 0]
'#userNameParam' is not a valid login or you do not have permission.
Msg 15151, Level 16, State 1, Procedure dbo.sp_custom_addADUser, Line 16 [Batch Start Line 0]
Cannot add the principal '#userNameParam', because it does not exist or you do not have permission.
(1 row affected)

Answer 1

The error message gives a hint of what's happening -- it's using the parameter name #userNameParam where you would want it to be using the value someone#mycompany.com.
This is because CREATE USER can't accept a parameter (as this previous answer mentions).
One option is to use dynamic SQL. I.e., build the SQL statement you want to execute as a string -- concatenating in the value of the parameter -- and then run it with sp_executesql.
Make sure you understand the risks of SQL Injection and how to mitigate them before using dynamic SQL.

Answer 2

It's reading [#userNameParam] as a quoted identifier (like a column name), not as a variable, because of the square brackets. However, you can't use a variable for an object name, like a user name for instance, so just removing the brackets won't get the job done. You'll need a touch of dynamic SQL to make it all happen.
With any dynamic SQL, you'll want to include measures to avoid SQL injection, so I used both a parameterized query and QUOTENAME for the example code. The #CRLF variable just injects carriage return/line feeds into the dynamic string for readability when you print the result for debugging. There are multiple lines in the string builder for readability when looking at the procedure code.
See the excellent link in Tim Goodman's answer for more details here.
CREATE PROCEDURE [dbo].[sp_custom_addADUser]
#userNameParam NVARCHAR(255)
AS
DECLARE #sqlCreate NVARCHAR(500)
,#sqlAlter NVARCHAR(500)
,#CRLF CHAR(2) = CHAR(10)+CHAR(13);
SET #sqlCreate = CONCAT(#sqlCreate, 'CREATE USER #userName', #CRLF);
SET #sqlCreate = CONCAT(#sqlCreate, 'FROM EXTERNAL PROVIDER', #CRLF);
SET #sqlCreate = CONCAT(#sqlCreate, 'WITH DEFAULT_SCHEMA = dbo;');
--PRINT #sqlCreate;
EXECUTE sp_executesql #sqlCreate, N'#userName', QUOTENAME(#userNameParam);
SET #sqlAlter = ('ALTER ROLE testRole ADD MEMBER #userName;');
--PRINT #sqlAlter;
EXECUTE sp_executesql #sqlAlter, N'#userName', QUOTENAME(#userNameParam);