Giter VIP home page Giter VIP logo

mod_auth_gssapi's Introduction

mod_auth_gssapi

Intro

This module has been built as a replacement for the aging mod_auth_kerb. Its aim is to use only GSSAPI calls and be as much as possible agnostic of the actual mechanism used.

Negotiate, Client Specific Behavior, and External Clients

The mod_auth_gssapi httpd plugin relies on Microsoft's IANA registered www-authenticate: Negotiate auth scheme to provide Kerberos and NTLM authentication to web browsers.
The negotiation process is client driven and the default process is to attempt Kerberos first, then fall back onto NTLM. If NTLM is not desired it must be disabled client-side. Many browsers such as recent versions of Firefox default to disabling NTLM and require opt-in (regardless of OS). However. many browsers behave differently on Windows, defer to the Windows Authentication subsystem, and therefore still use an NTLM fallback per the original Microsoft specification in RFC4559 by default. Browsers which default to NTLM fallback on Windows include chromium based browsers such as Chrome and Edge as well as older browsers such as IE.

If NTLM is enabled client side and Kerberos auth fails then the browser will prompt the user with a username and password dialog that looks similar to an HTTP Basic auth form, regardless of whether the server is configured to handle NTLM. This often confuses and frustrates users and admins. It may be possible to disable NTLM fallback if an admin has control of every user OS and user browser, but in that scenario (corporate network/intranet) the admin has presumably correctly configured Kerberos so fallback is unlikely to occur. The larger issue is if you have an external facing auth server and therefore no control over all clients some of whom may be on Windows using a browser that delegates to the Windows Authentication subsystem. Neither Kerberos nor NTLM are designed to work in a public Internet scenario and therefore using IP-based request filtering on the auth server to conditionally prompt only internal managed Kerberos clients (corporate intranet) users with www-authenticate: Negotiate is a reasonable solution.

Dependencies

A modern version of MIT's Krb5 distribution or any GSSAPI implementation that supports the credential store extension is necessary to achieve full functionality. Reduced functionality is provided without these extensions.

MIT krb5 (>=1.11)
Apache httpd (>=2.4.11)

Tests

To run tests, you also need:

  • The Kerberos 5 Key-Distribution-Center (krb5-kdc package on Debian, krb5-server on Fedora)
  • Packages mod_session, krb5-workstation, python3-requests-gssapi, and python3-gssapi on Fedora
  • Some tests require krb5-pkinit package on fedora and krb5 >= 1.15.
  • nss_wrapper, packaged in Fedora
  • socket_wrapper, packaged in Fedora

Installation

autoreconf -fi
./configure
make
make install

Configuration

Apache authentication modules are usually configured per location, see the mod_authn_core documentation for the common directives

Basic configuration

The simplest configuration scheme specifies just one directive, which is the location of the keytab.

Example

<Location /private>
    AuthType GSSAPI
    AuthName "GSSAPI Single Sign On Login"
    GssapiCredStore keytab:/etc/httpd.keytab
    Require valid-user
</Location>

Your Apache server need read access to the keytab configured. If your Kerberos implementation does not support the credential store extensions you can also simply set the KRB5_KTNAME environment variable in the Apache init script and skip the GssapiCredStore option completely.

Environment Variables

(Note: these are not process environment variables, but rather Apache environment variables, as described in the apache docs.)

gssapi-no-negotiate

This environment variable is used to suppress setting Negotiate headers. Not sending these headers is useful to work around browsers that do not handle them properly (and incorrectly show authentication popups to users).

Example

For instance, to suppress negotiation on Windows browsers, one could set:

BrowserMatch Windows gssapi-no-negotiate

Configuration Directives

Alphabetic List of Directives

GssapiAcceptorName
GssapiAllowedMech
GssapiBasicAuth
GssapiBasicAuthMech
GssapiBasicTicketTimeout
GssapiConnectionBound
GssapiCredStore
GssapiDelegCcacheDir
GssapiDelegCcacheEnvVar
GssapiDelegCcachePerms
GssapiDelegCcacheUnique
GssapiImpersonate
GssapiLocalName
GssapiNameAttributes
GssapiNegotiateOnce
GssapiPublishErrors
GssapiPublishMech
GssapiRequiredNameAttributes
GssapiSessionKey
GssapiSignalPersistentAuth
GssapiSSLonly
GssapiUseS4U2Proxy
GssapiUseSessions

GssapiSSLonly

Forces the authentication attempt to fail if the connection is not being established over TLS. The default is "Off", which could be helpful in a local development environment, but we do not recommend for production deployments. A passive adversary could listen to the plaintext HTTP connection to observe any private information in the client's request or server's response (for example: the full HTTP response body, or any web application session cookies, etc). You should only use mod_auth_gssapi with HTTPS in production, so we recommend that you enable this setting in production for added protection.

  • Enable with: GssapiSSLonly On
  • Default: GssapiSSLonly Off

GssapiLocalName

Tries to map the client principal to a local name using the gss_localname() call. This requires configuration in the /etc/krb5.conf file in order to allow proper mapping for principals not in the default realm (for example a user coming from a trusted realm). See the 'auth_to_local' option in the [realms] section of krb5.conf(5)

When GssapiLocalName is set to on, mod_auth_gssapi will set the REMOTE_USER variable to the resolved user name. mod_auth_gssapi will also set the GSS_NAME variable to the complete client principal name.

  • Enable with: GssapiLocalName On
  • Default: GssapiLocalName Off

GssapiConnectionBound

This option is not needed for krb5 or basic auth in almost all cases. It incurs overhead, so leaving it off is recommended.

For NTLMSSP (and any other GSS mechanisms that require more than one round-trip to complete authentication), it is necessary to bind to the authentication to the connection in order to keep the state between round-trips. With this option, incomplete context are stored in the connection and retrieved on the next request for continuation.

  • Enable with: GssapiConnectionBound On
  • Default: GssapiConnectionBound Off

GssapiSignalPersistentAuth

For clients that make use of Persistent-Auth header, send the header according to GssapiConnectionBound setting.

  • Enable with: GssapiSignalPersistentAuth On
  • Default: GssapiSignalPersistentAuth Off

GssapiUseSessions

In order to avoid constant and costly re-authentication attempts for every request, mod_auth_gssapi offers a cookie based session method to maintain authentication across multiple requests. GSSAPI uses the mod_sessions module to handle cookies so that module needs to be activated and configured. GSSAPI uses a secured (encrypted + MAC-ed) payload to maintain state in the session cookie. The session cookie lifetime depends on the lifetime of the GSSAPI session established at authentication. NOTE: It is important to correctly set the SessionCookieName option. See the mod_sessions documentation for more information.

  • Enable with: GssapiUseSessions On
  • Default: GssapiUseSessions Off

Example

GssapiUseSessions On
Session On
SessionCookieName gssapi_session path=/private;httponly;secure;

GssapiSessionKey

When GssapiUseSessions is enabled a key use to encrypt and MAC the session data will be automatically generated at startup, this means session data will become unreadable if the server is restarted or multiple servers are used and the client is load balanced from one to another. To obviate this problem the admin can choose to install a permanent key in the configuration so that session data remain accessible after a restart or by multiple servers sharing the same key.

Two schemes to read persistent keys are provided, 'key' and 'file'.

  • 'key' A key is read from the configuration directive. The key must be a base64 encoded raw key of 32 bytes of length.

  • 'file' A file on the file system is used to store the key. If the file does not exists one is created with a randomly generated key during the first execution.

Examples

GssapiSessionKey key:VGhpcyBpcyBhIDMyIGJ5dGUgbG9uZyBzZWNyZXQhISE=
GssapiSessionKey file:/var/lib/httpd/secrets/session.key

GssapiCredStore

The GssapiCredStore option allows to specify multiple credential related options like keytab location, client_keytab location, ccache location etc.

Example

GssapiCredStore keytab:/etc/httpd.keytab
GssapiCredStore ccache:FILE:/var/run/httpd/krb5ccache

GssapiDelegCcacheDir

If delegation of credentials is desired credentials can be exported in a private directory accessible by the Apache process. The delegated credentials will be stored in a file named after the client principal and a request environment variable (KRB5CCNAME by default) will be set to point to that file.

Example

GssapiDelegCcacheDir /var/run/httpd/clientcaches

A user [email protected] delegating its credentials would cause the server to create a ccache file named /var/run/httpd/clientcaches/[email protected]

GssapiDelegCcacheUnique

Enables using unique ccache names for delegation. ccache files will be placed in GssapiDelegCcacheDir and named using the principal and a six-digit unique suffix.

Note: Consuming application must delete the ccache otherwise it will litter the filesystem if sessions are used. An example sweeper can be found in the contrib directory. If using with gssproxy, see note at the top of that file.

  • Enable with: GssapiDelegCcacheUnique On
  • Default: GssapiDelegCcacheUnique Off

GssapiDelegCcacheEnvVar

Set the name of the request environment variable that will receive the credential cache name. If unspecified, defaults to KRB5CCNAME.

Example

GssapiDelegCcacheEnvVar AJP_KRB5CCNAME

GssapiUseS4U2Proxy

Enables the use of the s4u2Proxy Kerberos extension also known as constrained delegation This option allows an application running within Apache to operate on behalf of the user against other servers by using the provided ticket (subject to KDC authorization). This options requires GssapiDelegCcacheDir to be set. The ccache will be populated with the user's provided ticket which is later used as evidence ticket by the application.

Note: This flag has no effect when Basic-Auth is used since user's credentials are delegated anyway when GssapiDelegCcacheDir is set.

Example

GssapiUseS4U2Proxy On
GssapiCredStore keytab:/etc/httpd.keytab
GssapiCredStore client_keytab:/etc/httpd.keytab
GssapiCredStore ccache:FILE:/var/run/httpd/krb5ccache
GssapiDelegCcacheDir /var/run/httpd/clientcaches

NOTE: The client keytab is necessary to allow GSSAPI to initiate via keytab on its own. If not present an external mechanism needs to kinit with the keytab and store a ccache in the configured ccache file.

GssapiBasicAuth

Allows the use of Basic Auth in conjunction with Negotiate. If the browser fails to use Negotiate it will instead fallback to Basic and the username and password will be used to try to acquire credentials in the module via GSSAPI. If credentials are acquired successfully then they are validated against the server's keytab.

  • Enable with: GssapiBasicAuth On
  • Default: GssapiBasicAuth Off

Example

<Location /gssapi>
  AuthType GSSAPI
  AuthName "Login"
  GssapiBasicAuth On
  GssapiCredStore keytab:/etc/httpd/http.keytab
  Require valid-user
</Location>

GssapiAllowedMech

List of allowed mechanisms. This is useful to restrict the mechanism that can be used when credentials for multiple mechanisms are available. By default no mechanism is set, this means all locally available mechanisms are allowed. The recognized mechanism names are: krb5, iakerb, ntlmssp

Example

GssapiAllowedMech krb5
GssapiAllowedMech ntlmssp

GssapiBasicAuthMech

List of mechanisms against which Basic Auth is attempted. This is useful to restrict the mechanisms that can be used to attempt password auth. By default no mechanism is set, this means all locally available mechanisms are allowed, unless GssapiAllowedMech is set, in which case those are used. GssapiBasicAuthMech always takes precedence over GssapiAllowedMech. The recognized mechanism names are: krb5, iakerb, ntlmssp

Example

GssapiBasicAuthMech krb5

GssapiNameAttributes

Enables the module to source Name Attributes from the client name (authorization data associated with the established context) and exposes them as environment variables.

Value format: ENV_VAR_NAME ATTRIBUTE_NAME

This option can be specified multiple times, once for each attribute to expose. The Special value "json" is used to expose all attributes in a json formatted string via the special environment variable GSS_NAME_ATTRS_JSON The environment variable GSS_NAME_ATTR_ERROR is set with the Gssapi returned error string in case the inquire name function fails to retrieve attributes, and with the string "0 attributes found", if no attributes are set.

Note: These variables are NOT saved in the session data stored in the cookie so they are available only on the first authenticated request when GssapiUseSessions is used.

Note: It is recommended but not required to use only capital letters and underscores for environment variable names.

Example

GssapiNameAttributes json
GssapiNameAttributes RADIUS_NAME urn:ietf:params:gss:radius-attribute_1

