Generic Identity and Integrated Security with SQL

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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?
 
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
 
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.
 
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
 
Back
Top