1:26 p.m.
(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
1:28 a.m.
New subject: ppolicy by group
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) ...
3:32 a.m.
New subject: ppolicy by group
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.
3:49 a.m.
New subject: ppolicy by group
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
4:52 a.m.
New subject: ppolicy by group
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.
7:22 a.m.
New subject: ppolicy by group
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
8:39 a.m.
New subject: ppolicy by group
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.
9:18 a.m.
New subject: ppolicy by group
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
5572
days inactive
5573
days old
openldap-technical@openldap.org
7 comments
3 participants
participants (3)
-
Buchan Milne -
Jeroen van Aart -
Michael Ströder