I'm using mod_auth_kerb & Apache HTTPD to authenticate website users against a Kerberos server. I'm receiving a strange error message in my Apache error log. (Please note, I've changed the principal in this post for security reasons, but the format remains the same). Turning on debug level output for Apache allowed me to obtain more informative logs:
[debug] src/mod_auth_kerb.c(1932): [client x.x.x.x] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1277): [client x.x.x.x] Acquiring creds for HTTP/[email protected]
[debug] src/mod_auth_kerb.c(1470): [client x.x.x.x] Credentials cache FILE:/tmp/krb5cc_48 not found, create one
[error] [client x.x.x.x] Could not parse principal HTTP/[email protected]/server_hostname: Malformed representation of principal (-1765328250)
[debug] src/mod_auth_kerb.c(1598): [client x.x.x.x] Failed to obtain credentials for s4u2proxy
[debug] src/mod_auth_kerb.c(1137): [client x.x.x.x] GSS-API major_status:000d0000, minor_status:0000000d
[error] [client x.x.x.x] gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
I suppose the problem is with the "/server_hostname" at the end of the principal. In my Kerberos keytab file the principal is listed as HTTP/[email protected]
. How can I change the principal that is submitted to mod_auth_kerb? Or is there another way to reconcile this parsing error?
It turned out to be a file system permission problem. The keytab was owned by root:root, and permissions were set to read/write for owner only (0600). Therefore, Apache HTTPD was not able to access the keytab file. I still don't know how mod_auth_kerb was coming up with the context initiator principal that it was. But, now that the keytab is readable by Apache everything is working properly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With