Is there an easy way to spoof a domain-users to allow me to run database scripts on a box not connected to otherwise expected domains?
Details
I have inherited a group of .sqlproj projects. They create publish scripts with stuff like...
PRINT N'Creating User [SOMEDOMAIN\SOME-USER]...';
GO
CREATE USER [SOMEDOMAIN\SOME-USER] FOR LOGIN [SOMEDOMAIN\SOME-USER];
GO
SOMEDOMAIN does not exist on my workstation and it is not required for me to access the data; these users are not required by the application as far as I can tell and are for extraneous processes or are not currently utilized.
Because they don't exist, this blows up.
(669,1): SQL72014: Framework Microsoft SqlClient Data Provider: Msg 15401, Level 16, State 1, Line 1 Windows NT user or group 'SOMEDOMAIN\SOME-USER' not found. Check the name again.
(669,0): SQL72045: Script execution error. The executed script:
CREATE USER [SOMEDOMAIN\SOME-USER] FOR LOGIN [SOMEDOMAIN\SOME-USER];
An error occurred while the batch was being executed.
What's the easiest way to handle commands like this without rewriting scads of database code? (No, really. It's scads. The same (!!?) users are dropped and recreated several times across a number of databases. Don't ask. I don't know.)
For example, if I could spoof the domains and users, I'm potentially golden. Is that possible? I looked up creating domains, and it looks like a Windows Server thing (I have Pro).
Any other slick workarounds that wouldn't require editing the SQL?
I mean the right answer is probably to have a more nuanced set of scripts in the sqlproj, similar (maybe?) to this discussion, but a refactor at that scale is not within the project's current scope.
You can separate users and their associated logins into a separate database project in the same solution and have the new database project reference the old one. The trick is to specify "same database" as the location.
Then, you'll move all of your users into the new database project.
Now you're free to deploy either project. If you deploy the old project, it'll deploy without any users; if you deploy the new, it'll deploy with users. And, if you want to get fancy, you could have more than one security project (say your dev and prod environments are in different Windows domains you could have a DevSecurity and ProdSecurity project each with their own notion of what the users should be).
If you have permission grants that explicitly reference the users, I think you'll need to refactor those. Luckily, that's not so bad - you can put in an abstraction of a database role to hold any permissions for your users (the role itself can live in the base project definition) and then place any role memberships in with the user definitions in the project that holds the users.