DirectoryEntry Impersonate or WindowsIdentity Impersonate?

Ask a Question related to ASP.NET Security, Design and Development.

  1. #1

    Default DirectoryEntry Impersonate or WindowsIdentity Impersonate?

    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

    Bill Belliveau Guest

  2. Similar Questions and Discussions

    1. Impersonate + AD
      Hi, I've got a difficult situation... Is a website that runs on IIS with Anonymous Authentication, the tag <identity impersonate="false"> on the...
    2. Asp.net impersonate
      I don't think impersonation loads the user profile of the account being impersonated. If you think about it, that would make impersonation very...
    3. Impersonate a user
      Hi guys, I am working for an asp app with the use of sql 2000, COM+ and iis 5.0. In part of the solution, some files (lotus notes related) will...
    4. cmd.exe should run in impersonate account.
      Hi All, I am starting a new process from asp.net(cmd.exe). See the following code, System.Security.Principal.WindowsImpersonationContext...
    5. impersonate
      Hi all, I create a aspnet web app for my company. I set it up on a win2000 server with IIS5 as a intranet app. For security, I want to restrict...
  3. #2

    Default Re: DirectoryEntry Impersonate or WindowsIdentity Impersonate?

    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:

    [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/connection_caching.asp?frame=true[/url]

    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" <anonymous@discussions.microsoft.com> wrote in message
    news:51440923-5DF1-4455-B8D8-64CDEAC46ABA@microsoft.com...
    > 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\) Guest

  4. #3

    Default Re: DirectoryEntry Impersonate or WindowsIdentity Impersonate?

    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

    [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/connection_caching.asp?frame=tru[/url]

    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.
    Bill Belliveau Guest

  5. #4

    Default Re: DirectoryEntry Impersonate or WindowsIdentity Impersonate?

    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" <anonymous@discussions.microsoft.com> wrote in message
    news:10C8465F-B490-4C90-9834-45CE12F88CAC@microsoft.com...
    > 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:
    >
    >
    [url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/connection_caching.asp?frame=true[/url]
    >
    > 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.

    Joe Kaplan \(MVP - ADSI\) Guest

Posting Permissions

  • You may not post new threads
  • You may post replies
  • You may not post attachments
  • You may not edit your posts

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139