RE: RE: LDAP connections to the proper server, and unknown error??

I'm sure it will help gobs and gobs, John! Thanks loads for these comments! 

Unfortunately I'm in the middle of rollouts of the first batch of programs in 
this set that makes up a long overall project, since the testers are waiting 
for the first ones, and they couldn't wait for this. BUT this functionality 
will have to be "retrofitted" into those when I get it working. 

So it'll be a few days before I can revisit this, even with these helpful 
points.

I also got a suggestion from IBM's support line, on using the qshell LDAPSEARCH 
to check the actual (numeric) IP's, and another from Scott Klement to try 
TELNET to the server name/port number. I will try those also. 

Also, meantime, the sysadmin is researching into setting up our i5 boxes as 
"replica LDAP servers", assuming I understand the terminology correctly, 
meaning copying the LDAP data to the IBM (partitions/boxes) on a nightly 
schedule, since using the *LOCAL directory would probably be smooth as ice (in 
my directory newbie opinion). 

I have thought that would be a "kludge", since the dadgum thing is supposed to 
work!  :-) I've been sure that either (1) I'm just missing the exact values 
somewhere, or (2) missing something in the API's, or now, based on your mention 
of PTF's, (3) missing PTF's. ! 

I say again, THANKS loads!

--Alan


-----Original Message-----
Behalf Of jmcmeek@xxxxxxxxxx
Sent: Thursday, July 13, 2006 10:52 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RE: LDAP connections to the proper server, and unknown
error??


Alan,

Where does this problem stand from the perspective of trying to do these 
searches using QSH ldapsearch utility?  And what release are you on?

Here's some tips that might help with getting this working, at least 
trying to use the equivalent ldapsearch requests from QSH.  What I know 
about RPG is limited to how it is spelled ;-)

Invalid credentials:

Besides the obvious problems -- DN or password was wrong -- here's some 
tips on what the DNs should look like.  Active Directory supports two 
styles of bind DNs.  Using John Doe, login name=jdoe, in the mycompany.com 
domain as an example:
1) you can bind using a full DN like "cn=John 
Doe,cn=users,dc=mycompany,dc=com"
2) or you can bind using what I call a principal name (because it looks 
like a Kerberos principal name):  jdoe@xxxxxxxxxxxxx

If you don't create users in the "users" folder, the "cn=users" part of 
the name needs to be changed to match how you manage users.  There should 
be some Windows tools that will show you the full DN for any given user, 
but I don't have access to Windows 2000/2003 domain to help there.

Protocol error:

When you do searches using "dc=mycompany,dc=com" as the search base, 
Active Directory returns several "referrals" which the client library 
optionally chases (issues the same search using the server and base DN 
from the referral).  If you use ldapsearch with the "-R" option, the 
ldapsearch utility will not chase these referrals, and instead prints the 
referrals to the output.  That will show you if referrals are involved.

But I digress.

In V5R3 - possibly earlier releases - there was a problem in how the i5/OS 
LDAP client library handled referrals that resulted in the Active 
Directory server returning a protocol error and immediately closing the 
client's connection.  This was fixed in V5R3 by PTF 5722SS1-SI17082.

I hope this helps.

John McMeeking
i5/OS Directory Server team
T