Hi,
I've an openldap database I use for auth purposes in which some memberUid is hashed while other not, e.g.:
(results given by sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ou=Groups,dc=unit,dc=company,dc=net) .......................... dn: cn=GROUP,ou=Groups,dc=unit,dc=company,dc=net objectClass: top objectClass: posixGroup cn: GROUP gidNumber: 1026 memberUid: firstuser memberUid:: IGFyaWFubmE= [...] ...........................
I cannot find any documentation about this kind of "memberUid hashed storage", the only differece is the double colon after memberUid
please can you point me to the documentation or tell me how to "decode" the memberUid information
also, on a client machine configured to use libnss-ldapd, if I list the groups with "sudo getent group" I can see the "clear text" members (e.g. firstuser in the example above) but not the "hashed" one; the same using the "members" command
ciao Giovanni
Am Tue, 25 Oct 2016 19:07:55 +0200 schrieb Giovanni Biscuolo g@xelera.eu:
Hi,
I've an openldap database I use for auth purposes in which some memberUid is hashed while other not, e.g.:
(results given by sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ou=Groups,dc=unit,dc=company,dc=net) .......................... dn: cn=GROUP,ou=Groups,dc=unit,dc=company,dc=net objectClass: top objectClass: posixGroup cn: GROUP gidNumber: 1026 memberUid: firstuser memberUid:: IGFyaWFubmE= [...] ...........................
I cannot find any documentation about this kind of "memberUid hashed storage", the only differece is the double colon after memberUid
please can you point me to the documentation or tell me how to "decode" the memberUid information
also, on a client machine configured to use libnss-ldapd, if I list the groups with "sudo getent group" I can see the "clear text" members (e.g. firstuser in the example above) but not the "hashed" one; the same using the "members" command
The relevant documentation is RFC-2849. Note that the output of a search result is LDIF. The attribute value in question is not hashed but base64 encoded, as the second colon indicates. The reason for base64 encoding is either non-ascii characters or a trailing space.
-Dieter
Dear Dieter thank you so much!
* Dieter Klünter [2016-10-26 15:07:13 +0200]:
[...]
memberUid:: IGFyaWFubmE=
[...]
also, on a client machine configured to use libnss-ldapd, if I list the groups with "sudo getent group" I can see the "clear text" members (e.g. firstuser in the example above) but not the "hashed" one; the same using the "members" command
to be a little more clear: "getent group" does not show the base64 encoded users (aka listed as "memberUid:: ..." in LDIF)
on the other side, "groups <user>" correctly lists all the groups the user is member of, despite the base64 encoding of its memberUid attribute
this way - fortunately - all the permissions and ACLs on the client machines are working fine, but superusers cannot get a list of group members with canonical tools like getent
I have to find a solution to list groups and members... I'm lazy and I'd like to avoid to manually fix all the attributes
The relevant documentation is RFC-2849.
great! I was just using the wrong search keywords: the double colon meaning is well documented there
Note that the output of a search result is LDIF. The attribute value in question is not hashed but base64 encoded, as the second colon indicates. The reason for base64 encoding is either non-ascii characters or a trailing space.
leading space in my case (what's the tool doing this?!?!.... mumble...)
kudos! ciao Giovanni
On 26/10, Giovanni Biscuolo wrote:
Dear Dieter thank you so much!
- Dieter Klünter [2016-10-26 15:07:13 +0200]:
[...]
memberUid:: IGFyaWFubmE=
[...]
also, on a client machine configured to use libnss-ldapd, if I list the groups with "sudo getent group" I can see the "clear text" members (e.g. firstuser in the example above) but not the "hashed" one; the same using the "members" command
to be a little more clear: "getent group" does not show the base64 encoded users (aka listed as "memberUid:: ..." in LDIF)
on the other side, "groups <user>" correctly lists all the groups the user is member of, despite the base64 encoding of its memberUid attribute
this way - fortunately - all the permissions and ACLs on the client machines are working fine, but superusers cannot get a list of group members with canonical tools like getent
I have to find a solution to list groups and members... I'm lazy and I'd like to avoid to manually fix all the attributes
That sounds more like it's just not enumerating the users properly. First of all, which version of nss_ldap are you using, and could you post your config? There's for example a bug in 265 where there are missing entries when `nss_connect_policy` is set to `oneshot`, but some distros have patched it.
(Though I'd also recommend switching to nss-pam-ldapd instead, which is actually maintained.)
Johannes Löthberg wrote:
On 26/10, Giovanni Biscuolo wrote:
Dear Dieter thank you so much!
- Dieter Klünter [2016-10-26 15:07:13 +0200]:
[...]
memberUid:: IGFyaWFubmE=
[...]
also, on a client machine configured to use libnss-ldapd, if I list the groups with "sudo getent group" I can see the "clear text" members (e.g. firstuser in the example above) but not the "hashed" one; the same using the "members" command
to be a little more clear: "getent group" does not show the base64 encoded users (aka listed as "memberUid:: ..." in LDIF)
That sounds more like it's just not enumerating the users properly.
Python 2.7.12 (default, Jun 28 2016, 06:57:42) [GCC] on linux2 Type "help", "copyright", "credits" or "license" for more information.
'IGFyaWFubmE='.decode('base64')
' arianna'
IGFyaWFubmE= is simply ' arianna' with space as first character (hence the base64-encoding of the attribute value in the LDIF output). No wonder why the group membership of user arianna is not correct. It must match exactly. Computers are like that.
=> fix the attribute value
Ciao, Michael.
Dear all,
now I've understood the meaning of "memberUid::" attributes: stupid me I was not able to sort this out by myself and contributed generating more noise on this list
**thank you very much** to the ones that helped me understand this
now that all things are clear, **please consider this solved** :-)
I'm not going to reply to any further message in this thread unless they bring something new or interesting on the topic
for those who are interested in details about the last messages I read in this thread, below are my *last* comments
ciao Giovanni
* Johannes Löthberg [2016-10-27 14:32:05 +0200]:
On 26/10, Giovanni Biscuolo wrote:
[...]
to be a little more clear: "getent group" does not show the base64 encoded users (aka listed as "memberUid:: ..." in LDIF)
on the other side, "groups <user>" correctly lists all the groups the user is member of, despite the base64 encoding of its memberUid attribute
[...]
First of all, which version of nss_ldap are you using,
the one from libnss-ldapd ver. 0.8.13-3ubuntu1
and could you post your config?
no thanks, it would not add useful infos (beleave me, it's pretty default)
(Though I'd also recommend switching to nss-pam-ldapd instead, which is actually maintained.)
I agree :-)
* Michael Ströder [2016-10-27 16:06:04 +0200]:
[...]
IGFyaWFubmE= is simply ' arianna' with space as first character (hence the base64-encoding of the attribute value in the LDIF output).
OK thank you, now it's pretty clear that it's a base64 encoded memberUid value, it's encoded because the user name has one ledaing space [1]
No wonder why the group membership of user arianna is not correct. It must match exactly. Computers are like that.
beleave me or not: "groups arianna" returns me a complete list of groups for arianna, included the ones in which arianna is enumerated as a base64 memberUid attribute value (with one leading space)
same story for unix permissions and nfsv4 ACLs (and CIFS via SAMBA via nfsv4 too)
=> fix the attribute value
no thanks: they are too much **and** group membership (so permissions too) are working fine in my infrastructure
I've also managed to write a simple ldapsearch wrapper script to list the members of specific (or all) groups
ciao a tutti Giovanni
[1] still not cleat to me what tool (sure it was not manually done) did that, but this is OT **for sure**
openldap-technical@openldap.org
-
Dieter Klünter -
Giovanni Biscuolo -
Johannes Löthberg -
Michael Ströder