On Apr 2, 2014, at 11:14 PM, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Josh Miller joshua@itsecureadmin.com schrieb am 02.04.2014 um 17:58 in
Nachricht 1EF35D11-9A5F-4161-822A-AAA84F5A2459@itsecureadmin.com:
On Apr 2, 2014, at 3:57 AM, Monica Warnock monica.warnock@ed.ac.uk wrote:
…
dn: dc=name,dc=name objectClass: dcObject objectClass: organization dc:: ZGxpYi1tb25pZHAg o:: ZGxpYi1tb25pZHAg
dn: ou=Users,dc=name,dc=name objectClass: organizationalUnit ou: Users
dn: cn=Bob Jones,ou=Users,dc=name,dc=name cn: Bob Jones sn: Jones objectClass: inetOrgPerson objectClass: eduPerson eduPersonAffiliation: staff userPassword:: cGFzc3dvcmQg uid: bjones
When I log in as bjones using the correct password the 'username or
password
is not valid'.
What is the relevance of the entries such as the userPassword:: which now
appear with two colons?
I have added more test users and on their entry the uid entry also has the
double colons with a hashed entry following. ...
If you modify or create an entry with any trailing spaces the results will be returned base64 encoded (values are stored correctly, but returned this way).
You can decode with something like the following, which shows that you have
a trailing space on your “dc” attribute:
echo -n "ZGxpYi1tb25pZHAg" | base64 -D
dlib-monidp
I have seen that in many cases if your base64 encoded attributes do not end
with a “==" that you have trailing spaces:
I think whether you see "==" at the end or not is independent of trailing spaces, but it depends on how long the input string is. (From RFC 4648):
- Test Vectors
BASE64("") = "" BASE64("f") = "Zg==" BASE64("fo") = "Zm8=“
Ah, thank you, Ulrich, you are most correct. The “=“ character is a pad in base64 encoding.
I had the mis-fortune of executing a test that supported my theory while responding but have since read the RFC you referenced and appreciate the correction.
Thanks, Josh