Today’s blog post comes from a Twitter thread on which @SQLSoldier, @sqlstudent144 and @SQLTaiob were discussing
the internals of contained database users. Unless you have been living under a rock, you’ve heard about
the concept of contained users within a SQL Server database (hit
the link if you have not). In this article I’d like to show you that you can, indeed, script out contained database users and recreate them on another database, as either contained users or as good old fashioned logins/server principals as well. Why would this be useful? Well, because you would not need to know
the password for
the user in order to recreate it on another instance. I know there is a limited number of scenarios where this would be necessary, but nonetheless I figured I’d throw this blog post to show how it can be done. A more
obscure use case: with
the password hash (which I’m about to show you how to obtain) you could also crack
the password using a utility like hashcat, as highlighted on this SQLServerCentral article.
The Investigation SQL Server uses System Base Tables to save
the password hashes of logins and contained database users. For logins it uses sys.sysxlgns, whereas for contained database users it leverages sys.sysowners. I’ll show you what I do to figure this stuff out: I create a login/contained user, and then I immediately browse
the transaction log with, for example, fn_dblog. It’s pretty obvious that only two base tables touched by
the operation are sys.sysxlgns, and also sys.sysprivs –
the latter is used to track permissions. If I connect to
the DAC on my instance, I can query for
the password hash of this login I’ve just created. A few interesting things about this hash. This was taken on my laptop, and I happen to be running SQL Server 2014 RTM CU2, which is
the latest public build of SQL Server 2014 as of time of writing. In 2008 R2 and prior versions (back to 2000),
the password hashes would start with 0x0100.
The reason why this changed is because starting with SQL Server 2012 password hashes are kept using a SHA512 algorithm, as opposed to SHA-1 (used since 2000) or Snefru (used in 6.5 and 7.0). SHA-1 is nowadays deemed unsafe and is very easy to crack. For regular SQL logins, this information is exposed through
the sys.sql_logins catalog view, so there is really no need to connect to
the DAC to grab an SID/password hash pair. For contained database users, there is (currently) no method of obtaining SID or password hashes without connecting to
the DAC. If we create a contained database user, this is what we get from
the transaction log: Note that
the System Base Table used in this case is sys.sysowners. sys.sysprivs is used as well, and again this is to track permissions. To query sys.sysowners, you would have to connect to
the DAC, as I mentioned previously. And this is what you would get: There are other ways to figure out what SQL Server uses under
the hood to store contained database user password hashes, like looking at
the execution plan for a query to sys.dm_db_uncontained_entities (Thanks, Robert Davis!) SIDs, Logins, Contained Users, and Why You Care…Or Not. One of
the reasons behind
the existence of Contained Users was
the concept of portability of databases: it is really painful to maintain Server Principals (Logins) synced across most shared-nothing SQL Server HA/DR technologies (Mirroring, Availability Groups, and Log Shipping). Often times you would need
the Security Identifier (SID) of these logins to match across instances, and that meant that you had to fetch whatever SID was assigned to
the login on
the principal instance so you could recreate it on a secondary. With contained users you normally wouldn’t care about SIDs, as
the users are always available (and synced, as long as synchronization takes place) across instances. Now you might be presented some particular requirement that might specify that SIDs synced between logins on certain instances and contained database users on other databases. How would you go about creating a contained database user with a specific SID?
The answer is that you can’t do it directly, but there’s a little trick that would allow you to do it. Create a login with a specified SID and password hash, create a user for that server principal on a partially contained database, then migrate that user to contained using
the system stored procedure sp_user_migrate_to_contained, then drop
the login. CREATE LOGIN <login_name> WITH PASSWORD = <password_hash> HASHED, SID = <sid> ; GO USE <partially_contained_db>; GO CREATE USER <user_name> FROM LOGIN <login_name>; GO EXEC sp_migrate_user_to_contained @username = <user_name>, @rename = N’keep_name’, @disablelogin = N‘disable_login’; GO DROP LOGIN <login_name>; GO Here’s how this skeleton would look like in action: And now I have a contained user with a specified SID and password hash. In my example above, I renamed
the user after migrated it to contained so that it is, hopefully, easier to understand. Enjoy!
