Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When you do...</p> <pre><code>NetworkCredential credentials = new NetworkCredential("user", "password"); connection = new LdapConnection("domain"); connection.Bind(credentials); DirectoryContext directoryContext = new DirectoryContext(DirectoryContextType.Domain, "domain"); // This call returns a domain object with unreadable properties Domain domain = Domain.GetDomain(directoryContext); </code></pre> <p>...you're in fact just creating a (System.DirectoryServices.Protocols).LdapConnection with specific NetworkCredentials and you validate your "user" and "password" credentials against that. But then you don't use the connection-object anymore; instead you create a new entirely unrelated (System.DirectoryServices.ActiveDirectory).DirectoryContext-object.</p> <p>And because you're not using a constructor where you're explicitly specifying a username and a password the DirectoryContext-object will get <a href="http://msdn.microsoft.com/en-us/library/ms141476.aspx" rel="nofollow noreferrer">using the credentials of the user running the Application Pool</a> (in IIS 6+, in IIS 5.1 the application will, if memory serves me right, always be a/the local system account - IUSR_XXX - which won't be able to access Active Directory because it's not a domain account).</p> <p>The different credentials that are used when you're running your code in an IIS-environment versus just testing using a console application (where you're running code as the logged in/interactive user) is a common cause of problems in programming Directory Services.</p> <p>Try using the constructor <a href="http://msdn.microsoft.com/en-us/library/ms141478.aspx" rel="nofollow noreferrer">where you specify a username and password for the DirectoryContext-object</a>.</p> <p>As far as impersonation is concerned you might have better luck by using this code-snippet...</p> <pre><code>System.Security.Principal.WindowsImpersonationContext impersonationContext; impersonationContext = ((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate(); //Insert your code that runs under the security context of the authenticating user here. impersonationContext.Undo(); </code></pre> <p>...taken from <a href="http://support.microsoft.com/kb/306158" rel="nofollow noreferrer">KB306158: How to implement impersonation in an ASP.NET application</a>.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COYou're right about not using the connection in the domain call... that connection is used elsewhere in the code and wasn't relevant to the current problem, sorry for including it! It's the `CredentialCache` set on the proxy from the calling code that determines what identity the call to `GetDomain()` is made under. Because this is a web service, it may not be called from a web page, so I don't believe I can impersonate from User.Identity, correct me if I'm wrong. I've also tried setting Thread.CurrentPrincipal to a generic principal for my impersonation, but no luck. Thanks for the input!
      singulars
    2. COIt's difficult to help you more based on the code you've provided. How is the link between the proxy-object and the call to Domain.GetDomain made? Is it the netCred user/pass that you want to use when connecting to AD? Is it the end-user's credentials you want to use? Are the proxy-object on a seperate tier? Because then it could be a NTLM vs Kerberos double-hop issue. Can you debug and see the credentials used to call Domain.GetDomain? Can you set the credentials explicitly like I suggested and see if it works that way? When does it work and when does it not work?
      singulars
    3. COA call is made through the proxy object to a method that calls Domain.GetDomain. The NetworkCredential I'm setting is a user account that has permissions to query Active Directory. When I check the credentials from inside the web service, they are being set correctly. The proxy and object are separate app domains, but are running on the same machine. I don't have have a handle to the `User` object from the caller (the caller isn't a web page), so I can't use the impersonation you suggested. <more>
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload