Pending "gss_init_sec_context() failed: Unspecified GSS failure...."
Sylvain RICHET
Seems to be a GSS API ?
A communication problem between NegotiateAuth (pluggued in Firefox)
dans the underlying GSS API library (libgssapi-krb5-2 ?) ?
The authentication process succeeds (as configured in "mod_auth_kerb")
but...
1) the NegotiateAuth log traces this error "gss_init_sec_context()
failed: Unspecified GSS failure...."
2) Using WireShark, i can't find any SPNEGO ticket in the data sent
by Firefox to webserver after authentication
I browse a lot, and found many posts relative to gss_init_sec_context
() and the error msg.
But it didn't help me: given workarounds don't match my problem.
# ON BROWSER SIDE
-----------------
> tail -f /tmp/negotiateauth.log
-1217141024[b742e1c0]: service = kwebapp.beeware.org
-1217141024[b742e1c0]: using negotiate-gss
-1217141024[b742e1c0]: entering nsAuthGSSAPI::nsAuthGSSAPI()
-1217141024[b742e1c0]: Attempting to load gss functions
-1217141024[b742e1c0]: entering nsAuthGSSAPI::Init()
-1217141024[b742e1c0]: nsHttpNegotiateAuth::GenerateCredentials()
[challenge=Negotiate]
-1217141024[b742e1c0]: entering nsAuthGSSAPI::GetNextToken()
-1217141024[b742e1c0]: gss_init_sec_context() failed: Unspecified GSS
failure. Minor code may provide more information
SPNEGO cannot find mechanisms to negotiate
-1217141024[b742e1c0]: leaving nsAuthGSSAPI::GetNextToken
[rv=80004005]
==>
==> As you can see, the problem is : "gss_init_sec_context() failed:
Unspecified GSS failure...."
==>
# ON APACHE SIDE
-----------------
> tail -f /var/log/apache2/error.log
[Thu Jan 07 11:17:05 2010] [debug] src/mod_auth_kerb.c(1579): [client
192.168.100.237] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[Thu Jan 07 11:17:05 2010] [debug] mod_deflate.c(615): [client
192.168.100.237] Zlib: Compressed 486 to 328 : URL /
[Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(1579): [client
192.168.100.237] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(1023): [client
192.168.100.237] Using WEB/kwebapp.b...@BEEWARE.ORG as server
principal for password verification
[Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(691): [client
192.168.100.237] Trying to get TGT for user sri...@BEEWARE.ORG
[Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(605): [client
192.168.100.237] Trying to verify authenticity of KDC using principal
WEB/kwebapp.b...@BEEWARE.ORG
[Thu Jan 07 11:17:13 2010] [debug] src/mod_auth_kerb.c(1105): [client
192.168.100.237] kerb_authenticate_user_krb5pwd ret=0
user=sri...@BEEWARE.ORG authtype=Basic
[Thu Jan 07 11:17:13 2010] [debug] src/mod_auth_kerb.c(1579): [client
192.168.100.237] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[Thu Jan 07 11:17:13 2010] [debug] src/mod_auth_kerb.c(1023): [client
192.168.100.237] Using WEB/kwebapp.b...@BEEWARE.ORG as server
principal for password verification
[Thu Jan 07 11:17:13 2010] [debug] src/mod_auth_kerb.c(691): [client
192.168.100.237] Trying to get TGT for user sri...@BEEWARE.ORG
[Thu Jan 07 11:17:13 2010] [debug] src/mod_auth_kerb.c(605): [client
192.168.100.237] Trying to verify authenticity of KDC using principal
WEB/kwebapp.b...@BEEWARE.ORG
[Thu Jan 07 11:17:13 2010] [debug] src/mod_auth_kerb.c(1105): [client
192.168.100.237] kerb_authenticate_user_krb5pwd ret=0
user=sri...@BEEWARE.ORG authtype=Basic
[Thu Jan 07 11:17:13 2010] [debug] mod_deflate.c(615): [client
192.168.100.237] Zlib: Compressed 102 to 91 : URL /index.html
==> On Apache side, everything seems to be ok
# ON SERVER SIDE (KDC)
----------------------
> tail -f /var/log/krb5kdc.log
Jan 07 11:19:48 ubuntu krb5kdc[5648](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) 172.16.191.1: ISSUE: authtime 1262859588, etypes {rep=18
tkt=18 ses=18}, sri...@BEEWARE.ORG for krbtgt/BEEWA...@BEEWARE.ORG
Jan 07 11:19:49 ubuntu krb5kdc[5648](info): TGS_REQ (7 etypes {18 17
16 23 1 3 2}) 172.16.191.1: ISSUE: authtime 1262859588, etypes {rep=18
tkt=18 ses=18}, sri...@BEEWARE.ORG for WEB/
kwebapp.b...@BEEWARE.ORG
Jan 07 11:19:49 ubuntu krb5kdc[5648](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) 172.16.191.1: ISSUE: authtime 1262859589, etypes {rep=18
tkt=18 ses=18}, sri...@BEEWARE.ORG for krbtgt/BEEWA...@BEEWARE.ORG
Jan 07 11:19:49 ubuntu krb5kdc[5648](info): TGS_REQ (7 etypes {18 17
16 23 1 3 2}) 172.16.191.1: ISSUE: authtime 1262859589, etypes {rep=18
tkt=18 ses=18}, sri...@BEEWARE.ORG for WEB/
kwebapp.b...@BEEWARE.ORG
==> On KDC side, everything seems to be ok too.
# CONFIGURATION
---------------
# Kerberos Client (Firefox) :
- Firefox 3.5.6 (on Ubuntu 9.10) with NegotiateAuth
- lib GSS : libgssapi-krb5-2
- Apache/2.2.12 with "mod-auth_kerb"
# Kerberos Server (MIT implementation)
- Ubuntu Server 9.10
- krb5-* packages
# "mod-auth_kerb" config on virtual host :
> cat /var/www/kwebapp.beeware.org/.htaccess
<Files "*">
<Limit GET POST>
AuthName "Kerberos Login"
AuthType Kerberos
Krb5Keytab /tmp/krb5.keytab
KrbAuthRealms BEEWARE.ORG
KrbMethodNegotiate on
KrbMethodK5Passwd on
KrbVerifyKDC on
KrbServiceName WEB
Require valid-user
</Limit>
</Files>
# Keytab file "/tmp/krb5.keytab" is OK, and readable (good rights)
Sylvain RICHET
Thanks in advance
Russ Allbery
> I really don't succeed to solve this error message ! Seems to be a GSS
> API ? A communication problem between NegotiateAuth (pluggued in
> Firefox) dans the underlying GSS API library (libgssapi-krb5-2 ?) ?
> The authentication process succeeds (as configured in "mod_auth_kerb")
> but...
> 1) the NegotiateAuth log traces this error "gss_init_sec_context()
> failed: Unspecified GSS failure...."
Which meansn that SPNEGO failed.
> 2) Using WireShark, i can't find any SPNEGO ticket in the data sent
> by Firefox to webserver after authentication
Which also supports that SPNEGO failed.
> -1217141024[b742e1c0]: gss_init_sec_context() failed: Unspecified GSS
> failure. Minor code may provide more information
> SPNEGO cannot find mechanisms to negotiate
This implies to me that either the server didn't offer Kerberos GSSAPI as
an SPNEGO mechanism or the client browser didn't have the libraries
required to do Kerberos GSSAPI.
> [Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(1579): [client
> 192.168.100.237] kerb_authenticate_user entered with user (NULL) and
> auth_type Kerberos
> [Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(1023): [client
> 192.168.100.237] Using WEB/kwebapp.b...@BEEWARE.ORG as server
> principal for password verification
The server didn't do GSSAPI -- it did Basic Auth authentication and then
verified the password with Kerberos. If you're happy with that, nothing
need change, but you're not actually doing SPNEGO or Negotiate-Auth and
you're exposing the account password to the web server.
Your KDC log supports that this is what is happening and shows no service
principal request from the browser, which indicates that it never got far
enough in the Negotiate-Auth dialog to even attempt authentication.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Sylvain RICHET
> Sylvain RICHET <akamanou...@gmail.com> writes:
> > I really don't succeed to solve this error message ! Seems to be a GSS
> > API ? A communication problem between NegotiateAuth (pluggued in
> > Firefox) dans the underlying GSS API library (libgssapi-krb5-2 ?) ?
> > The authentication process succeeds (as configured in "mod_auth_kerb")
> > but...
> > 1) the NegotiateAuth log traces this error "gss_init_sec_context()
> > failed: Unspecified GSS failure...."
>
> Which meansn that SPNEGO failed.
>
> > 2) Using WireShark, i can't find any SPNEGO ticket in the data sent
> > by Firefox to webserver after authentication
>
> Which also supports that SPNEGO failed.
>
> > -1217141024[b742e1c0]: gss_init_sec_context() failed: Unspecified GSS
> > failure. Minor code may provide more information
> > SPNEGO cannot find mechanisms to negotiate
>
> This implies to me that either the server didn't offer Kerberos GSSAPI as
> an SPNEGO mechanism or the client browser didn't have the libraries
> required to do Kerberos GSSAPI.
>
> > [Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(1579): [client
> > 192.168.100.237] kerb_authenticate_user entered with user (NULL) and
> > auth_type Kerberos
> > [Thu Jan 07 11:17:12 2010] [debug] src/mod_auth_kerb.c(1023): [client
> > principal for password verification
>
> The server didn't do GSSAPI -- it did Basic Auth authentication and then
> verified the password with Kerberos. If you're happy with that, nothing
> need change, but you're not actually doing SPNEGO or Negotiate-Auth and
> you're exposing the account password to the web server.
>
> Your KDC log supports that this is what is happening and shows no service
> principal request from the browser, which indicates that it never got far
> enough in the Negotiate-Auth dialog to even attempt authentication.
>
> --
> Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Thanks, Russ !
Your opinion concerning my logs leads me a little.
Probably it is a problem on the Kerberos client (that is: Firefox/
NegotiateAuth/GSS-API lib).
That's why the KDC does not log any GSSAPI request (SPNEGO request)
But i didn't find any workaround...
Russ Allbery
> Thanks, Russ !
> Your opinion concerning my logs leads me a little.
> Probably it is a problem on the Kerberos client (that is: Firefox/
> NegotiateAuth/GSS-API lib).
> That's why the KDC does not log any GSSAPI request (SPNEGO request)
> But i didn't find any workaround...
Some things to double-check: Are the Kerberos libraries installed on the
client? If the client is a Linux system, are the Kerberos development
libraries installed on the client? (At least some builds of Firefox on
some Linux distributions have tried to load the *.so name instead of the
full library name, which doesn't exist unless the development package is
installed.) Are you certain Firefox is built with Negotiate-Auth GSSAPI
support on the client?
Sylvain RICHET
Hi Russ,
According to [https://developer.mozilla.org/En/
Integrated_Authentication], if i well understand, Firefox doesn't
need to be rebuilt for NegotiateAuth support.
NegotiateAuth has just to be configured with network.nego* directives
(in about:config).
Russ Allbery
> According to [https://developer.mozilla.org/En/
> Integrated_Authentication], if i well understand, Firefox doesn't
> need to be rebuilt for NegotiateAuth support.
> NegotiateAuth has just to be configured with network.nego* directives
> (in about:config).
That page doesn't discuss how to configure Firefox to find the GSS-API
library on UNIX at run-time, which makes me think there's still some
compile-time default at work. It may be that you can manually configure
the location of the library and Firefox always builds with the relevant
bit of dynamic glue, even if the library wasn't found at compile time, but
I wouldn't know without looking in more detail at the source.
Phil Pishioneri
> That page doesn't discuss how to configure Firefox to find the GSS-API
Firefox config preference is named "network.negotiate-auth.gsslib".
-Phil
Sylvain RICHET
Hi Phil,
Indeed, i have already tried to set Firefox entries like this :
> network.negotiate-auth.using-native-gsslib = false
> network.negotiate-auth.gsslib = /usr/lib/libgssapi_krb5.so.2.2
But nothing better !
So i set back (reset) this entries
I have also heard about an entry named "network.auth.use-sspi".
(e.g see: http://www.helpdesk.umd.edu/topics/applications/kerberos/4782/)
But it doesn't appear in Firefox/Ubuntu(Linux).
Many browse, but still no workaround.
Following Russ advice, I'm going to look for the way to compile
Firefox with GSSAPI/NegotiateAuth option...
Sylvain RICHET
SO...
Following these docs...
https://developer.mozilla.org/En/Configuring_Build_Options
https://developer.mozilla.org/En/Simple_Firefox_build
... i have rebuild Firefox with a .mozconfig file like this :
[...]
ac_add_options --enable-application=browser
ac_add_options --enable-debug
ac_add_options --enable-negotiateauth
ac_add_options --disable-tests
[...]
... and test again with the new binary of Firefox (Help > About:
"Minefield")
As you can see, "negotiateauth" should have been enabled.
BUT : nothing else better !
Damned !
:-(
Douglas E. Engert
Sylvain RICHET wrote:
> On 11 jan, 21:47, Phil Pishioneri <p...@psu.edu> wrote:
>> On 1/11/10 12:40 PM, Russ Allbery wrote:
>>
>>> That page doesn't discuss how to configure Firefox to find the GSS-API
>>> library on UNIX at run-time, ...
>> Firefox config preference is named "network.negotiate-auth.gsslib".
>>
>> -Phil
>
> Hi Phil,
>
> Indeed, i have already tried to set Firefox entries like this :
> > network.negotiate-auth.using-native-gsslib = false
> > network.negotiate-auth.gsslib = /usr/lib/libgssapi_krb5.so.2.2
>
> But nothing better !
Since you said rebuilding did not help, some other simple questions to ask:
Have you tried Wireshark or other analyzer to see what might be going on?
Do you have a krb5.conf file?
Does the web server support GSS? What is the server?
Does the client have user credentials? (klist)
Have you posted the problem on modauthk...@lists.sourceforge.net
(I expect most of the people are on this list too.)
Since you built FireFox, what code did it use for the native-gsslib?
Is it Java?
> So i set back (reset) this entries
>
> I have also heard about an entry named "network.auth.use-sspi".
> (e.g see: http://www.helpdesk.umd.edu/topics/applications/kerberos/4782/)
SSPI is the native Microsoft API that can inter operate with the GSS-API on
other platforms.
Does the Kerberos you are trying to use o the client have support for SPNEGO?
> But it doesn't appear in Firefox/Ubuntu(Linux).
>
> Many browse, but still no workaround.
> Following Russ advice, I'm going to look for the way to compile
> Firefox with GSSAPI/NegotiateAuth option...
>
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Sylvain RICHET
> Have you tried Wireshark or other analyzer to see what might be going on?
Yes, a lot.
> Do you have a krb5.conf file?
Yes of course, there is a krb5.conf file on client machine.
> Does the web server support GSS? What is the server?
Apache/2.2.12 (Ubuntu), with mod_auth_kerb.
I suppose that, whether Apache2 can plug a kerberos module, then it
supports GSS ?...
> Does the client have user credentials? (klist)
1) The client have the keytab with the entry concerning the targeted
service.
2) The client user has credentials in KDC. On KDC server, kinit
(user) / klist commands show the user.
> Have you posted the problem on modauthkerb-h...@lists.sourceforge.net
> (I expect most of the people are on this list too.)
I subscribed last week, and I have already tried to... but i'm "read-
only" on that list
(how to get POST authorization ? i don't know...)
> Since you built FireFox, what code did it use for the native-gsslib?
> Is it Java?
sorry, I don't understand what you mean because i do not have any
specific idea on how it works.
I just noticed there's an "negotiateauth" to enable... (if not yet
enable in Firefox Ubuntu version !)
Douglas E. Engert
Sylvain RICHET wrote:
> Hi Douglas,
>
>> Have you tried Wireshark or other analyzer to see what might be going on?
> Yes, a lot.
>
>> Do you have a krb5.conf file?
> Yes of course, there is a krb5.conf file on client machine.
>
>> Does the web server support GSS? What is the server?
> Apache/2.2.12 (Ubuntu), with mod_auth_kerb.
> I suppose that, whether Apache2 can plug a kerberos module, then it
> supports GSS ?...
>
>> Does the client have user credentials? (klist)
> 1) The client have the keytab with the entry concerning the targeted
> service.
The client should *not* have the keytab, the web server has to have
the keytab with an HTTP/fqdn.of.server@realm principal.
> 2) The client user has credentials in KDC. On KDC server, kinit
> (user) / klist commands show the user.
What does klist on client show? The user on the client has to
have have tickets, usually by kinit, login (pam_krb5) or ssh delegation.
>
>> Have you posted the problem on modauthkerb-h...@lists.sourceforge.net
>> (I expect most of the people are on this list too.)
> I subscribed last week, and I have already tried to... but i'm "read-
> only" on that list
> (how to get POST authorization ? i don't know...)
>
>> Since you built FireFox, what code did it use for the native-gsslib?
>> Is it Java?
> sorry, I don't understand what you mean because i do not have any
> specific idea on how it works.
I thought you said you complied FireFox. I was asking does FireFox
use its own Kerberos libraries, of Java versions of Kerberos?
> I just noticed there's an "negotiateauth" to enable... (if not yet
> enable in Firefox Ubuntu version !)
What "negotiateauth"???
Do you mean in the about:config page, one of the network.negotiate-auth.*
options? Or is this something else?
Sylvain RICHET
> the keytab with an HTTP/fqdn.of.server@realm principal.
with an entry for the requested service (HTTP/fqdn...)
>> 2) The client user has credentials in KDC. On KDC server, kinit
>> (user) / klist commands show the user.
> What does klist on client show? The user on the client has to
> have have tickets, usually by kinit, login (pam_krb5) or ssh delegation.
VERY relevant question !
It becomes clear that, with a Linux Client, something has to glue
(just like it is in w2k environment, at the session init, in
interaction with the domain controler)
On linux client, this *something* is precisely : kinit !
So, i have launched a kinit command on my Firefox (Ubuntu) client.
And then, sniffing with WireShark shows me that the SPNEGO token is
transmitted in headers :
[...]
Authorization: Negotiate YII....
[...]
In Firefox log (easily enabled by command : export
NSPR_LOG_MODULES=negotiateauth:5;export NSPR_LOG_FILE=/tmp/
negociateauth.log)
no more error like :
"gss_init_sec_context() failed: Unspecified GSS failure. Minor code
may provide more information SPNEGO cannot find mechanisms to
negotiate..."
Everything seems to be ok.
> I thought you said you complied FireFox. I was asking does FireFox
> use its own Kerberos libraries, of Java versions of Kerberos?
No response yet to this question
> What "negotiateauth"???
> Do you mean in the about:config page, one of the network.negotiate-auth.*
> options? Or is this something else?
NegociateAuth is the firefox side extension for GSS-API support.
Even if [network.nego*] were visible in "about:config",
it wasn't sure that this extension was enabled by default in the
Ubuntu Firefox binary.
A previous post from Russ suggested me to re-compile Firefox, with
this extension enabled.
If you donwload Firefox sources, you will find this extension in :
./mozilla-central/extensions/auth.
But, finally, no need to do all this stuff.
Just a matter of kinit to launch on client side !!
Once again, thanks a lot, Douglas.
Russ Allbery
> VERY relevant question !
> It becomes clear that, with a Linux Client, something has to glue
> (just like it is in w2k environment, at the session init, in
> interaction with the domain controler)
> On linux client, this *something* is precisely : kinit !
> So, i have launched a kinit command on my Firefox (Ubuntu) client.
> And then, sniffing with WireShark shows me that the SPNEGO token is
> transmitted in headers :
> [...]
> Authorization: Negotiate YII....
> [...]
> In Firefox log (easily enabled by command : export
> NSPR_LOG_MODULES=negotiateauth:5;export NSPR_LOG_FILE=/tmp/
> negociateauth.log)
> no more error like :
> "gss_init_sec_context() failed: Unspecified GSS failure. Minor code
> may provide more information SPNEGO cannot find mechanisms to
> negotiate..."
> Everything seems to be ok.
Something to watch out for: in the past, with at least some builds of
Firefox, I've found that I needed to have a valid ticket cache *before* I
start Firefox, or at least before the first time Firefox encounters
Negotiate-Auth, or something internally caches the fact that Kerberos
authentication doesn't work and then will never try again.
Sylvain RICHET
That's why in need to launch a kinit command, before Firefox,
in order to get a local ticket cache.
Without cache, as i mentionned in my first pot, NegotiateAuth log
displays :
[...]
-1217141024[b742e1c0]: gss_init_sec_context() failed: Unspecified GSS
failure. Minor code may provide more information
SPNEGO cannot find mechanisms to negotiate
[...]
Martijn van Brummelen
Hi,
Sylvain RICHET-5 wrote:
>
> Any help would be deeply appreciated.
> Thanks in advance
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
I had the same problem/error and fixed it by adding "allow_weak_crypto =
true" under [libdefaults] in /etc/krb5.conf
This works for me, at least on Debian Squeeze, Ubuntu Karmic, and Ubuntu
Lucid.
This was announced in /usr/share/doc/libkrb5-3/NEWS.Debian.gz.
Hope this helps.
Regards,
Martijn van Brummelen
--
View this message in context: http://old.nabble.com/Pending-%22gss_init_sec_context%28%29-failed%3A-Unspecified-GSS-failure....%22-tp27065502p28912771.html
Sent from the Kerberos - General mailing list archive at Nabble.com.