There are at least four choices: mod_auth_ldap, mod_ntlm, mod_auth_kerb,
LDAP seemed the easiest to set up. However, it requires either allowing
anonymous access to AD or putting a user name and password in plain text
into httpd.conf that is authorized to access AD.
NTLM really only makes sense if you're on an NT4 domain, but I learned
of its existence before mod_auth_kerb's, so I've tried it. I'm running
on a FreeBSD box and at the time, the only version available via the
ports was for Apache1, so I had to compile/install "manually". It also
doesn't handle authentication of groups very well. Basically, groups are
handled in separate file(s) outside of AD.
Kerberos is what I'm using now and it's working nicely. It also required
"manual" intervention on FreeBSD in order to get a reasonably current
version. For it to work as intended, it requires a bit of set up. I'm
don't remember exactly what, but I think it involved doing some set-up
on the domain controller and then copying files over to the Apache
server. Directions should be easily found by googling. I just used
"KrbVerifyKDC off" to avoid all that, but my security requirements are
The SSPI module is dead as far as I can tell, but can still be gotten. I
was never able to get very far with it.
Steve Dwire wrote:
> [cross-posting to dev]
> OK… I’m about to expose my ignorance and Windows-centric perspective
> With SQL Server and the Query Analyzer client, I can log on using
> “Windows Authentication”, and the server somehow magically accepts the
> credentials I used to log in to the system. I don’t have to re-type my
> domain logon and password, and it’s not cached anywhere. IIS and
> Internet Explorer have some means of exchanging those credentials as
> well – if everything’s configured “properly.”
> At this point, all I know is that it’s possible for a server process
> to accept my /existing/ windows domain authentication /even when I’m
> on a different machine/. I have no idea how that handshake works. I’m
> thinking that if we could get Subversion and Apache to work the same
> way, we would resolve the security problem with cleartext passwords
> and make life happier for most Windows domain users (and admins).
> Can someone a) point me to a document explaining (at a high level) how
> those existing client/server handshakes work, b) enumerate what would
> have to be added to the SVN (or TortoiseSVN) client software and
> apache mod_auth_??? to support this kind of seamless authentication
> mode, and/or c) explain why that concept just plain won’t work between
> svn and Apache?
> Steve Dwire
> * From: * Paul Ossenbruggen [mailto:firstname.lastname@example.org]
> *Sent:* Wednesday, August 25, 2004 3:39 PM
> *To:* email@example.com
> *Subject:* Credentials Caching - Security Guy Not Happy
> Our security guy just got wind of the fact that credentials are cached
> in clear text on disk, he is not too happy, and has told me that we
> need to turn this on:
> / [auth] /
> / store-auth-creds = no /
> This I have the feeling will make the system unusable, as I understand
> it, every user would have to authenticate every time they performed a
> svn command that accessed the server.
> Since, I went thought the process of setting up our system so that our
> system uses Active Directory to authenticate, this means that our
> Active Directory passwords are cached in what is essentially clear
> text. I explained to him that the permissions are set so that only the
> person who is account is logged in is allowed to see the files but
> this is not sufficient for the paranoid security guy because it still
> means that someone could read the disk if they have physical access to
> the machine and a low level disk utility or root access. Since it is
> our Active Directory password in clear text someone could get access
> to other servers in the company!
> That in a new version, in the not too distant future, that the auth
> directory is encrypted by svn. I mean, it really cool that, we have
> all these SSL capabilities in svn and this would be the last chink in
> the armor.
> What can I do in the mean time to appease the security guy and still
> retain the convenience that the auth-cache provides? I was thinking of
> perhaps putting the auth cache in an encrypted directory somehow, how
> hard is this to do?
> I have about a week to come up with a solution to this or I will be
> typing a lot of passwords and will have a lot of unhappy users.
> - Paul
> PS I am sure our security guy does not mind being called paranoid.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Aug 26 21:53:28 2004