Re: some memberUid in my database are hashed
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 " 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** -- Giovanni Biscuolo Xelera - IT infrastructures http://xelera.eu/contact-us/ **per favore** Quota Bene: http://wiki.news.nic.it/QuotarBene **please** use Inline Reply: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style signature.asc Description: Digital signature
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 " 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 -- Giovanni Biscuolo Xelera - IT infrastructures http://xelera.eu/contact-us/ **per favore** Quota Bene: http://wiki.news.nic.it/QuotarBene **please** use Inline Reply: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style signature.asc Description: Digital signature
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 " 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/ signature.asc Description: Digital signature
some memberUid in my database are hashed
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 -- Giovanni Biscuolo Xelera - IT infrastructures http://xelera.eu/contact-us/ signature.asc Description: Digital signature
