Hi Richard, as always, thank you very much for your answers. You make this list very very usefull ! 2007/4/27, Richard Megginson <rmeggins at redhat.com>: > > * 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 at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > >
