After upgrading to Domino 6.53 (from R5.12), LDAP writing from a 3rd party app is creating Domino person docs of Type and Form “ldapPerson” instead of Person. Anyone know why?
It only creates at all when schema checking is disabled. When it’s enabled, the writes fail due to this ldapPerson objectclass that Domino doesn’t like.
In schema.nsf (6.5x) there is a document for an “ObjectClass: Person”…and the following fields are set:
LDAP Name = Person
OID = 2.5.6.6
Notes Mapping = ldapPerson
In an old schema.nsf (R5.x) the same document has a blank Notes Mapping field. I can’t test this yet (will next week), but I think this may be the difference and the problem.
Can anyone with more LDAP expertise provide some insight?
Subject: LDAP Gurus? - Why ldapPerson?
After upgrading to Domino 6.53 (from R5.12), LDAP writing from a 3rd party app is creating Domino person docs of Type and Form “ldapPerson” instead of Person. Anyone know why?
An LDAP application wishing to create a Person document in the Domino directory, must use all the objectClass values described in Object class hierarchy for dominoPerson object class
Subject: RE: LDAP Gurus? - Why ldapPerson?
Thank you. What I found is this. In R5 it worked fine, and broke when I installed 6.5x. The LDAP writing application did not change, but I did see that it only used the following:
person
organizationalPerson
inetOrgPerson
This was working somehow, but once 6.5x went in, it stopped. When I added “top” and “dominoPerson” in a test, that worked.
Now I need to be able to have the LDAP write tool write to the mailsystem field. It works when schema checking is off, but I would prefer for it to be on. I’ve tried to figure out why that’s failing on that attribute, and a couple of others, but if I can fix one I can fix them all.
Any idea?
Subject: RE: LDAP Gurus? - Why ldapPerson?
Now I need to be able to have the LDAP write tool write to the mailsystem field. It works when schema checking is off, but I would prefer for it to be on. I’ve tried to figure out why that’s failing on that attribute, and a couple of others, but if I can fix one I can fix them all.
To determine what the actual LDAP operation is and how the LDAP server is handling it, put LDAPDEBUG=7 in Notes.ini, reboot LDAP, execute your program, and see what the server console reveals.
Subject: RE: LDAP Gurus? - Why ldapPerson?
Thank you. I’ve been using that all along to get more info and it helps a great deal.
I’ve done some extensive scenario testing (with schema checking on and off) and have found that it was failing on Shortname (which is technoted to now be UID) when schema checking was on. Once changed, that works fine, or I can just turn off schema checking, which I’ve discovered was never on in our environment in R5 anyway. Also, the LDAP write was always writing an objectclass of Person, which in R5 was creating a person doc, but in 6.x started creating docs of Type ldapPerson.
Instead of objectclass of Person, I need to use “dominoPerson.”
So if schema checking is on, I have to make shortname now be UID instead, and I need to make sure (regardless if schema check is on or off) that objectclass Person is actually dominoPerson. If Person AND dominoPerson objectclasses are being used, that works fine too, as long as one of them is dominoPerson.
Thanks for your replies.
Subject: RE: LDAP Gurus? - Why ldapPerson?
So if schema checking is on, I have to make shortname now be UID instead, and I need to make sure (regardless if schema check is on or off) that objectclass Person is actually dominoPerson.
Just always use UID, regardless of whether schema checking is on or off.
If Person AND dominoPerson objectclasses are being used, that works fine too, as long as one of them is dominoPerson.
Per Object class hierarchy for dominoPerson object class, you really should have 5 values for the multi-valued objectClass attribute:
top
person
organizationalPerson
inetOrgPerson
dominoPerson
In LDAP, the order does not matter.
Subject: RE: LDAP Gurus? - Why ldapPerson?
Got it. Thanks for steering me in the right direction.