Hello Andy,

I want to add something to my post, I had forgotten nmas and overlooked the link from Kevin. Kevin gives the first good quick tip to investigate. But there are really other topics that correspond to what I have thrown into the room.

yes the problem exists exactly as you described. It is an upper-case lower-case problem. I even remember that it affected some special characters. If I remember correctly it is a configuration problem of the NDS and is, if I remember correctly, due to entries in the nam.conf and something else that I really can't think of. Open a case, the backliners know immediately where to go. I'll rummage around in my head, I had this issue with a big customer and I think I wrote scripts to filter out the users who have this problem with the Universam password.

Please look for the diagpwd tool if it is available in your OES installation.  One thing in the whole topic is also important, the replica design of your NDS on site. To explain this in one sentence is too complex, it needs a deep dive. Soory

Further keywords are SDI Domain Key servers and SDI consistency. Unfortunately, I have no information about the OES version and eDir versions of the servers in the tree.

That tool sounds about right, but to get diagpwd to actually behave, as it is spitting errors at me from a couple of boxes that have all the partitions.

ERROR -1 ldap_simple_bind_s
Segmentation fault (core dumped)

any quick ideas? I have the CA public key, freshly exported as a DER, and converted to the PEM needed. So that should be OK.  some packet captures up soon, as this is not something the client considers a high priority yet.

 Problem running diagpwd 

There is a similar topic here. I also had the error, in my case it was a defective pem file. If I remember correctly, none of them can be used

For me it's around 9 pm in the evening. I'll call it a day today. I hope I can write a few lines about ldap traces tomorrow, using the NDS on 636 to see if a der or pem is ok. The ndstrace is also a great tool for tracking down defects that Andy has, so I should also write a short sentence about it. You can also use this topic if the messenger doesn't want to work with GroupWise ldap or the mobility has a cough with the eDir or Groupwise when it comes to user or group add.

George

diagpwd isn't initiating a TLS connection like any other LDAP tools, so it is clearly failing on that front.

Packet capture shows just the basic TCP handshake up and down with diagpwd.  

I think a patching and restart of that server is part of what I'll be doing, and calling it a week. Though no OES related patches, just SLES level.

just very briefly, there were diagpwd versions that are actually defective, the whole thing depends on the patch status of the OES server. What I also observed was that the schema was not consistently up to date for all objects in an NDS, in this NDS objects had a timestamp for the schema which was in the future. As I said, the problem on site can be solved with diligence and a drawing that also shows how, for example, the nmas login sequence processes the topic and which services are responsible for which login. VIeles is based on measurements as it has already been done here

George

just very briefly, there were diagpwd versions that are actually defective, the whole thing depends on the patch status of the OES server. What I also observed was that the schema was not consistently up to date for all objects in an NDS, in this NDS objects had a timestamp for the schema which was in the future. As I said, the problem on site can be solved with diligence and a drawing that also shows how, for example, the nmas login sequence processes the topic and which services are responsible for which login. VIeles is based on measurements as it has already been done here

George

That these instances of diagpwd are not initiating TLS is a strong indicator of a defect in my eyes on something that must have TLS working.  And that is long before hitting other issues along the way.