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

Re: some memberUid in my database are hashed

Hi Ulrich,

* Ulrich Windl [2016-10-27 09:09:44 +0200]:


> > to be a little more clear: "getent group" does not show the base64 encoded
> > users (aka listed as "memberUid:: ..." in LDIF)
> Which command did you use?

"getent group" as I said :-)

> Here (SLES11 SP4) a "getent passwd | grep 'the
> entry you are looking for'" gives a corresponding result.

me too, but I have issues "just" with memberUid attributes in my groups, not
with usernames in general


> BTW: Decoding your "IGFyaWFubmE=" gives " arianna". A leading space in the
> user name is _very_ experimental!

OK let's assume it's _very_ experimental, anyway I just notice that:

> > on the other side, "groups <user>" correctly lists all the groups the user
> > is member of, despite the base64 encoding of its memberUid attribute

so I don't really know why "groups" correctly lists LDAP groups in which
user is listed as memberUid (base64 encoded with leading spaces), while
"getent passwd" stops processing usernames at first base64 encountered name

all I know is that standard unix file permissions and nfsv4 ACLs are working
fine with this uncommon memberUid base64 encoded attributes

for sure I'd avoid using base64 encoded memberUid attributes, but it
happened somehow (still investigating) and it seems that having leading (or
trailing?) spaces in that attribute (causing it to be base64 encoded) does
not cause any problem to libnss-ldapd (pretty stadard configured)

...so, being very lazy, I'm investigating the possibility to leave the
attributes alone and write a simple ldapsearch wrap script for my users to
list all available groups and their members

best regards

Giovanni Biscuolo
Xelera - IT infrastructures

**per favore** Quota Bene: http://wiki.news.nic.it/QuotarBene
**please** use Inline Reply: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

Attachment: signature.asc
Description: Digital signature