Forms or windows authentication with active directory?

[jp]

Hi, I'm having a hard time deciding (figuring out) how to implement
security in my asp.net application.

Requirements:
- Use active directory as database of users to authenticate against
- Have a login screen
- IIS and SQL Server Database are on different servers (delegation and
kerberos needed) to make trustedconnection=yes in connection string
work (no username and password in connection string).

If I use Windows Authentication in IIS and web.config, everything
works fine, except there is no login screen, so someone can access an
internal application by sitting at someone else's computer, if they
are already logged in.

If I use Forms Authentication in .NET and anonymous authentication in
IIS (using a user from the domain) and impersonate=true (so the
anonymous user can access active directory for authentication), the
user being impersonated is used to access the SQL Server when I need
the authenticated user to be the one to access SQL Server.

The only way I can figure the second situation to work would be to
have the authenticated user then assume impersonation and that seems
like it's not a good idea.


Any thoughts or ideas are more than welcome!

thanks.

[Joe Kaplan \(MVP - ADSI\)]

You could call the LogonUser API with the username and password you get from
the forms authentication in order to get a token that use can use to create
a WindowsIdentity that you can impersonate with in code. An advantage to
this is that you don't need delegation to hop to the SQL server as you get a
primary token from calling LogonUser. There is a nice sample in MSDN in the
docs on WindowsImpersonationContext.

The downside is that if you are running IIS on Win2K, you need SYSTEM level
privileges to call LogonUser, so that compromises your security. This
restriction is lifted in Win2K3.

You get much better integration with Windows auth right out of the box
though. Perhaps you could convince the users to be more careful about
locking their workstations when the leave and not letting other people
access resources on their behalf?

Another option would be to access SQL with a domain account based on your
processModel or app pool identity. This would only work if you are using
Windows auth to SQL just to avoid SQL auth, but don't need to access SQL as
the individual user accounts. In that case, you don't need impersonation,
and you could do Forms auth. with an Active Directory bind.

HTH,

Joe K.

"jp" <janetpye@hotmail.com> wrote in message
news:5607b8d.0402050850.560218d4@posting.google.co m...

> Hi, I'm having a hard time deciding (figuring out) how to implement
> security in my asp.net application.
>
> Requirements:
> - Use active directory as database of users to authenticate against
> - Have a login screen
> - IIS and SQL Server Database are on different servers (delegation and
> kerberos needed) to make trustedconnection=yes in connection string
> work (no username and password in connection string).
>
> If I use Windows Authentication in IIS and web.config, everything
> works fine, except there is no login screen, so someone can access an
> internal application by sitting at someone else's computer, if they
> are already logged in.
>
> If I use Forms Authentication in .NET and anonymous authentication in
> IIS (using a user from the domain) and impersonate=true (so the
> anonymous user can access active directory for authentication), the
> user being impersonated is used to access the SQL Server when I need
> the authenticated user to be the one to access SQL Server.
>
> The only way I can figure the second situation to work would be to
> have the authenticated user then assume impersonation and that seems
> like it's not a good idea.
>
>
> Any thoughts or ideas are more than welcome!
>
> thanks.

[jp]

Thanks for the advice. I'm a little confused about WindowsIdentity.
Can you give me an example of how to use LogonUser, get a token and
create a WindowsIdentity?



"Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@removethis.accenture.com> wrote in message news:<#hyfvUH7DHA.2416@TK2MSFTNGP10.phx.gbl>...

> You could call the LogonUser API with the username and password you get from
> the forms authentication in order to get a token that use can use to create
> a WindowsIdentity that you can impersonate with in code. An advantage to
> this is that you don't need delegation to hop to the SQL server as you get a
> primary token from calling LogonUser. There is a nice sample in MSDN in the
> docs on WindowsImpersonationContext.
>
> The downside is that if you are running IIS on Win2K, you need SYSTEM level
> privileges to call LogonUser, so that compromises your security. This
> restriction is lifted in Win2K3.
>
> You get much better integration with Windows auth right out of the box
> though. Perhaps you could convince the users to be more careful about
> locking their workstations when the leave and not letting other people
> access resources on their behalf?
>
> Another option would be to access SQL with a domain account based on your
> processModel or app pool identity. This would only work if you are using
> Windows auth to SQL just to avoid SQL auth, but don't need to access SQL as
> the individual user accounts. In that case, you don't need impersonation,
> and you could do Forms auth. with an Active Directory bind.
>
> HTH,
>
> Joe K.
>
> "jp" <janetpye@hotmail.com> wrote in message
> news:5607b8d.0402050850.560218d4@posting.google.co m...

