DirectoryEntry Impersonate or WindowsIdentity Impersonate?

[Bill Belliveau]

Another security question.
Our project interfaces with the Active Directory. To satisfy the security issues, we have a couple options when we talk to the Directory.

1. Use the WindowsIdentity to impersonate the current user either by impersonating the User.Identity where available or by using UserLogon.
2. Making a DirectoryEntry for each query/edit and send the username and password per request as part of the DE.

My questions are what are the security and performance impact of these methods?

Thanks,
Bill

 

[Joe Kaplan \(MVP - ADSI\)]

This is an interesting question that I think can only be answered with
testing. I'm not sure it makes any difference at all if you are using
AuthenticationTypes.Secure, but it would be interesting to know.

There are a few things to know though:
The underlying ADSI layer will use a cached handle to the directory if an
open object exists in memory with the server, credentials and flags.
Therefore, if you are doing a lot of binds with the same credentials, it
might make sense to try to hang on to a root object for that user until they
are finished. This is detailed somewhat here:

http://msdn.microsoft.com/library/d...s/adsi/adsi/connection_caching.asp?frame=true

One the other hand, if you are doing just a few binds for each user, I would
be surprised if it makes an difference.

My instinct is to use the user's credentials if you have them as I have
found it to be much easier to debug problems in that situation because it
eliminates a big variable. That is what I have done in many of my . NET AD
apps.

Joe K.

Another security question.
Our project interfaces with the Active Directory. To satisfy the security

issues, we have a couple options when we talk to the Directory.

1. Use the WindowsIdentity to impersonate the current user either by

impersonating the User.Identity where available or by using UserLogon.

2. Making a DirectoryEntry for each query/edit and send the username and

password per request as part of the DE.

 

[Bill Belliveau]

After kicking this around for a few days the only thing I'm wondering about is security. When calling DirectoryEntry(path, username, password) does it access resources in a secure context? I assume it probably does something like LogonUser, get a token and then accesses the directory. Although as I'm finding out with ADAM, when using a userProxy object user credentials are sent plain text

In anycase, I think we've concluded that given the state of the project LogonUser is going to be more viable to impliment at this point

Bil

----- Joe Kaplan (MVP - ADSI) wrote: ----

This is an interesting question that I think can only be answered wit
testing. I'm not sure it makes any difference at all if you are usin
AuthenticationTypes.Secure, but it would be interesting to know

There are a few things to know though
The underlying ADSI layer will use a cached handle to the directory if a
open object exists in memory with the server, credentials and flags
Therefore, if you are doing a lot of binds with the same credentials, i
might make sense to try to hang on to a root object for that user until the
are finished. This is detailed somewhat here

http://msdn.microsoft.com/library/d...us/adsi/adsi/connection_caching.asp?frame=tru

One the other hand, if you are doing just a few binds for each user, I woul
be surprised if it makes an difference

My instinct is to use the user's credentials if you have them as I hav
found it to be much easier to debug problems in that situation because i
eliminates a big variable. That is what I have done in many of my . NET A
apps

Joe K.

 

[Joe Kaplan \(MVP - ADSI\)]

It is something like that. If you bind with the LDAP provider and specify
credentials, the method for exchanging credentials with the server is
determined by the AuthenticationTypes flags you pass in. If you use
AuthenticationTypes.Secure, the negotiate protocol is used (Kerberos or
NTLM). Your credentials are not passed in plain text. If you don't specify
Secure, then they are passed in plain text unless you specify
SecureSocketsLayer, in which case SSL/TLS is used for all LDAP traffic
(assuming the server has a valid cert and SSL can be negotiated).

I'd suggest using AuthenticationTypes.Secure always when binding to AD and
passing credentials.

With ADAM, you may wish to configure SSL to make sure that you can protect
credentials. You can still use Secure binding with Windows accounts in ADAM
(through userProxy objects) since those are just passed on to AD. I'm not
yet quite sure how it works with ADAM users.

Joe K.

After kicking this around for a few days the only thing I'm wondering

about is security. When calling DirectoryEntry(path, username, password)
does it access resources in a secure context? I assume it probably does
something like LogonUser, get a token and then accesses the directory.
Although as I'm finding out with ADAM, when using a userProxy object user
credentials are sent plain text.

In anycase, I think we've concluded that given the state of the project

LogonUser is going to be more viable to impliment at this point.