10:07 a.m.
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/
6:07 a.m.
Am Tue, 25 Oct 2016 19:07:55 +0200
schrieb Giovanni Biscuolo <g(a)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
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
7:03 a.m.
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/
5:32 a.m.
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.)
--
Sincerely,
Johannes Löthberg
PGP Key ID: 0x50FB9B273A9D0BB5
https://theos.kyriasis.com/~kyrias/
7:06 a.m.
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.
3:20 a.m.
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**
--
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
2416
days inactive
2419
days old
openldap-technical@openldap.org
5 comments
4 participants
participants (4)
-
Dieter Klünter -
Giovanni Biscuolo -
Johannes Löthberg -
Michael Ströder