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 LdapSea
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 fo
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 openL
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. W
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 en
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?
--
sergio.
> This decodes ok as
>
> {SASL}username@realm
>
> (omit the trailing ==, before decoding)
>
> So you mean to delegate auth to a sasl realm called 'realm', containing a
> user called 'username' ?
>
> Have you literally added this example value to an ldap entry and dumped it
> with slapcat ?
>
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
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 n
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.
--
sergio.
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 0x
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.
On Wed, Aug 15, 2012 at 3:14 PM, 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 enc
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.
--
sergio.
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.
> Thi
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:
us
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
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.
--
sergio.
18 matches
Mail list logo
