Bug 1333813

Odrej,

The Negotiate method (SPNEGO) is available by default in mod_auth_gssapi and cannot be turned off, GssapiNegotiateOnce is a different workaround for browasers that try to be too clever. It will offer the Negotiate method but only one time so that browsers do not end up in a loop.

The KrbAuthRealms option has no real equivalent in mod_auth_gssapi, if you want to control which realms are allowed, the best way is to set the GssapiLocalName feature On and then control in krb5.conf what mappings you allow (allow only the specific realm you want). If you do not want to use the global /etc/krb5.conf you can create a separate file and add the KRB5_CONFIG environment variable to apahe's startup.

The KrbServiceName option has no equivalent in mod_auth_gssapi it is not clear to me what use you have for it ?
GSSAPI will use whatever service key is avaiable in the keytab and is able to decrypt the incoming auth blobs, there is no real need to specify it in the configuration file.

HTH.

Hi Simo,

My experience is that when I have "KrbMethodNegotiate" turned on, browser tries to delegate user ticket - i.e. SSO. Unfortunately this does not seem to work with NGINX in between.
Disabling KrbMethodNegotiate forces browser to always prompt user for username/password and it will pass NGINX happily, too.

Anyway, will try.

How about the "KrbSaveCredentials" - do we have an option to select if we want to save user credentials to cache file or kernel keyring or default configuration as per krb5.conf is always honored?

Thanks,
Ondrej