GssapiRequiredNameAttributes

This option allows specifying one or more Name Attributes that the client must possess in order to be authorized to access the location. The required Name Attributes are specified by name=value pairs (name being the ATTRIBUTE_NAME as mentioned above, and value being a Null-terminated string. Alternately, if a Name Attribute produces binary values or is expected to contain a space character, the desired value can be specified by a ':=' and a base64-encoded string).

A combination of Name Attributes (including multiple values from a single Name Attribute type) can be specified with an expression that separates each name=value pair with the "and" or "or" logical operators. Operator precedence can be influenced by parenthesized statements.

foo=bar
foo:=YmFy
foo=bar or foo=baz
foo=bar and foo=baz and bar=baz
(foo=bar and foo=baz) or bar:=YmFy

If the Name Attributes associated with the client do not satisfy the given expression, or no Name Attributes are present, a 403 response is returned.

Example

GssapiRequiredNameAttributes "auth-indicators=high"
GssapiRequiredNameAttributes "auth-indicators=high or other-attr=foo"
GssapiRequiredNameAttributes "((auth-indicators=low and auth-indicators=med) or auth-indicators=high)"

GssapiNegotiateOnce

When this option is enabled the Negotiate header will not be resent if Negotiation has already been attempted but failed.

Normally when a client fails to use Negotiate authentication, a HTTP 401 response is returned with a WWW-Authenticate: Negotiate header, implying that the client can retry to use Negotiate with different credentials or a different mechanism.

Consider enabling GssapiNegotiateOnce when only one single sign on mechanism is allowed, or when GssapiBasicAuth is enabled.

NOTE: if the initial Negotiate attempt fails, some browsers will fallback to other Negotiate mechanisms, prompting the user for login credentials and reattempting negotiation. This situation can mislead users - for example if krb5 authentication failed and no other mechanisms are allowed, a user could be prompted for login information even though any login information provided cannot succeed. When this occurs, some browsers will not fall back to a Basic Auth mechanism. Enable GssapiNegotiateOnce to avoid this situation.

  • Enable with: GssapiNegotiateOnce On
  • Default: GssapiNegotiateOnce Off

GssapiImpersonate

This option can be used even if AuthType GSSAPI is not used for given Location or LocationMatch, to obtain service ticket for a user that was already authenticated by different module. (This is also known as s4u2self, or protocol transition.)

The principal of the user is retrieved from the internal r->user identifier which typically holds the username from the authentication results.

Optionally, this user principal can later be used for s4u2proxy (constrained delegation). To do this, ensure the server principal is permitted to acquire forwardable tickets to itself from arbitrary users (i.e., with the option +ok_to_auth_as_delegate).

  • Enable with: GssapiImpersonate On
  • Default: GssapiImpersonate Off

GssapiDelegCcachePerms

This option is used to set alternative ownership and permission for delegated ccache files stored in the GssapiDelegCcacheDir location. It is a multivalue configuration directive that can accept the following three settings:

  • mode
  • uid
  • gid If a setting is not present the relative file property will not be modified and the default owners and/or mode will be retained.

mode

This option allows to set the file mode, the format used is a numeric mode
with the same semantics of the chmod unix command for mapping numbers to
permissions.

uid

A user id number or name, an attempt to change the user owner of the file
to the uid number specified will be made. If a user name has been
specified, it will be resolved at startup time and the user's id number
stored internally for all subsequent operations.

gid

A group id number or name, an attempt to change the group owner of the
file to the gid number specified will be made. If a group name has been
specified, it will be resolved at startup time and the group's id number
stored internally for all subsequent operations.

Example

GssapiDelegCcachePerms mode:0660 gid:webuiworkers

GssapiPublishErrors

This option is used to publish errors as Environment Variables for use by httpd processes.

A general error type is provided in the MAG_ERROR variable, and can have the following values: "GSS ERROR", "INTERNAL ERROR", "AUTH NOT ALLOWED" Additionally, in the variable named MAG_ERROR_TEXT there may be a free form error message.

When the error type is "GSS ERROR" the variables GSS_ERROR_MAJ and GSS_ERROR_MIN contain the numeric errors returned by GSSAPI, and the MAG_ERROR_TEXT will contain a GSS Error message, possibly prepended by an additional message that provides more context.

  • Enable with: GssapiPublishErrors On
  • Default: GssapiPublishErrors Off

GssapiAcceptorName

This option is used to force the server to accept only for a specific name.

This allows, for example to select to use a specific credential when multiple keys are provided in a keytab.

A special value of {HOSTNAME} will make the code use the name apache sees in the httpd request to select the correct name to use. This may be useful to allow multiple names and multiple keys to be used on the same apache instance.

Note: By default no name is set and any name in a keytab or mechanism specific acceptor credential will be allowed.

Note: Global gssapi options set in krb5.conf like 'ignore_acceptor_hostname' may affect the ability to restrict names.

Note: The GSS_C_NT_HOSTBASED_SERVICE format is used for names (see example).

Example

GssapiAcceptorName [email protected]

GssapiBasicTicketTimeout

This option controls the ticket validity time requested for the user TGT by the Basic Auth method.

Normally basic auth is repeated by the browser on each request so a short validity period is used to reduce the scope of the ticket as it will be replaced quickly. However in cases where the authentication page is separate and the session is used by other pages the validity can be changed to arbitrary duration.

Note: the validity of a ticket is still capped by KDC configuration.

Note: the value is specified in seconds.

  • Default: GssapiBasicTicketTimeout 300

Example

GssapiBasicTicketTimeout 36000

Sets ticket/session validity to 10 hours.

GssapiPublishMech

This option is used to publish the mech used for authentication as an Environment variable named GSS_MECH.

It will return a string of the form 'Authtype/Mechname'. Authtype represents the type of auth performed by the module. Possible values are 'Basic', 'Negotiate', 'NTLM', 'Impersonate'. Mechname is the name of the mechanism as reported by GSSAPI or the OID of the mechanism if a name is not available. In case of errors the 'Unavailable' string may also be returned for either Authtype or Mechname.

  • Enable with: GssapiPublishMech On
  • Default: GssapiPublishMech Off

mod_auth_gssapi's People

Contributors

abbra avatar adelton avatar alejandro-perez avatar davisd123 avatar flo-renaud avatar frasertweedale avatar frozencemetery avatar hlavki avatar iboukris avatar jgroffen avatar ktdreyer avatar michael-o avatar notroj avatar npmccallum avatar simo5 avatar slominskir avatar stanislavlevin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mod_auth_gssapi's Issues

New Release

Hi,

Without change 855341b expired sessions do not appear to reauthenticate in 1.3.1. Is there a chance of another release?

Thanks!

-- ken

Segmentation fault on subrequest

I managed to have ap_is_initial_req == FALSE but req->main == NULL on some requests. This lead to a segfault. Adding a NULL check to the initial request check seems to work fine.

module loading order seems to matter

When I switched from mod_auth_kerb to mod_auth_gssapi in the ipsilon project, specifically adding tests, I found that I wasn't getting an WWW-Authenticate header back so had no chance to do negotiation.

AFAICT this boiled down to the order of the modules: mod_auth_gssapi needs to be loaded before mod_auth_mellon.

mod_auth_gssapi needs mod_auth_kerb to work??

I have the following setup and cannot get mod_auth_gssapi to run correctly:

RedHat7, Apache 2.4

  • generic http:// to https:// rewrite ssl.conf
  • Alias intranet.company.com pointing to interalname.company.com (hostname of the Server)
  • Keytab File with intranet.company.com
  • vhost listening to port 443 with "ServerName intranet.company.com"
  • in the <Location /></Location> part I have the following setup
AuthType GSSAPI
AuthName "Company Intranet Single-Sign-On"
GssapiBasicAuth On

Require valid-user

GssapiCredStore keytab:/etc/httpd/http_intranet.keytab
GssapiDelegCcacheDir /var/run/httpd/krbcache

When installing TYPO3 with the extension realurl which does rewrite (mod_rewrite) GET-Parameter into shiny, human-readable URLs, the Apache Log gets filled up with the following error:

[auth_gssapi:error] [pid 6875] [client xxx.xxx.xxx.xxx:61373] gss_accept_sec_context() failed: [Unspecified GSS failure.  Minor code may provide more information (Request is a replay)]

only when installing mod_auth_kerb this issue is successfully resolved and SSO is working smoothly.

Is there a dependency to mod_auth_kerb or can you explain this behavior?

GssapiUseSessions seem to send duplicate cookie.

This seem strange unless I missed something:

< WWW-Authenticate: Negotiate oYGzMIGwoAMKAQChCwYJKoZIhvcSAQICooGbBIGYYIGVBgkqhkiG9xIBAgICAG+BhTCBgqADAgEFoQMCAQ+idjB0oAMCAReibQRrKZpTca6SFodVsBYYpXeaSGm7MRGyK7n2Ri3Uq3qwYx8iOw47Rau0eml3Ppo4ACLwXeN4HZZ8jL9C+i1b1v+rJofXj4cyb1NG6ZypdZaXQSVbf/DrYVr+SftG1lIz6V1BX0KZf8MRzGtM6PQ=
< Set-Cookie: gssapi_session=MagBearerToken=KnTGhvBWmyG%2b78Ikm8%2bzLX8%2fgBDtHD0a%2f3N62jyzxXXmUUY09oWyNPJN0hszm0ChhlPF4Az5e%2bIfNUm1FtpKw46jsm4z0ZZlEQ%3d%3d;path=/private;httponly;secure;
< X-Powered-By: PHP/5.6.7
< Cache-Control: no-cache
< Set-Cookie: gssapi_session=MagBearerToken=KnTGhvBWmyG%2b78Ikm8%2bzLX8%2fgBDtHD0a%2f3N62jyzxXXmUUY09oWyNPJN0hszm0ChhlPF4Az5e%2bIfNUm1FtpKw46jsm4z0ZZlEQ%3d%3d;path=/private;httponly;secure;
< Content-Length: 75

My config:
<Location /private>
GssapiUseSessions On
Session On
SessionCookieName gssapi_session path=/private;httponly;secure;
GssapiBasicAuth On
AuthType GSSAPI
AuthName "GSSAPI Single Sign On Login"
GssapiConnectionBound On
Require valid-user

Saving forwarded credentials fail for service principal names

Service principal names have an embedded '/' in the name
When creating a ccache file we need to mangle it or it will be seen as a path separator and the ccache savewill fail as no such directories as 'host' 'HTTP' etc are presente in the credential cache directory normally.

GssapiNegotiateOnce

I've been trying different settings and I am not able to use GssapiNegotiateOnce:

"Invalid command 'GssapiNegotiateOnce', perhaps misspelled or defined by a module not included in the server configuration."

CentOS 7.2

Name : mod_auth_gssapi
Version : 1.3.1
Release : 1.el7
Architecture: x86_64

Client GSSAPI mechanism for Basic auth

Hello,

The following code section deals with Basic auth when 'init_sec_context()' returns 'GSS_S_CONTINUE_NEEDED':
https://github.com/modauthgssapi/mod_auth_gssapi/blob/master/src/mod_auth_gssapi.c#L467

However, in practice I think it will probably never happen because we acquire client credentials and call 'init_sec_context()' with 'GSS_C_NO_OID' which usually defaults to KRB mech, and as we do not request 'mutual_req_flag' we should get 'GSS_S_COMPLETE' on the first call to 'init_sec_context()' (only SPNEGO and NTLM mechs would always return 'GSS_S_CONTINUE_NEEDED' on the first call although mutual auth was not requested).

That's the behavior I get in lab tests which matches RFC 2078, quote:

The client calls GSS_Init_sec_context() to establish a security
context to the server identified by targ_name, and elects to set the
mutual_req_flag so that mutual authentication is performed in the
course of context establishment. GSS_Init_sec_context() returns an
output_token to be passed to the server, and indicates
GSS_S_CONTINUE_NEEDED status pending completion of the mutual
authentication sequence. Had mutual_req_flag not been set, the
initial call to GSS_Init_sec_context() would have returned
GSS_S_COMPLETE status. The client sends the output_token to the
server.

In my opinion - in order to give the client the best chances to succeed - we could specify SPNGO mech OID instead of 'GSS_C_NO_OID' when acquiring client credentials and when calling 'init_sec_context()'.

