|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
System.DirectoryServices works on one machine, but not another in same domainI 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//
Show quote
"Chris Newby" <Chris.Ne***@Rockcreekglobal.com> wrote in message And how does GetRootPathString looks like? Is the user logged on into the 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// > domain or not? Willy. 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). Show quote "Willy Denoyette [MVP]" <willy.denoye***@telenet.be> wrote in message news:uojTTNbAGHA.3864@TK2MSFTNGP12.phx.gbl... > > "Chris Newby" <Chris.Ne***@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. > > 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. Show quote "Chris Newby" <Chris.Ne***@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.denoye***@telenet.be> wrote in message > news:uojTTNbAGHA.3864@TK2MSFTNGP12.phx.gbl... >> >> "Chris Newby" <Chris.Ne***@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. >> >> > > 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// Show quote "Willy Denoyette [MVP]" <willy.denoye***@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.Ne***@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.denoye***@telenet.be> wrote in message >> news:uojTTNbAGHA.3864@TK2MSFTNGP12.phx.gbl... >>> >>> "Chris Newby" <Chris.Ne***@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. >>> >>> >> >> > > >The domain controller is on a seperate server from the web server and the Often times, when using ASP.NET, you can't get away with 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 "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, 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? Show quote "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, I started playing around with the querystring and found that there Watch out - you're using the / as a separator, and if I remember>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 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  |
|||||||||||||||||||||||
Other interesting topics