[Freeipa-users] Library to change expired password

[Rob Crittenden]

Jason Gerard DeRose wrote:
> On Thu, 2009-10-29 at 17:56 -0400, Dan Scott wrote:
>> Hi,
>>
>> I'm trying to integrate FreeIPA with a Java webapp using JAAS. I have
>> the login module configured properly and it is working fine.
>>
>> However, I have a problem with the initial user setup. New accounts
>> are created with expired passwords for good reason. However, I would
>> like a way to for a user to change their expired kerberos password
>> which does not use the command line. e.g. an SSL web form.
>>
>> On searching the web, there does not appear to be a (free) java
>> library which implements the same functionality as ipa-passwd, kinit
>> or ssh for changing expired passwords. Does anyone know if such a
>> thing exists? The IPA documentation indicates that ssh has an option
>> 'challenge-response' for changing expired passwords. I would like the
>> same functionality on a web page.
> 
> Yes, you raise a good point and we obviously need a way to do this via
> the web UI.
> 
> Rob, if a user's password is expired, how does the password change work?
> Does the user still do a Kerberos auth with the old password, or do we
> need a non-Kerberos protected web page through which to update the
> password?
> 
> Either way, this will be a simple thing to add to the UI.

As Sumit said, the self-service page currently requires kerberos so 
you'd have to get a TGT first which means you need a valid password.

This may not be too difficult to do in a web form (SSL protected, of 
course). You should be able to create a non-kerberos auth page that 
prompts for username, old and new password and a submit button. You 
could pass this onto a a simple backend that does an LDAP bind as the 
user with the old password then use ldap_passwd() to set the new password.

>> Assuming that this is true (which I find very hard to believe), then I
>> can think of 3 possible solutions:
>>
>> 1. Attempt to execute the system commands from within Java (Yuck -
>> quite apart from the difficulties of escaping the arguments, the
>> password will be displayed in the system process list while the
>> command is being executed).
>> 2. Use XMLRPC. Although this introduces another whole layer into the
>> system, this might be the best way to go.
>> 3. Update the users password expiry in the LDAP directory to (say) 1
>> day in the future so that they can login.
>>
>> I am currently looking at the XMLRPC route. However, no matter what
>> request I send to the server, I receive 'XmlRpcException:HTTP server
>> returned unexpected status: Authorization Required'. Do I need to
>> store the details of the failed login so that I can authorize my RPC?
> 
> Ah, you've raised an important question that we currently don't have
> documented, AFAIK.  Your XML-RPC client will have to set the
> 'Authorization' header for the Kerberos negotiation.  But as some
> clients might not allow you to set the HTTP headers, we obviously need
> other mechanisms, including using just a username/password.

One can set KrbMethodK5Passwd to on in /etc/httpd/conf.d/ipa.conf to 
allow it to fall back to username/password authentication. Still 
requires a non-expired password though.

>> Is there any documentation on the FreeIPA XMLRPC which I can read? I
>> have the API, but no more. I had to dig into the apache configuration
>> to find the domain path context (/xml/ipa).

Yes, just the API is documented, there aren't any programming examples 
other than the code itself AFAIK.

One thing you can do is add the -v option to the ipa command-line tools 
to see the XML-RPC request/response. That might help.

> Right now the documentation is scarce, but we're currently working on
> solidifying and formalizing the XML-RPC API and plan to document it in
> detail once this is done.

Yeah, we'll have to see if we can get some sample requests into the v2 
API docs.

> 
> Thanks for your interest in FreeIPA and we appreciate your feedback!
> 
>> Thanks,
>>
>> Dan Scott
>> http://danieljamesscott.org

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20091030/94c6078a/attachment.bin>