Thoughts?

Cheers,
Isaac B.

Using Basic authentication: Unspecified GSS failure. Minor code may provide more information (Ticket expired)

When I try to login to my webserver from a non-Kerberos enabled browser (machine does NOT use Kerberos authentication and network.negotiate-auth.trusted-uris is NOT set in Firefox), authentication fails and I see following error message in the server logs:

[auth_gssapi:error] โ€ฆ gss_init_sec_context() failed: [Unspecified GSS failure.  Minor code may provide more information (Ticket expired)]

Initially I also got:

[auth_gssapi:error] โ€ฆ In Basic Auth, gss_acquire_cred_with_password() failed: [Unspecified GSS failure.  Minor code may provide more information (Principal in credential cache does not match desired name)]

This message currently does not appear, but I have seen it a long time ago already. So it seems to show up randomly?

Login using a Kerberos enabled browser (i.e. machine uses Kerberos authentication and network.negotiate-auth.trusted-uris is set in Firefox) succeeds, so this seems to affect only Basic authentication.

I use following Apache config:

                <Location /auth/login/RemoteUser:self>
                        AuthName "???"
                        AuthType GSSAPI

                        GssapiBasicAuth On
                        GssapiCredStore keytab:/etc/apache2/http.keytab

#                       GssapiConnectionBound On
#                       Header set Persistent-Auth "true"

#                       GssapiUseSessions On
#                       Session On
#                       SessionCookieName gssapi_session path=/;httponly;secure;

                        Require valid-user
                </Location>

The commented out parts were in use (and the client also authenticated several times during the time they were enabled), but to limit the testcase I removed them for now.

The machine's clock is synchronised via NTP and I checked that the time is correct.

I am currently at 7407b64, but e6d9a30 is also affected. Prior versions do not support Basic authentication. Apache is at 2.4.10-9 (Debian 8/Jessie).

RFE | Add raw NTLM authentication support.

I was playing with the idea of implement direct NTLM authentication (without Negotiate) by using gss-ntlmssp in the back end.
So I gave it a try and it was surprisingly easy using native GSSAPI calls and I wanted to share my draft.

I want to try work on a proper patch and interested in you opinion about it.
There may be unrelated changes in this diff - sorry.

diff --git a/src/mod_auth_gssapi.c b/src/mod_auth_gssapi.c
index e233110..3735540 100644
--- a/src/mod_auth_gssapi.c
+++ b/src/mod_auth_gssapi.c
@@ -32,6 +32,9 @@ APLOG_USE_MODULE(auth_gssapi);

 APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *));

