Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > DirectoryEntry Impersonate or WindowsIdentity Impersonate?

Reply
Thread Tools

DirectoryEntry Impersonate or WindowsIdentity Impersonate?

 
 
Bill Belliveau
Guest
Posts: n/a
 
      01-28-2004
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

 
Reply With Quote
 
 
 
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      01-28-2004
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/de...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.

"Bill Belliveau" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>



 
Reply With Quote
 
 
 
 
Bill Belliveau
Guest
Posts: n/a
 
      01-30-2004
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/de....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.
 
Reply With Quote
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      01-31-2004
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.

"Bill Belliveau" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> Bill
>
> ----- Joe Kaplan (MVP - ADSI) wrote: -----
>
> 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/de...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.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LDAP directoryEntry =?Utf-8?B?aHV6eg==?= ASP .Net 7 01-31-2011 09:39 PM
Comexception when setting domain password with directoryentry in a ASP.NET project Marek Kopanski ASP .Net 1 03-18-2005 04:55 AM
DirectoryEntry Disposal Test cameron ASP .Net 3 04-14-2004 09:55 AM
Access Denied Exception When Using DirectoryEntry ASP .Net 0 12-17-2003 04:26 PM
DirectoryEntry and CopyTo function Mik ASP .Net 0 07-04-2003 10:46 AM



Advertisments