DirectorySearcher.FindOne() failure on W2K3....

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

An odd problem, but here goes:

We implemented an ASMX web service as a gateway to the University's OpenLDAP directory to provide basic gorup membership / attribute lookups based on UID using the System.DirectoryServices namespace. Problem is that on a W2k3 box (member of AD), DirectorySearcher.FindOne() fails with a "Object reference not set to an instance..." error, with the stack dump pointing to the "IADsContainer::GetObject" method. On Win XP SP1, SP RC2, Win2k Server, Win2k Adv Server, and Win 2k Workstation (all members of the same AD), this works fine - but NOT on 2k3...tried both ConsoleMode (even running as Admin - yuck!!) app and WebPage / Service.

After verifying that firewalls were not causing our problem(s), I wrote a simple Win32 DLL using the LDAP API directly (with the same criteria) to query the OpenLDAP server, and (as expected) it works flawlessly. I can, however, simulate the same problem with the LDAP API by attempting ANY sort of binding operation against the OpenLDAP server...the code stalls for a few moments, then bombs out, failing on the bind attempt (the OpenLDAP directory provided by the University is set up for anonymous read-only querying ONLY - skipping the binding allows the queries to run successfully).

Question is: Are there any known changes / updates on server 2k3 (I assume a security and/or ADSI change) would cause this to operation to fail?? I have no problem using my Win32 DLL, but I would rather use the built-in supported namespaces instead.

TAI,
MichaelY
 
We implemented an ASMX web service as a gateway to the University's OpenLDAP directory
to provide basic gorup membership / attribute lookups based on UID using the System.DirectoryServices namespace.
Problem is that on a W2k3 box (member of AD), DirectorySearcher.FindOne() fails with a "Object reference not set to an instance..." error,
Click to expand...

That kinda sounds like a permissions problem - especially in ASP.NET
apps, permissions and bind credentials are crucial.

Since I'm not myself an ASP.NET expert, I'd strongly recommend you
check out the microsoft.public.adsi.general newsgroup, or the Yahoo
group "ADSIandDirectoryServices" (groups.yahoo.com - search for that
name).

So of the folks there are experts on ASP.NET permissioning and stuff
like that - they should be able to point to in the right direction.

Just out of curiosity - FindOne() is known to have some issues, e.g.
memory leaks. Does .FindAll() work???

Marc

================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Marc,

Tried the FindAll() method instead - same results (even while running as a console application, logged in as administrator)....any other ideas????

Also, since I did not provide exact error details last time, here is the stack dump from either search attempt:

Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
at System.DirectoryServices.Interop.IDirectorySearch.GetColumn(IntPtr hSearch
Result, IntPtr szColumnName, IntPtr pSearchColumn)
at System.DirectoryServices.ResultsEnumerator.GetCurrentResult()
at System.DirectoryServices.ResultsEnumerator.get_Current()
at System.DirectoryServices.ResultsEnumerator.System.Collections.IEnumerator.
get_Current()
at System.DirectoryServices.SearchResultCollection.get_InnerList()
at System.DirectoryServices.SearchResultCollection.get_Count()
at ConsoleDriver.TestApp.Main()....

TIA,
MichaelY
 
Tried the FindAll() method instead - same results (even while running as a console application, logged in as administrator)....any other ideas????

Okay, thanks.
Also, since I did not provide exact error details last time, here is the stack dump from either search attempt:

Unhandled Exception: System.NullReferenceException: Object reference not set to
an instance of an object.
at System.DirectoryServices.Interop.IDirectorySearch.GetColumn(IntPtr hSearch
Result, IntPtr szColumnName, IntPtr pSearchColumn)
Click to expand...

That failure would indicate it can't find the column it's looking
for.... hm..... is there any chance you might be asking for a column
that's either present in OpenLDAP but not AD, or vice versa?

Marc
 
That failure would indicate it can't find the column it's looking
for.... hm..... is there any chance you might be asking for a column
that's either present in OpenLDAP but not AD, or vice versa?
Click to expand...
Absolutely - the property we're looking for only exists in the OpenLdap realm, and does not exist in our local AD, although I'm hoping this isn't a problem with ADSI - we really don't care about and/or want that property in our local AD - it's a property specific to students only (entities that we don't have in our local AD anyway).

Perhaps a little background - due to 'edu' politics, our local AD is only our division (about 500-750 people). The OpenLDAP directory (University-wide) is ALL students, faculty, staff, etc (about 65,000 +)...you get the point. The service we are providing is an attribute lookup on student entities to see if they meet certain criteria. So, essentially, we just want to query to OpenLdap server, read the results (which the Win32 LDAP API does nicely, without binding), and continue with the appropriate business logic from there.

Perhaps the ADSI API's (and consequently System.DirectoryServices) are trying to do something with the local domain controllers during binding that is now restricted on W2k3???

Thanx again,
MichaelY
 
Hi Michael,
Perhaps the ADSI API's (and consequently System.DirectoryServices) are trying to do something
with the local domain controllers during binding that is now restricted on W2k3???
Click to expand...

I can't think of anything that would cause this kind of problem.
Hmm..... not sure if anyone else has ever seen this......

You might want to repost your question to a more appropriate
newsgroup, such as

* microsoft.public.adsi.general
* microsoft.public.platformsdk.adsi
* microsoft.public.server.active_directory

There's a ton of very qualified and helpful AD experts hanging out
there..... (and not necessarily here).

MArc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Marc,

I'll go ahead and post the same questions in those grouops - thanx so much for your help / time - it is greatly appereciated!!!

MichaelY
 
Back
Top