Windows Impersonation authentication to SQL Server?



Hello, sorry if this is unorthodox way of asking, but when using
Impersonation will each Windows Domain user accounts need to be granted
access in SQL Server - Security - Logins section for db app in which they'd
all be tracked and displayed in SQL Profiler? Thanks in advance.


"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:OE6HyfwMKHA.4124@xxxxxxxxxxxxxxxxxxxxxxx
I'm not much of a SQL guy so I'm not totally sure on all the details
required to get the logons configured in SQL and what your options are.
It seems like you should be able to do both individual user accounts and
also groups as well. Typically, you'd want a role mapping scheme where
windows groups end up getting mapped to SQL roles for the actual security
implementation so that you have a nice abstraction layer in SQL for
managing the actual permissions (roles) and can use AD and groups as a way
of assigning membership to those roles. Depending on the number of users
involved, working with individual accounts may be fine for you. I'd
definitely ask for more details in a SQL group. :)

You should definitely see the individual Windows logons for the users
connecting to the database in profilers or other logs. That's kind of the
whole point. :)

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
"7777" <NoSpam@xxxxxxxxxx> wrote in message
news:e4TJowvMKHA.4124@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for your informative reply Joe, much appreciated. So if the
asp.net app and SQL Server were to be set up in the Delegation method
would there be individual Windows user accounts listed in SQL Server ->
Security -> Logins section (which each corresponding database username
would be mapped to their individual Windows accounts) in that when SQL
Profiler is run in the background while users are using the asp.net app
each of their individual Windows accounts would show up in dispalying
fine detailed auditing of which user did what to the db data?



"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:eWu0SxqMKHA.508@xxxxxxxxxxxxxxxxxxxxxxx
Yes, both Windows authentication.

In delegation, authentication to SQL server is done as the user
authenticated by the front end application (typically a web app using
integrated auth), allowing you to implement very granular security on
individual Windows users in SQL itself.

Trusted sub system is basically the practice of access SQL as a fixed
service account. In SQL, this can be done with either Windows security
or SQL security but the article is discussing Windows security. Trusted
sub system is typically easier to configure (delegation can be quite
tricky) and may perform better in some use cases but forced all
authorization logic to be implemented at the front tier. This is
sometimes a good thing and sometimes a bad thing, depending on how you
want to use SQL.

It is also fair to say that delegation and trusted sub system are
architectural styles for implementing authentication and authorization
in distributed applications and the principals can be applied without
using Windows security as long as other protocols that support these
principals exist. Trusted sub system is typically easy to set up while
delegation tends to be much harder to implement effectively without
Windows security. Technology enabled by protocols like
WS-Trust/WS-Federation and Geneva server will begin to change all that,
at least for applications and services that can implement those
protocols instead of only Kerberos/negotiate auth in Windows. Alas, as
far as I know SQL is not there yet.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
"7777" <NoSpam@xxxxxxxxxx> wrote in message
news:%23uJ9EZZMKHA.3384@xxxxxxxxxxxxxxxxxxxxxxx
Hello, a little foggy on this but are both methods of Impersonation /
Delegation vs. Trusted Subsystem from the following link of
http://msdn.microsoft.com/en-us/library/ms998292.aspx are both Windows
based authentication to SQL Server? Kind of had the impression that
Impersonation was more like a bunch of basic usernames/passwords stored
in a user db table that all shared 1 Windows authentication account?
Ultimately we'd like to go with individual Windows Authentication
accounts for all the users for high granular auditing/security in still
utilizing Windows security and wasn't quite sure if the
Impersonation/Delegation is able to do this. Thanks in advance.








.



Relevant Pages

  • Re: Windows Authentication with non current user name
    ... > Windows authentification is for Integrated Security and SQL Authentification ... > is for SQL accounts. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Windows Authentication to SQL Server?
    ... app and SQL Server were to be set up in the Delegation method would there be ... individual Windows accounts) in that when SQL Profiler is run in the ... In delegation, authentication to SQL server is done as the user ... SQL security but the article is discussing Windows security. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Windows Authentication to SQL Server?
    ... oranges in trying to convert an asp.net app which uses forms authentication ... mode throughout the app with one SQL login account into SQL Server versus ... converting the asp.net app into a full individual Windows authentication ... Ultimate goal would be to see the individual windows ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Windows Authentication to SQL Server?
    ... required to get the logons configured in SQL and what your options are. ... working with individual accounts may be fine for you. ... You should definitely see the individual Windows logons for the users ... or SQL security but the article is discussing Windows security. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Windows Authentication to SQL Server?
    ... I'm not much of a SQL guy so I'm not totally sure on all the details required to get the logons configured in SQL and what your options are. ... you'd want a role mapping scheme where windows groups end up getting mapped to SQL roles for the actual security implementation so that you have a nice abstraction layer in SQL for managing the actual permissions and can use AD and groups as a way of assigning membership to those roles. ... Depending on the number of users involved, working with individual accounts may be fine for you. ... this can be done with either Windows security or SQL security but the article is discussing Windows security. ...
    (microsoft.public.dotnet.framework.aspnet.security)

Loading