LDAP Schema woes

Today, I wanted to add a new field to our person document form in our directory for our internal VOIP telephone extensions. There are alot of people out there now using VOIP, but the problem is that our users don’t know what the extensions are for people in other sites/locations. If they would use the VOIP extension instead of dialing the long distance number, we could save alot of money.

I created a field called OnNet, refreshed the design of the NAB, populated the field with some actual data, and then went to test it out. Works great.

However, our corporate accessible directory is a web application on a Linux box that performs LDAP queries to Domino.

If I authenticated to LDAP, I could see all of the person document fields with a LDAP browser including OnNet and the data, but if I don’t authenticate, I can only see the domino fields (or LDAP attributes) that are specified in the * server configuration document.

I had this test server setup in the same domain as my production server, but with a non-replica copy of the NAB, so that any changes I made wouldn’t be replicated to the rest of the production environment.

I couldn’t figure out why the LDAP schema wasn’t updated with my new Domino field. I would expect to see an LDAP attribute in the schema.nsf database with the name of OnNet and OID of id-at-DominoOnNet (where OnNet is the name of the field that I added to the NAB). It does not appear.

I tried to run tell ldap reloadschema, but received the error “LDAP Schema: Failed Loading”
EDIT: please note “tell ldap exportschema” is no longer a valid command in R6.5 and greater.

Frustrating.

I also tried manually adding the attribute OnNet, Syntax name: Directory String, and OID: id-at-DominoOnNet but I kept receiving a popup box with title “Field Contains Incorrect Value” and in the popup box it said “Incorrect data type for operator or @Function: Text expected”

Double Frustrating.

I got around the problem by just adding a random number of 1111111 as the OID, then I was able to add OnNet in the * Server configuration document by selecting the attribute from the left column.

After I was able to add the attribute in the * server configuration document, I deleted the attribute in schema.nsf to see what would happen.

(after restarting LDAP) I was able to successfully query my name and receive the expected result for OnNet with my extension number.

I realized two things after this accidental hack.
1. In reading through the admin help, the schema is built from the administration server, and since the administration server didn’t have the new design with the OnNet field, the id-at-DominoOnNet wasn’t added to the schema (I’m guessing anyways, I haven’t rolled this out to production yet).
2. I didn’t notice the “NEW” button on the “LDAP Attribute Type Selection” popup box that will let you add any attribute manually instead of selecting it from the list of attributes that are derived from the schema.nsf. DOH!!!!

In reality this was an exercise in futility because we really want people (and the directory application on the linux box) to perform authenticated LDAP queries, but at least I know more about extending the schema now.

EDIT: In researching my issue, I searched through the admin help of course, but also the Domino 6 and 6 forums at ibm.com, where I found Chris Miller’s excellent (though a little dated) documentation called Using LDAP in Domino

One Response to “LDAP Schema woes”

  • Chris Miller says:

    You are correct, I cover this often in my LDAP sessions. The schema is built on the administration server and pushed out to the other servers. So any modifications need to be performed there if you are thinking of modifying the schema

Leave a Reply

Consulting

I'm currently available
for Lotus Notes / Domino consulting engagements.

LinkedIn

Connect with me:

LinkedIn

Advertisement
Advertisement
Categories