It’s been almost 3 years since I updated these SPs! I can’t believe so much time has gone by! Well, I’m sure all of you have been holding your collective breath but I finally have some new updates. I’m particularly excited about the @DropTempTables and @Output options.
Just as a reminder they can be found in the drop down of the free scripts menu. Or here: sp_dbpermissions | sp_srvpermissions
New Features
- @UserLikeSearch to turn off the LIKE searches. It’s on by default.
- @IncludeMSShipped to exclude users/logins created by Microsoft. They are included by default.
- @DropTempTables to keep the temp tables (dropped by default) that the data is stored in. This way individuals and automated process can collected the data and process it. The temp tables are:
- ##[DB/Srv]Principals
- ##[DB/Srv]Roles
- ##[DB/Srv]Permissions
- @Output allows for new output options.
- None – No output at all. This is mostly meant to be used with when the plan is to collect data from the temp tables.
- CreateOnly – Return only the create scripts.
- DropOnly – Return only the drop scripts.
- ScriptsOnly – Return both the create and drop scripts.
- Default – Normal behavior.
Other changes
- A couple of bug fixes.
- Added IF EXISTS to the principal (user/logins) drop and create scripts.
- Moved SID towards the end of the list (leaving create & drop scripts at the end) since most of the time you don’t really need the SID.
- Remove the create/drop scripts for the users (sp_DBPermissions) guest, public, sys and INFORMATION_SCHEMA
Quick intro if you haven’t seen these SPs before. They are a couple of stored procedures I wrote to help me with security research. Each of the stored procedures returns three data sets.
- A list of principals and some basic properties about them.
- Role membership
- Object/Database/Server level permissions
Each of the datasets has a set of do/undo scripts as well as various useful columns. For example the second data set contains information about which logins/users belong to which roles; and scripts to either add or remove the login/user from that role.
The stored procedures also have a number of parameters for restricting the result sets. For example principal name, role name, principal type, object name etc.
These sp’s can be run/stored anywhere and work just fine but if you run them in master then you can more easily call them from any database on the instance.
A few examples of times I’ve found them particularly handy:
- I need to know every database a user has access to and what access they have.
- I need to know all permissions for a given login across all databases.
- I need to copy a login from one server to another (with SID and password).
- I need to know everyone who has permissions to a specific object in the database.
- I need to know everyone who is a member of sysadmin.
Standard disclaimers: This code is as-is. You should be careful running code you haven’t reviewed on your systems. Feel free to use it and place it on your systems. Please do not post my code without giving proper credit and preferably back to the original page. And of course if you happen to notice a problem, or have a suggestion please post them here or email me and I’ll be glad to fix/add as appropriate.
Filed under: Dynamic SQL, Microsoft SQL Server, Security, SQLServerPedia Syndication, System Functions and Stored Procedures, T-SQL Tagged: code language, database permissions, dynamic sql, language sql, microsoft sql server, security, server permissions 