+static const char ntlm_oid[] = "\x2b\x06\x01\x04\x01\x82\x37\x02\x02\x0a";
+gss_OID_desc ntlm_mech_oid = { 10, &ntlm_oid };
+
 static char *mag_status(request_rec *req, int type, uint32_t err)
 {
     uint32_t maj_ret, min_ret;
@@ -208,6 +211,7 @@ static int mag_auth(request_rec *req)
 {
     const char *type;
     const char *auth_type;
+    size_t auth_type_len = 0;
     struct mag_config *cfg;
     const char *auth_header;
     char *auth_header_type;
@@ -231,6 +235,8 @@ static int mag_auth(request_rec *req)
     char *clientname;
     gss_OID mech_type = GSS_C_NO_OID;
     gss_buffer_desc lname = GSS_C_EMPTY_BUFFER;
+    gss_buffer_desc mech_buff = GSS_C_EMPTY_BUFFER;
+    bool is_ntlm = false;
     struct mag_conn *mc = NULL;
     bool is_basic = false;
     gss_ctx_id_t user_ctx = GSS_C_NO_CONTEXT;
@@ -301,13 +307,15 @@ static int mag_auth(request_rec *req)
         mag_check_session(req, cfg, &mc);
     }

+    auth_header = apr_table_get(req->headers_in, "Authorization");
+
     if (mc) {
         /* register the context in the memory pool, so it can be freed
          * when the connection/request is terminated */
         apr_pool_userdata_set(mc, "mag_conn_ptr",
                               mag_conn_destroy, mc->parent);

-        if (mc->established) {
+        if (mc->established && !auth_header) {
             ap_log_rerror(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0, req,
                           "Already established context found!");
             apr_table_set(req->subprocess_env, "GSS_NAME", mc->gss_name);
@@ -321,7 +329,6 @@ static int mag_auth(request_rec *req)
         pctx = &ctx;
     }

-    auth_header = apr_table_get(req->headers_in, "Authorization");
     if (!auth_header) goto done;

     auth_header_type = ap_getword_white(req->pool, &auth_header);
@@ -329,7 +336,18 @@ static int mag_auth(request_rec *req)

     if (strcasecmp(auth_header_type, "Negotiate") == 0) {
         auth_type = "Negotiate";
-
+        auth_type_len = 10;
+        auth_header_value = ap_getword_white(req->pool, &auth_header);
+        if (!auth_header_value) goto done;
+        input.length = apr_base64_decode_len(auth_header_value) + 1;
+        input.value = apr_pcalloc(req->pool, input.length);
+        if (!input.value) goto done;
+        input.length = apr_base64_decode(input.value, auth_header_value);
+    } else if ((strcasecmp(auth_header_type, "NTLM") == 0)  &&
+               (cfg->use_ntlm_auth == true)) {
+        auth_type = "NTLM";
+        auth_type_len = 5;
+        is_ntlm = true;
         auth_header_value = ap_getword_white(req->pool, &auth_header);
         if (!auth_header_value) goto done;
         input.length = apr_base64_decode_len(auth_header_value) + 1;
@@ -339,6 +357,7 @@ static int mag_auth(request_rec *req)
     } else if ((strcasecmp(auth_header_type, "Basic") == 0) &&
                (cfg->use_basic_auth == true)) {
         auth_type = "Basic";
+        auth_type_len = 6;
         is_basic = true;

         gss_buffer_desc ba_user;
@@ -468,6 +487,32 @@ static int mag_auth(request_rec *req)
                                 maj, min));
         goto done;
     }
+    /*maj = gss_oid_to_str(&min, mech_type, &mech_buff);
+    if (GSS_ERROR(maj)) {
+        ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, req, "%s",
+                      mag_error(req, "gss_oid_to_str() failed",
+                                maj, min));
+        goto done;
+    }
+    if(mech_buff.length && mech_buff.value)
+        fprintf(stderr, "Mech OID from accept: %.*s\n",
+                mech_buff.length, (char *) mech_buff.value);
+    else
+        fprintf(stderr, "No Mech OID from accept\n");
+    gss_release_buffer(&min, &mech_buff);
+
+    if(is_ntlm) {
+        if(mech_type->length != ntlm_mech_oid.length ||
+            memcmp(mech_type->elements, ntlm_mech_oid.elements, mech_type->length)) {
+            ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, 0, req,
+                          "Not NTLM mech in an NTLM authentication - aborting");
+            gss_delete_sec_context(&min, pctx, GSS_C_NO_BUFFER);
+            gss_release_buffer(&min, &output);
+            output.length = 0;
+            goto done;
+        }
+    } */
+
     if (is_basic) {
         while (maj == GSS_S_CONTINUE_NEEDED) {
             gss_release_buffer(&min, &input);
@@ -561,19 +606,23 @@ static int mag_auth(request_rec *req)
     ret = OK;

 done:
-    if (ret == HTTP_UNAUTHORIZED) {
+    if (ret == HTTP_UNAUTHORIZED || !is_basic) {
         if (output.length != 0) {
             replen = apr_base64_encode_len(output.length) + 1;
-            reply = apr_pcalloc(req->pool, 10 + replen);
+            reply = apr_pcalloc(req->pool, auth_type_len + replen);
             if (reply) {
-                memcpy(reply, "Negotiate ", 10);
-                apr_base64_encode(&reply[10], output.value, output.length);
+                memcpy(reply, auth_type, auth_type_len);
+                reply[auth_type_len -1] = ' ';
+                apr_base64_encode(&reply[auth_type_len], output.value, output.length);
                 apr_table_add(req->err_headers_out,
                               "WWW-Authenticate", reply);
             }
-        } else {
+        } else if (ret == HTTP_UNAUTHORIZED) {
             apr_table_add(req->err_headers_out,
                           "WWW-Authenticate", "Negotiate");
+            if (cfg->use_ntlm_auth)
+                apr_table_add(req->err_headers_out,
+                          "WWW-Authenticate", "NTLM");
             if (cfg->use_basic_auth) {
                 apr_table_add(req->err_headers_out,
                               "WWW-Authenticate",
@@ -784,6 +833,14 @@ static const char *mag_use_basic_auth(cmd_parms *parms, void *mconfig, int on)
     return NULL;
 }

+static const char *mag_use_ntlm_auth(cmd_parms *parms, void *mconfig, int on)
+{
+    struct mag_config *cfg = (struct mag_config *)mconfig;
+
+    cfg->use_ntlm_auth = on ? true : false;
+    return NULL;
+}
+
 static const command_rec mag_commands[] = {
     AP_INIT_FLAG("GssapiSSLonly", mag_ssl_only, NULL, OR_AUTHCFG,
                   "Work only if connection is SSL Secured"),
@@ -809,6 +866,8 @@ static const command_rec mag_commands[] = {
     AP_INIT_FLAG("GssapiBasicAuth", mag_use_basic_auth, NULL, OR_AUTHCFG,
                      "Allows use of Basic Auth for authentication"),
 #endif
+    AP_INIT_FLAG("GssapiNTLMAuth", mag_use_ntlm_auth, NULL, OR_AUTHCFG,
+                     "Allows use of NTML Auth without Negotiate"),
     { NULL }
 };

diff --git a/src/mod_auth_gssapi.h b/src/mod_auth_gssapi.h
index 4cf7d39..9b20b85 100644
--- a/src/mod_auth_gssapi.h
+++ b/src/mod_auth_gssapi.h
@@ -45,6 +45,7 @@ struct mag_config {
     gss_key_value_set_desc *cred_store;
     struct seal_key *mag_skey;
     bool use_basic_auth;
+    bool use_ntlm_auth;
 };

 struct mag_conn {

Windows version

Is it planned to release an Apache for Windows compilable or binary version of mod_auth_gssapi ?

reauths every request when configured with mod_authnz_pam

When mod_auth_gssapi is configured alongside mod_authnz_pam and GssapiUseSessions, the session appears to be ignored and every request requires authentication.

config:

AuthType GSSAPI AuthName "GSSAPI Single Sign On Login" GssapiCredStore keytab:/etc/httpd/rt.keytab GssapiLocalName on GssapiUseSessions On Session On SessionCookieName gssapi_session path=/;httponly;secure; GssapiSessionKey key:{redacted} Require pam-account rtir

Basic auth with NTLM backend

Following the discussion at issue #31 it seem that when only ntlmssp mech is allowed then basic-auth fails although we have code to do gssapi dance if necessary.

I'll collect debugs as soon as master stabilizes as currently NTLM does not work at all for me.

GssapiUseS4U2Proxy fails when falling back to Basic auth

Using the following config atop the master branch @3361a7910e5b934d65ca3cb70aa551dddff69179 with the patch applied from https://github.com/modauthgssapi/mod_auth_gssapi/pull/65, the use of Delegated credentials fails. After the failure, I do see krb5ccache_HTTP and user@REALM ccaches in /run/httpd/clientcaches, and it seems like the user@REALM ccache isn't in place "fast enough" to be used (in this case a PHP application using putenv("KRB5CCNAME={$_SERVER['KRB5CCNAME']}"); connecting to PostgreSQL). The error I receive is GSSAPI continuation error: No credentials cache found Delegated credentials work perfectly in this situation when not falling back to Basic auth (when the browser client already has creds).

GssapiSSLonly On
GssapiBasicAuth On
GssapiAllowedMech krb5

GssapiUseS4U2Proxy On
GssapiCredStore keytab:/etc/httpd/conf/HTTP.keytab
GssapiCredStore client_keytab:/etc/httpd/conf/HTTP.keytab
# The following must be writable by the apache user
GssapiCredStore ccache:FILE:/run/httpd/clientcaches/krb5ccache_HTTP
GssapiDelegCcacheDir /run/httpd/clientcaches

GssapiUseSessions On
Session On
SessionEnv On
SessionCookieName gssapi_session path=/example;domain=example.com;httponly;secure;

Another strange thing happens in the above scenario... I get the following SELinux AVC:

SELinux is preventing /usr/sbin/httpd from read access on the key Unknown.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that httpd should be allowed read access on the Unknown key by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                system_u:system_r:gssd_t:s0
Target Objects                Unknown [ key ]
Source                        httpd
Source Path                   /usr/sbin/httpd
Port                          <Unknown>
Host                          host.example.com
Source RPM Packages           httpd-2.4.18-1.fc23.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-158.4.fc23.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     host.example.com
Platform                      Linux host.example.com 4.3.5-300.fc23.x86_64
                              #1 SMP Mon Feb 1 03:18:41 UTC 2016 x86_64 x86_64
Alert Count                   20
First Seen                    2016-02-12 19:28:12 CST
Last Seen                     2016-02-12 19:58:27 CST
Local ID                      9377811c-f5ac-4605-9642-8f00b2e3ea78

Raw Audit Messages
type=AVC msg=audit(1455328707.588:7791): avc:  denied  { read } for  pid=6026 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:gssd_t:s0 tclass=key permissive=1


type=SYSCALL msg=audit(1455328707.588:7791): arch=x86_64 syscall=keyctl success=yes exit=ECHILD a0=b a1=1d86e34c a2=0 a3=0 items=0 ppid=3799 pid=6026 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)

Hash: httpd,httpd_t,gssd_t,key,read

Basic auth failed

@simo5 i figure out delegation credentials now i am stuck with fallback basic auth not working :/ Still getting 401 even if i use correct username and password:/

Apache2 config

<VirtualHost *:80>
    ServerName  kerberos.mywork.merck.com
        ServerAlias 54.40.221.55

    ServerAdmin [email protected]
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

 RewriteEngine On

 RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
 RewriteRule ^/(.*)$ balancer://upstream%{REQUEST_URI} [P,QSA,L]

     <Location />
    AuthType GSSAPI
    AuthName "Login"
    Require valid-user

    GssapiUseS4U2Proxy On
    GssapiCredStore keytab:/etc/apache2/kerberos.mywork.service.keytab
    GssapiCredStore client_keytab:/etc/apache2/kerberos.mywork.service.keytab
    GssapiDelegCcacheDir /home/admin
    GssapiBasicAuth On
    RequestHeader set REMOTE_USER %{REMOTE_USER}s
    RequestHeader set AUTH_TYPE %{AUTH_TYPE}s
    RequestHeader set KRB5CCNAME %{KRB5CCNAME}s
</Location>

<Proxy balancer://upstream>
  BalancerMember http://0.0.0.0:9999
 </Proxy>

 ProxyRequests Off
 ProxyVia On
 ProxyPreserveHost On

 <Proxy *>
  Require all granted
 </Proxy>

 <Directory /var/www/html>
  Options -MultiViews
  Require all granted
 </Directory>

</VirtualHost>

Local klist -f -> verify that i do not have ticket

klist -f
Credentials cache: API:1C2F03F8-3ECC-4EE4-B82E-F616A881F691
        Principal: [email protected]

  Issued    Expires  Flags    Principal

Curl to server:

curl --verbose -u <username>:<password> http://kerberos.mywork.merck.com
* Adding handle: conn: 0x7fec40804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fec40804000) send_pipe: 1, recv_pipe: 0
* About to connect() to kerberos.mywork.merck.com port 80 (#0)
*   Trying 54.40.222.179...
* Connected to kerberos.mywork.merck.com (54.40.222.179) port 80 (#0)
* Server auth using Basic with user '<username>'
> GET / HTTP/1.1
> Authorization: Basic PHVzZXJuYW1lPjo8cGFzc3dvcmQ+
> User-Agent: curl/7.30.0
> Host: kerberos.mywork.merck.com
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Content-Type: text/html; charset=iso-8859-1
< Date: Mon, 11 May 2015 20:01:13 GMT
* Server Apache/2.4.10 (Debian) is not blacklisted
< Server: Apache/2.4.10 (Debian)
< WWW-Authenticate: Negotiate
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="Login"
< Content-Length: 472
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.4.10 (Debian) Server at kerberos.mywork.merck.com Port 80</address>
</body></html>
* Connection #0 to host kerberos.mywork.merck.com left intact

Apache2 - Access log

54.40.222.179 - - [11/May/2015:20:01:13 +0000] "GET / HTTP/1.1" 401 760 "-" "curl/7.30.0"

Apache2 - Error log

[Mon May 11 20:01:13.248338 2015] [auth_gssapi:error] [pid 13516] [client 54.40.222.179:3540] gss_init_sec_context() failed: [Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)]

NTLM stopped working

In the last changes we managed to break NTLM (both raw and negotiate).

When the client sends the second request with the challenge response we fail to accept the context with:

[Tue Jun 16 21:40:07.857590 2015] [auth_gssapi:error] [pid 8818] [client 10.0.0.250:37686] gss_accept_sec_context() failed: [Invalid credential was supplied (Not a user credential type)]

Maybe related to 'mc' cleanup or to changes related to credentials acquirement ( testing without cred_store).
Perhaps we should keep the acquired credentials with the context on 'mc' and release it along as well.

Set KRB5CCNAME when enabling GssapiUseS4U2Proxy and GssapiUseSessions

In order to have true GSSAPI SSO and reap the benefits of GssapiUseSessions, it would be helpful to have the KRB5CCNAME environment variable set when successful authentication occurred via GssapiUseSessions. In this way, PHP (and other processors) can make use of the delegated credentials to query PostgreSQL (and other applications).

Right now, it appears that KRB5CCNAME is set on the first retrieval, but when Already established context found! occurs, we get something like PHP Notice: Undefined index: KRB5CCNAME... so there is no way (yet) to employ GssapiUseSessions and pass delegated credentials on subsequent requests.

Chrome 42 on Windows 7 with Basic Auth: gss_accept_sec_context() failed: [No credentials were supplied, or the credentials were unavailable or inaccessible (Unknown error)]

When a Chrome 42.0.2311.135 browser on Windows 7 (Enterprise, 64-bit, build 7601) tries to use Basic Authentication against an Apache 2.4.10-10 (Debian 8 "Jessie") server with mod_auth_gssapi 1.2.0, authentication will fail and the server will log:

gss_accept_sec_context() failed: [No credentials were supplied, or the credentials were unavailable or inaccessible (Unknown error)]

I verified the issue on one of our user's computers, as well as in an own virtual machine.

The problem does not occur with Chrome 41 on Ubuntu 14.04, not with Firefox (any version) on Windows, Linux or Mac, and neither with Safari on iOS or MacOSX (after installing gss-ntlmssp 0.6.0).

Allow username/password authentication

mod_auth_kerb allowed authenticating with username/password via HTTP basic authentication, if the browser did not support the negotiate mechanism. This support seems to be lacking in mod_auth_gssapi.

Support for this is a prerequisite for issue #8 (Fallback to AuthBasicProviders).

mod_auth_gssapi unconditionally includes gssapi/gssapi_ntlmssp.h

In my installation on Debian 8 there is no gssapi/gssapi_ntlmssp.h, still mod_auth_gssapi tries to include it in mod_auth_gssapi.h line 9.

I tried both v1.2.0 and v1.3.0 - both are affected. HEAD should be affected as well, since there were not related changes.

Error message:

/usr/share/apr-1.0/build/libtool --no-silent  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I.  -Iasn1c  -pipe -g -O2 -fstack-protector-strong -Wformat -Werror=format-security  -DLINUX -D_REENTRANT -D_GNU_SOURCE    -pthread -isystem /usr/include/mit-krb5  -I/usr/include/apache2  -I/usr/include/apr-1.0  -g -O2 -MT mod_auth_gssapi_la-mod_auth_gssapi.lo -MD -MP -MF .deps/mod_auth_gssapi_la-mod_auth_gssapi.Tpo -c -o mod_auth_gssapi_la-mod_auth_gssapi.lo `test -f 'mod_auth_gssapi.c' || echo './'`mod_auth_gssapi.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Iasn1c -pipe -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -isystem /usr/include/mit-krb5 -I/usr/include/apache2 -I/usr/include/apr-1.0 -g -O2 -MT mod_auth_gssapi_la-mod_auth_gssapi.lo -MD -MP -MF .deps/mod_auth_gssapi_la-mod_auth_gssapi.Tpo -c mod_auth_gssapi.c  -fPIC -DPIC -o .libs/mod_auth_gssapi_la-mod_auth_gssapi.o
In file included from mod_auth_gssapi.c:25:0:
mod_auth_gssapi.h:9:35: fatal error: gssapi/gssapi_ntlmssp.h: No such file or directory
 #include <gssapi/gssapi_ntlmssp.h>
                                   ^
compilation terminated.
Makefile:481: recipe for target 'mod_auth_gssapi_la-mod_auth_gssapi.lo' failed

Dockerfile to reproduce:

FROM debian:8
MAINTAINER ...
ENV DEBIAN_FRONTEND noninteractive

VOLUME /export

RUN apt-get -y update && apt-get -y install build-essential autoconf libtool pkg-config apache2-dev libkrb5-dev libssl-dev

ADD mod_auth_gssapi mod_auth_gssapi

RUN cd mod_auth_gssapi && mkdir m4 && autoreconf -fi && ./configure && make && make DESTDIR=/export install

Saving of Credentials and Basic Authentication

As suggested by @Frenche in #69, the discussion is moved here:

I think the discussion of which kind of credentials we want to save in basic-auth should be moved to another issue.
In general, in basic-auth we have the following options:

  • Store user's TGT acquired with password as mod_auth_kerb does.
  • Store user's TGT delegated via regular delegation as mod_auth_gssapi does today.
  • Store constrained delegated credentials only when S4U2Proxy is available.

Note that the two first should be equivalent, that is why PHP's PDO failure is strange.
We know the ccache is good before calling PHP's PDO and we know it is good after the script runs (as you can run 'klist' on it or run the ldapsearch command from CLI after the script has run).

Maybe for some reason, PHP's PDO tries to read another ccache file although KRB5CCNAME points to the correct one (maybe strace could help, but it isn't easy).

For my situation described in #69, I'm looking for the end-user functionality that mod_auth_kerb provides: the ability to fallback to Basic auth and save the credentials in a way that they can be used for further access to downstream systems (PostgreSQL, LDAP, etc.). This is something like the first option above.

Can't install on Red Hat 6.7 (Santiago)

I have Redhat 6.7 (Santiago) and I tried to install this module by:

  1. installing autoconf (2.69)
  2. autoconf
  3. ./configure - and on this I get error:

./configure: line 2220: syntax error near unexpected token -Wall' ./configure: line 2220:AM_INIT_AUTOMAKE(-Wall foreign subdir-objects tar-pax)'

Fall-back to LDAP

I see a few references to falling back to basic, but if I understand correctly that just means to prompt for user/password but it still uses gssapi.

How could I fall-back to an authentication type other than gssapi (LDAP) for some clients who are coming from workstations in a heavily restricted external AD domain that can't do kerberos with me for reasons.

AH00027: No authentication done but request not allowed without authentication for /test/index.php. Authentication not configured?

Using:
httpd-2.4.10-15.fc21.x86_64
mod_auth_gssapi-1.1.0-2.fc21.x86_64
mod_auth_kerb-5.4-30.fc21.x86_64

There seems to be a difference between how mod_auth_kerb and mod_auth_gssapi process path determination and authentication/authorization within Apache. Using the snippet from ssl.conf below, browsing to https://example.com/test/ authenticates properly, but if you uncomment the mod_auth_gssapi-related directives, and comment the mod_auth_kerb-related directives, Apache will generate a 500 Internal Server Error: AH00027: No authentication done but request not allowed without authentication for /test/index.php. Authentication not configured?

Alias /test /var/www/test
<Directory /var/www/test>
  SSLRequireSSL
  AllowOverride None
  Options None


#  AuthType GSSAPI
#  AuthName "GSSAPI Single Sign On Login"
#  GssapiSSLonly On
#  GssapiUseS4U2Proxy On
#  GssapiCredStore keytab:/etc/httpd/conf/HTTP.keytab
#  GssapiCredStore client_keytab:/etc/httpd/conf/HTTP.keytab
#  GssapiCredStore ccache:FILE:/run/httpd/krb5ccache
#  GssapiDelegCcacheDir /run/httpd/clientcaches

  AuthType Kerberos
  AuthName "Kerberos Single Sign On Login"
  KrbAuthoritative On
  KrbAuthRealms EXAMPLE.COM
  KrbConstrainedDelegation On
  KrbMethodK5Passwd Off
  KrbMethodNegotiate On
  KrbSaveCredentials On
  KrbServiceName HTTP/example.com

# Comment the following if using gss-proxy (which doesn't work with KrbConstrainedDelegation)
  Krb5Keytab /etc/httpd/conf/HTTP.keytab

  <RequireAll>
    Require valid-user
    Require ip 10.1.1.0/24 2001:db8:0::/64
  </RequireAll>
</Directory>

Fallback to AuthBasicProviders

I am searching for a way to fallback to AuthBasicProviders if the user is unknown to mod_auth_gssapi. In particular I want to use the Redmine PerlAuthenHandler, which is somehow hooked into the AuthBasicProvider list by mod_perl2.

It seems that currently both mod_auth_basic as well as mod_auth_gssapi prohibit this by declining authentication if the configured AuthType does not match. From a naive point of view implementing fallback from GSSAPI to Basic appears to be easy, though: If there is no Kerberos ticket, mod_auth_gssapi has to fallback to WWW-Authenticate: Basic anyway, so if the user it gets is unknown, it could just pass on the user/password to mod_auth_basic and its registered AuthBasicProviders.

To give you a better idea of my situation, here is (part of) my config:

PerlLoadModule Apache::Authn::RedmineAuthOnly

<IfModule mod_ssl.c>
        <VirtualHost *:443>
                ServerAdmin ???
                ServerName ???
                DocumentRoot /usr/share/redmine/public

                ErrorLog ${APACHE_LOG_DIR}/error.???.log
                CustomLog ${APACHE_LOG_DIR}/access.???.log combined

                <Location />
                        AuthName "???"

                        AuthType GSSAPI

                        GssapiCredStore keytab:/etc/apache2/http.keytab

                        GssapiConnectionBound On
                        Header set Persistent-Auth "true"

                        GssapiUseSessions On
                        Session On
                        SessionCookieName gssapi_session path=/;httponly;secure;

#                       AuthType Basic
#                       AuthUserFile /dev/null
#                       PerlAccessHandler Apache::Authn::RedmineAuthOnly::access_handler
#                       PerlAuthenHandler Apache::Authn::RedmineAuthOnly::authen_handler

                        RedmineDSN "DBI:mysql:database=???;host=localhost"
                        RedmineDbUser "???"
                        RedmineDbPass "???"

                        Require valid-user
                </Location>

Processing order of authentication rules

In the Apache docs it is mentioned :
By default all Require directives are handled as though contained within a container directive. In other words, if any of the specified authorization methods succeed, then authorization is granted.

But it seems different for mod_auth_gssapi.

For example, in my httpd.conf file I authorize 'all' to access error pages :

Alias /error/ "/instance/kerb/apache_2.4/error/"
<IfModule mod_negotiation.c>
        <IfModule mod_include.c>
                <Directory "/appli/projects/kerb/apache_2.4/error/">
                        AllowOverride None
                        Options IncludesNoExec
                        AddOutputFilter Includes html
                        AddHandler type-map var
                        Require all granted
                        LanguagePriority fr en cs de es it nl sv pt-br ro
                        ForceLanguagePriority Prefer Fallback
                </Directory>

                ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var
                ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var
                ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var
                ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var
                ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var
                ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var
                ErrorDocument 410 /error/HTTP_GONE.html.var
                ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var
                ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var
                ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var
                ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var
                ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var
                ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var
                ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var
                ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var
                ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var
                ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var
        </IfModule>
</IfModule>

Then in my vhosts, I add GSSAPI authentication :

        <Location />
                AuthName "GSSAPI Single Sign On Login"
                AuthType GSSAPI
                GssapiCredStore keytab:/instance/kerb/apache_2.4/conf/krb5.keytab
                Require valid-user
        </Location>

Then, when accessing a wrong URL, I didn't obtain my custom 'HTTP 404' error page.

Here is the logs :

[Mon Oct 13 18:25:43.133200 2014] [authz_core:debug] [pid 9554] mod_authz_core.c(802): [client 10.151.27.181:52141] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.133228 2014] [authz_core:debug] [pid 9554] mod_authz_core.c(802): [client 10.151.27.181:52141] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.133239 2014] [:info] [pid 9554] [client 10.151.27.181:52141] Sessions not available, no cookies!
[Mon Oct 13 18:25:43.133331 2014] [authz_core:debug] [pid 9554] mod_authz_core.c(802): [client 10.151.27.181:52141] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.133339 2014] [authz_core:debug] [pid 9554] mod_authz_core.c(802): [client 10.151.27.181:52141] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.133345 2014] [core:error] [pid 9554] [client 10.151.27.181:52141] AH00027: No authentication done but request not allowed without authentication for /error/HTTP_UNAUTHORIZED.html.var. Authentication not configured?
[Mon Oct 13 18:25:43.186508 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.186534 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.186546 2014] [:info] [pid 9540] [client 10.151.27.181:52142] Sessions not available, no cookies!
[Mon Oct 13 18:25:43.188821 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of Require valid-user : granted
[Mon Oct 13 18:25:43.189426 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of <RequireAny>: granted
[Mon Oct 13 18:25:43.189808 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.189868 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.189911 2014] [core:error] [pid 9540] [client 10.151.27.181:52142] AH00027: No authentication done but request not allowed without authentication for /content-negotiation.html/foo. Authentication not configured?
[Mon Oct 13 18:25:43.189977 2014] [negotiation:error] [pid 9540] [client 10.151.27.181:52142] AH00687: Negotiation: discovered file(s) matching request: /instance/kerb/apache_2.4/htdocs/kerb/content-negotiation (None could be negotiated).
[Mon Oct 13 18:25:43.190120 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.190463 2014] [authz_core:debug] [pid 9540] mod_authz_core.c(802): [client 10.151.27.181:52142] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.190521 2014] [core:error] [pid 9540] [client 10.151.27.181:52142] AH00027: No authentication done but request not allowed without authentication for /error/HTTP_NOT_FOUND.html.var. Authentication not configured?
[Mon Oct 13 18:25:43.341182 2014] [authz_core:debug] [pid 9584] mod_authz_core.c(802): [client 10.151.27.181:52143] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.341210 2014] [authz_core:debug] [pid 9584] mod_authz_core.c(802): [client 10.151.27.181:52143] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.341221 2014] [:info] [pid 9584] [client 10.151.27.181:52143] Sessions not available, no cookies!
[Mon Oct 13 18:25:43.341304 2014] [authz_core:debug] [pid 9584] mod_authz_core.c(802): [client 10.151.27.181:52143] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.341312 2014] [authz_core:debug] [pid 9584] mod_authz_core.c(802): [client 10.151.27.181:52143] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.341318 2014] [core:error] [pid 9584] [client 10.151.27.181:52143] AH00027: No authentication done but request not allowed without authentication for /error/HTTP_UNAUTHORIZED.html.var. Authentication not configured?
[Mon Oct 13 18:25:43.367737 2014] [authz_core:debug] [pid 9565] mod_authz_core.c(802): [client 10.151.27.181:52144] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Mon Oct 13 18:25:43.367801 2014] [authz_core:debug] [pid 9565] mod_authz_core.c(802): [client 10.151.27.181:52144] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Mon Oct 13 18:25:43.367814 2014] [:info] [pid 9565] [client 10.151.27.181:52144] Sessions not available, no cookies!
[Mon Oct 13 18:25:43.380333 2014] [authz_core:debug] [pid 9565] mod_authz_core.c(802): [client 10.151.27.181:52144] AH01626: authorization result of Require valid-user : granted
[Mon Oct 13 18:25:43.380451 2014] [authz_core:debug] [pid 9565] mod_authz_core.c(802): [client 10.151.27.181:52144] AH01626: authorization result of <RequireAny>: granted

