select 'net group EDW1-' + name + ' /DOMAIN /ADD'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1-' + name not in (select name from sys.server_principals)
UNION ALL
select 'net group EDW1_SHOWPLAN_' + name + ' /DOMAIN /ADD'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_SHOWPLAN_' + name not in (select name from sys.server_principals)
UNION ALL
select 'net group EDW1_CREATE_INDEX_' + name + ' /DOMAIN /ADD'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_CREATE_INDEX_' + name not in (select name from sys.server_principals)
UNION ALL
select 'net group EDW1_CREATE_VIEW_' + name + ' /DOMAIN /ADD'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_CREATE_VIEW_' + name not in (select name from sys.server_principals)
UNION ALL
select 'net group EDW1_CREATE_PROC-' + name + ' /DOMAIN /ADD'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_CREATE_PROC-' + name not in (select name from sys.server_principals)
GO

The second script that I’ve got creates the logins for each of these domain groups, again by simply looking at the ones that don’t exist in sys.server_principals.  This script generates T-SQL code which I then just copy and paste into another SQL Query window and then execute the script.  The only thing that I have to remember with this script is that there are line breaks in the output so I need to ensure that I run this with the results going to text not to the default grid.

select 'use master
GO
CREATE LOGIN [MyDomain\EDW1-' + name + '] FROM WINDOWS
GO
use ' + name + '
GO
CREATE USER [MyDomain\EDW1-' + name + '] FROM LOGIN [MyDomain\EDW1-' + name + ']
GO
EXEC sp_addrolemember @rolename=''db_datareader'', @membername=''MyDomain\EDW1-' + name + '''
GO'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1-' + name not in (select name from sys.server_principals)
union all
select 'use master
GO
CREATE LOGIN [MyDomain\EDW1_CREATE_INDEX_' + name + '] FROM WINDOWS
GO
use ' + name + '
GO
CREATE USER [MyDomain\EDW1_CREATE_INDEX_' + name + '] FROM LOGIN [MyDomain\EDW1_CREATE_INDEX_' + name + ']
GO'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_CREATE_INDEX_' + name not in (select name from sys.server_principals)
UNION ALL
select 'use master
GO
CREATE LOGIN [MyDomain\EDW1_CREATE_PROC-' + name + '] FROM WINDOWS
GO
use ' + name + '
GO
CREATE USER [MyDomain\EDW1_CREATE_PROC-' + name + '] FROM LOGIN [MyDomain\EDW1_CREATE_PROC-' + name + ']
GO
GRANT SHOW PLAN TO  [MyDomain\EDW1_CREATE_PROC-' + name + ']
GO'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_CREATE_PROC-' + name not in (select name from sys.server_principals)
union all
select 'use master
GO
CREATE LOGIN [MyDomain\EDW1_CREATE_VIEW_' + name + '] FROM WINDOWS
GO
use ' + name + '
GO
CREATE USER [MyDomain\EDW1_CREATE_VIEW_' + name + '] FROM LOGIN [MyDomain\EDW1_CREATE_VIEW_' + name + ']
GO
GRANT SHOWPLAN TO  [MyDomain\EDW1_CREATE_VIEW_' + name + ']
GO'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_CREATE_VIEW_' + name not in (select name from sys.server_principals)
union all
select 'use master
GO
CREATE LOGIN [MyDomain\EDW1_SHOWPLAN_' + name + '] FROM WINDOWS
GO
use ' + name + '
GO
CREATE USER [MyDomain\EDW1_SHOWPLAN_' + name + '] FROM LOGIN [MyDomain\EDW1_SHOWPLAN_' + name + ']
GO
GRANT SHOWPLAN TO  [MyDomain\EDW1_SHOWPLAN_' + name + ']
GO'
from sys.databases
where (name like 'rpt%'
or name like 'secure%')
and 'MyDomain\EDW1_SHOWPLAN_' + name not in (select name from sys.server_principals)

The great thing about these scripts is that they produce a consistent set of domain groups for each new database that is added to the reporting server so that the helpdesk can quickly and easily figure out which groups users need to be placed into.  Could I have done this in PowerShell? Yeah, I’m sure that I could have.  But I don’t know the PowerShell cmdlets that would have been needed to create the domain accounts, so honestly I didn’t bother even trying.  I knew the SQL commands to do this off the top of my head.  While someone else probably could have written this in PowerShell in 10 minutes, I did it in T-SQL in 10 minutes and it’s reproduceable.

(Don’t forget for the index domain groups I’ve got a SQL Agent job that grants the rights to those that runs every night.)

If I need to add another set of domain groups into the script, I can simply copy and paste an existing one and make the few needed changes.

Denny

Registration for this great 4 day class is now open, however seating is limited so get your reservation in now in order to attend this class.

DAY 1: Planning and Installation

• Welcome and Introductions
• Module 1: Installing and Configuring SQL Server 2012 on Windows Server Core
• Module 2: Installing and Configuring SQL Server 2012 in a Cluster
• Module 3: Performing unattended installations of SQL Server 2012
• Module 4: Deploying SQL Server 2012 using sysprep
• Module 5: Automating SQL Server 2012 installations with VMware’s vSphere Deployments
• Module 6: SQL Server 2012 Storage Design Considerations
• Module 7: Installing SQL Server 2012 in a virtual environment
• Module 8: Securing a SQL Server 2012 installation

DAY 2: Mission Critical

