As I just went through configuring our SVN server with Kerberos SPNEGO
single sign-on, you can take a look at the successful result as Apache
httpd configuration.
First you need to generate a Service principal on your Kerberos Key
Distribution Center which is then copied as keytab file
/etc/apache2/krb5-svn-HTTP.keytab to the Unix and Apache httpd based SVN
server.
On a Windows KDC (Active Directory) first create a normal user account
for your HTTP service with. In this example the hostname of the http SVN
server is svn.company.org. Then use the following command to create a
service principal and attach it to the user account and write it to the
keytab file:
ktpass -princ HTTP/svn.company.org_at_COMPANY.ORG -mapop set -pass
userpassword -mapuser svn-HTTP -out krb5-svn-HTTP.keytab
Note that svn.company.org needs it own IP address as the reverse lookup
must lead to the hostname back as otherwise most Kerberos clients does
not accept it!
The Apache httpd configuration for VirtualHost svn.company.org:
<Location /svn>
DAV svn
SVNParentPath /home/svn
SVNListParentPath on
SVNPathAuthz off
#SVNAutoVersioning on
#ModMimeUsePathInfo on
AuthName "SVN Login"
AuthType Kerberos
KrbAuthRealms COMPANY.ORG
KrbServiceName HTTP
Krb5Keytab /etc/apache2/krb5-svn-HTTP.keytab
KrbVerifyKDC off
KrbMethodNegotiate on
KrbMethodK5Passwd on
KrbSaveCredentials off
KrbAuthoritative off
AuthLDAPURL "ldap://ldap1 ldap2
ldap3/dc=company,dc=org?userPrincipalName,samaccountname?sub?(objectClas
s=person)"
AuthLDAPGroupAttributeIsDN on
AuthLDAPBindDN cn=ldapaccess,cn=users,dc=company,dc=org
AuthLDAPBindPassword ldapaccesspw
AuthLDAPRemoteUserIsDN off
# for the following option you need this patch for Apache 2.x
# as otherweise the username is shown in SVN as
username_at_COMPANY.ORG
# https://issues.apache.org/bugzilla/show_bug.cgi?id=42561
AuthLDAPRemoteUserAttribute samaccountname
# all groups needed here for internal SVN commands
require ldap-group
CN=readgroupA,OU=Groups,DC=company,DC=org
require ldap-group
CN=readgroupB,OU=Groups,DC=company,DC=org
require ldap-group
CN=readgroupC,OU=Groups,DC=company,DC=org
</Location>
<Location /svn/[^/]+/!svn>
# all groups needed here for internal SVN commands
require ldap-group
CN=readgroupA,OU=Groups,DC=company,DC=org
require ldap-group
CN=readgroupB,OU=Groups,DC=company,DC=org
require ldap-group
CN=readgroupC,OU=Groups,DC=company,DC=org
</Location>
# multiple SVN repositories follow:
<Location /svn/RepositoryA>
<LimitExcept MERGE MKCOL POST PUT DELETE PATCH
PROPPATCH>
# readonly access
require ldap-group
CN=readgroupA,OU=Groups,DC=company,DC=org
require ldap-group
CN=readgroupB,OU=Groups,DC=company,DC=org
</LimitExcept>
<Limit MERGE MKCOL POST PUT DELETE PATCH PROPPATCH>
# read and write access
require ldap-group
CN=readgroupC,OU=Groups,DC=company,DC=org
</Limit>
</Location>
> -----Original Message-----
> From: Tony Butt [mailto:Tony.Butt_at_cea.com.au]
> Sent: Tuesday, September 22, 2009 2:34 AM
> To: Alec Kloss
> Cc: Derek Hoffman; users_at_subversion.tigris.org
> Subject: Re: Help: Apache2, Kerberos, AD, caching authentication?
>
> On Mon, 2009-09-21 at 08:30 -0500, Alec Kloss wrote:
> > On 2009-09-17 15:54, Tony Butt wrote:
> > > On Wed, 2009-09-16 at 21:03 -0500, Derek Hoffman wrote:
> > > > Thank you for the reply Andrey.
> > > >
> > > > I looked into it more realized that it was actually multiple DNS
> > > > requests caused by me using a FQDN for the KDC in my
> krb5.conf file. I
> > > > changed it to use the IP address of the KDC instead and
> everything has
> > > > sped up a great deal.
> > > >
> > > > I'm thinking that I should ask the authors of the
> apache kerberos module
> > > > about this, and get their opinion on it.
> > > >
> > > > Thanks again,
> > > > Derek.
> > > >
> > > >
> > > Derek,
> > > We had this exact problem some years ago, and used exactly that
> > > solution, which helped. The short answer is, though, you
> will still be
> > > hitting your kerberos provider for each and every request.
> > >
> > > I had some luck by configuring kerberos for pam, and then using
> > > mod_auth_pam to do apache authentication.
> > >
> > > Eventually, we settled on ldap authentication, apache2.2
> ldap is quite
> > > solid, and caches 'out of the box'
> > >
> > > Tony Butt
> > > CEA Technologies
> > > Canberra, Australia
> > [chop]
> >
> > This means your Subversion clients are using HTTP Basic
> > authentication which is handled by mod_auth_kerb. This is a really
> > ineffecient way to utilize Kerberos. If you use HTTP Negotiate
> > authentication (aka SPNEGO) you should have much faster
> > authentication as the server never needs to talk to the KDC at all,
> > and your clients will get single sign-on in the process which
> > should make them happier. I suggest using an alternate HTTP Basic
> > provider in Apache to handle clients that can't do Negotiate such
> > as LDAP or SASL to handle the HTTP basic results. I use the SASL
> > provider with some success, and it seems to include a cache as well.
> >
> >
> I tried for some weeks to get SPNEGO to work correctly, and eventually
> gave up in disgust.
>
> My final mod_auth_kerb config looked like this
>
> AuthType Kerberos
> Krb5Keytab /etc/apache2/apache.ktab
> KrbAuthRealms CEA.COM.AU
> KrbServiceName HTTP
> KrbMethodNegotiate on
> KrbServiceName HTTP/lion.cea.com.au_at_CEA.COM.AU
>
> But negotiate was refused, form both Firefox (with the firefox config
> set correctly, I think), and the svn client at the time (1.3.x)
>
> If you have any better advice on how to make this work, I am all ears,
> as I would much prefer that to ldap.
>
> Tony
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&
> dsMessageId=2397636
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397701
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-22 10:39:19 CEST