On 3/6/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
... So basically this handles the client side generation of the digest which is sent to the server rather than the password itself, then the server compares this digest with the digest generated from the userPassword field?
No, typically a password is combined with some information shared by the client and server, to prove both sides know the same password, avoiding the need for the password to traverse the network. There are 2-3 request-response pairs here, negotiating session setup and responding to challenges from the server.
Stefan Zoerner last year hooked up a way to use digested passwords in the ... If not you can just throw an exception since you cannot generate a digest because the userPassword is not in available to do so. I may be totally off here since I'm twice removed from this code and I may have some misconceptions about how these mechanisms actually work but I just thought I'd mention it here for the record.
This is the case. In other LDAP servers you have to explicitly configure the server to store the password plaintext.
You can actually extend AbstractServerTestCase or something like that in server-unit.
Cool, I'll migrate to that. So, based on feedback from you and Emmanuel, I will: 1) Branch the trunk to add SASL. 2) Assign Alex a subtask to add supportedSASLMechanisms in the branch. 3) Start a page in Confluence. Enrique
