NWIDirQ.dll - Anonymous Bind

Dear,
we encountered a very strange problem while we want to connect to a 
win2003 active directory server in anonymous mode (username&pswrd not 
filled) we traced the TCP-LDAP transfer between client and server pc 
and saw some strange occurences the first time we use the component very
straight forward 
             MyLDAPQ.FullName = "xxxxxxxx"
             MyLDAPQ.PortNumber = 389
             MyLDAPQ.Connect
connect seems to work and doesnt give a return error
but in traces you see next to a normal bind > ack 
another 'query'  of a ldap schema in some kind of way  
some kind of lookup
this lookup fails at our customer and unbinds the connection
with the obvious result we cant get data transfered or 
results back!
Could you please explain what happens ? or suggest a modification 
to server side security settings to resolve this issue ?

additional info:
older version of our package used MS ADOControl and worked on that 
same server in anonymous using a username - then only bind and ack is send
(no lookup)... this works perfect but the customer we implement for doesnt
accept this as a solution!
Our testing server doesnt have the same 'unbind' problem - but the 
schema lookup also occurs here so I would think its a security setting 
that needs to be revised?

Some clarifiactions:
Thanks for your answer. Our question is more on how does NWiDirQ work ?
When we setup a connection with AD providing an UserID/Password we can 
see with an ethernet sniffer that two LDAP messages are sent throught the 
network: LDAP BindRequest - LDAP BindResult(ok)
But when we setup an anonymous connection (no UserID) we get:
LDAP BindRequest - LDAP BindResult(ok) - LDAP SearchRequest ???
The last LDAP SearchRequest is automatically generated by your component.
It seems that your component has a kind of intelligence and tries to 
discover the schemas of the LDAP database. We do not have such request in 
our code. Our problem is that we do not have the control on it and if the 
LDAP SearchRequest fails we lose the connection with the LDAP Server. 
This is our problem.
 
In the past, we have already helped you to improve your component (refer 
to Suzan Perrin), we would appreciate some kind of assistance.
 
Thanks in advance.
  
Regards,
 
Wielemans D. / De Meulder H.
Quentris (Ascom) Belgium

Sorry to insist but it becomes urgent. 
Do I have a chance to get an answer ?

DidierWielemans wrote:

> Dear,
> we encountered a very strange problem while we want to connect to a 
> win2003 active directory server in anonymous mode (username&pswrd not 
> filled) we traced the TCP-LDAP transfer between client and server pc 
> and saw some strange occurences the first time we use the component very
> straight forward 
>              MyLDAPQ.FullName = "xxxxxxxx"
>              MyLDAPQ.PortNumber = 389
>              MyLDAPQ.Connect
> connect seems to work and doesnt give a return error
> but in traces you see next to a normal bind > ack 
> another 'query'  of a ldap schema in some kind of way  
> some kind of lookup
> this lookup fails at our customer and unbinds the connection
> with the obvious result we cant get data transfered or 
> results back!
> Could you please explain what happens ? or suggest a modification 
> to server side security settings to resolve this issue ?

> additional info:
> older version of our package used MS ADOControl and worked on that 
> same server in anonymous using a username - then only bind and ack is send
> (no lookup)... this works perfect but the customer we implement for doesnt
> accept this as a solution!
> Our testing server doesnt have the same 'unbind' problem - but the 
> schema lookup also occurs here so I would think its a security setting 
> that needs to be revised?

> Some clarifiactions:
> Thanks for your answer. Our question is more on how does NWiDirQ work ?
> When we setup a connection with AD providing an UserID/Password we can 
> see with an ethernet sniffer that two LDAP messages are sent throught the 
> network: LDAP BindRequest - LDAP BindResult(ok)
> But when we setup an anonymous connection (no UserID) we get:
> LDAP BindRequest - LDAP BindResult(ok) - LDAP SearchRequest ???
> The last LDAP SearchRequest is automatically generated by your component.
> It seems that your component has a kind of intelligence and tries to 
> discover the schemas of the LDAP database. We do not have such request in 
> our code. Our problem is that we do not have the control on it and if the 
> LDAP SearchRequest fails we lose the connection with the LDAP Server. 
> This is our problem.

> In the past, we have already helped you to improve your component (refer 
> to Suzan Perrin), we would appreciate some kind of assistance.

> Thanks in advance.

> Regards,

> Wielemans D. / De Meulder H.
> Quentris (Ascom) Belgium

Hi Didier,

Didier.Wielemans@Quentris.com (DidierWielemans) wrote in news:3exFh.3062
$ra4.721@prv-forum2.provo.novell.com:

> Sorry to insist but it becomes urgent. 
> Do I have a chance to get an answer ?
unfortunately these forums are no longer actively monitored by Novell 
folks; instead they should now serve more for user2user support; since your 
question is very specific I asked Susan who did formerly here very great 
support, and she provided this answer:

The schema is automatically read by the control.  That's by design because 
the control will require this to provide layout information.  The schema is 
read whether you use anonymous bind or not, but in the case of 
authenticated bind, the read is deferred to check the connect first.

The latest version of the control was modified to use whatever connection 
you bound with (using connect).  In earlier versions it ALWAYS used a 
separate anonymous connection which was slow and didn't work for anonymous 
bind restricted directories.

So if he can't read the schema it's going to fail or think no objects are 
defined.  He can test whether the schema can be read with ldp or ldapsearch 
etc.

I know of a bug that I wrote against activex that was happening on an AD 
server,

Bug 175329 - NWIDir control hangs on root DSE fetch with long schema dn.

https://bugzilla.novell.com/show_bug.cgi?id=175329

But that demonstrated itself as a nasty hang.

Thank you
Susan