• Module 1: SQL Server 2012 AlwaysOn Overview
• Module 2: Configuring SQL Server 2012 AlwaysOn
• Module 3: SQL Server 2012 AlwaysOn Availability Groups Drilldown
• Module 4: What’s new in SQL Server 2012 Manageability
• Module 5: What’s new in Transact-SQL
• Module 6: Migrating from SQL Server 2000/2005/2008 to SQL Server 2012

DAY 3: Breakthrough Insights

• Module 1: Installing and configuring a SQL Server 2012 based Business Intelligence Environment
• Module 2: Configuring SQL Server 2012 Business Intelligence
• Module 3: Introduction to PowerPivot
• Module 4: Introduction to PowerView
• Module 5: Introduction to Dashboards and ScoreCards
• Module 6: Optimizing your datawarehouse performance using ColumnStore index
• Module 7: Introduction to Data Quality Services

DAY 4: Manageability and Security

• Module 1: Table Partitioning for performance and saving money
• Module 2: Transaction Logs from the inside out
• Module 3: Certificates aren’t just for web browsing any more
• Module 4: Data Encryption will keep your data safe if it escapes
• Module 5: SQL Injection is a bigger problem then you want to think it is
• Module 6: Permissions, Rights and Authorizations will keep your data safe

After a couple of days we noticed something a little strange.  There was a very strange wait type which was showing a LOT of wait type.  This wait type was PREEMPTIVE_OS_GETPROCADDRESS which means that SQL Server is waiting on something outside of the database engine to respond.  When I looked into the spid which was doing the waiting I saw that it was running the extended stored procedure xp_delete_file.  What this file does, in case you aren’t aware is remove old SQL Server backups from the hard drive of the server based on parameters that you specified.

First thing that I did was look at the permissions of the files, they appeared to be setup correctly.  the local admin group had full control, users had no rights, owner has full control.  Knowing that the SQL Account should be a member of the administrators group on these servers (I didn’t set the machine up, so don’t get me started on minimum permissions).  However when I looked in the admin group for this node of the cluster, the SQL Account wasn’t a member of the admin group.  I jumped on to the other node and it was in that machines.

The reason that this was a problem is because of the way that NTFS handles permissions on new files when the user is an owner of the folder and has full control rights.  Because the folder is owned by the local admin group, and the SQL Server was a member of the local admin group when the files were created they inherited the rights from the folder which were admins had full control, users had no rights, and owner had full control.  Except that in this case ownership of the folder and the files was built in\Administrators which also carried down to the files.  So when the SQL Account came through on the second machine looking to delete files it didn’t have the rights because it wasn’t in the built in\Administrators group any more.

Fortunately fixing this problem was pretty easy.  I simply put the SQL Account in the local admin group on the misconfigured node and scheduled a short outage to restart SQL on that node so that it could pickup the new permissions.  Then the long waits went away and the older backups were able to be deleted as they should be.

If you’d like to read more about why you don’t normally want to have the SQL Server running with admin rights and what the minimum needed rights means might I recommend you check out my security book Securing SQL Server (paperback | kindle | website) available on Amazon.com and other online retailers.

Denny

Fixing this is actually a rather easy fix.  Log into the server’s console as root, then edit the /etc/security/access.conf and add a new line for each user that needs access.

Now if you have several users that need access to the physical hosts, then create a group in unix, and add this group to the access.conf file.  Each new line should look something like…

+:UserName|GroupName:ALL

In the case of my account the line looks something like this.

+:dcherry:ALL

If you wanted to use a group, then the line is similar.

+:groupname:ALL

Have fun fixing this little one if you’ve got a lot of VMware hosts to fix.

Denny

So if you deny a user access to a bunch of tables, then you put that user into the db_datareader fixed database role that user will have select rights to all the tables in the database, including all the tables that the user has been denied access to.

Denny

So, now how do you fix this?  Unfortunately the only fix to this is to grant the users Windows login as a separate login, then grant this login rights into the database.  You can then grant the user which is mapped directly to the users Windows login a default schema of dbo.

Because of this the user should specify the schema when creating objects.

The downside to this is that they won’t be able to use the object editor to create new tables.  All new tables will need to be created in T/SQL directly.

Denny

99% of the time the rights are exactly what they need to be.  Now sometimes you may need to tweak them so that no one has rights to create jobs on the production SQL Servers but they do have the ability to query the tables, so you revoke the rights to sp_add_job.  I can see that (heck I’ve even done it before).

But someone’s auditor told them that they needed to remove the rights to the extended stored procedure sp_reset_connection.  Now this isn’t something that is normally called by a client app.  It’s called automatically by the SQL driver when the client app is going to reconnect to a pooled connection to let the SQL Server know to clean up it’s data so that the connection is ready to be reused.

Did the auditor know what this procedure was used for?  Probably not.  Most people don’t have the slightest idea what this procedure is, or what it does.  If you watch SQL Profiler you’ll see it go scrolling by with no idea what it is used for.  Why did this auditor decide that in order to pass the audit this procedure shouldn’t be allowed to be used?  I’ve got no idea, but I would imagine that at some point some DBA at some other companies told them that they didn’t use it, and that they disabled it.  As long as no connection pooling was being used they probably didn’t notice any problems, however if temp tables are left in the session, there could be a collision.

If this was my system, I’d go to my manager and explain what this was, and what it was used for.  I’d then go to the auditor and let them know that the rights weren’t going to be changed.

Before just blindly following an order to change rights on any system object be sure to see what will happen when that procedure isn’t available to other users.  Removing rights to system procedures could end up having disastrous results if you are not careful.

Denny