Two notes about impersonation in SQLCLR

Posted by Chris on October 04, 2006

While experimenting a bit with impersonation in SQLCLR I noted two things I thought would be good to mention here. Firstly, if you are creating a function you need to set the named parameter DataAccess or SystemDataAccess (I assume it works with both set as well) of the SqlFunction attribute to Read. Strange that it works with either one of them.

The other thing was that BOL is not 100% accurate in the description of what the property WindowsIdentity of SqlContext can return. In BOL it says that if you are running integrated security this returns the token for the caller of the code, but if SQL Server security is used it returns NULL. What is missing is that if a SQL Server login which is a member of the sysadmins fixed server role (such as sa) is the caller of the code then WindowsIdentity will return a token. There is no meaning in calling the Impersonate method on it though, as it is the token for the SQL Server service account. Since SQLCLR code by default executes as the SQL Server service account there is not a lot of meaning in impersonating it..


Trackbacks are closed.

blog comments powered by Disqus