On Sat, May 05, 2012 at 07:06:27AM -0400, Nico Kadel-Garcia wrote:
> Well, yes. There are SSL key based authentication methods, for example. And
> in theory, Kerberos can work out. Unfortunately, few small sites set up
> Kerberos, and even sites that do don't mandate the use of the keys. Let's
> actually look at the RHEL 6 mod_auth_kerb settings, shall we?
>
>
> #<Location /private>
> # SSLRequireSSL
> # AuthType Kerberos
> # AuthName "Kerberos Login"
> # KrbMethodNegotiate On
> # KrbMethodK5Passwd Off
> # KrbAuthRealms EXAMPLE.COM
> # Krb5KeyTab /etc/httpd/conf/keytab
> # require valid-user
> #</Location>
> Not active by default nor configuerd for Subversion, that's OK.
>
> KrbMedhodK5Passwd Off:, that prevents the use of pure password negotiaton
> and forces clients to use Kerberos tickets. Except...... if you have RHEL 4
> systems, or Subversion clients from older but still active systems, you're
> screwed and must use password negotiation. That means password storage on
> the client, of your *Kerberos passwords!!!!!*
The root of this problem clearly is people using severely outdated
software. If they do this, then they must live with the feature set
that was available at the time the now outdated software was current.
> Note the unlisted default setting "KrbAuthoritative On". That one, set to
> off, allows authentication to be passwd to other modules.
Yes, you can chain them. What's your point? That people would
inadvertantly keep entering a wrong password if the server is set
up incorrectly?
> Also note: if the user is not in Kerberos, this becomes unusuable. Many
> system accounts, such as "named" and "root", would benefit from centralized
> source control access to a read-only repository. (I'm preseint about just
> such a setup for BIND in June.) Setting up Kerberos authentication for
> system rather than user accounts becomes.... an adventure that could
> require a lot of thought, especially for unattended operations.
That is correct. Single-sign on is not very easy in the non-interactive
case because, well, somebody has to sign on :)
Setting up authenticated non-interactive access is always a bit tricky.
> So it's potentially *better* to use Kerberos, but it does present
> configuration issues. It's certainly not plug and play, and it's very easy
> for people to wind up storing their passwords in the clear again, only this
> time tied to their Kerberos passwords.
I agree. However, your argument amounts to something like "if you create
a subversion repository, never make backups, and then some day rm -rf
the repository... you will lose all your data and cry". Well, yes, of course.
If people don't use the system as intended, and as appropriate for their
use cases, then what can the developers do to help them?
Received on 2012-05-05 13:16:39 CEST