Hello list.

We're using some braindead appliance that insist on having internal telephone numbers in LDAP, whereas we need to also store external numbers (external prefix + internal number) for other purposes.

I didn't found any way to dynamically alter the content of the telephonenumber attribute when asked by the client (filtering the prefix on the fly), so I quickly opted to store the information twice: the short and the long number.

The appliance doesn't allow to select which attribute to use, it always use the first value from telephoneNumber attribute. So the current solution is to store both values in this attribute, and use the valsort overlay to always have the short number first. However, this rely on client being aware of the trick, and using to the second value when several are available, whereas we'd prefer to do the trick server-side.

I then tried to use different attributes (homePhone vs telephoneNumber) to store those different values, and use attribute mapping to reply with the expected value depending on the client. I had a quick look at rwm overlay, but attribute mapping seems to be global only, not for a given client only. On Buchan's suggestion, I tried relay backend instead, so as to only remap attributes values using a specific context.

This seems the correct strategies, however I'm facing a few issues. First, using a distinct database doesn't allow to provide a virtual view from a branch in my original database to another branch in the same database. Meaning, I can't have ou=telephony,dc=myprefix a virtual view of ou=users,dc=myprefix, I need to use a distinct prefix.

Second, trying the solution at the end of slapo-rwm man page to only map some attributes and exclude others is actually filtering too much. As soon as I use 'map attribute *' to exclude unmapped attributes, I can't list entries anymore. Adding the pseudo-attributes 'entry' to mapped attributes, which is documented as needed for research operation in slapd.access man page, doesn't help. So I had to ressort to ACLs instead to exclude unwanted attribute.

Third, this solution doesn't work currently when trying to sync the appliance users from ldap. From ldap log, it seems some specific control is not supported with relay backend:

Jul 22 13:46:12 etoile slapd[10826]: conn=3 fd=23 ACCEPT from IP=193.55.250.9:37225 (IP=0.0.0.0:389) Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 BIND dn="cn=callmanager,ou=roles,cn=telephony" method=128 Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 BIND dn="cn=callmanager,ou=roles,dc=msr-inria,dc=inria,dc=fr" mech=SIMPLE ssf=0 Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=0 RESULT tag=97 err=0 text= Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SRCH base="ou=users,cn=telephony" scope=2 deref=3 filter="(objectClass=inetOrgPerson)" Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SRCH attr=uid givenname initials sn manager departmentnumber telephonenumber mail title homephone mobile pager Jul 22 13:46:12 etoile slapd[10826]: conn=3 op=1 SEARCH RESULT tag=101 err=12 nentries=0 text=critical control unavailable in context

When using a different loglevel, the only critical control requested is 1.2.840.113556.1.4.319, pagedControl. However, the client request for it seems to succeed:

Jul 22 13:48:10 etoile slapd[11317]: => get_ctrls Jul 22 13:48:10 etoile slapd[11317]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Jul 22 13:48:10 etoile slapd[11317]: <= get_ctrls: n=1 rc=0 err=""

My wild guess is that the control doesn't survive the context switch from the original base (dc=msr-inria,dc=inria,dc=fr) to the virtual base (cn=telephony). Should I report this as a bug, or am I misunderstanding ?

I'm using openldap 2.4.11, and here is the virtual base configuration, if that matters: database relay suffix "cn=telephony" relay "dc=msr-inria,dc=inria,dc=fr" overlay rwm rwm-suffixmassage "dc=msr-inria,dc=inria,dc=fr"

access to dn.subtree="cn=telephony" attrs=userPassword by anonymous ssf=56 auth by anonymous peername.ip=193.55.250.9 auth by * none

access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*) attrs=entry,objectClass,telephoneNumber,uid,givenName,sn,manager,mail by * read

access to dn.subtree="ou=users,cn=telephony" filter=(telephoneNumber=*) by * none

map attribute telephoneNumber homePhone map attribute telephoneNumber

Any hint welcome, either on the solution choice, or on the selected solution troubles.