Hello.
Is it possible to ask openldap not to encode magic tokens for pass-through authentication? Now ldapsearch shows: userPassword:: e1NBU0x9dXNlcm5hbWVAcmVhbG0K== but I'd like to see: userPassword:: {SASL}username@realm instead.
On 08/13/12 15:26 +0400, sergio wrote:
Hello.
Is it possible to ask openldap not to encode magic tokens for pass-through authentication? Now ldapsearch shows: userPassword:: e1NBU0x9dXNlcm5hbWVAcmVhbG0K==
Notice the double colons.
but I'd like to see: userPassword:: {SASL}username@realm
Which would not exist here.
instead.
Your value contains a newline character, which is why it is being returned encoded.
On 08/15/2012 12:03 AM, Dan White wrote:
userPassword:: e1NBU0x9dXNlcm5hbWVAcmVhbG0K==
Notice the double colons.
Yes, it shows that the value is base64 encoded.
but I'd like to see: userPassword:: {SASL}username@realm
Which would not exist here.
This is my mistake of course, I mean: userPassword: {SASL}username@realm
Your value contains a newline character, which is why it is being returned encoded.
Unfortunately you are wrong. This is my bad example. Real values in the database have no newline or some other non-ASCII non printable characters.
sergio wrote:
On 08/15/2012 12:03 AM, Dan White wrote:
userPassword:: e1NBU0x9dXNlcm5hbWVAcmVhbG0K==
Notice the double colons.
Yes, it shows that the value is base64 encoded.
but I'd like to see: userPassword:: {SASL}username@realm
Which would not exist here.
This is my mistake of course, I mean: userPassword: {SASL}username@realm
Your value contains a newline character, which is why it is being returned encoded.
Unfortunately you are wrong. This is my bad example. Real values in the database have no newline or some other non-ASCII non printable characters.
I repeat what I always write in such a case: If you want to process LDIF then be prepared to process any LDIF data compliant to RFC 2849. Period.
Best approach is to use a decent LDIF module for your favourite scripting language.
Ciao, Michael.
On Wed, Aug 15, 2012 at 3:14 PM, sergio mailbox@sergio.spb.ru wrote:
On 08/15/2012 11:08 AM, Michael Ströder wrote:
If you want to process LDIF then be prepared to process any LDIF data
compliant to RFC 2849. Period.
RFC 2849 doesn't say any special about userPassword and why it should be base64 encoded.
From notes on ldif syntax :
4) Any dn or rdn that contains characters other than those defined as "SAFE-UTF8-CHAR", or begins with a character other than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. *Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded.*
8) *Values or distinguished names that end with SPACE SHOULD be base-64 encoded.*
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F ; any value <= 127 decimal except NUL, LF, ; and CR
If you are sure there is nothing but SAFE-CHAR, check for space or and non-ascii charset.
Sometimes there are invisible characters in eg. latin1 that will "hide" in a charset capable editor.
(characters other than US-ASCII would be encoded also - view data with a dumber text editor)
Cheers Brett
On 08/15/2012 02:00 PM, Brett @Google wrote:
If you are sure there is nothing but SAFE-CHAR, check for space or and non-ascii charset.
I'm absolutely sure. If I put same value to the title attribute I see it plaintext. And I'm absolutely sure that there are no any hidden or invalid characters.
As I see the answer is that userPassword is an octet string and it's not possible to change (without slapd recompile) as it's defined in system schema. Am I right?
Le 8/15/12 1:56 PM, sergio a écrit :
On 08/15/2012 02:00 PM, Brett @Google wrote:
If you are sure there is nothing but SAFE-CHAR, check for space or and non-ascii charset.
I'm absolutely sure.
Really ???
e1NBU0x9dXNlcm5hbWVAcmVhbG0K==
decoded gives :
0x7B 0x53 0x41 0x53 0x4C 0x7D 0x75 0x73 0x65 0x72 0x6E 0x61 0x6D 0x65 0x40 0x72 0x65 0x61 0x6C 0x6D 0x0A
To me, the last char is a plain Line Feed character, something that is not in the SAFE_CHAR collection :
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F ; any value <= 127 decimal except NUL, LF, ; and CR
And you are wondering why it's get Base64 encoded ?
Le 8/15/12 5:22 PM, sergio a écrit :
On 08/15/2012 06:12 PM, Emmanuel Lécharny wrote:
e1NBU0x9dXNlcm5hbWVAcmVhbG0K==
ONCE AGAIN:
This is my bad example. Real values in the database have no newline or some other non-ASCII non printable characters.
It even can't be correctly decoded.
Then can you provide an example of base64 encoded value that we can evaluate ?
Le 8/16/12 7:49 AM, sergio a écrit :
On 08/15/2012 10:27 PM, Emmanuel Lécharny wrote:
Then can you provide an example of base64 encoded value that we can evaluate ?
May be you can provide an example which will show plain text password?
What are you talking about ?
You have asked that openLDAP not to encode the UserPassword value, when OpenLDAP does *not* encode anything. The value is *always* store in binary format. This is the LdapSearch utility which encodes in base64 this attribute, which is supposed not to be a String, but a byte array :
attributetype ( 2.5.4.35 NAME 'userPassword' DESC 'RFC2256/2307: password of user' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 // Which is OctetString... )
This is what to expect from a decent tool, like LdapSearch. Would it make any sense that the tool tries to expose any OctetString value as a String, and fallback to a base64 encoding if the valeu does not contain some SAFE_CHARS ?
Now, if you want to get the String value out of a base64 encoded OctetString AttributeType, you have to write your own tooling...
On 08/16/2012 11:33 AM, Emmanuel Lécharny wrote:
You have asked that openLDAP not to encode the UserPassword value, when OpenLDAP does *not* encode anything.
Sorry, I should write slapcat or ldapsearch in the original letter.
The value is *always* store in binary format. This is the LdapSearch utility which encodes in base64 this attribute, which is supposed not to be a String, but a byte array
So, userPassword described in system schema and it can't be changed. And so ldapseach and slapcat print it in base-64 and it's also hardcoded.
Now, if you want to get the String value out of a base64 encoded OctetString AttributeType, you have to write your own tooling...
Ask the question differently.
ldap needs some links for external auth. And as they are text string I'd like to see them as text. Moreover I'd like to specify a template, for example I want to authenticate all inetOrgPerson-s as uid@MYREALM.
On 08/15/2012 03:14 AM, sergio wrote:
On 08/15/2012 11:08 AM, Michael Ströder wrote:
If you want to process LDIF then be prepared to process any LDIF data compliant to RFC 2849. Period.
RFC 2849 doesn't say any special about userPassword and why it should be base64 encoded.
I'm not a programmer by any stretch of the imagination but it appears to me that the LDIF generator is hard-coded to always base64-encode the userPassword value.
Digging through the OpenLDAP gitweb, I found these lines in libraries/libldap/ldif.c:
365 * name and OID of attributeTypes that must be base64 encoded in any case 366 */ 367 typedef struct must_b64_encode_s { 368 struct berval name; 369 struct berval oid; 370 } must_b64_encode_s; 371 372 static must_b64_encode_s default_must_b64_encode[] = { 373 { BER_BVC( "userPassword" ), BER_BVC( "2.5.4.35" ) }, 374 { BER_BVNULL, BER_BVNULL } 375 };
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/l...
I don't see any justification in the file for doing so, but the RFC says any value MAY be encoded. I think Michael's advice is very prudent.
/* Wes Hardin */
Hello, Wes.
I'm not a programmer by any stretch of the imagination but it appears to me that the LDIF generator is hard-coded to always base64-encode the userPassword value.
Yes, looks you're right.
I don't see any justification in the file for doing so, but the RFC says any value MAY be encoded. I think Michael's advice is very prudent.
MAY be encoded, yes. This means that ldapsearch or slapcat can output all values base-64 encoded. But it's very inconvenient. When userPassword is a link to another authenticator base-64 encoding is also inconvenient.
sergio wrote:
I don't see any justification in the file for doing so, but the RFC says any value MAY be encoded. I think Michael's advice is very prudent.
MAY be encoded, yes. This means that ldapsearch or slapcat can output all values base-64 encoded. But it's very inconvenient. When userPassword is a link to another authenticator base-64 encoding is also inconvenient.
*Ignorance* is inconvenient. What does any of this have to do with pass-through authentication? When slapd handles an authentication it uses the binary value. base64 has nothing to do with it.
On 08/16/2012 11:07 AM, Howard Chu wrote:
*Ignorance* is inconvenient. What does any of this have to do with pass-through authentication? When slapd handles an authentication it uses the binary value. base64 has nothing to do with it.
Under "pass-through authentication" I mean "magic tokens for pass-through authenticatio", not "pass-through authentication" itself.
openldap-technical@openldap.org
-
Brett ＠Google -
Dan White -
Emmanuel Lécharny -
Howard Chu -
Michael Ströder -
sergio -
Wes Hardin