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 -- Giovanni Biscuolo Xelera - IT infrastructures http://xelera.eu/contact-us/
Attachment:
signature.asc
Description: Digital signature