(I originally posted this on openldap-software, posting it to technical, since it seems to allow this type of discussion)
Gavin Henry wrote:
If you don't have a default ppolicy defined and no pwdPolicySubentry then slapd will perform as it is currently configured.
Thanks I got it more or less working. But only ssh seems to obey it so far (I set pam_lookup_policy to yes). I would like to know if anyone had success to make other frequently used software to obey the password policy. Such as imap, MTAs, webservers, especially if used through pam.
Thank you, Jeroen
On Wednesday 25 June 2008 22:26:48 Jeroen van Aart wrote:
(I originally posted this on openldap-software, posting it to technical, since it seems to allow this type of discussion)
Gavin Henry wrote:
If you don't have a default ppolicy defined and no pwdPolicySubentry then slapd will perform as it is currently configured.
Thanks I got it more or less working. But only ssh seems to obey it so far (I set pam_lookup_policy to yes). I would like to know if anyone had success to make other frequently used software to obey the password policy. Such as imap, MTAs, webservers, especially if used through pam.
The biggest problem here is that not all software makes provision for "authentication" to respond with anything besides "yes" or "no".
I was trying to see if it would be feasible to add ppolicy support to mod_auth_ldap (for apache), or Squid's mod_auth_ldap, but what HTTP code should the authentication return (ideally one that would result in the user being sent to a page suitable for that code - e.g. to change their password) to apache? In the squid case, it looks initially like squid needs a patch support any password expiry at all (http://sarg.sourceforge.net/ncsaplus.php).
It doesn't look as if Courier's authdaemon supports password expiry at all yet.
I have also started discussions with some web application frameworks (e.g. Catalyst).
Maybe it would be worthwhile making a list of which applications could really do with password expiry support, and filing bugs on them for the missing pieces?
At present, I have password expiry working with login, sudo, ssh (on servers with password authentication enabled), and I need Catalyst and apache myself.
Now, if I could just change my passwords when prompted (ITS 5569) ...
Buchan Milne wrote:
The biggest problem here is that not all software makes provision for "authentication" to respond with anything besides "yes" or "no".
Yupp.
I was trying to see if it would be feasible to add ppolicy support to mod_auth_ldap (for apache), or Squid's mod_auth_ldap, but what HTTP code should the authentication return (ideally one that would result in the user being sent to a page suitable for that code - e.g. to change their password) to apache? In the squid case, it looks initially like squid needs a patch support any password expiry at all (http://sarg.sourceforge.net/ncsaplus.php).
Bear in mind that in a single password environmemt proxy authentication (like with Squid) is somewhat a security risk anyway since the password is transferred in clear over the wire to the proxy for each HTTP hit going through the proxy.
I have also started discussions with some web application frameworks (e.g. Catalyst).
I'd rather recommend to use a decent WebSSO system and integrate web servers/applications with that central authentication component because when using centralized passwords you don't want to transmit the password to every integrated system. Rather in a SSO system system see only short-time tickets. I'm successfully using CAS for that in one customer project. It works pretty well and the developers are very responsive.
Maybe it would be worthwhile making a list of which applications could really do with password expiry support, and filing bugs on them for the missing pieces?
Not worth the effort for web access. Rather integrate with a WebSSO solution and handle the password policy stuff in a central place.
Ciao, Michael.
On Thursday 26 June 2008 12:32:04 Michael Ströder wrote:
Buchan Milne wrote:
The biggest problem here is that not all software makes provision for "authentication" to respond with anything besides "yes" or "no".
Yupp.
I was trying to see if it would be feasible to add ppolicy support to mod_auth_ldap (for apache), or Squid's mod_auth_ldap, but what HTTP code should the authentication return (ideally one that would result in the user being sent to a page suitable for that code - e.g. to change their password) to apache? In the squid case, it looks initially like squid needs a patch support any password expiry at all (http://sarg.sourceforge.net/ncsaplus.php).
Bear in mind that in a single password environmemt proxy authentication (like with Squid) is somewhat a security risk anyway since the password is transferred in clear over the wire to the proxy for each HTTP hit going through the proxy.
Unfortunately, however, it does not seem that there is any secure proxy authentication scheme for an entirely Unix environment (Mozilla on Unix as the client, Squid on Unix as the proxy server), even with Kerberos infrastructure in place.
I have also started discussions with some web application frameworks (e.g. Catalyst).
I'd rather recommend to use a decent WebSSO system and integrate web servers/applications with that central authentication component because when using centralized passwords you don't want to transmit the password to every integrated system. Rather in a SSO system system see only short-time tickets. I'm successfully using CAS for that in one customer project. It works pretty well and the developers are very responsive.
Indeed, but if you have existing applications on an existing framework that has LDAP support (we use SSL end-to-end), then it should have support for expiring passwords. Migrating to an SSO system would be an option, but I have many more features which have higher priority ... In this specific case, there are also advantages to the application having access to the clear-text password (as it can then be used with the logged-in users credentials to perform operations on other devices which authenticate against the same system, but have no SSO support).
Maybe it would be worthwhile making a list of which applications could really do with password expiry support, and filing bugs on them for the missing pieces?
Not worth the effort for web access. Rather integrate with a WebSSO solution and handle the password policy stuff in a central place.
Yes and no. Either people should stop shipping web server authentication modules for LDAP, or they should have password policy support. Not having password policy support because you should use a different system is irrelevant IMHO.
Regards, Buchan
Buchan Milne wrote:
On Thursday 26 June 2008 12:32:04 Michael Ströder wrote:
Bear in mind that in a single password environmemt proxy authentication (like with Squid) is somewhat a security risk anyway since the password is transferred in clear over the wire to the proxy for each HTTP hit going through the proxy.
Unfortunately, however, it does not seem that there is any secure proxy authentication scheme for an entirely Unix environment (Mozilla on Unix as the client, Squid on Unix as the proxy server), even with Kerberos infrastructure in place.
Hmm, Mozilla has NTLM support. I'm using it with SPNEGO/Kerberos (together with CAS). Not sure whether that would work with Proxy-Authorize either.
I have also started discussions with some web application frameworks (e.g. Catalyst).
I'd rather recommend to use a decent WebSSO system and integrate web servers/applications with that central authentication component because when using centralized passwords you don't want to transmit the password to every integrated system. Rather in a SSO system system see only short-time tickets. I'm successfully using CAS for that in one customer project. It works pretty well and the developers are very responsive.
Indeed, but if you have existing applications on an existing framework that has LDAP support (we use SSL end-to-end), then it should have support for expiring passwords.
But it may be less overall work to add support for expiring passwords to one central authc instance and integrate systems with that. Because you always have to redirect the user to a password change form. Implementing this interaction is the problem for most systems. Look at Apache's mod_auth_ldap which does not provide a interactive UI at all. It simply cannot provide the user interaction needed.
Migrating to an SSO system would be an option, but I have many more features which have higher priority ...
Your mileage may vary...
In this specific case, there are also advantages to the application having access to the clear-text password (as it can then be used with the logged-in users credentials to perform operations on other devices which authenticate against the same system, but have no SSO support).
Yes, web2ldap is working like that.
Either people should stop shipping web server authentication modules for LDAP, or they should have password policy support.
Let's look at a very simply case: How should a web server which implements HTTP basic authc implement the user interaction needed? It simply relies on the browser popping up the login window, nothing else. What you could do is redirect the user to an error page implemented as CGI-BIN which makes further checks. You can do that yourself.
Ciao, Michael.
On Thursday 26 June 2008 13:52:05 Michael Ströder wrote:
Let's look at a very simply case: How should a web server which implements HTTP basic authc implement the user interaction needed? It simply relies on the browser popping up the login window, nothing else. What you could do is redirect the user to an error page implemented as CGI-BIN which makes further checks. You can do that yourself.
But, ideally I would like to send the user to the right page (not a generic "authorization failed"), in which case I need a different error code to send them to a suitable error page (which might have a form for them to change their password etc.).
Regards, Buchan
Buchan Milne wrote:
On Thursday 26 June 2008 13:52:05 Michael Ströder wrote:
Let's look at a very simply case: How should a web server which implements HTTP basic authc implement the user interaction needed? It simply relies on the browser popping up the login window, nothing else. What you could do is redirect the user to an error page implemented as CGI-BIN which makes further checks. You can do that yourself.
But, ideally I would like to send the user to the right page (not a generic "authorization failed"), in which case I need a different error code to send them to a suitable error page (which might have a form for them to change their password etc.).
You could redirect them always to the not-autorized-URL and the CGI-BIN handler behind that retrys the LDAP bind together with ppolicy control reacting according to the ppolicy control values in the bind response.
Just a rough idea though...not sure how to reliably pass the username/password to the not-autorized-URL. Let's think about it...
Ciao, Michael.
On Thursday 26 June 2008 17:39:27 Michael Ströder wrote:
Buchan Milne wrote:
On Thursday 26 June 2008 13:52:05 Michael Ströder wrote:
Let's look at a very simply case: How should a web server which implements HTTP basic authc implement the user interaction needed? It simply relies on the browser popping up the login window, nothing else. What you could do is redirect the user to an error page implemented as CGI-BIN which makes further checks. You can do that yourself.
But, ideally I would like to send the user to the right page (not a generic "authorization failed"), in which case I need a different error code to send them to a suitable error page (which might have a form for them to change their password etc.).
You could redirect them always to the not-autorized-URL and the CGI-BIN handler behind that retrys the LDAP bind together with ppolicy control reacting according to the ppolicy control values in the bind response.
That is what I will implement for now, but if the user's password has already expired, you use an additional grace login. If your site's policy is to allow 3 grace logins, most likely the page should then also provide the user with a means to have their password reset ...
Just a rough idea though...not sure how to reliably pass the username/password to the not-autorized-URL. Let's think about it...
I would pass only the username through to a form telling the user that authentication failed, notifying them that they can test the password and if necessary be prompted to change it, if they enter the password again.
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Jeroen van Aart -
Michael Ströder