programmatically login using LDAP and impersonation

[bob]

I'm on a network system that has some pretty strict policies that I can not change. My criteria is to use forms login for extranet users, against a sql server database and impersonate an account that is on an intranet Active Directory.

Saying it a different way, I need to impersonate an intranet Active directory account that must be authenticated using Kerberos authentication.

I'm stuck at this point trying to figure out how to programticly impersonate the account that will be used to access the sql server. It will only allow windows authentication, our system uses LDAP windows auth, that runs thru a kerberos portal.

*sigh* The only thing I can think of is to programaticly log in the intranet account, get the authentication ticket assign that ticket to the user, then using the login name and password they provided check the database and determine authorization from there. Is there another way, am I missing something? If I'm not missing something where can I get the information that I need?

EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com

 

[bob]

Its on .net 2.0 framework, sql server 2005, win server 2003.

EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com

 

[Consultant]

use the enterprise library

 

[Dominick Baier]

why?

 

[Dominick Baier]

In Windows 2003 domains you can impersonat an account by using the UPN (user@domain)

e.g.

WindowsIdentity id = new WindowsIdentity(username);
id.Impersonate();

 

[Joe Kaplan]

Is it possible that you can configure the IIS App Pool identity to use the
domain account you need to log in to both SQL and AD? This is by far the
easiest way and requires no impersonation. Authentication will use Kerberos
as long as proper SPNs for all of the identities are configured, otherwise
it will fail over to NTLM.

Alternately, you can call LogonUser (see SDK docs of
WindowsImpersonationContext for sample) and impersonate or potentially
configure the ASP.NET identity element to impersonate a specific identity.
However, I'd stay away from both of those if possible as you then need to
store the credentials of the identity yourself instead of letting IIS do it
in the metabase.

Joe K.

 

[Joe Kaplan]

Well, sort of.

In able to actually be able to do anything, the process that created the
WindowsIdentity must have act as part of the operating system privilege.
This is not a normal configuration.

It is a very useful feature all the same...

Joe K.

 

[Dominick Baier]

well - for SQL and file access you don't need this privilege..i tested that

but i know that some stupid "side effects" can require this often...

 

[Dominick Baier]

sorry - of course only for remote resource via constrained delegation.

 

[Joe Kaplan]

Right. That's what I was getting at. The remote stuff is also dicey
because a lot of stuff in the .NET runtime accesses local resources like
file system or perf counters on the way out to the remote resource, so a lot
of things that should work (accessing a remote web service via HTTP) don't
because they may hit a config file or a perf counter.

Joe K.