(In reply to Ondrej from comment #3)
> How about the "KrbSaveCredentials" - do we have an option to select if we
> want to save user credentials to cache file or kernel keyring or default
> configuration as per krb5.conf is always honored?

To control credential delegation, you'll want the `GssapiDelegCcacheDir` option.  For its own use, mod_auth_gssapi will use the value of `GssapiCredStore` for its own storage.

Ok, I tried this configuration:

<Location /private>
#       AuthType Kerberos
        AuthType GSSAPI
        AuthName "Kerberos Login"
        GssapiCredStore         keytab:/etc/krb5.keytab
        GssapiAllowedMech       krb5
        GssapiBasicAuth         On
        GssapiCredStore         ccache:MEMORY:user_ccache

#  KrbMethodNegotiate Off
#  KrbSaveCredentials on
#  KrbVerifyKDC off
#  KrbAuthRealms REALM.COM
#  KrbServiceName HTTP
  require valid-user
</Location>

The uncommented sections work well with mod_auth_kerb. The new version of the configuration above does not work with mod_auth_gssapi module.

Error I am receiving is:
 gss_acquire_cred[_from]() failed to get server creds: [The operation or option is not available or unsupported ( SPNEGO cannot find mechanisms to negotiate)]


Tried Firefox and MS IE - non of them work. They ask for username & password forever producing this error message on the server.

What could be wrong?

That configuration works for me both with krb5 login and with basic auth, though I'm using a different keytab location (/etc/httpd/http.keytab).

Can you check that the appropriate principal is present in the keytab you're using?

[root@carney private]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
...
   2 CARNEY$@REALM.COM
   2 HTTP/carney.domain.com
   2 HTTP/carney.domain.com
   2 HTTP/carney.domain.com
   2 HTTP/carney.domain.com
   2 HTTP/carney.domain.com
   2 HTTP/carney
   2 HTTP/carney
   2 HTTP/carney
   2 HTTP/carney
   2 HTTP/carney
....

As I say, there should not be a problem with keytab as it works well with mod-auth-kerb

Can you try pointing at a different keytab that just has the first HTTP prinicipal?

Tried that - exported the HTTP/* principals to a dedicated keytab file. Updated both apache config file and the gssproxy configuration, too.

Same error. Still not working.

setup KRB5_TRACE for httpd process. The trace produced does not show any problem:
...

[62836] 1463733683.849293: Response was from master KDC
[62836] 1463733683.849758: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP
[62836] 1463733683.850168: Request or response is too big for UDP; retrying with TCP
[62836] 1463733683.850417: Sending request (286 bytes) to REALM.COM (tcp only)
[62836] 1463733683.851467: Initiating TCP connection to stream 192.168.1.1:88
[62836] 1463733683.852731: Sending TCP request to stream 192.168.1.1:88
[62836] 1463733683.856045: Received answer (2032 bytes) from stream 192.168.128.6:88
[62836] 1463733683.856322: Terminating TCP connection to stream 192.168.1.1:88
[62836] 1463733683.857205: Response was from master KDC
[62836] 1463733683.857501: Processing preauth types: 19
[62836] 1463733683.857812: Selected etype info: etype aes256-cts, salt "REALM.COMondrejv", params ""
[62836] 1463733683.857949: Produced preauth for next request: (empty)
[62836] 1463733683.858153: AS key determined by preauth: aes256-cts/4482
[62836] 1463733683.858533: Decrypted AS reply; session key is: aes256-cts/C4C8
[62836] 1463733683.858771: FAST negotiation: unavailable
[62836] 1463733683.859059: Initializing MEMORY:user_2130955931460119117 with default princ ondrejv
[62836] 1463733683.859418: Storing ondrejv -> krbtgt/REALM.COM in MEMORY:user_2130955931460119117
[62836] 1463733683.859677: Storing config in MEMORY:user_2130955931460119117 for krbtgt/REALM.COM: pa_type: 2
[62836] 1463733683.859952: Storing ondrejv -> krb5_ccache_conf_data/pa_type/krbtgt\/REALM.COM\@REALM.COM@X-CACHECONF: in MEMORY:user_2130955931460119117

Can you give me more information on what goes wrong?  Firefox logs, perhaps?

Firefox can not authenticate - once I submit my login details to the dialog box and press "OK", the authentication window immediately reappear prompting me for the same. Forever.

Unfortunately this is a CENTOS-7 machine, but I can try to replicate it on RHEL and submit a support case to SEG team.

(In reply to Ondrej from comment #13)
> Firefox can not authenticate - once I submit my login details to the dialog
> box and press "OK", the authentication window immediately reappear prompting
> me for the same. Forever.

Sure, I get that.  Doesn't help me debug it though.

Re-launch firefox with these environment variables set:

export NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5
export NSPR_LOG_FILE=/tmp/log.txt

try to do the requests a couple times, then attach the log file to this ticket.

Created attachment 1161478 [details]
Firefox log file

Attached requested FF log file

Thanks for the file.

I've just started poring through it, but it looks like your server has both mod_auth_gssapi and mod_auth_kerb enabled?  Have you tried disabling mod_auth_kerb entirely?

From the trace, it looks like your browser really wants to use basic auth, but the server really wants it to negotiate.  If turning off mak doesn't fix it, I will investigate further.

uninstalled mod_auth_kerb module from the server, restarted Apache, tried again - still the same. No change.

Hi, is there any progress with the case? Would it help if I opened an official support case with RedHat for tis?
The thing is, that I am having problems with delegated Kerberos tokens and mod_auth_kerb so hoping mod_auth_gssapi would help here.

Onrej,
the KRB_TRACE seem to confirm that the user was successfully authenticated, can you look at apache logs and see if mod_auth_gssapi says anything about what went wrong ?

Ondrej,
I actually have an idea of what may be wrong, based on the keytab you have.

Would you be able to use the ktutil, to change the keytab and only store in a new kytab the HTTP/ entries for the fully quaified name ? Leave out the CARNEY$ and the short name ones for this test.

Then try again basic auth after restring apache and mod_auth_gssapi with this new keytab in its conf.

Hi Simo,

I stripped off the short names:

[root@carney conf.d]# klist -k /etc/httpd/httpd.keytab
Keytab name: FILE:/etc/httpd/httpd.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 HTTP/carney.dublin.s3group.com.S3GROUP.COM
   2 HTTP/carney.dublin.s3group.com.S3GROUP.COM
   2 HTTP/carney.dublin.s3group.com.S3GROUP.COM
   2 HTTP/carney.dublin.s3group.com.S3GROUP.COM
   2 HTTP/carney.dublin.s3group.com.S3GROUP.COM

Gssproxy has the following configuration:
[root@carney conf.d]# cat /etc/gssproxy/gssproxy.conf
[gssproxy]

[service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0

[service/HTTP]
  mechs = krb5
  cred_store = keytab:/etc/httpd/httpd.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 348

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

also running with '-d' parameter, but does not show any error.
Apache configuration (again):
[root@carney conf.d]# cat gssapi.conf 
<Location /private>
#  	AuthType Kerberos
  	AuthType GSSAPI
  	AuthName "Kerberos Login"
  	GssapiCredStore 	keytab:/etc/httpd/httpd.keytab
#  	GssapiAllowedMech 	krb5
  	GssapiBasicAuth 	On
	GssapiCredStore 	ccache:MEMORY:user_ccache
	
#  KrbMethodNegotiate Off
#  KrbSaveCredentials on
#  KrbVerifyKDC off
#  KrbAuthRealms DUBLIN.AD.S3GROUP.COM
#  KrbServiceName HTTP
  require valid-user
</Location>

KRB_TRACE looks good:
[11824] 1471852042.724560: Response was from master KDC
[11824] 1471852042.724626: Processing preauth types: 19
[11824] 1471852042.724642: Selected etype info: etype aes256-cts, salt "DUBLIN.AD.S3GROUP.COMondrejv", params ""
[11824] 1471852042.724662: Produced preauth for next request: (empty)
[11824] 1471852042.724678: AS key determined by preauth: aes256-cts/4482
[11824] 1471852042.724794: Decrypted AS reply; session key is: aes256-cts/8B69
[11824] 1471852042.724805: FAST negotiation: unavailable
[11824] 1471852042.724848: Initializing MEMORY:user_9909616464742866137 with default princ ondrejv.S3GROUP.COM
[11824] 1471852042.724869: Storing ondrejv.S3GROUP.COM -> krbtgt/DUBLIN.AD.S3GROUP.COM.S3GROUP.COM in MEMORY:user_9909616464742866137
[11824] 1471852042.724895: Storing config in MEMORY:user_9909616464742866137 for krbtgt/DUBLIN.AD.S3GROUP.COM.S3GROUP.COM: pa_type: 2
[11824] 1471852042.724916: Storing ondrejv.S3GROUP.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/DUBLIN.AD.S3GROUP.COM\@DUBLIN.AD.S3GROUP.COM@X-CACHECONF: in MEMORY:user_9909616464742866137

But browser is still unable to authenticate, apache produces the same error:
[Mon Aug 22 08:47:22.812019 2016] [auth_gssapi:error] [pid 11824] [client 192.168.60.181:59246] gss_acquire_cred[_from]() failed to get server creds: [The operation or option is not available or unsupported (Unknown error)]

What krb5 package version are you using ?
It sounds like something is not supported here.
Do you havee gss-proxy enabled and configured to server apache by chance ?

Yes, gssproxy is running:
[root@carney system]# systemctl status gssproxy
�� gssproxy.service - GSSAPI Proxy Daemon
   Loaded: loaded (/etc/systemd/system/gssproxy.service; disabled; vendor preset: disabled)
   Active: active (running) since Mon 2016-08-22 08:43:50 IST; 6h ago
  Process: 11547 ExecStart=/usr/sbin/gssproxy -D -d (code=exited, status=0/SUCCESS)
 Main PID: 11548 (gssproxy)
   CGroup: /system.slice/gssproxy.service
           ������11548 /usr/sbin/gssproxy -D -d


I have GSS_USE_PROXY=1 in /etc/sysconfig/httpd. Authentication seems to start working OK when I change it to GSS_USE_PROXY=0 and add ACLs so that apache can read /etc/httpd/httpd.keytab.

So yes, looks like this is rather something wrong with gssproxy. Using:
gssproxy.x86_64 0:0.4.1-8.el7_2

Update: Without gssproxy, browser does not ask me for password, I get automatically granted for access, environment variable "REMOTE_USER" is correctly set to ondrejv, but unfortunately Kerberos cache is not delegatedto the remote php script - KRB5CCNAME is not set.

So the problem has 2 layers:
1. gssproxy
2. Kerberos cache delegation

Ok so this is a gssproxy issue, changing component.

To delegate the ccache please drop the line:

   GssapiCredStore         ccache:MEMORY:user_ccache

and add a line like:

   GssapiDelegCcacheDir /var/run/httpd/clientcaches

make sure apache can write to that location.

Also if your script takes ownership of the ccache file and delete it you may want to also use GssapiDelegCcacheUnique (requires latest module, so not available on RHEL/CentOS)

Hi,

Is there any progress with this case? I would really like to see mod_auth_gssapi working with gssproxy as it would eliminate need of extra keytab file for the webserver.
Should I open Redhat support case for this?

Thanks,
Ondrej

(In reply to Ondrej from comment #29)
> Is there any progress with this case? I would really like to see
> mod_auth_gssapi working with gssproxy as it would eliminate need of extra
> keytab file for the webserver.

Simo posted two suggestions above on this bug.  Did they improve the situation any?

The suggestions Simo posted were more regarding Delegating Kerberos credentials.
These were (more/less - Chrome still does not work, will open a separate bug for this) resolved.

This bug is about a fact that mod-auth-gssapi does not work with gssproxy backend.
It does work without gssproxy (see comment #25)
Once I enable gssproxy for Apache, mod-auth-gssapi stops working, can't authenticate.

Now we know the problem is with gssproxy - I would like to make it working with gssproxy as well.

This problem will be solved in the future by implementing the cred store extensions in gssproxy.

We will probably require applications using the delegated credentials to themselves be using gssproxy as well, at least initially.

In the mean time, everything should work if you don't ask for credential storage out of mod_auth_gssapi.

Created attachment 1281903 [details]
console.log

Verified using IPA and GSSProxy ::
ipa-server-4.5.0-13.el7.x86_64
gssproxy-0.7.0-3.el7.x86_64

Marking BZ as verified. see attachment for console log.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2033

Just a note that this still does not work for me - but since I am not sure if that's a problem with gssproxy or mod_auth_gssapi, I have opened a new report:

https://bugzilla.redhat.com/show_bug.cgi?id=1527937