# Friday, August 10, 2007
« Off to Tech.Ed! | Main | Learning to program, part 1 - What you c... »

So I was talking with Rob Farley at Tech.Ed (Rob, you’re my hero ;-)) and the topic he raised the topic of what if we did not grant *users* access to our SQL Servers, but instead only allowed groups.

Not something I had really thought about much before but This is a really good idea™.

The question that naturally arises is: How do we enforce this with something stronger than “because I said so”.

The good news is that it appears that SQL Server 2008’s Declarative Management Framework (a.k.a. “policies”) can be of assistance here.

Background on the Declarative Management Framework:
  • A Facet is a piece of data about the system that you can use in your policies. 23 Facets are included in the current Katmai CTP.
  • Each Facet can have 2 or 10 or more Properties. It is the properties that are used in your conditions. Facets are logically groupings of properties by SQL Server
  • A Condition is a logical expression about a property or set or properties
  • A Policy is a named instance of a specified Condition with a rule on how it will be enforced (on a schedule, on changes etc).
Step 1: Create a new Condition and call it GroupsExist. Choose the Login facet and the LoginType property. Set it to equal WindowsGroup.

In the case that there are user accounts like .\ASPNET or the ##MS_PolicyExecutionLogin## login that have a legitimate right to be there, list those in the expression as illustrated below.
 

Step 2: Create a new Policy based on the GroupsExist condition and cal it OnlyAllowGroupsNotUsers. Apply it to Server/Login and set it to Enforce as illustrated below.



One of the really cool things is that you can create your policies in a not enabled state, and use the built-in testing harness to get the policy right before enforcing it.

To test a policy in SQL Server Management Studio, right-click on it and choose Test… This will run the policy against the current state of the server and report the details of success or failure.

Now when the policy is disabled, the following statement will do as it is designed.

CREATE LOGIN [MYLAPTOP\SampleUserAccountAccess] FROM WINDOWS GO


However when the policy is Enabled, I am getting the following error, which I assume means I am am on the right track :-)

Msg 10314, Level 16, State 11, Procedure sp_syspolicy_execute_policy, Line 25
An error occurred in the Microsoft .NET Framework while trying to load assembly id 65536. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE.

Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.SqlServer.DmfSqlClrWrapper, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies.

Strong name validation failed. (Exception from HRESUL
T: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) System.Security.SecurityException: System.IO.FileLoadException:
at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
The statement has been terminated.


I’ll research this message next week, as well as re-do the sameple when back home and connected to AD, and if the results differ I’ll re-post.

...Topic for future blogging: Ensuring consistent policies across several instances of SQL Server. Stay tuned.

Listening To: The dodgy motor in the fridge in my apartment.





Friday, August 10, 2007 10:05:04 AM (AUS Eastern Standard Time, UTC+10:00)
Yes, nice. I like it.
Comments are closed.