For info, I don't have this behaviour with other authentication modules like mod_auth_kerb or mod_auth_basic.

Login with Safari fails: gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)]

A user of ours has an issue where he cannot login using his Safari browser.

He receives the message that authentication failed, while the server logs:

gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)]

This happens with Safari 8.0.3 on Mac OS X 10.10.2 and iOS 8.2 as well:

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/600.3.18 (KHTML, like Gecko) Version/8.0.3 Safari/600.3.18"
"Mozilla/5.0 (iPhone; CPU iPhone OS 8_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12D508 Safari/600.1.4"

Our config is:

                        AuthType GSSAPI

                        GssapiCredStore keytab:/etc/apache2/http.keytab
                        GssapiCredStore ccache:MEMORY:user_ccache

                        GssapiBasicAuth On

                        GssapiConnectionBound On
                        Header set Persistent-Auth "true"

                        GssapiUseSessions On
                        Session On
                        SessionCookieName gssapi_session path=/;httponly;secure;

The same issue happens with mod-auth-kerb-5.4 (5.4-2.2 on Debian 8 "Jessie"), so this is probably not a bug in mod-auth-gssapi, but a misconfiguration. To fix it, I need your support.

P.S: Other browsers, like Chrome and Firefox on the same operating system (Mac OS X) are unaffected. These browsers are also known to be not affected on Linux (various distributions). I have not tested with IE or on Windows so far.

The service name is a CNAME for the server hostname. That hostname then resolves to an A record, which has a proper PTR reverse record setup.

Send final token (if any) in 200 OK response

Hi Simo,

In some cases the client may want to inquire the context with 'gss_inquire_context' in order to get the 'src_name' of the initiator.
However, according to the spec (rfc2743) 'src_name' is valid only when 'open' (returned param) is true, meaning only when the context is fully established.

According to several tests I've made, in some flows the server still has a last token to send when 'gss_accept_sec_context' returns 'GSS_S_COMPLETE'.
Specifically it happens when SPNEGO mech is used or when raw KRB5 is used and 'mutual_auth' is requested.

With IIS, this last token is conveyed to the client via an "WWW-Authenticate: Negotiate" header sent in the 200 OK response.
This allows the client to fully establish the security context and initiator's 'src_name' can be inquired.

This one liner patch below fixes it for me:

diff --git a/src/mod_auth_gssapi.c b/src/mod_auth_gssapi.c
index e233110..ea989b1 100644
--- a/src/mod_auth_gssapi.c
+++ b/src/mod_auth_gssapi.c
@@ -561,7 +561,7 @@ static int mag_auth(request_rec *req)
     ret = OK;

 done:
