Part 4 of Global Directory

One useful application of a global directory if others can not only lookup your email address, but your phone number as well. This is possible with a mapping of phone numbers in the DNS known as ENUM. This article explains how to setup the structures for that part of your online presence.

This article is part of a series of articles about the global directory.

Reverse Directory: LDAP Configuration Examples

Following are a few example LDIF files that could be used to configure LDAP.

These assume that you have created an ldap.tcp SRV record pointing to your LDAP server.

Example: Personal Access Number

If the phone number is used to access a person or department directly, it probably makes sense to refer to that person's or department's direct contact information. We will therefore refer to uid=bakker,dc=orvelte,dc=nep from the number +012345.

To redirect from ENUM to the orvelte.nep LDAP service, create the following object in your LDAP server:

# Redirection for +012345 under e164.arpa
dn: dc=5,dc=4,dc=3,dc=2,dc=1,dc=0,dc=e164,dc=arpa
dc: 5
ref: ldap://ldap.orvelte.nep/dc=orvelte,dc=nep
objectClass: referral
objectClass: dcObject

# Redirection for +012345 under e164.org
dn: dc=5,dc=4,dc=3,dc=2,dc=1,dc=0,dc=e164,dc=org
dc: 5
ref: ldap://ldap.orvelte.nep/dc=orvelte,dc=nep
objectClass: referral
objectClass: dcObject

This would be your only directory base node if you only had this number; but you might also have a range of numbers, in which case you would also need to create intermediate nodes up to the directory base node, with one or more intermediates like this:

# +01234 under e164.arpa
dn: dc=4,dc=3,dc=2,dc=1,dc=0,dc=e164,dc=arpa
dc: 4
ou: ENUM +01234
objectClass: dcObject
objectClass: organizationalUnit

# +01234 under e164.org
dn: dc=4,dc=3,dc=2,dc=1,dc=0,dc=e164,dc=org
dc: 4
ou: ENUM +01234
objectClass: dcObject
objectClass: organizationalUnit

Your directory probably wants to see these inserted in top-down order.

Now you should create the user identities equal to the number. These could themselves hold information, or they could refer to a "real" user identity with either an alias or a referral. Using a referral that would be:

# Referral from 012345@orvelte.nep to bakker@orvelte.nep
dn: uid=012345,dc=orvelte,dc=nep
uid: 012345
ref: ldap://ldap.orvelte.nep/uid=bakker,dc=orvelte,dc=nep
objectClass: uidObject
objectClass: referral

Alternatively, you could have used an alias object because you are referring to a single object on the same LDAP server:

# Referral from 012345@orvelte.nep to bakker@orvelte.nep
dn: uid=012345,dc=orvelte,dc=nep
uid: 012345
aliasedObjectName: uid=bakker,dc=orvelte,dc=nep
objectClass: uidObject
objectClass: alias

You can now setup your object uid=bakker,dc=orvelte,dc=nep as you would like to:

dn: uid=bakker,dc=orvelte,dc=nep
uid: bakker
labeledURI: xmpp:bakker@orvelte.nep Chat over XMPP
labeledURI: sip:bakker@orvelte.nep Call using SIP
labeledURI: geo:52.843631,6.659689 Our GPS coordinates
mail: bakker@orvelte.nep
seeAlso: cn=Jan Degens,dc=openfortress,dc=nl
objectClass: uidObject
objectClass: account
objectClass: labeledURIObject

This, or an underlying object, is also a good place to store your X.509 certificate.

Example: General Access Number

Assuming that your phone number +012345 is seen as a public access number to your organisation; you would want to point it to your general information and not reveal any personal details. If a phone number is mentioned, it'd be a receptionist's. This sort of information is usually present in the main object of a hierarchy, like in dc=orvelte,dc=nep.

This information relaying is done with almost the same setup as above, except for the second referral or alias:

# Referral from 012345@orvelte.nep to orvelte.nep
dn: uid=012345,dc=orvelte,dc=nep
uid: 012345
ref: ldap://ldap.orvelte.nep/dc=orvelte,dc=nep
objectClass: uidObject
objectClass: referral

The alias-based alternative would be:

# Referral from 012345@orvelte.nep to orvelte.nep
dn: uid=012345,dc=orvelte,dc=nep
uid: 012345
aliasedObjectName: dc=orvelte,dc=nep
objectClass: uidObject
objectClass: alias

This intermediate step is required to support the scheme where uid=012345,dc=5,... is looked up -- the reference is from dc=5,... to dc=orvelte,dc=nep so the query tool would ask for uid=012345,dc=orvelte,dc=nep; for LDAP, it might be possible to skip this, but in general protocols like/want to use a username; think of email, XMPP, SIP. There is nothing wrong with supporting this scheme in LDAP as well.

Your LDAP server probably contains the object for dc=orvelte,dc=nep with just the right information -- be it personally identifying or organisational information.

Next: Fully Distributed OpenPGP