System.DirectoryServices works on one machine, but not another in same domain

[Chris Newby]

I have a .net application that is basically doing:
=================================================================
DirectoryEntry root = new DirectoryEntry( GetRootPathString() );
DirectorySearcher search = new DirectorySearcher( root, someFilterString,
null, SearchScope.Subtree );
SearchResult result = search.FindOne();
=================================================================

All within the same domain, "result" is valid (ie, returns the results that
I expect) on one server and null on another. What should I look into to
start figuring out why "result" is null on the one server?

TIA//

 

[Willy Denoyette [MVP]]

I have a .net application that is basically doing:
=================================================================
DirectoryEntry root = new DirectoryEntry( GetRootPathString() );
DirectorySearcher search = new DirectorySearcher( root,
someFilterString, null, SearchScope.Subtree );
SearchResult result = search.FindOne();
=================================================================

All within the same domain, "result" is valid (ie, returns the results
that I expect) on one server and null on another. What should I look into
to start figuring out why "result" is null on the one server?

TIA//

And how does GetRootPathString looks like? Is the user logged on into the
domain or not?


Willy.

 

[Chris Newby]

GetRootPathString looks like: LDAP://DC=local/DC=mycompanyname

As for the user being logged in ... this code is actually being run from an
Asp.Net application that is configured to use Integrated Security (which
appears to be working correctly on the server returning null for the search
described previously).

 

[Willy Denoyette [MVP]]

Where is the AD server running? And where are the clients? Here I mean the
browser clients, do they run on the same server as the asp.net application
or not. I'm asking this because, unless all is set-up correctly to allow
kerberos delegation, your authentication handshake will not get passed to
the AD server when the client is running on another box as the IIS server.
You also should take care when running the AD (the domain controller) on a
server running IIS, such set-up should be avoided if at all possible.

Willy.

 

[Chris Newby]

The domain controller is on a seperate server from the web server and the
client pc. A user opens up his browser on his local machine and makes
requests to the Asp.Net application which is running on its own server (in
this specific case, there are actually two seperate web servers, one that
works and one that doesn't).

So, I think delegation is likely the problem ... in fact we've suspected
problems with the delegation setup of the server in question in the past,
however we haven't been able to resolve those issues.

I've read most of the KBs on MSDN regarding delegation without success ...
do you have any links that might be of use?

Also, is it possible that there is something else defective besides
delegation?

Thanks for your help//

 

[Marc Scheuner [MVP ADSI]]

The domain controller is on a seperate server from the web server and the

client pc. A user opens up his browser on his local machine and makes
requests to the Asp.Net application which is running on its own server

Often times, when using ASP.NET, you can't get away with the
"serverless-binding" LDAP string, but you need to specify a server to
query in your domain.

E.g. instead of LDAP://dc=mycompany,dc=com, you need to explicitly
specify the server:

LDAP://MyDC01.mycompany.com/dc=mycompany,dc=com

Marc

 

[Chris Newby]

Marc, I started playing around with the querystring and found that there
were what looked like some case-sensativity issues. For example:

LDAP://dc=local,dc=mycompany does not work, but
LDAP://DC=local/DC=mycompany does work

However, I was still having issues with the same server as before ... so I
turned off Integrated Security and turned on Basic Authentication and logged
in as myself ... and the problem server started working.

This furthurs my gut feeling that there is a delegation problem ... but I'm
not sure why. After all, even tho the web application may or may not be set
to use Integrated Security ... it is still using integrated security to do
things like talk to Sql Server databases, and I would imagine it still must
use delegation to contact the domain controller.

What are your thoughts?

 

[Marc Scheuner [MVP ADSI]]

Marc, I started playing around with the querystring and found that there

were what looked like some case-sensativity issues. For example:

LDAP://dc=local,dc=mycompany does not work, but
LDAP://DC=local/DC=mycompany does work

Watch out - you're using the / as a separator, and if I remember
correctly, in that case you have to specify the path one way (e.g.
DC=local/DC=mycompany). I'm using the standard LDAP separator of ","
(comma) between items, and in this case, you have to specify the path
the other way around :
dc=mycompany,dc=local

My suggestions:

1) To rule out case sensitivity (which shouldn't be a factor, except
for the LDAP:// prefix, which has to be all uppercase), try

LDAP://DC=local/DC=mycompany
and
LDAP://dc=local/dc=mycompany

I'm pretty sure both should work.

2) To see if my bind string works, too, try using it in the right
order:

LDAP://dc=mycompany,dc=local

Cheers!
Marc