-    if (ret == HTTP_UNAUTHORIZED) {
+    if (!is_basic) {
         if (output.length != 0) {
             replen = apr_base64_encode_len(output.length) + 1;
             reply = apr_pcalloc(req->pool, 10 + replen);

Option to Specify SPN to use (or 'Any')

I've moved from mod_auth_kerb to mod_auth_gssapi in a project I'm working on, and it works very well. Thank you.

However, it only works when the website is accessed via http://hostname/ or http://fqdn/. I assume the SPN is being picked up from the address used to access the site, and this isn't always the case, e.g. it could be accessed via http://www.alias.com/ - in which case currently authentication fails.

With mod_auth_kerb I could use the option KrbServiceName to specify which SPN to use, e.g.

KrbServiceName HTTP/hostname

Or even better was

KrbServiceName Any

Is it possible to implement something similar in mod_auth_gssapi?

Or... is it possible to tell Apache which SPN to use? I thought setting ServerName may work, but it appears not to.

Reset auth when client send Authorization header.

Or as Simo put it: "Forcibly reset credentials on client request".

Currently, with IIS, when the client sends a new Authorization header on an
already authenticated connection (either NTLM or when Persistent-Auth
is set to true) then the server restart the authentication and the
client will be served according to the new one.
However, with mod_auth_gssapi if the connection is authenticated the
server ignores it and serves the client by previous auth.

Some client implementations treat negotiate as purely request-based
auth and might therefore mix requests from different identities over
the same connection.
So it appears IIS behavior is more graceful in this case and maybe
worth adapting.

Something like:

--- a/src/mod_auth_gssapi.c
+++ b/src/mod_auth_gssapi.c
@@ -301,7 +301,9 @@ static int mag_auth(request_rec *req)
         mag_check_session(req, cfg, &mc);
     }

-    if (mc) {
+    auth_header = apr_table_get(req->headers_in, "Authorization");
+
+    if (mc && !auth_header) {
         /* register the context in the memory pool, so it can be freed
          * when the connection/request is terminated */
         apr_pool_userdata_set(mc, "mag_conn_ptr",
@@ -321,7 +323,6 @@ static int mag_auth(request_rec *req)
         pctx = &ctx;
     }

-    auth_header = apr_table_get(req->headers_in, "Authorization");
     if (!auth_header) goto done;

     auth_header_type = ap_getword_white(req->pool, &auth_header);

Installation error

I have a CentOS 7 and i cannot install mod_auth_gssapi.

first, in the README you don't mention which packets we have to install to compile the module and that we have to use autoconf before ./configure.

Then when I use autoconf command I have these errros :
configure.ac:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:12: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:16: error: possibly undefined macro: AM_CONDITIONAL

How can I fix it please ?

Segmentation fault with Basic auth when KRB5_KTNAME file does not exist

Hi,

While trying to prove my point about issue #31 I ran into this crash.

I'm testing with pull #33 code, not using cred_store and the file pointed by KRB5_KTNAME doesn't exist.
When I try to access with Basic auth I get the below (I was expecting it to fail but not this way ;-)

Program received signal SIGSEGV, Segmentation fault.
0xb6d55ac1 in krb5_gss_internal_release_oid (minor_status=0xbfffef78, oid=0x0) at rel_oid.c:65
65          if ((*oid != gss_mech_krb5) &&
(gdb) bt
#0  0xb6d55ac1 in krb5_gss_internal_release_oid (minor_status=0xbfffef78, oid=0x0) at rel_oid.c:65
#1  0xb6d392db in gss_release_oid (minor_status=minor_status@entry=0xbfffef78, oid=oid@entry=0x0) at g_initialize.c:188
#2  0xb6d3a998 in gss_inquire_name (minor_status=minor_status@entry=0xbffff034, name=name@entry=0x8021f3b0, name_is_MN=name_is_MN@entry=0x0,
    MN_mech=MN_mech@entry=0x0, attrs=attrs@entry=0xbffff03c) at g_inq_name.c:82
#3  0xb6d5d758 in spnego_gss_inquire_name (minor_status=0xbffff034, name=0x8021f3b0, name_is_MN=0x0, MN_mech=0x0, attrs=0xbffff03c) at spnego_mech.c:2641
#4  0xb6d32a35 in import_internal_attributes (dmech=0x8021d028, sname=0x8021f9e0, sname=0x8021f9e0, dname=0x802230b8, minor=0xbffff034) at g_glue.c:311
#5  gssint_import_internal_name (minor_status=minor_status@entry=0xbffff1dc, mech_type=0x8021d028, union_name=union_name@entry=0x8021f9e0,
    internal_name=internal_name@entry=0xbffff0f4) at g_glue.c:400
#6  0xb6d3443a in gss_init_sec_context (minor_status=minor_status@entry=0xbffff1dc, claimant_cred_handle=0x8021dd00,
    context_handle=context_handle@entry=0xbffff1e8, target_name=0x8021f9e0, req_mech_type=req_mech_type@entry=0x0, req_flags=req_flags@entry=0,
    time_req=time_req@entry=300, input_chan_bindings=input_chan_bindings@entry=0x0, input_token=input_token@entry=0xbffff200,
    actual_mech_type=actual_mech_type@entry=0x0, output_token=output_token@entry=0xbffff1f8, ret_flags=ret_flags@entry=0x0, time_rec=time_rec@entry=0x0)
    at g_init_sec_context.c:167
#7  0xb6ef6758 in mag_auth (req=0x80219070) at mod_auth_gssapi.c:548
#8  0x80030386 in ap_run_check_user_id (r=r@entry=0x80219070) at request.c:80
#9  0x80033d29 in ap_process_request_internal (r=r@entry=0x80219070) at request.c:244
#10 0x80053278 in ap_process_async_request (r=r@entry=0x80219070) at http_request.c:315
#11 0x80053412 in ap_process_request (r=r@entry=0x80219070) at http_request.c:363
#12 0x8004f72f in ap_process_http_sync_connection (c=0x80210d18) at http_core.c:190
#13 ap_process_http_connection (c=0x80210d18) at http_core.c:231
#14 0x800462c6 in ap_run_process_connection (c=0x80210d18) at connection.c:41
#15 0x8004674f in ap_process_connection (c=c@entry=0x80210d18, csd=0x80210b80) at connection.c:203
#16 0xb76aeecb in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:707
#17 0xb76af115 in make_child (s=0x800a7dd8, slot=slot@entry=0) at prefork.c:749
#18 0xb76b0091 in prefork_run (_pconf=0x800830c8, plog=0x800a99c0, s=0x800a7dd8) at prefork.c:966
#19 0x8001db9e in ap_run_mpm (pconf=0x800830c8, plog=0x800a99c0, s=0x800a7dd8) at mpm_common.c:94
#20 0x80015fdb in main (argc=2, argv=0xbffff7a4) at main.c:777

Problem with DirectoryIndex

Hi!

I want to restrict access to a virtual host with mod_auth_gssapi. The problem is, that if I enable the authentication the default index.php is not provided anymore. Following messages show up in the -error.log:

[Thu Apr 02 23:26:07.535887 2015] [core:error] [pid 22578] [client 192.168.12.198:56044] AH00027: No authentication done but request not allowed without authentication for /index.php. Authentication not configured?
[Thu Apr 02 23:26:07.536216 2015] [core:error] [pid 22578] [client 192.168.12.198:56044] AH00027: No authentication done but request not allowed without authentication for /index.phtml. Authentication not configured?
[Thu Apr 02 23:26:07.536343 2015] [core:error] [pid 22578] [client 192.168.12.198:56044] AH00027: No authentication done but request not allowed without authentication for /index.html. Authentication not configured?

If I call index.php directly, everything works fine. Also if I disable authentication the DirectoryIndex works as expected.

Here's my vhost-config:

<VirtualHost ttrss.example.com:80>
             ServerName ttrss.example.com
             ServerAlias ttrss
             Redirect permanent / https://ttrss.example.com
</VirtualHost>

<VirtualHost ttrss.example.com:443>
    ServerName ttrss.example.com
    ServerAlias ttrss
    ServerAdmin [email protected]

    SSLEngine on
    SSLCertificateFile "/etc/httpd/conf/server.crt"
    SSLCertificateKeyFile "/etc/httpd/conf/server.key"

    ErrorLog "/var/log/httpd/ttrss.example.com-error_log"
    CustomLog "/var/log/httpd/ttrss.example.com-access_log" common

    DocumentRoot "/srv/http.ttrss.example.com"

    <Directory "/srv/http.ttrss.example.com">
               AuthType GSSAPI
               AuthName "Single Sign On Login"
               GssapiCredStore keytab:/etc/httpd/conf/vhosts/ttrss.example.com.keytab
               GssapiSSLonly On
               GssapiBasicAuth On
               Require valid-user
    </Directory>
    <Location /api>
              Allow from all
              Satisfy Any
    </Location>
</VirtualHost>

Openssl 1.1.0 api break

OpenSSL is breaking the API with 1.1
Requires adding compatibility code to be able to compile against either version.

Log format headers doesn't include the module name

Hello,

On Apache 2.4, it seems that all log trace contains the module name like that : [module_name:loglevel]

But for mod_auth_gssapi, we only have : [:loglevel]

Example:

[Mon Oct 13 12:17:01.066614 2014] [authz_core:debug] [pid 3726] mod_authz_core.c(802): [client 10.151.27.181:46888] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.066704 2014] [:info] [pid 3726] [client 10.151.27.181:46888] Session key not available, no cookies!, referer: http://jpa.com/configuring.html

Module does not support multi-trip GSS authentication?

We've just tried to use this module with a GSSAPI mechanism that uses multiple roundtrips for authentication. This apparently segfaults. Can you confirm whether the module supports multiple roundtrips for GSSAPI authentication (as opposed to Kerberos, which requires only one round trip)?

apxs error with headers in non standard paths

I had some problems to compile mod_auth_gssapi for Apache 2.4.10 and lib Krb5, Openssl in specific directories.

Making all in src
make[1]: Entering directory /test/build/mod_auth_gssapi-1.0.2/src' make all-am make[2]: Entering directory/test/build/mod_auth_gssapi-1.0.2/src'
/soft/http/2.4.10/bin/apxs -c /soft/http/2.4.10/libs/apr/libs/libapr-1.la -lrt -lcrypt -lpthread -L/soft/http/2.4.10/libs/krb5/lib -L/soft/http/2.4.10/libs/openssl/lib -L/soft/http/2.4.10/libs/krb5/lib -L/lib -Wl,-rpath,/soft/http/2.4.10/libs/openssl/lib -Wl,-rpath,/soft/http/2.4.10/libs/krb5/lib -Wl,-rpath,/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -L/soft/http/2.4.10/libs/openssl/lib -lssl -lcrypto -O2 -Wall -march=nocona -fPIC -pthread -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/include -I -I/soft/http/2.4.10/libs/apr/include/apr-1 mod_auth_gssapi.c sessions.c crypto.c
/soft/http/2.4.10/libs/apr/build-1/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -O2 -Wall -march=nocona -fPIC -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/soft/http/2.4.10/include -I/soft/http/2.4.10/libs/apr/include/apr-1 -I/soft/http/2.4.10/libs/apr-util/include/apr-1 -I/soft/http/2.4.10/libs/openldap/include/ -I/soft/http/2.4.10/libs/expat/include -c -o mod_auth_gssapi.lo mod_auth_gssapi.c && touch mod_auth_gssapi.slo
In file included from mod_auth_gssapi.c:25:
mod_auth_gssapi.h:6:27: error: gssapi/gssapi.h: No such file or directory
mod_auth_gssapi.h:7:31: error: gssapi/gssapi_ext.h: No such file or directory
[...]
mod_auth_gssapi.c:508: error: 'struct mag_config' has no member named 'cred_store'
mod_auth_gssapi.c:516: error: 'struct mag_config' has no member named 'cred_store'
apxs:Error: Command failed with rc=65536

After this modification in "src/Makefile.am"
'- @apxs@ -c ${LIBS} ${CFLAGS} mod_auth_gssapi.c sessions.c crypto.c
'+ @apxs@ -c ${CPPFLAGS} ${LIBS} ${CFLAGS} mod_auth_gssapi.c sessions.c crypto.c

And this in "src/Makefile.in"
'- @apxs@ -c ${LIBS} ${CFLAGS} mod_auth_gssapi.c sessions.c crypto.c
'+ @apxs@ -c ${CPPFLAGS} ${LIBS} ${CFLAGS} mod_auth_gssapi.c sessions.c crypto.c

It went fine

Making all in src
make[1]: Entering directory /test/build/mod_auth_gssapi-1.0.2/src' make all-am make[2]: Entering directory/test/build/mod_auth_gssapi-1.0.2/src'
/soft/http/2.4.10/bin/apxs -c -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/apr/include /soft/http/2.4.10/libs/apr/libs/libapr-1.la -lrt -lcrypt -lpthread -L/soft/http/2.4.10/libs/krb5/lib -L/soft/http/2.4.10/libs/openssl/lib -L/soft/http/2.4.10/libs/krb5/lib -L/lib -Wl,-rpath,/soft/http/2.4.10/libs/openssl/lib -Wl,-rpath,/soft/http/2.4.10/libs/krb5/lib -Wl,-rpath,/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -L/soft/http/2.4.10/libs/openssl/lib -lssl -lcrypto -O2 -Wall -march=nocona -fPIC -pthread -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/include -I -I/soft/http/2.4.10/libs/apr/include/apr-1 mod_auth_gssapi.c sessions.c crypto.c
/soft/http/2.4.10/libs/apr/build-1/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -O2 -Wall -march=nocona -fPIC -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/soft/http/2.4.10/include -I/soft/http/2.4.10/libs/apr/include/apr-1 -I/soft/http/2.4.10/libs/apr-util/include/apr-1 -I/soft/http/2.4.10/libs/openldap/include/ -I/soft/http/2.4.10/libs/expat/include -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/apr/include -c -o mod_auth_gssapi.lo mod_auth_gssapi.c && touch mod_auth_gssapi.slo
/soft/http/2.4.10/libs/apr/build-1/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -O2 -Wall -march=nocona -fPIC -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/soft/http/2.4.10/include -I/soft/http/2.4.10/libs/apr/include/apr-1 -I/soft/http/2.4.10/libs/apr-util/include/apr-1 -I/soft/http/2.4.10/libs/openldap/include/ -I/soft/http/2.4.10/libs/expat/include -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/apr/include -c -o sessions.lo sessions.c && touch sessions.slo
/soft/http/2.4.10/libs/apr/build-1/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -O2 -Wall -march=nocona -fPIC -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/soft/http/2.4.10/include -I/soft/http/2.4.10/libs/apr/include/apr-1 -I/soft/http/2.4.10/libs/apr-util/include/apr-1 -I/soft/http/2.4.10/libs/openldap/include/ -I/soft/http/2.4.10/libs/expat/include -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/apr/include -c -o crypto.lo crypto.c && touch crypto.slo
/soft/http/2.4.10/libs/apr/build-1/libtool --silent --mode=link gcc -std=gnu99 -o mod_auth_gssapi.la -rpath /soft/http/2.4.10/modules -module -avoid-version crypto.lo sessions.lo mod_auth_gssapi.lo /soft/http/2.4.10/libs/apr/libs/libapr-1.la -lrt -lcrypt -lpthread -L/soft/http/2.4.10/libs/krb5/lib -L/soft/http/2.4.10/libs/openssl/lib -L/soft/http/2.4.10/libs/krb5/lib -L/lib -Wl,-rpath,/soft/http/2.4.10/libs/openssl/lib -Wl,-rpath,/soft/http/2.4.10/libs/krb5/lib -Wl,-rpath,/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -L/soft/http/2.4.10/libs/openssl/lib -lssl -lcrypto -O2 -Wall -march=nocona -fPIC -pthread -I/soft/http/2.4.10/libs/krb5/include -I/soft/http/2.4.10/libs/openssl/include -I/soft/http/2.4.10/include -I -I/soft/http/2.4.10/libs/apr/include/apr-1
make[2]: Leaving directory /test/build/mod_auth_gssapi-1.0.2/src' make[1]: Leaving directory/test/build/mod_auth_gssapi-1.0.2/src'
make[1]: Entering directory /test/build/mod_auth_gssapi-1.0.2' make[1]: Nothing to be done forall-am'.
make[1]: Leaving directory `/test/build/mod_auth_gssapi-1.0.2'

Unable to authenticate when mod_rewrite alters the request

In general terms, there seems to be an issue as to when mod_auth_gssapi returns authorization results back to Apache for handling. In may cases it seems like the results are either too late or too early for further processing (that's only my subjective opinion).

Here is an example accessing /mythweb, which uses mod_rewrite internal redirects quite heavily. mod_auth_gssapi is unable to authenticate the user--no authentication error is returned to the end user, but simply a "Secure connection failed" error.

It should be noted that if I modify the URL from https://example.com/mythweb/ to https://example.com/mythweb/mythweb.php/, I do get authenticated.

[Fri Apr 10 19:23:23.560952 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.560994 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.561043 2015] [core:trace3] [pid 11414] request.c(116): [client 10.1.1.99:54182] auth phase 'check user' gave status 401: /mythweb/, referer: https://example.com/
[Fri Apr 10 19:23:23.561071 2015] [core:debug] [pid 11414] util_cookies.c(129): [client 10.1.1.99:54182] AH00009: ap_cookie: user '(null)' removed cookie: 'mythweb_gssapi_session=;Max-Age=0;path=/mythweb;domain=example.com;httponly;secure;', referer: https://example.com/
[Fri Apr 10 19:23:23.561115 2015] [http:trace3] [pid 11414] http_filters.c(1045): [client 10.1.1.99:54182] Response sent with status 401, headers:, referer: https://example.com/
[Fri Apr 10 19:23:23.561128 2015] [http:trace5] [pid 11414] http_filters.c(1052): [client 10.1.1.99:54182]   Date: Sat, 11 Apr 2015 00:23:23 GMT, referer: https://example.com/
[Fri Apr 10 19:23:23.561146 2015] [http:trace5] [pid 11414] http_filters.c(1055): [client 10.1.1.99:54182]   Server: Apache/2.4.10 (Fedora) OpenSSL/1.0.1k-fips mod_auth_gssapi/1.1.0 mod_auth_kerb/5.4 PHP/5.6.7 mod_wsgi/4.3.2 Python/2.7.8, referer: https://example.com/
[Fri Apr 10 19:23:23.561157 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Set-Cookie: mythweb_gssapi_session=;Max-Age=0;path=/mythweb;domain=example.com;httponly;secure;, referer: https://example.com/
[Fri Apr 10 19:23:23.561167 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Strict-Transport-Security: max-age=15552000, referer: https://example.com/
[Fri Apr 10 19:23:23.561179 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   WWW-Authenticate: Negotiate, referer: https://example.com/
[Fri Apr 10 19:23:23.561188 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   WWW-Authenticate: Basic realm=\\"GSSAPI Login\\", referer: https://example.com/
[Fri Apr 10 19:23:23.561197 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Cache-Control: no-cache, referer: https://example.com/
[Fri Apr 10 19:23:23.561206 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Set-Cookie: mythweb_gssapi_session=;Max-Age=0;path=/mythweb;domain=example.com;httponly;secure;, referer: https://example.com/
[Fri Apr 10 19:23:23.561215 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Content-Length: 381, referer: https://example.com/
[Fri Apr 10 19:23:23.561223 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Keep-Alive: timeout=5, max=100, referer: https://example.com/
[Fri Apr 10 19:23:23.561231 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Connection: Keep-Alive, referer: https://example.com/
[Fri Apr 10 19:23:23.561239 2015] [http:trace4] [pid 11414] http_filters.c(874): [client 10.1.1.99:54182]   Content-Type: text/html; charset=iso-8859-1, referer: https://example.com/
[Fri Apr 10 19:23:23.570641 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.570666 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.581286 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of Require valid-user : granted, referer: https://example.com/
[Fri Apr 10 19:23:23.581306 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of <RequireAny>: granted, referer: https://example.com/
[Fri Apr 10 19:23:23.581320 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.581339 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] applying pattern '^(css|data|images|js|themes|skins|README|INSTALL|[a-z_]+\\.(php|pl))(/|$)' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.581356 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.581365 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] applying pattern '^(pl(/.*)?)$' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.581372 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.581379 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] applying pattern '^(.+)$' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.581387 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.581394 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] applying pattern '^(.*)$' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.581404 2015] [rewrite:trace2] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] rewrite '' -> 'mythweb.php', referer: https://example.com/
[Fri Apr 10 19:23:23.581417 2015] [rewrite:trace3] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] add per-dir prefix: mythweb.php -> /usr/share/mythweb/mythweb.php, referer: https://example.com/
[Fri Apr 10 19:23:23.581432 2015] [rewrite:trace2] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] trying to replace prefix /usr/share/mythweb/ with /mythweb, referer: https://example.com/
[Fri Apr 10 19:23:23.581444 2015] [rewrite:trace5] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] strip matching prefix: /usr/share/mythweb/mythweb.php -> mythweb.php, referer: https://example.com/
[Fri Apr 10 19:23:23.581456 2015] [rewrite:trace4] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] add subst prefix: mythweb.php -> /mythweb/mythweb.php, referer: https://example.com/
[Fri Apr 10 19:23:23.581468 2015] [rewrite:trace1] [pid 11414] mod_rewrite.c(475): [client 10.1.1.99:54182] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e38e20/initial] [perdir /usr/share/mythweb/] internal redirect with /mythweb/mythweb.php [INTERNAL REDIRECT], referer: https://example.com/
[Fri Apr 10 19:23:23.581731 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.581747 2015] [authz_core:debug] [pid 11414] mod_authz_core.c(802): [client 10.1.1.99:54182] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.587674 2015] [authz_core:debug] [pid 11460] mod_authz_core.c(802): [client 10.1.1.99:54183] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.587706 2015] [authz_core:debug] [pid 11460] mod_authz_core.c(802): [client 10.1.1.99:54183] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.598836 2015] [authz_core:debug] [pid 11460] mod_authz_core.c(802): [client 10.1.1.99:54183] AH01626: authorization result of Require valid-user : granted, referer: https://example.com/
[Fri Apr 10 19:23:23.598855 2015] [authz_core:debug] [pid 11460] mod_authz_core.c(802): [client 10.1.1.99:54183] AH01626: authorization result of <RequireAny>: granted, referer: https://example.com/
[Fri Apr 10 19:23:23.598869 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.598878 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] applying pattern '^(css|data|images|js|themes|skins|README|INSTALL|[a-z_]+\\.(php|pl))(/|$)' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.598895 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.598904 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] applying pattern '^(pl(/.*)?)$' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.598913 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.598920 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] applying pattern '^(.+)$' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.598927 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] strip per-dir prefix: /usr/share/mythweb/ -> , referer: https://example.com/
[Fri Apr 10 19:23:23.598934 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] applying pattern '^(.*)$' to uri '', referer: https://example.com/
[Fri Apr 10 19:23:23.598943 2015] [rewrite:trace2] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] rewrite '' -> 'mythweb.php', referer: https://example.com/
[Fri Apr 10 19:23:23.598970 2015] [rewrite:trace3] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] add per-dir prefix: mythweb.php -> /usr/share/mythweb/mythweb.php, referer: https://example.com/
[Fri Apr 10 19:23:23.598981 2015] [rewrite:trace2] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] trying to replace prefix /usr/share/mythweb/ with /mythweb, referer: https://example.com/
[Fri Apr 10 19:23:23.598988 2015] [rewrite:trace5] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] strip matching prefix: /usr/share/mythweb/mythweb.php -> mythweb.php, referer: https://example.com/
[Fri Apr 10 19:23:23.598995 2015] [rewrite:trace4] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] add subst prefix: mythweb.php -> /mythweb/mythweb.php, referer: https://example.com/
[Fri Apr 10 19:23:23.599002 2015] [rewrite:trace1] [pid 11460] mod_rewrite.c(475): [client 10.1.1.99:54183] 10.1.1.99 - [email protected] [example.com/sid#7fb0643b5430][rid#7fb064e0ef10/initial] [perdir /usr/share/mythweb/] internal redirect with /mythweb/mythweb.php [INTERNAL REDIRECT], referer: https://example.com/
[Fri Apr 10 19:23:23.599158 2015] [authz_core:debug] [pid 11460] mod_authz_core.c(802): [client 10.1.1.99:54183] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://example.com/
[Fri Apr 10 19:23:23.599172 2015] [authz_core:debug] [pid 11460] mod_authz_core.c(802): [client 10.1.1.99:54183] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://example.com/

2 Anhancements...

This module is exactly that what I was looking for as a replacement for the Kerberos Module. But I have 2 issues:
#1: would it be possible to add an option to convert the UPN to lower case?
#2: I do not have root privileges on the Linux box in the company, I run rpmbuild in my home but the installation tries to install in the Apache location. It would be great when buildroot, prefix .... Are not ignored and when required package locations could be configured like for the serf library for instance?!

GssapiUseSessions : Session Cookies are not retrieved

Hello,

I have some problem to configure the sessions. Here is my configuration :

    <Location />
            GssapiUseSessions On
            Session On
            SessionCookieName gssapi_session path=/

            AuthName "GSSAPI Single Sign On Login"
            AuthType GSSAPI
            GssapiCredStore keytab:/instance/kerb/apache_2.4/conf/krb5.keytab
            Require valid-user
    </Location>

Cookies are correctly set and forwarded but it seems that they are not correctly retrieved by mod_auth_gssapi. Here is the logs :

[Mon Oct 13 12:17:01.066590 2014] [authz_core:debug] [pid 3726] mod_authz_core.c(802): [client 10.151.27.181:46888] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.066614 2014] [authz_core:debug] [pid 3726] mod_authz_core.c(802): [client 10.151.27.181:46888] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.066704 2014] [:info] [pid 3726] [client 10.151.27.181:46888] Session key not available, no cookies!, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.083542 2014] [:info] [pid 3726] [client 10.151.27.181:46888] Session key not available, generating new one., referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.084610 2014] [authz_core:debug] [pid 3726] mod_authz_core.c(802): [client 10.151.27.181:46888] AH01626: authorization result of Require valid-user : granted, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.084698 2014] [authz_core:debug] [pid 3726] mod_authz_core.c(802): [client 10.151.27.181:46888] AH01626: authorization result of <RequireAny>: granted, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.085466 2014] [core:debug] [pid 3726] util_cookies.c(59): [client 10.151.27.181:46888] AH00007: ap_cookie: user 'jjohn@TEST' set cookie: 'gssapi_session=MagBearerToken=H2pwOTBN%2fBdiqXuij103hRm4g3pXOO%2fG4ce0VI5D%2f471MgwicimG6qJv5KzyJJ%2foNwI9PcHfjG%2fOQ%2fzyWYVRmyeVW8NHkEnobVqlemxQg%2bnnB%2fJRCEaNT3neP5rPd1ZJI9gLkhWxKZJcTOkHXC7ofg%3d%3d;path=/', referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.145582 2014] [authz_core:debug] [pid 3731] mod_authz_core.c(802): [client 10.151.27.181:46889] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.145607 2014] [authz_core:debug] [pid 3731] mod_authz_core.c(802): [client 10.151.27.181:46889] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.145670 2014] [:error] [pid 3731] [client 10.151.27.181:46889] Failed to unseal session data!, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.153305 2014] [authz_core:debug] [pid 3731] mod_authz_core.c(802): [client 10.151.27.181:46889] AH01626: authorization result of Require valid-user : granted, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.154371 2014] [authz_core:debug] [pid 3731] mod_authz_core.c(802): [client 10.151.27.181:46889] AH01626: authorization result of <RequireAny>: granted, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.154546 2014] [core:debug] [pid 3731] util_cookies.c(59): [client 10.151.27.181:46889] AH00007: ap_cookie: user 'jjohn@TEST' set cookie: 'gssapi_session=MagBearerToken=BdMILp5JXzpZ8I%2f67xzcBo0PdTVZzbolyZbkFg6NwEPFy3XgngJBBduI4icrObT%2bStylX2CZ2Prp7pTh%2fcGUSIV0lswiMW3%2blyzQNssx1EA6kZKyLDJnrmD%2f4dIlnnzs%2fMbzdDA1CMJ7FwkrU5uC8A%3d%3d;path=/', referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.225068 2014] [authz_core:debug] [pid 3761] mod_authz_core.c(802): [client 10.151.27.181:46890] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.225096 2014] [authz_core:debug] [pid 3761] mod_authz_core.c(802): [client 10.151.27.181:46890] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.225163 2014] [:error] [pid 3761] [client 10.151.27.181:46890] Failed to unseal session data!, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.322471 2014] [authz_core:debug] [pid 3761] mod_authz_core.c(802): [client 10.151.27.181:46890] AH01626: authorization result of Require valid-user : granted, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.322588 2014] [authz_core:debug] [pid 3761] mod_authz_core.c(802): [client 10.151.27.181:46890] AH01626: authorization result of <RequireAny>: granted, referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.322736 2014] [core:debug] [pid 3761] util_cookies.c(59): [client 10.151.27.181:46890] AH00007: ap_cookie: user 'jjohn@TEST' set cookie: 'gssapi_session=MagBearerToken=g1%2bZ%2bbVLvWm1JPUlPimOFhFaJGDpDKT4xrluEpq%2b2SCTdVq6P43FPkqADj0H%2ff%2f4EIh3eFwsb9jz6XoNC%2bWhRZhUY%2bRzEPICk%2f%2b4bnwH3aHjlaw0blbksfj1GTzyOQN3LNjifvYNXUah59450OZjwQ%3d%3d;path=/', referer: http://jpa.com/configuring.html
[Mon Oct 13 12:17:01.416877 2014] [authz_core:debug] [pid 3766] mod_authz_core.c(802): [client 10.151.27.181:46891] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: http://jpa.com/style/css/manual-zip-100pc.css
[Mon Oct 13 12:17:01.416901 2014] [authz_core:debug] [pid 3766] mod_authz_core.c(802): [client 10.151.27.181:46891] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: http://jpa.com/style/css/manual-zip-100pc.css
[Mon Oct 13 12:17:01.416964 2014] [:error] [pid 3766] [client 10.151.27.181:46891] Failed to unseal session data!, referer: http://jpa.com/style/css/manual-zip-100pc.css
[Mon Oct 13 12:17:01.417002 2014] [core:debug] [pid 3766] util_cookies.c(59): [client 10.151.27.181:46891] AH00007: ap_cookie: user '(null)' set cookie: 'gssapi_session=MagBearerToken=BdMILp5JXzpZ8I%2f67xzcBo0PdTVZzbolyZbkFg6NwEPFy3XgngJBBduI4icrObT%2bStylX2CZ2Prp7pTh%2fcGUSIV0lswiMW3%2blyzQNssx1EA6kZKyLDJnrmD%2f4dIlnnzs%2fMbzdDA1CMJ7FwkrU5uC8A%3d%3d;path=/', referer: http://jpa.com/style/css/manual-zip-100pc.css

Even when the cookie is already set, it is not used and a new one is created on each request.

I've tried many configurations but always with the same result.

Thanks for your help.

behind a load balancer

I have a load balancer setup between (4) web instances running apache. I have not had any luck getting this to work behind the load balanced SPN. I first attempted this with mod_auth_kerb and finally gave up thinking I had hit a bug somewhere and found this project (also noticed its in Fedora now). I managed to get SSO working with the physical hostname of one of the boxes as my SPN, ie. hostweb1 and that works no problem. I then generated a new host keytab using the SPN for my loadbalanced address, ie, web.company.com. That's where things stop working and SSO no longer works. Is there any further debuglevel I can get out of the module to see where things are breaking? My backend is using RHEL IPA (latest stable version in RHEL6).

Below is my config and the error I am seeing from the module.

[Thu Aug 13 10:45:35.067102 2015] [auth_gssapi:error] [pid 115007] [client 10.250.18.28:57620] gss_accept_sec_context() failed: [An unsupported mechanism was requested (Unknown error)]

Config:

AuthType GSSAPI
AuthName "GSSAPI Single Sign On Login"

GssapiBasicAuth on
GssapiCredStore keytab:/etc/httpd/http.keytab
GssapiLocalName on
GssapiConnectionBound on
GssapiSignalPersistentAuth on
GssapiAllowedMech krb5
GssapiBasicAuthMech krb5
Require valid-user

apxs unknown option errors with Apache 2.4.10

Trying to compile the current -git version (1.0.2) on Arch Linux, with Apache 2.4.10, and getting the following:

make[2]: Entering directory '/home/grawity/pkg/my-aur/mod_auth_gssapi-git/src/mod_auth_gssapi/src'
/usr/bin/apxs -c -L/usr/lib -R/usr/lib -lapr-1 -luuid -lrt -lcrypt  -lpthread -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4   -pthread   -I/usr/include/httpd -I -I/usr/include/apr-1  mod_auth_gssapi.c sessions.c crypto.c
apxs:Error: Unknown option: R.
apxs:Error: Unknown option: /.
apxs:Error: Unknown option: u.
apxs:Error: Unknown option: s.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: /.
apxs:Error: Unknown option: m.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: h.
apxs:Error: Unknown option: =.
apxs:Error: Unknown option: x.
apxs:Error: Unknown option: 8.
apxs:Error: Unknown option: 6.
apxs:Error: Unknown option: -.
apxs:Error: Unknown option: 6.
apxs:Error: Unknown option: 4.
apxs:Error: Unknown option: m.
apxs:Error: Unknown option: t.
apxs:Error: Unknown option: u.
apxs:Error: Unknown option: O.
apxs:Error: Unknown option: 2.
apxs:Error: Unknown option: f.
apxs:Error: Unknown option: s.
apxs:Error: Unknown option: t.
apxs:Error: Unknown option: k.
apxs:Error: Unknown option: -.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: -.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: m.
apxs:Error: Unknown option: =.
apxs:Error: Unknown option: s.
apxs:Error: Unknown option: s.
apxs:Error: Unknown option: -.
apxs:Error: Unknown option: b.
apxs:Error: Unknown option: u.
apxs:Error: Unknown option: f.
apxs:Error: Unknown option: f.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: -.
apxs:Error: Unknown option: s.
apxs:Error: Unknown option: z.
apxs:Error: Unknown option: =.
apxs:Error: Unknown option: 4.
apxs:Error: Unknown option: t.
apxs:Error: Unknown option: h.
apxs:Error: Unknown option: r.
apxs:Error: Unknown option: d.
Usage: apxs -g [-S <var>=<val>] -n <modname>
       apxs -q [-v] [-S <var>=<val>] [<query> ...]
       apxs -c [-S <var>=<val>] [-o <dsofile>] [-D <name>[=<value>]]
               [-I <incdir>] [-L <libdir>] [-l <libname>] [-Wc,<flags>]
               [-Wl,<flags>] [-p] <files> ...
       apxs -i [-S <var>=<val>] [-a] [-A] [-n <modname>] <dsofile> ...
       apxs -e [-S <var>=<val>] [-a] [-A] [-n <modname>] <dsofile> ...
Makefile:521: recipe for target 'all-local' failed

(...Seems like it's choking on options that should have been passed to gcc?)

make test fails on Fedora 23

On Fedora 23, using master checkout, with the following packages installed

httpd-2.4.18-1.fc23.x86_64
krb5-server-1.14.1-5.fc23.x86_64
krb5-workstation-1.14.1-5.fc23.x86_64
mod_session-2.4.18-1.fc23.x86_64
nss_wrapper-1.1.3-1.fc23.x86_64
socket_wrapper-1.1.6-1.fc23.x86_64

running make test as root fails with

# make test
Making all in src/asn1c
make[1]: Entering directory '/root/mod_auth_gssapi/src/asn1c'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/root/mod_auth_gssapi/src/asn1c'
Making all in src
make[1]: Entering directory '/root/mod_auth_gssapi/src'
make  all-am
make[2]: Entering directory '/root/mod_auth_gssapi/src'
make[2]: Leaving directory '/root/mod_auth_gssapi/src'
make[1]: Leaving directory '/root/mod_auth_gssapi/src'
make[1]: Entering directory '/root/mod_auth_gssapi'
make[1]: Nothing to be done for 'all-am'.
make[1]: Leaving directory '/root/mod_auth_gssapi'
./tests/magtests.py
[Mon May 30 03:49:00.651308 2016] [core:emerg] [pid 10393] (22)Invalid argument: AH00024: Couldn't set permissions on the mpm-accept mutex; check User and Group directives
(22)Invalid argument: could not create accept mutex
AH00015: Unable to open logs
SPNEGO: FAILED
SPNEGO Proxy Auth: FAILED
SPNEGO No Auth: FAILED
SPNEGO Negotiate Once: FAILED
BASIC-AUTH: FAILED
BASIC-AUTH Two Users: FAILED
BASIC Fail Second User: FAILED
BASIC Proxy Auth: FAILED

When I add

User apache
Group apache

to the tests/httpd.conf file, it no longer complains about Invalid argument and similar but the tests themselves still fail:

# make test
Making all in src/asn1c
make[1]: Entering directory '/root/mod_auth_gssapi/src/asn1c'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/root/mod_auth_gssapi/src/asn1c'
Making all in src
make[1]: Entering directory '/root/mod_auth_gssapi/src'
make  all-am
make[2]: Entering directory '/root/mod_auth_gssapi/src'
make[2]: Leaving directory '/root/mod_auth_gssapi/src'
make[1]: Leaving directory '/root/mod_auth_gssapi/src'
make[1]: Entering directory '/root/mod_auth_gssapi'
make[1]: Nothing to be done for 'all-am'.
make[1]: Leaving directory '/root/mod_auth_gssapi'
./tests/magtests.py
SPNEGO: FAILED
SPNEGO Proxy Auth: FAILED
SPNEGO No Auth: FAILED
SPNEGO Negotiate Once: FAILED
BASIC-AUTH: FAILED
BASIC-AUTH Two Users: FAILED
BASIC Fail Second User: FAILED
BASIC Proxy Auth: FAILED

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.