[Freeipa-users] http service keytab for cname virtual host

[Simo Sorce]

On Thu, 2012-03-29 at 08:58 +0200, Natxo Asenjo wrote:
> On Wed, Mar 28, 2012 at 11:36 PM, Simo Sorce <simo at redhat.com> wrote:
>         
>         
>         CNAMEs should work just fine with the host's HTTP/A-name at REALM
>         key.
>         In fact I just tested a virtual host on my ipa server using a
>         cname and
>         it worked.
> 
> great! 
>  
> 
>         Can you post your (sanitized) mod_auth_kerb configuration ?
>         Also what browser are you testing with ?
> 
> sure:
> 
>  <VirtualHost *:80>
>         ServerName vhost.ipa.domain.tld
>         ServerAdmin webmaster at domain.tld
>         DocumentRoot /var/www/html/vhost1
>         LogLevel debug
>         CustomLog    /var/log/httpd/vhost1.access.log combined
>         ErrorLog     /var/log/httpd/vhost1.error.log
> 
> <Location "/kerb">
>   AuthType Kerberos
>   AuthName "Kerberos Login"
>   KrbMethodNegotiate on
>   KrbMethodK5Passwd off
>   KrbServiceName HTTP
>   KrbAuthRealms IPA.DOMAIN.TLD
>   Krb5KeyTab /etc/httpd/conf/webserver01_http.keytab
>   KrbSaveCredentials on
>   Require valid-user
> </Location>
> 
> </VirtualHost>
> 
>         If you kdestroy and then kinit clean, and then try to access
>         the server
>         *only* using the CNAME you should see the browser has acquired
>         a ticket
>         for HTTP/A-name, You can use klist to verify. If this works
>         you know it
>         is a server side issue only. If you do not have the ticket,
>         there may be
>         a DNS/browser issue.
> 
> yes, I get a HTTP/A-name ticket and a 500 internal server error on the
> browser. So you are right, we have an apache issue only. If you can
> shed some light on the the mod_kerb config that will be great.
> 
Your configuration looks right, but I went back and looked at your logs
and I saw a permission denied error.

I would check that the apache user can access the keytab
file: /etc/httpd/conf/webserver01_http.keytab
If you are using RHEL/Fedora, also check the audit.log file in case the
file is mislabeled and SELinux is preventing access to it.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York