Re: [modauthkerb] Keytab not readable? Can't authenticate workstation for SSO

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

Thanks so much for all the help on this issue, this is a great community of
people and I appreciate your willingness to help!  Special thanks to Yves
and Douglas for taking the time go through this with me in great detail.
 It made a huge difference!

This issue is finally resolved.  Here are some of the things that worked in
my particular case:

I was finally able to removed the "GSS-API major_status:000d0000,
minor_status:000186a4" Apache log error.  It was exactly what we all
thought it was: Apache not being able to read the keytab file.  The way I
corrected this was:

1) Editing the httpd.conf file and changing the "User" and "Group" lines to
a new user and group.  This is where you establish the owner of the Apache
process.  Before I was trying to do a chown on the httpd.pid file to change
the Apache owner, but that didn't seem to work and those changes were
actually being restored to their defaults when I restarted Apache anyway.
 Also remember to restart Apache when you've edited the httpd.conf file in
order to ensure these changes to take effect (sudo service httpd restart).

2) I added another keytab file for Apache specifically.   This was just an
exact duplicate of the other file but in a different location.  I changed
this file to have the same user and group as I specified in the httpd.conf
file above (sudo chown username:groupname
/path/to/apache-specific/keytab/krb5.keytab).  I also changed the
permissions on this new keytab file so it is only readable by the Apache
user (sudo chown 400 /path/to/apache-specific/keytab/krb5.keytab).

After making the above changes, when hitting
https://cname.mysite.com/user/login/sso and having Firefox configured
(about:config > network.negotiate-auth.trusted-uris = .mysite.com), I was
receiving the following in the Apache error log:

[info] Subsequent (No.2) HTTPS request received for child 1 (server
arecord.mysite.com:80)

[debug] src/mod_auth_kerb.c(1628): [client <ip address>]
kerb_authenticate_user entered with user (NULL) and auth_type Kerberos

[debug] src/mod_auth_kerb.c(1240): [client <ip address>] Acquiring creds
for HTTP/are...@EX...

[debug] src/mod_auth_kerb.c(1385): [client <ip address>] Verifying client
data using KRB5 GSS-API

[debug] src/mod_auth_kerb.c(1401): [client <ip address>] Client didn't
delegate us their credential

[debug] src/mod_auth_kerb.c(1420): [client <ip address>] GSS-API token of
length 180 bytes will be sent back
[debug] ssl_engine_kernel.c(1889): OpenSSL: Write: SSL negotiation finished
successfully

Which is exactly what should be logged during successful login according to
this (near the bottom):
http://blog.stefan-macke.com/2011/04/19/single-sign-on-with-kerberos-using-debian-and-windows-server-2008-r2/

Another problem I had was that we are using HTTP authentication to protect
the site using a Drupal module called
shield<https://drupal.org/project/shield>.
 So when you would hit the URL, you would get prompted for HTTP auth
credentials (before entering these credentials is when the successful
Apache log message would be logged) and if the credentials were entered
correctly, I would be sent to the 401 Authorization Required screen.
 Disabling shield seemed to do the trick.

I was still having a problem after getting rid of the HTTP auth, but it
ended up being Drupal specific.  Hitting
https://cname.mysite.com/user/login/sso would redirect me to our default
login screen and display the following error message at the top of the
page: "you have been successfully authenticated".  This was odd because I
was still not authorized to access content.  Turns out to be something that
is fixed in the newest version of the LDAP module (7.x-2.0-beta6 at the
time of this posting) .  If you're a Drupal user, see this issue for more
details: https://drupal.org/node/1956224

Here is the final working setup of my httpd.conf file (In my case it was
actually a site specific .conf file because we are hosting multiple sites
on the same server using vhosts.  The httpd.conf file used an "include" to
reference this site specific file):

  LoadModule auth_kerb_module /path/to/modules/mod_auth_kerb.so

 <Location /user/login/sso>
    AuthType Kerberos
    KrbAuthRealms EXAMPLE.ORG
    KrbMethodNegotiate on
    KrbMethodK5Passwd off
    require valid-user
    KrbServiceName HTTP
    Krb5Keytab /path/to/apache-specific/keytab/krb5.keytab
  </Location>

I hope this can help someone facing similar issues.  Thanks again!

-Jim

On Fri, Nov 1, 2013 at 11:56 AM, Martin Yves <yve...@el...> wrote:

>   Hello Douglas,
>
> Personally, the "service account" I created for SPN and keytab
> generation is also used to authenticate LDAP queries...
> As far as password does not expire and is correct, I discover no
> troubles about it.
>
> To sum up for Jim, here are some tasks I think about:
>
> - if the "user account" holding the SPN and used to generate
>   keytab is not a specific service account,
>   it is worth to delete it and create it again...
>
> - create a dedicated "service account" (standard account but
>   dedicated to Kerberos SSO) in AD and create keytab
>
> - check and clean duplicates SPN
>
> - do not use default location /etc/krb5.keytab but (for instance)
>   /etc/apache2/http-arecord.keytab
>
> - validates SPN with kinit/kvno:
>
> $ kinit MeMyselfI
> $ kvno HTTP/arecord.mysite.com
>
> $ kdestroy
> $ kinit HTTP/arecord.mysite.com
>  => check password authentication with "service account" password
>
> $ kdestroy
> $ kinit -k -t /etc/apache2/http-arecord.keytab HTTP/arecord.mysite.com
>  => is equivalent to the previous one but password comes from keytab
>
>
> If all that diagnostic steps pass, there is no reason Apache2 cannot
> accept your token from your browser... Or else you have a big trouble
> in Apache2/mod_auth_kerb. You should provide use with details about it.
>
>
> For a reason I have not found yet, few months ago, with Debian Wheezy
> mod_auth_kerb 5.4-2 and DC AD 2008, I had to explicitly set
> "KrbServiceName HTTP/arecord.mysite.com" instead of default "HTTP"
> to get my system to load keytab. It no longer "guess" expected SPN
> probably because our network was in a migration from one domain to
> another. I just checked and that trick is no longer required, defaults
> works.
>
>
> Hope this helps
> --
> Yves Martin
>
>