François Beretti wrote:
2007/4/27, Richard Megginson <rmeggins(a)redhat.com>:
> > - After Start TLS (when the password is not expired), it seems
> > that the connection become sometimes anonymous, and needs a new bind.
> I'm not sure what you mean. Can you elaborate on this?
I mean that I believe (I have not tried to reproduce it) that when I
do a start tls operation, I get anonymous, even if I had done a bind
request just before. So in my code, just after a start tls, I always
do a bind (even if I had already done it before start tls).
Please verify this.
startTLS should not change the authentication state
(unless you are also doing client cert based auth with the startTLS
request via SASL/EXTERNAL).
> > I thought only the Stop TLS operation must disable the authentication
> > on the LDAP connection
> Do you mean authentication or transport encryption?
I mean that when you call stop tls, you become anonymous
Yes. This is by design -
see
http://www.rfc-editor.org/rfc/rfc2830.txt
section 5.2:
5.2. TLS Connection Closure Effects
Closure of the TLS connection MUST cause the LDAP association to move
to an anonymous authentication and authorization state regardless of
the state established over TLS and regardless of the authentication
and authorization state prior to TLS connection establishment.
<snip>
>
> > 3) when using the Password Modify Extended operation, then at the next
> > logon the server requires the user to change its password ! So I
> > definitly can't use this operation on a server implementing password
> > policy. I believe that in the Fedora DS password policy code this
> > operation is only seen as an administration request, not intended to
> > be done by a user : it is handled as a "force password" request, not
a
> > "change password" request.
> Hmm - that could be a bug in that we perhaps do not reset the password
> expiration time. It's supposed to - it goes through the same code as
> regular password modify.
I am really not sure of this
Can you verify this?