Generic Identity and Integrated Security with SQL

19 Dec 2005 7:31 PM

Bruce Parker

I have setup the following lines of code:
System.AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)

mPrincipal = System.Threading.Thread.CurrentPrincipal
mUser = mPrincipal.Identity

' Create generic identity.
mApplicationIdentity = New
Security.Principal.GenericIdentity(controlCenterConfiguration.Employee.Alias)

' Create generic principal.
mApplicationPrincipal = New
Security.Principal.GenericPrincipal(mApplicationIdentity, rolesArray)

'set the thread to run under this new identity
System.Threading.Thread.CurrentPrincipal = mApplicationPrincipal

I am able to use code-based security using this with no problem.

What is not clear to me is how Integrated Security with SQL is still
working. My instinct says it should not work, but it does. I would have
thought my WindowsIdentity would have been replaced by my GenericIdentity and
the thread would not have my windows authentication information.

Will someone explain this to me?

20 Dec 2005 12:30 PM

Yuan Ren[MSFT]

Hi,

Welcome to MSDN newsgroup!

Based on my understanding, your question is wonder why you can be
authorized successfully by SQL Server when changing the principle of
current thread in the application. If I have misunderstood anything, please
let me know.

In my opinion, there are two possibilities for the current issue. One is
the current principle of thread which connects to the SQL server is not the
one changed principle before. Another is the principle of "Employee.Alias"
have permission to connect the SQL server.

And then, I suggest you use the profiler tool to monitor which principle
has been used to connect the SQL Server. It'll help us to narrow down the
current problem. Thanks for your understanding. I'm looking forward your
reply!

Regards,

Yuan Ren [MSFT]
Microsoft Online Support

20 Dec 2005 2:10 PM

Bruce Parker

Using the Profiler, the connection to the SQL Server is definitely using my
Windows Identity. The identity being passed to SQL Server I would think
would be my Generic Identity which has no permissions. This Generic Identity
is establish during the startup of the application.

Does it have something to do with me setting the following?
System.AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)

This is set before I create the generic identity.

There is something going on here I do not understand.

""Yuan Ren[MSFT]"" wrote:

Show quote

> Hi,
>
> Welcome to MSDN newsgroup!
>
> Based on my understanding, your question is wonder why you can be
> authorized successfully by SQL Server when changing the principle of
> current thread in the application. If I have misunderstood anything, please
> let me know.
>
> In my opinion, there are two possibilities for the current issue. One is
> the current principle of thread which connects to the SQL server is not the
> one changed principle before. Another is the principle of "Employee.Alias"
> have permission to connect the SQL server.
>
> And then, I suggest you use the profiler tool to monitor which principle
> has been used to connect the SQL Server. It'll help us to narrow down the
> current problem. Thanks for your understanding. I'm looking forward your
> reply!
>
> Regards,
>
> Yuan Ren [MSFT]
> Microsoft Online Support
>
>

21 Dec 2005 2:38 PM

Yuan Ren[MSFT]

Hi,

Thanks for your reply!

From your description, I think maybe the thread connect to SQL Server is
not the one which has been changed of principle before.

Could please provide some codes about connection SQL Server? It'll help me
to perform some testing. Thanks for your understanding!

Regards,

Yuan Ren [MSFT]
Microsoft Online Support