> > Hi, I'm having a hard time deciding (figuring out) how to implement
> > security in my asp.net application.
> >
> > Requirements:
> > - Use active directory as database of users to authenticate against
> > - Have a login screen
> > - IIS and SQL Server Database are on different servers (delegation and
> > kerberos needed) to make trustedconnection=yes in connection string
> > work (no username and password in connection string).
> >
> > If I use Windows Authentication in IIS and web.config, everything
> > works fine, except there is no login screen, so someone can access an
> > internal application by sitting at someone else's computer, if they
> > are already logged in.
> >
> > If I use Forms Authentication in .NET and anonymous authentication in
> > IIS (using a user from the domain) and impersonate=true (so the
> > anonymous user can access active directory for authentication), the
> > user being impersonated is used to access the SQL Server when I need
> > the authenticated user to be the one to access SQL Server.
> >
> > The only way I can figure the second situation to work would be to
> > have the authenticated user then assume impersonation and that seems
> > like it's not a good idea.
> >
> >
> > Any thoughts or ideas are more than welcome!
> >
> > thanks.

[Joe Kaplan \(MVP - ADSI\)]

The "school" solution is to use the updated sample from MSDN from the
WindowsImpersonationContext class reference:

[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemSecurityPrincipalWindowsImpersonationCo ntextClassTopic.asp?frame=true[/url]

The big thing to remember is that there are very important security
limitations on calling LogonUser in Win2K that are not present in XP or 2K3.
That can complicate your deployment scenario. Reading the documentation for
LogonUser is very important.

Joe K.

"jp" <janetpye@hotmail.com> wrote in message
news:5607b8d.0402100807.77c37548@posting.google.co m...

> Thanks for the advice. I'm a little confused about WindowsIdentity.
> Can you give me an example of how to use LogonUser, get a token and
> create a WindowsIdentity?
>
>
>
> "Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@removethis.accenture.com>

wrote in message news:<#hyfvUH7DHA.2416@TK2MSFTNGP10.phx.gbl>...

> > You could call the LogonUser API with the username and password you get

from

> > the forms authentication in order to get a token that use can use to

create

> > a WindowsIdentity that you can impersonate with in code. An advantage

to

> > this is that you don't need delegation to hop to the SQL server as you

get a

> > primary token from calling LogonUser. There is a nice sample in MSDN in

the

> > docs on WindowsImpersonationContext.
> >
> > The downside is that if you are running IIS on Win2K, you need SYSTEM

level

> > privileges to call LogonUser, so that compromises your security. This
> > restriction is lifted in Win2K3.
> >
> > You get much better integration with Windows auth right out of the box
> > though. Perhaps you could convince the users to be more careful about
> > locking their workstations when the leave and not letting other people
> > access resources on their behalf?
> >
> > Another option would be to access SQL with a domain account based on

your

> > processModel or app pool identity. This would only work if you are

using

> > Windows auth to SQL just to avoid SQL auth, but don't need to access SQL

as

> > the individual user accounts. In that case, you don't need

impersonation,

> > and you could do Forms auth. with an Active Directory bind.
> >
> > HTH,
> >
> > Joe K.
> >
> > "jp" <janetpye@hotmail.com> wrote in message
> > news:5607b8d.0402050850.560218d4@posting.google.co m...

> > > Hi, I'm having a hard time deciding (figuring out) how to implement
> > > security in my asp.net application.
> > >
> > > Requirements:
> > > - Use active directory as database of users to authenticate against
> > > - Have a login screen
> > > - IIS and SQL Server Database are on different servers (delegation and
> > > kerberos needed) to make trustedconnection=yes in connection string
> > > work (no username and password in connection string).
> > >
> > > If I use Windows Authentication in IIS and web.config, everything
> > > works fine, except there is no login screen, so someone can access an
> > > internal application by sitting at someone else's computer, if they
> > > are already logged in.
> > >
> > > If I use Forms Authentication in .NET and anonymous authentication in
> > > IIS (using a user from the domain) and impersonate=true (so the
> > > anonymous user can access active directory for authentication), the
> > > user being impersonated is used to access the SQL Server when I need
> > > the authenticated user to be the one to access SQL Server.
> > >
> > > The only way I can figure the second situation to work would be to
> > > have the authenticated user then assume impersonation and that seems
> > > like it's not a good idea.
> > >
> > >
> > > Any thoughts or ideas are more than welcome!
> > >
> > > thanks.