I have tried to create virtual views of existing local data and I have
realized that the rewrite/remap overlay (slapo-rwm) in conjunction with
the relay backend (slapd-relay) (both are experimental) does not exactly
do what I would like to have.
To explain the problem, let me consider the following hypothetical
situation. We have two groups of UNIX clients. All clients should be
accessed by the same set of users having different user ID on each
client group. In addition, it would be nice to have different user
passwords for each client group.
In the local schema, we define two new attributes xxxUidNumber and
xxxUserPassword, and a new object class xxxPosixAccount holding them.
The local.schema file, the initial slapd.conf file (OpenLDAP 2.4.22),
and the real data ldif file are at the end of this email. The real data
are in 'ou=users,ou=auth,o=example', and the virtual view is in
'ou=xxxUsers,ou=auth,o=example'.
1 The search problem
====================
Here are some queries and results to demonstrate it:
Real data:
----------
Search request A
~~~~~~~~~~~~~~~~
/usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \
-D "cn=ldap_manager,ou=auth,o=example" \
-w qwerty \
-b 'cn=user10,ou=users,ou=auth,o=example'
dn: cn=user10,ou=users,ou=auth,o=example
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: xxxPosixAccount
cn: user10
sn: user10
uid: user10
uidNumber: 1111
xxxUidNumber: 2222
gidNumber: 3333
homeDirectory: /tmp
loginShell: /bin/tcsh
gecos: User 10
userPassword:: e1NTSEF9QWlmMWtyQXhkRGQ3bHJ5amp6VzFoTUgxOFdVU01BPT0=
xxxUserPassword: {SSHA}BaPK4xvEKVpYwj3qK0zbOWpVOAwSMA==
Virtual view:
-------------
Search request B
~~~~~~~~~~~~~~~~
/usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \
-D "cn=ldap_manager,ou=auth,o=example" \
-w qwerty \
-b 'cn=user10,ou=xxxUsers,ou=auth,o=example'
dn: cn=user10,ou=xxxUsers,ou=auth,o=example
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: xxxPosixAccount
cn: user10
sn: user10
uid: user10
uidNumber: 1111
uidNumber: 2222
gidNumber: 3333
homeDirectory: /tmp
loginShell: /bin/tcsh
gecos: User 10
userPassword:: e1NTSEF9QWlmMWtyQXhkRGQ3bHJ5amp6VzFoTUgxOFdVU01BPT0=
userPassword:: e1NTSEF9QmFQSzR4dkVLVnBZd2ozcUswemJPV3BWT0F3U01BPT0=
The rewrite/remap part in slapd.conf was as follows:
overlay rwm
rwm-suffixmassage "ou=users,ou=auth,o=example"
rwm-map attribute userPassword xxxUserPassword
rwm-map attribute uidNumber xxxUidNumber
Because of the simple mapping, the reply contains uidNumber and
userPassword attributes two times. To eliminate this, we modify the
rewrite/remap part in slapd.conf:
overlay rwm
rwm-suffixmassage "ou=users,ou=auth,o=example"
rwm-map attribute userPassword xxxUserPassword
rwm-map attribute userPassword
rwm-map attribute uidNumber xxxUidNumber
rwm-map attribute uidNumber
Now the answer from the previous search request (B) seems to be as desired:
dn: cn=user10,ou=xxxUsers,ou=auth,o=example
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: xxxPosixAccount
cn: user10
sn: user10
uid: user10
uidNumber: 2222
gidNumber: 3333
homeDirectory: /tmp
loginShell: /bin/tcsh
gecos: User 10
userPassword:: e1NTSEF9QmFQSzR4dkVLVnBZd2ozcUswemJPV3BWT0F3U01BPT0=
But the next search request returns values, although one would expect an
empty result set, as the attribute xxxUidNumber (used in the filter) is
not explicitly present in the virtual view (it is mapped):
Search request C
~~~~~~~~~~~~~~~~
/usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \
-D "cn=ldap_manager,ou=auth,o=example" \
-w qwerty \
-b 'ou=xxxUsers,ou=auth,o=example' \
'(xxxUidNumber=*)'
dn: cn=user10,ou=xxxUsers,ou=auth,o=example
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: xxxPosixAccount
cn: user10
sn: user10
uid: user10
uidNumber: 2222
gidNumber: 3333
homeDirectory: /tmp
loginShell: /bin/tcsh
gecos: User 10
userPassword:: e1NTSEF9QmFQSzR4dkVLVnBZd2ozcUswemJPV3BWT0F3U01BPT0=
I think the attribute xxxUidNumber should be removed from the internal
query to the foreign data set, because it is used as a foreign name (and
in the same time not as a local name) in the mapping, and the query (C)
above should return an empty result set.
One can improve this by modifying the rewrite/remap part in slapd.conf
as follows:
overlay rwm
rwm-suffixmassage "ou=users,ou=auth,o=example"
rwm-map attribute cn *
rwm-map attribute sn *
rwm-map attribute uid *
rwm-map attribute gidNumber *
rwm-map attribute homeDirectory *
rwm-map attribute loginShell *
rwm-map attribute gecos *
rwm-map attribute userPassword xxxUserPassword
rwm-map attribute uidNumber xxxUidNumber
rwm-map attribute *
Now both search requests (B and C) work as expected. The last remap line
correctly removes everything what is not mapped. The problem here is
that one has to explicitly list all desired attributes in the remap
configuration. If a new attribute is added to the real data, it would
not show in the result set without a change in the remap configuration.
2 The authentication problem
============================
The following two bind request use the same password for authentication,
regardless of the mapping and the value of the attribute xxxUserPassword.
/usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \
-D "cn=user10,ou=users,ou=auth,o=example" \
-w abc123 \
-b 'cn=user10,ou=users,ou=auth,o=example' dn
dn: cn=user10,ou=users,ou=auth,o=example
/usr/local/bin/ldapsearch -LLL -H ldaps://censor.ethz.ch -x \
-D "cn=user10,ou=xxxUsers,ou=auth,o=example" \
-w abc123 \
-b 'cn=user10,ou=xxxUsers,ou=auth,o=example' dn
dn: cn=user10,ou=xxxUsers,ou=auth,o=example
If we use the userPassword (xyz789), reported by the view (e.g. query
B), the bind request returns 'Invalid credentials'.
If I understand it correctly, this is not a bug. The LDAP bind request
does not contain the name of the attribute holding the user password at
the server site, so there is (unfortunately) nothing to map.
There are many real life situations where, for security reasons, it
would be desirable to have different passwords for different
applications, or groups of applications/clients (e.g. web access, UNIX
login, etc.). Unfortunately, it seems the present virtual views
(slapo-rwm + slapd-relay) cannot solve it. For the moment, I see only
one possibility -- to create a copy of the user entries and to modify
the userPassword attribute. (Please let me know, if you know a better
solution.) But there are disadvantages connected with this approach, for
example the maintenance of the data consistency, large indices, etc.
My question is -- would it be possible to solve the password mapping in
the OpenLDAP software? For example, (i) to extend the structure holding
the bind request data to include an attribute name, (ii) to initialise
its value to 'userPassword', (iii) to allow slapo-rwm to rewrite/remap
it, and then (iv) to use the new value of the attribute name for the
internal user password verification.
With best regards,
Vlado
-------------------------------------------------------------------------
local.schema:
=============
attributetype ( 1.3.6.1.4.1.9999.2.1.102
NAME 'xxxUidNumber'
DESC 'An integer uniquely identifying a user in an administrative
domain (XXX private)'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.9999.2.1.105
NAME 'xxxUserPassword'
DESC 'RFC2256/2307: password of user (XXX private)'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
objectclass ( 1.3.6.1.4.1.9999.2.2.10
NAME 'xxxPosixAccount'
DESC 'Abstraction of an account with POSIX attributes (XXX private)'
SUP top AUXILIARY
MAY ( xxxUidNumber $ xxxUserPassword ) )
slapd.conf:
===========
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /etc/openldap/local.schema
pidfile /var/openldap/slapd.pid
argsfile /var/openldap/slapd.args
loglevel 256
TLSCertificateFile /etc/openldap/xxx_cert.pem
TLSCertificateKeyFile /etc/openldap/xxx_key.pem
TLSRandFile /var/run/prngd-socket
TLSCACertificateFile /etc/openldap/yyy_cacert.pem
database relay
suffix "ou=xxxUsers,ou=auth,o=example"
subordinate
overlay rwm
rwm-suffixmassage "ou=users,ou=auth,o=example"
rwm-map attribute userPassword xxxUserPassword
rwm-map attribute uidNumber xxxUidNumber
database hdb
suffix "ou=auth,o=example"
directory /var/openldap/hdb
rootdn "cn=ldap_manager,ou=auth,o=example"
rootpw {SSHA}jN4XaG5UmYFwpY/47aW0nLralRwSMA==
dbconfig set_cachesize 0 268435456 0
dbconfig set_flags DB_TXN_NOSYNC
dbconfig set_flags DB_LOG_AUTOREMOVE
dbconfig set_lk_max_locks 3000
dbconfig set_lk_max_lockers 3000
dbconfig set_lk_max_objects 3000
dbconfig set_lg_regionmax 1048576
dbconfig set_lg_max 10485760
dbconfig set_lg_bsize 2097152
dbconfig set_lg_dir /var/log/hdb
dbconfig set_tmp_dir /tmp
Real data:
==========
dn: ou=auth,o=example
objectClass: top
objectClass: organizationalUnit
ou: auth
dn: ou=users,ou=auth,o=example
objectClass: top
objectClass: organizationalUnit
ou: users
dn: cn=user10,ou=users,ou=auth,o=example
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: xxxPosixAccount
cn: user10
sn: user10
uid: user10
uidNumber: 1111
xxxUidNumber: 2222
gidNumber: 3333
homeDirectory: /tmp
loginShell: /bin/tcsh
gecos: User 10
# abc123
userPassword: {SSHA}Aif1krAxdDd7lryjjzW1hMH18WUSMA==
# xyz789
xxxUserPassword: {SSHA}BaPK4xvEKVpYwj3qK0zbOWpVOAwSMA==
