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

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
Thu Dec 15 14:08:30 CST 2005


"Chris Newby" <Chris.Newby@Rockcreekglobal.com> wrote in message
news:uuaboKaAGHA.344@TK2MSFTNGP11.phx.gbl...
>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
Thu Dec 15 14:20:12 CST 2005

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]" <willy.denoyette@telenet.be> wrote in message
news:uojTTNbAGHA.3864@TK2MSFTNGP12.phx.gbl...
>
> "Chris Newby" <Chris.Newby@Rockcreekglobal.com> wrote in message
> news:uuaboKaAGHA.344@TK2MSFTNGP11.phx.gbl...
>>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.
>
>

Willy
Thu Dec 15 16:49:11 CST 2005

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" <Chris.Newby@Rockcreekglobal.com> wrote in message
news:uWaOqUbAGHA.3456@TK2MSFTNGP11.phx.gbl...
> 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]" <willy.denoyette@telenet.be> wrote in message
> news:uojTTNbAGHA.3864@TK2MSFTNGP12.phx.gbl...
>>
>> "Chris Newby" <Chris.Newby@Rockcreekglobal.com> wrote in message
>> news:uuaboKaAGHA.344@TK2MSFTNGP11.phx.gbl...
>>>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
Thu Dec 15 17:25:16 CST 2005

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//


"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message
news:%23oSAGncAGHA.344@TK2MSFTNGP11.phx.gbl...
> 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" <Chris.Newby@Rockcreekglobal.com> wrote in message
> news:uWaOqUbAGHA.3456@TK2MSFTNGP11.phx.gbl...
>> 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]" <willy.denoyette@telenet.be> wrote in message
>> news:uojTTNbAGHA.3864@TK2MSFTNGP12.phx.gbl...
>>>
>>> "Chris Newby" <Chris.Newby@Rockcreekglobal.com> wrote in message
>>> news:uuaboKaAGHA.344@TK2MSFTNGP11.phx.gbl...
>>>>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.
>>>
>>>
>>
>>
>
>

Marc
Fri Dec 16 00:38:03 CST 2005

>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
Fri Dec 16 10:03:04 CST 2005

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]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in message
news:f4o4q11o9pbtggfs6uo2tknerpamtkhckj@4ax.com...
> >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

Marc
Sat Dec 17 07:22:59 CST 2005

>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