OmniauthKerberosSpnegoController: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested

@jacobvosmaer-gitlab I'm pinging you here as you're listed as the "Kerberos" expert ( team page ) and you also implemented the controller (discussed in https://gitlab.com/gitlab-org/gitlab-ee/issues/745).

We now have two customers facing the same error message when negotiating authentication via kerberos. I've tried to narrow this down to an infrastructure miss-configuration or an incorrect keytab file with little success.

One customer has a working configuration in production but broken in test https://gitlab.zendesk.com/agent/tickets/74212 - Both customers report kerberos working correctly for Windows clients, but not GitLab.

The error seems to indicate an unsupported authentication method was attempted.

Do you have any suggestions for debugging this further (I have requested logs from the Kerberos server). We can also jump on a call and check the customers configuration. I do understand this isn't necessarily a GitLab bug but a miss-configuration that needs documenting in our integration guide https://docs.gitlab.com/ee/integration/kerberos.html

cc// @stanhu

I'm 99% it's something to do with this logic block here:

https://gitlab.com/gitlab-org/gitlab-ee/blob/master/app/helpers/kerberos_spnego_helper.rb#L59-65

specifically, kerberos.service_principal_name being set in the config.

@chaase do you have that set in your config?

Can you try this script in a rails console and let us know if it throws an error:

gitlab-rails console
require 'gssapi'
gss = GSSAPI::Simple.new(nil, nil, Gitlab.config.kerberos.keytab)
gss.acquire_credentials(nil)

kerberos.service_principal_name is set to "HTTP/gitlab-fqdn@REALM", see below

# gitlab-rails console
WARNING: No GitLab Enterprise Edition license has been provided yet. Pushing code and creation of issues and merge requests has been disabled. Upload a license in the admin area to activate this functionality.

No license installed, this is a test system

Loading production environment (Rails 4.2.8)
irb(main):001:0> require 'gssapi'
=> true
irb(main):002:0> Gitlab.config.kerberos
=> {"enabled"=>true, "keytab"=>"/etc/http.keytab", "service_principal_name"=>"HTTP/<gitlab-fqdn>@<REALM>", "use_dedicated_port"=>false, "port"=>8088, "https"=>false}
irb(main):003:0> File.stat(Gitlab.config.kerberos.keytab)
=> #<File::Stat dev=0xfe00, ino=276880, mode=0100600, nlink=1, uid=998, gid=0, rdev=0x0, size=238, blksize=4096, blocks=8, atime=2017-05-08 16:27:23 +0200, mtime=2017-04-13 18:06:04 +0200, ctime=2017-04-24 18:00:21 +0200>
irb(main):004:0> Process.uid
=> 998
irb(main):005:0> Process.gid
=> 998
irb(main):006:0> Process.euid
=> 998
irb(main):007:0> Process.egid
=> 998
irb(main):008:0> gss = GSSAPI::Simple.new(nil, nil, Gitlab.config.kerberos.keytab)
=> #<GSSAPI::Simple:0x007f7838dbf8a0 @host=nil, @service="host@", @int_svc_name=#<GSSAPI::LibGSSAPI::GssNameT address=0x007f7829839c90>, @context=nil, @scred=nil, @delegated_credentials=nil>
irb(main):009:0> gss.acquire_credentials(nil)
=> true

I can offer you access to the test system if needed.

@chaase Boom! So it looks like that setting the service_principal_name is the problem that is causing the error. @jacobvosmaer-gitlab, as per the team page, you are our Kerberos Expert. Do you have any ideas why setting that is causing this code to barf?

I tried both, with and without service_principal_name set. The behavior was identical, Win10 works, Debian does not and gss.acquire_credentials(nil) does return true

Another customer has run into this issue: https://gitlab.zendesk.com/agent/tickets/78063

@mydigitalself This is a support scheduling request. We'd like to get this issue prioritized.

changed milestone to %9.4

@DouweM will we need to borrow @jacobvosmaer-gitlab for this? cc @andrewn

Right now this seems like a client side issue with both Ubuntu or Debian systems (the only ones reporting auth failures with An unsupported mechanism was requested). I was able to reproduce this on OS X by not generating or configuring the KB5 client.

I'm still uncertain this is a GitLab bug. It seems @chaase did test authentication via Apache2 (another Kerberos setup) and it worked correctly where as GitLab did not. https://gitlab.com/gitlab-org/gitlab-ce/issues/31427#note_28892944

@chaase Are you able to provide the ubuntu release you tested this on and the KB5 client version? Maybe we can reproduce this issue.

Sure, here the details. I updated (and verified the situation) both server and client a minute ago via apt.

chaase@ubuntu ~ % lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial
chaase@ubuntu ~ % dpkg -l \*krb\* | grep '^ii'
ii  krb5-auth-dialog         3.12.0-2                      amd64        tray applet for reauthenticating kerberos tickets
ii  krb5-config              2.3                           all          Configuration files for Kerberos Version 5
ii  krb5-locales             1.13.2+dfsg-5ubuntu2          all          Internationalization support for MIT Kerberos
ii  krb5-user                1.13.2+dfsg-5ubuntu2          amd64        Basic programs to authenticate using MIT Kerberos
ii  libgssapi-krb5-2:amd64   1.13.2+dfsg-5ubuntu2          amd64        MIT Kerberos runtime libraries - krb5 GSS-API Mechanism
ii  libkrb5-26-heimdal:amd64 1.7~git20150920+dfsg-4ubuntu1 amd64        Heimdal Kerberos - libraries
ii  libkrb5-3:amd64          1.13.2+dfsg-5ubuntu2          amd64        MIT Kerberos runtime libraries
ii  libkrb5support0:amd64    1.13.2+dfsg-5ubuntu2          amd64        MIT Kerberos runtime libraries - Support library
chaase@ubuntu ~ % dpkg -l \*firefox\* | grep '^ii'
ii  firefox                      53.0.3+build1-0ubuntu0.16.04.2 amd64        Safe and easy web browser from Mozilla
ii  firefox-locale-de            53.0.3+build1-0ubuntu0.16.04.2 amd64        German language pack for Firefox
ii  unity-scope-firefoxbookmarks 0.1+13.10.20130809.1-0ubuntu1  all          Firefox bookmarks scope for Unity

@mydigitalself If it is determined that this is indeed a GitLab issue, then likely yes, at least for guidance.

@mydigitalself, since @jacobvosmaer-gitlab is the only (listed) Kerberos expert with the company at present please feel free to engage :)

@jacobvosmaer-gitlab it might be worth pairing with someone while investigating this issue in the interests of Kerberos knowledge transfer. @MrChrisW would you be interested in working with Jacob on this? (...and is there a time that works for both of you?)

@andrewn Thanks, I'm happy to knowledge share. At this stage we need to get a reliable way to reproduce the issue before any debugging can be done.

@chaase I'm unable to reproduce this issue using the same environment listed (Ubuntu + Firefox) - https://drive.google.com/file/d/0B_4wYK1qcPT1cFRUa0V4OHZWd1k/view?usp=sharing - Are there any other settings or configurations that may be missing?

@MrChrisW Hmm, I am using samba 4.6.1 as AD, maybe this is related. I can offer you access to my test systems if that helps.

Looks like we got another here: https://gitlab.zendesk.com/agent/tickets/78796

Customer is seeing

OmniauthKerberosSpnegoController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested

Completed 401 Unauthorized

In their logs. @MrChrisW thoughts here?

added Deliverable label

changed milestone to %9.5

OmniauthKerberosSpnegoController: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested

Overview

Designs

Child items ...

Activity

Admin message

Admin message

OmniauthKerberosSpnegoController: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested

Overview

Activity