Hi Greg,
Thanks for the response.
Still getting this error with gss_acquire_cred ():
*GSS-API error gss_accept_sec_context: d: Unspecified GSS failure.
Minor code may provide more information *
*GSS-API error gss_accept_sec_context: 186a5 : Request ticket server
HTTP/krbsite.krb.local
auses some of the
authentication requests to fail and it throws this error
There is no global variable named default_keytab_name in MIT krb5.
There is a krb5.conf configuration variable with this name, but it is
never changed by the GSS or Kerberos libraries.
*"GSS-API error gss_acc
n requests to fail and it throws this error
*"GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not
found in keytab" *(major code - 186a5, d)
Using this api *krb5_gss_register_acceptor_identity() *to set the default
keytab file for kerberos authentication.
It seems t
when sending multiple authentication requests (around 200
requests) for the same service from different client machines while users
are already domain users.
*GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not
found in keytab*
Probability of this issue occurring is around 20% only
other
resource for looking at AD/Mit KRB5.
-Original Message-
From: Greg Hudson [mailto:ghud...@mit.edu]
Sent: Thursday, January 15, 2015 11:49 PM
To: Xie, Hugh; 'kerberos@mit.edu'
Subject: Re: Wrong principal in request error on gss_accept_sec_context()
On 01/15/2015 05:18 PM, Xie, Hugh
, January 05, 2015 9:37 PM
To: Greg Hudson; 'kerberos@mit.edu'
Subject: RE: Wrong principal in request error on gss_accept_sec_context()
1. /efs/dist/kerberos/mit/1.11.5/exec/bin/klist -k -t $KRB5_KTNAME Keytab name:
FILE: /tmp/myacct.keytab
KVNO Timestamp Principal
, January 15, 2015 10:38 AM
To: Greg Hudson; 'kerberos@mit.edu'
Subject: RE: Wrong principal in request error on gss_accept_sec_context()
Kvno returns 15. I created a new entry HTTP/host2.site123.baml.com @
COMMON.BANKOFAMERICA.COM in keytab with kvno = 15. I still get the same wrong
principal error
On 01/15/2015 05:18 PM, Xie, Hugh wrote:
I upgrade the version of krb5 lib to version 1.13. Got more specific error:
Request ticket server HTTP/ host2.site123.baml@common.bankofamerica.com
kvno 15 enctype rc4-hmac found in keytab but cannot decrypt ticket
Any idea?
Whatever procedure
'
Subject: RE: Wrong principal in request error on gss_accept_sec_context()
To clarify the confusion, I am merely mentioning the same server myacct works
on one server but does not work in another server.
I added a new keytab entry HTTP/host2.site123.baml.com @
COMMON.BANKOFAMERICA.COM. The same
-
From: Greg Hudson [mailto:ghud...@mit.edu]
Sent: Tuesday, January 06, 2015 1:52 PM
To: Xie, Hugh; 'kerberos@mit.edu'
Subject: Re: Wrong principal in request error on gss_accept_sec_context()
On 01/05/2015 09:36 PM, Xie, Hugh wrote:
1. /efs/dist/kerberos/mit/1.11.5/exec/bin/klist -k -t
On 01/05/2015 04:04 PM, Xie, Hugh wrote:
Any follow up on this issue? Do you need any more information? Should I turn
on debugger to see where this error occurred, if yes I need some pointer
which files to set break points.
I'm a bit confused by the information given so far, and I think some
on gss_accept_sec_context()
On 01/05/2015 04:04 PM, Xie, Hugh wrote:
Any follow up on this issue? Do you need any more information? Should I turn
on debugger to see where this error occurred, if yes I need some pointer
which files to set break points.
I'm a bit confused by the information given so far
On 12/19/2014 01:33 PM, Xie, Hugh wrote:
We are using the same account on both hosts the Principal in the keytab is
mya...@common.bankofamerica.com
The service ticket on the clients has the principal of:
HTTP/host1.bankofamerica.com @ COMMON.BANKOFAMERICA.COM
HTTP/host2.site123.baml.com @
On 12/18/2014 02:02 PM, Xie, Hugh wrote:
I am getting Wrong principal in request error on gss_accept_sec_context()
on one host but does not on another. I verified /etc/hosts, both host conform
to this format
# Default /etc/hosts file
127.0.0.1 localhost.localdomain localhost
to create the verifier_cred_handle argument
of gss_accept_sec_context?
The application is custom app running under python. If you meant
acceptor_cred_handle, it is generated with the following with the following
code:
maj_stat = gss_acquire_cred(min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE
argument of gss_accept_sec_context?
The application is custom app running under python. If you meant
acceptor_cred_handle, it is generated with the following with the following
code:
maj_stat = gss_acquire_cred(min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE
]
Sent: Friday, December 19, 2014 12:11 PM
To: Xie, Hugh; kerberos@mit.edu
Subject: Re: Wrong principal in request error on gss_accept_sec_context()
When you try to connect to the non-working server on the client, what service
ticket appears in the cache as reported by klist? How does this compare
@ COMMON.BANKOFAMERICA.COM
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Friday, December 19, 2014 1:33 PM
To: Greg Hudson; kerberos@mit.edu
Subject: RE: Wrong principal in request error on gss_accept_sec_context()
We are using
Hi,
I am getting Wrong principal in request error on gss_accept_sec_context() on
one host but does not on another. I verified /etc/hosts, both host conform to
this format
# Default /etc/hosts file
127.0.0.1 localhost.localdomain localhost
123.150.123.123 myhost.bankdomain.com myhost
credential from gss_accept_sec_context()
On 10/08/2014 05:45 PM, Xie, Hugh wrote:
My mistake. The error is from * gss_inquire_context(min_stat,
state-context, gssuser, NULL, NULL, NULL, NULL, NULL, NULL);* post call to
* gss_init_sec_context*. Can I still call this function post
On 10/09/2014 07:12 AM, Xie, Hugh wrote:
Perhaps this is a bug. Gss_init_sec_context did return GSS_S_COMPLETE
for me.
I don't think we have a bug such that gss_inquire_context on an
established context would return GSS_S_NO_CONTEXT, no; that would show
up in our automated tests. Make sure
1,3,2,4 or 1,3,4,2, then the error disappear.
-Original Message-
From: Greg Hudson [mailto:ghud...@mit.edu]
Sent: Thursday, October 09, 2014 12:45 PM
To: Xie, Hugh; 'Kerberos@mit.edu'
Subject: Re: Not getting delegation credential from gss_accept_sec_context()
On 10/09/2014 07:12 AM, Xie
from gss_accept_sec_context()
Found the issue. It is order the function calls that matters:
Here is the order of call that produced the error:
1. gss_init_sec_context
2. gss_release_cred on the deleted_cred_handle (passed to #1 call) 3.
gss_release_cred on output_token 4. gss_inquire_context
If I
We are using version 1.9.1. When I turn on backback in debugger, I see the
gss_accept_sec_context was in turn called internally inside spnego_mech.c that
pass a NULL verifier_cred_handle krb5_gss_accept_sec_context_ext. Anyway I can
resolve this issue? Here are the full backtrace:
(gdb
On 10/08/2014 10:29 AM, Xie, Hugh wrote:
We are using version 1.9.1. When I turn on backback in debugger, I see the
gss_accept_sec_context was in turn called internally inside spnego_mech.c
that pass a NULL verifier_cred_handle krb5_gss_accept_sec_context_ext. Anyway
I can resolve
gss_accept_sec_context()
We are using version 1.9.1. When I turn on backback in debugger, I see the
gss_accept_sec_context was in turn called internally inside spnego_mech.c that
pass a NULL verifier_cred_handle krb5_gss_accept_sec_context_ext. Anyway I can
resolve this issue? Here are the full
After switching version 1.12.2, as a follow up question to the next step of
S4U2Proxy.
I passed the delegated_cred_handle from *gss_accept_sec_context()* to
*gss_init_sec_context*. I got a No context has been established error since
the context_handle is reinitialized to GSS_C_NO_CONTEXT
On 10/08/2014 03:41 PM, Xie, Hugh wrote:
After switching version 1.12.2, as a follow up question to the next step of
S4U2Proxy.
I passed the delegated_cred_handle from *gss_accept_sec_context()* to
*gss_init_sec_context*. I got a No context has been established error since
That was what I did. Both context_handle for *gss_accept_sec_context()* and
then * gss_init_sec_context* were initialized to GSS_C_NO_CONTEXT and the
address of context_handle are passed to these functions. I am getting error
No context has been established and Attempt to use incomplete
...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Wednesday, October 08, 2014 5:23 PM
To: Greg Hudson; Kerberos@mit.edu
Subject: RE: Not getting delegation credential from gss_accept_sec_context()
That was what I did. Both context_handle for *gss_accept_sec_context
On 10/08/2014 05:45 PM, Xie, Hugh wrote:
My mistake. The error is from * gss_inquire_context(min_stat,
state-context, gssuser, NULL, NULL, NULL, NULL, NULL, NULL);* post call to
* gss_init_sec_context*. Can I still call this function post
gss_init_sec_context with delegate handle?
Our
,
ticket, deleg_cred,
context);
if (GSS_ERROR(major_status))
goto fail;
ctx-gss_flags |= GSS_C_DELEG_FLAG;
}
*
I created some printf to check verifier_cred_handle I passed into
*gss_accept_sec_context()* are set back
On 10/06/2014 04:49 PM, Xie, Hugh wrote:
I created some printf to check verifier_cred_handle I passed into
*gss_accept_sec_context()* are set back to GSS_C_NO_CREDENTIAL once it reach
kg_accept_krb5(). That in turn cause one of the condition * cred-usage ==
GSS_C_BOTH * to be false. I
Hi,
Any conclusion on this discussion. I am facing the similar problem with
1.9.5.
My application works fine with 1.5.3 but when I upgraded to 1.9.5 then the
thread making a call to gss_accept_sec_context is hanging.
The hang is at:
File: src/include/k5-thread.h
Function:
static inline int
On Jul 20, 2011, at 1:07 AM, Greg Hudson wrote:
On Tue, 2011-07-19 at 16:21 -0400, Benjamin Coddington wrote:
gss_acquire_cred
gss_accept_sec_context
gss_export_lucid_sec_context
gss_delete_sec_context
I found that before we got to gss_delete_sec_context(), we had already
tried to clean up
On Jul 14, 2011, at 9:40 AM, Greg Hudson wrote:
On Wed, 2011-07-13 at 15:33 -0400, Benjamin Coddington wrote:
Anyway, calling gss_accept_sec_context this way allows svcgssd to
create a context for any requested service name -- but the problem we
found is that svcgssd opens the kerberos replay
On Tue, 2011-07-19 at 16:21 -0400, Benjamin Coddington wrote:
gss_acquire_cred
gss_accept_sec_context
gss_export_lucid_sec_context
gss_delete_sec_context
I found that before we got to gss_delete_sec_context(), we had already
tried to clean up the context in gss_krb5_export_lucid_sec_context
On Wed, 2011-07-13 at 15:33 -0400, Benjamin Coddington wrote:
Anyway, calling gss_accept_sec_context this way allows svcgssd to
create a context for any requested service name -- but the problem we
found is that svcgssd opens the kerberos replay cache for every
context/cred created, eventually
I am working on a linux NFS cluster that requires a single svcgssd to establish
contexts under multiple service names.
In this scenario, svcgssd can be started with -n so that it acquires creds at
context creation.
The behavior with -n is to call gss_accept_sec_context() with a NULL
-- Forwarded message --
From: michelle zhao michelle.z...@gmail.com
Date: Tue, May 3, 2011 at 4:07 PM
Subject: gss_accept_sec_context() error in v1.9
To:
Cc: krb...@mit.edu
Hi, there,
I'm trying to upgrade our krb5 library from 1.6.4 to 1.9.
The function that used to work
Hello,
I am having the same problem reported by jean-Yves two monthes ago:
http://mailman.mit.edu/pipermail/kerberos/2010-September/016493.html
After the krb library upgrades, the gss_accept_sec_context() fails with
minor status code 13 and the system I am running is CentOS. I wonder
machine) using Internet
explorer I get the following error
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may
provide more information (Unknown code krb5 230)
Can somebody please help?
Kerberos mailing list Kerberos
KRB5 GSS-API
[Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1282):
[client *.*.*.*] Verification returned code 851968
[Tue Feb 03 10:41:21 2009] [error] [client *.*.*.*] gss_accept_sec_context()
failed: Unspecified GSS failure. Minor code may provide more information
(Unknown code krb5 230
/mod_auth_kerb.c(1266):
[client *.*.*.*] Verifying client data using KRB5 GSS-API
[Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1282):
[client *.*.*.*] Verification returned code 851968
[Tue Feb 03 10:41:21 2009] [error] [client *.*.*.*]
gss_accept_sec_context()
failed: Unspecified GSS failure
):
[client *.*.*.*] Verification returned code 851968
[Tue Feb 03 10:41:21 2009] [error] [client *.*.*.*]
gss_accept_sec_context()
failed: Unspecified GSS failure. Minor code may provide more information
(Unknown code krb5 230)
There may be some problem with initialization causing the error
request.
But it does not work. I don't get authorized HTTP access.
In Apache's error_log I find:
gss_accept_sec_context() failed: Unspecified GSS failure. Minor
code may provide more information (, Decrypt integrity check failed)
Are you sure that the keytab specified by Krb5Keytab is consistent
HTTP access.
In Apache's error_log I find:
gss_accept_sec_context() failed: Unspecified GSS failure. Minor
code may provide more information (, Decrypt integrity check failed)
Are you sure that the keytab specified by Krb5Keytab is consistent
with the HTTP service principal that is in AD
.
The web browser is Seamonkey and it already sends the
Authorization: Negotiate YIIE0AYGKwYBBQ[..]
in the HTTP request.
But it does not work. I don't get authorized HTTP access.
In Apache's error_log I find:
gss_accept_sec_context() failed: Unspecified GSS failure. Minor
code may provide more
:
gss_accept_sec_context() failed: Unspecified GSS failure. Minor
code may provide more information (, Decrypt integrity check failed)
Are you sure that the keytab specified by Krb5Keytab is consistent
with the HTTP service principal that is in AD? That message is the
same as saying your password is wrong
Hi,
I would like to know when gss_accept_sec_context returns
GSS_S_CONTINUE_NEEDED ?
--
View this message in context:
http://www.nabble.com/gss_accept_sec_context-tp19345844p19345844.html
Sent from the Kerberos - General mailing list archive at Nabble.com
wrapped around the whole process. I am running into a problem though
where gss_accept_sec_context will sometimes return properly and let
everything go through. Other times it will return with a major error
of 851968 (Unexpected error) and a minor error of 0 (No error).
Needless to say
my mind
wrapped around the whole process. I am running into a problem though
where gss_accept_sec_context will sometimes return properly and let
everything go through. Other times it will return with a major error
of 851968 (Unexpected error) and a minor error of 0 (No error
properly.
However, at the server end..after succesfully executing gss_acquire_cred(),
I am failing in gss_accept_sec_context with maj_stat: 851968, min_stat:
-1765328154
However, after some googling... I can see that kerberos error code goes only
as far as -1765328157L...
It looks like a big
from the klist that
the service ticket is generated properly.
However, at the server end..after succesfully executing gss_acquire_cred(),
I am failing in gss_accept_sec_context with maj_stat: 851968, min_stat:
-1765328154
However, after some googling... I can see that kerberos error code goes
On 11/2/07, Manoj Mohan [EMAIL PROTECTED] wrote:
Thanks Kevin.. that suggestion helped a lot!!
when I did ktutil of my keytab file.. I had 2 entries (with KVNO 2)...
I deleted the file and recreated it with ktadd but with -e option to add
only one
encryption type and then the
On Nov 2, 2007, at 13:54, Kevin Coffman wrote:
On 11/2/07, Manoj Mohan [EMAIL PROTECTED] wrote:
when I did ktutil of my keytab file.. I had 2 entries (with KVNO
2)...
I deleted the file and recreated it with ktadd but with -e option
to add only one
encryption type and then the
On Fri, Nov 02, 2007 at 01:54:07PM -0400, Kevin Coffman wrote:
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ktadd does not look at those enctype definitions on the local machine
where you run ktadd. What is used is the supported_enctypes defined
for the realm
Hi,
I'm am trying to change the behavior of a functioning GSS-enabled
application server such that the server principal and corresponding
keytab entry used by gss_accept_sec_context is determined dynamically
based on the server principal named in the client's ticket (implicitly
specified
Cesar == Cesar Garcia [EMAIL PROTECTED] writes:
Cesar Hi, I'm am trying to change the behavior of a functioning
Cesar GSS-enabled application server such that the server
Cesar principal and corresponding keytab entry used by
Cesar gss_accept_sec_context is determined dynamically
Dear all
Sorry to ask such a simple question, but I just want to be certain of this.
I called gss_accept_sec_context and received a return value of 851968
(0xd). Can anyone decipher what this means in terms of result codes, as
I seem to have difficulty in interpreting the codes in gssapi.h
60 matches
Mail list logo
