[Fedora-directory-users] Issues with TLS, password modify operation, and password expiration

[François Beretti]

Hi,

I am implementing password policy in my LDAP-based software. When
using Fedora DS I encountered several problems (or questions) :

1) when password expired, no request other than modifying its
userPassword attribute is allowed. Two requests would have been
usefull in my opinion :

* Start TLS : I want to enable TLS just before changing my password, but :
        - Start TLS is not allowed, since it is not the only allowed
modify request on userpassword
        - After Start TLS (when the password is not expired), it seems
that the connection become sometimes anonymous, and needs a new bind.
I thought only the Stop TLS operation must disable the authentication
on the LDAP connection

* Password Modify Extended operation : I just thought it would be a
good idea to use it to change a password, but it is not allowed

2) when changing the password using a standard ldap modify request, if
I send two modify operations in the same request, the first one to
remove the old password and the second one to add the new password, do
I need to hash the old password for it to be in the same format than
in the directory ?

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.

4) I use the Novell LDAP client API. Any call to ldap_stop_tls_s
blocks the calling thread. I don't know if it comes from the server,
the client API, or both. It is not too bad since I can just call
ldap_unbind and ldap_init instead.


François

[Rich Megginson]

François Beretti wrote:
>  Hi,
>
>  I am implementing password policy in my LDAP-based software. When
>  using Fedora DS I encountered several problems (or questions) :
>
>  1) when password expired, no request other than modifying its
>  userPassword attribute is allowed. Two requests would have been
>  usefull in my opinion :
>
>  * Start TLS : I want to enable TLS just before changing my password, 
>  but :
>         - Start TLS is not allowed, since it is not the only allowed
>  modify request on userpassword 
Can you do the StartTLS extended operation first,
before the bind 
request, then the password modify?
>         - 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 thought only the Stop TLS operation must disable the
> authentication
>  on the LDAP connection 
Do you mean authentication or transport encryption?
>  * Password Modify Extended operation : I just thought it would be a
>  good idea to use it to change a password, but it is not allowed 
Even if you do this
as the first operation, before the bind?
>  2) when changing the password using a standard ldap modify request, if
>  I send two modify operations in the same request, the first one to
>  remove the old password and the second one to add the new password, do
>  I need to hash the old password for it to be in the same format than
>  in the directory ? 
No.  You should not send pre-hashed passwords, you should let
the DS 
hash the passwords.
>  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.
>  4) I use the Novell LDAP client API. Any call to ldap_stop_tls_s
>  blocks the calling thread. I don't know if it comes from the server,
>  the client API, or both. It is not too bad since I can just call
>  ldap_unbind and ldap_init instead.
>
>
>  François
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[François Beretti]

Hi Richard,

as always, thank you very much for your answers. You make this list
very very usefull !

2007/4/27, Richard Megginson <rmeggins(a)redhat.com&gt;:
>  > * Start TLS : I want to enable TLS just before changing my
> password,
>  > but :
>  >        - Start TLS is not allowed, since it is not the only allowed
>  > modify request on userpassword
>  Can you do the StartTLS extended operation first, before the bind
>  request, then the password modify? 
Yes of course, but since I detect the password expiration in the bind,
I must close the connection then open it again then start tls then
bind then change password. Not a big issue after all, but that was
just a remark

>  >        - 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).

>  > 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

>  >
>  > * Password Modify Extended operation : I just thought it would be a
>  > good idea to use it to change a password, but it is not allowed
>  Even if you do this as the first operation, before the bind? 
in fact I did not try this, I thought you can only change your
password if you do a bind, obviously I was wrong. But anyways, I
detect the expiration when I do the bind, so its to late, the bind is
done. I did not try to close the connection, init it and call the exop

>  >
>  > 2) when changing the password using a standard ldap modify request, if
>  > I send two modify operations in the same request, the first one to
>  > remove the old password and the second one to add the new password, do
>  > I need to hash the old password for it to be in the same format than
>  > in the directory ?
>  No.  You should not send pre-hashed passwords, you should let the DS
>  hash the passwords.
>  >
>  > 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
>  >
>  > 4) I use the Novell LDAP client API. Any call to ldap_stop_tls_s
>  > blocks the calling thread. I don't know if it comes from the server,
>  > the client API, or both. It is not too bad since I can just call
>  > ldap_unbind and ldap_init instead.
>  >
>  >
>  > François
>  >
>  > --
>  > Fedora-directory-users mailing list
>  > Fedora-directory-users(a)redhat.com
>  > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>  --
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>

[Rich Megginson]

François Beretti wrote:
>  2007/4/27, Richard Megginson <rmeggins(a)redhat.com&gt;:
> > >        - 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?