[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: some memberUid in my database are hashed

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...)


Giovanni Biscuolo

Xelera - IT infrastructures

Attachment: signature.asc
Description: Digital signature