Am Tue, 25 Oct 2016 19:07:55 +0200 schrieb Giovanni Biscuolo <g@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
Attachment:
pgpIk5bpM2N0i.pgp
Description: Digitale Signatur von OpenPGP