0

Sorry if this is the wrong stackexchange site for this.

Based upon the documentation (for reference I also used this blog post) I have this in httpd.conf:

# Increase max size of HTTP request headers so we are sure it can hold any SPNEGO token.
LimitRequestFieldSize 12392

# Load the module
LoadModule auth_gss_module /apps/apache2/modules/mod_auth_gss.so

# Set general log level so we get some output
LogLevel debug

<Directory "/var/www/secured"> 
    Order allow,deny 
    Allow from all 
    AuthType GSSAPI 
    AuthGSSServiceName HTTP 
    AuthGSSKeytabFile /path/to/keytab/servername.keytab 
    #AuthGSSStripDomainBS On 
    #AuthGSSStripDomainAT On 
    AuthGSSForceCase upper 
    AuthGSSDebug On 
    require valid-user 
</Directory>

And when I hit the page I get 'Unauthorized' in the browser and the following in the apache error_log:

tail -f logs/error_log 
[authz_core:debug] [pid 3657:tid 27] mod_authz_core.c(802): [client 10.138.48.42:1432] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(620): [client 10.138.48.42:1432] gss_authenticate: type = GSSAPI 
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(334): [client 10.138.48.42:1432] authenticate_user_gss called 
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(373): [client 10.138.48.42:1432] Using keytab: KRB5_KTNAME=/path/to/keytab/servername.keytab
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(411): [client 10.138.48.42:1432] Client wants GSS mech: <unknown> 
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(288): [client 10.138.48.42:1432] acquire_server_creds for HTTP@servername 
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(438): [client 10.138.48.42:1432] got server creds for: HTTP/servername.testdomain.local@
[core:error] [pid 3657:tid 27] [client 10.138.48.42:1432] gss_accept_sec_context() failed: Invalid token was supplied (No error)
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(650): [client 10.138.48.42:1432] Authentication failed. 
[core:debug] [pid 3657:tid 27] mod_auth_gss.c(592): [client 10.138.48.42:1432] note_gss_auth_failure: auth_name = <undefined>

I'm notice that I seem to acquire_server_creds for HTTP@servername but got server creds for: HTTP/servername.testdomain.local@. I'm at a loss where to start looking.

This is a Solaris 10 box, with Apache 2.4 trying to talk to a Windows 2008 Domain server.

Hosts file on Solaris server:

XXX.XXX.XXX.XXX servername.testdomain.local servername

No /etc/hostname file exists.

Dr.Avalanche
  • 133
  • 1
  • 1
  • 13

2 Answers2

1

Avalance,

I am the author of the blog entry you are referencing.

The problem you comment it is usually because the kerberos implementation uses the first name obtained by the system (usually the first entry in the /etc/hosts file). What it is happening is that you have the keytab with the fully qualified name and the first host entry is the name without qualifying. In those entries I configured the fully qualified name in the three places: keytab, first entry in /etc/hosts and the hostname of the machine (/etc/hostname).

If you check the previous entry I commented that I experienced the same problem.

ricky
  • 21
  • 1
  • thank you for your feedback, let me check the /etc/hosts and get back to you. I don't see a file called /etc/hostname – Dr.Avalanche Jan 20 '15 at 11:42
  • the hosts file has `servername.testdomain.local` the keytab has principal `HTTP/servername.testdomain.local@TESTDOMAIN.LOCAL` via `klist -k`. I'm confused which one needs to be changed. – Dr.Avalanche Jan 20 '15 at 14:41
1

Your /etc/hosts is ok (the fully qualified name is the first one). Check if the hostname in the machine is the short or the fully qualified name. Just execute hostname and check the response.

If the name is the short one, try to change the hostname name to the fully qualified name:

hostname servername.testdomain.local

I think there is a -t option to set it temporary.

ciao!

ricky
  • 61
  • 1