Re: GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not found in keytab
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@KRB.LOCAL not found in keytab (ticket kvno 4)*
Sequence of gss apis call for this kerberos authentication :
krb5_gss_register_acceptor_identity();
gss_import_name();
gss_acquire_cred();
gss_accept_sec_context();
*Note : After merging both keytab files this issue did not occured.*
>>
When using gss_acquire_cred_from() in place of gss_acquire_cred() getting
below error :
One additional argument in gss_acquire_cred_from() that is
"*gss_const_key_value_set_t
cred_store"* where specified keytab name when acquiring credentials.
Is there any loop (upto count no.) needed to run for
multiple authentication requests for different services ?
*GSS-API error gss_acquire_cred_from: d : Unspecified GSS failure.
Minor code may provide more information *
*GSS-API error gss_acquire_cred_from: 25ea101: No key table entry found
matching HTTP/**krbsite.krb.local@*
It seems file based keytab is not updated for every kerberos
authentication call.
Is the gss_acquire_cred_from() call still required to call
krb5_gss_register_acceptor_identity or not ?
Thanks,
On Sat, 12 Nov 2022 at 00:14, Greg Hudson wrote:
> On 11/11/22 10:33, Kerberos Enthusiast wrote:
> > It seems, if multiple servers supply separate keytabs, then the
> > subsequent kerberos auth request targeted for multiple kerberos servers
> > with separate keytabs and application keep on
> > updating "default_keytab_name" global variable and it causes 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_accept_sec_context: Request ticket server HTTP/ not
> > found in keytab" *(major code - 186a5, d)
>
> This message is a little bit puzzling, because the principal name
> ("HTTP/") is incomplete, and because the message of this form in the
> code includes a parenthetical about the ticket kvno.
>
> > Using this api *krb5_gss_register_acceptor_identity() *to set the default
> > keytab file for kerberos authentication.
>
> This function sets a thread-specific global variable. It should work to
> invoke it before each call to gss_acquire_cred(), or before each call to
> gss_accept_sec_context() using the default acceptor credential. Or:
>
> > Can we use any other gss_api to maintain the local context of the keytab
> > file and send this keytab for every authentication request?
>
> gss_acquire_cred_from() allows the caller to specify a keytab name when
> acquiring credentials. See:
>
>
> https://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html#credential-store-extensions
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not found in keytab
On 11/11/22 10:33, Kerberos Enthusiast wrote:
It seems, if multiple servers supply separate keytabs, then the
subsequent kerberos auth request targeted for multiple kerberos servers
with separate keytabs and application keep on
updating "default_keytab_name" global variable and it causes 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_accept_sec_context: Request ticket server HTTP/ not
found in keytab" *(major code - 186a5, d)
This message is a little bit puzzling, because the principal name
("HTTP/") is incomplete, and because the message of this form in the
code includes a parenthetical about the ticket kvno.
Using this api *krb5_gss_register_acceptor_identity() *to set the default
keytab file for kerberos authentication.
This function sets a thread-specific global variable. It should work to
invoke it before each call to gss_acquire_cred(), or before each call to
gss_accept_sec_context() using the default acceptor credential. Or:
Can we use any other gss_api to maintain the local context of the keytab
file and send this keytab for every authentication request?
gss_acquire_cred_from() allows the caller to specify a keytab name when
acquiring credentials. See:
https://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html#credential-store-extensions
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not found in keytab
Hello Kerberos, It seems, if multiple servers supply separate keytabs, then the subsequent kerberos auth request targeted for multiple kerberos servers with separate keytabs and application keep on updating "default_keytab_name" global variable and it causes some of the authentication 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 to be a single global keytab file used by the krb5 library. Can we use any other gss_api to maintain the local context of the keytab file and send this keytab for every authentication request? Thanks, On Fri, 11 Nov 2022 at 19:20, Kerberos Enthusiast < kerberos.enthusi...@gmail.com> wrote: > Hello Kerberos, > > I am trying to make a windows client authenticate with an authentication > server(using AD machine for KDC) to access multiple services. > There is a multiple keytab file per authentication server. > > But I'm facing this error below, while this does not occur every time, it > occurred 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. > > Using GSS-API to acquire cred : gss_acquire_cred(). > For loading keytab file : krb5_gss_register_acceptor_idennntity(). > > How can we resolve this? > Can we use any other GSS-API in place of this? > > Thanks, > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
GSS-API error gss_accept_sec_context: Request ticket server HTTP/ not found in keytab
Hello Kerberos, I am trying to make a windows client authenticate with an authentication server(using AD machine for KDC) to access multiple services. There is a multiple keytab file per authentication server. But I'm facing this error below, while this does not occur every time, it occurred 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. Using GSS-API to acquire cred : gss_acquire_cred(). For loading keytab file : krb5_gss_register_acceptor_idennntity(). How can we resolve this? Can we use any other GSS-API in place of this? Thanks, Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Wrong principal in request error on gss_accept_sec_context()
It has nothing to do with keytabs. The problem seems to go away once we use setspn to create the SPN under the same unix account in AD. The spn mapping does exists from host-HTTP, so in theory we should not have to create SPN. Anyway, I need to raise this question to Microsoft unless you know 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 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 you are using to generate the keytab entry is not generating the same key as the one present on the KDC. I am not personally very familiar with creating keytabs for use with Active Directory KDCs, but I know a lot of people use msktutil for that purpose, rather than ktutil. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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 -Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Xie, Hugh Sent: Monday, 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 --- -- 2 12/17/2014 15:30:08 mya...@common.bankofamerica.com 2. This is window client output recorded at the time: Cached Tickets: (2) #0 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: krbtgt/COMMON.BANKOFAMERICA.COM @ COMMON.BANKOFAMERICA.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40e0 - forwardable renewable initial pre_authen Start Time: 12/18/2014 13:13:36 (local) End Time: 12/18/2014 22:13:36 (local) Renew Time: 12/28/2014 13:13:36 (local) Session Key Type: RSADSI RC4-HMAC(NT) #1 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40a0 - forwardable renewable pre_authent Start Time: 12/18/2014 13:13:36 (local) End Time: 12/18/2014 21:33:36 (local) Renew Time: 12/28/2014 13:13:36 (local) Session Key Type: RSADSI RC4-HMAC(NT) 3. What is the window equivalent command on windows? -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Monday, January 05, 2015 5:12 PM To: Xie, Hugh; 'kerberos@mit.edu' Subject: Re: Wrong principal in request error 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, and I think some of my questions weren't clear enough. Let's start over. For the non-working server only: 1. On the server, run klist -k (or klist -k -t /path/to/keytab if the server is using a special keytab location). What is the output? 2. On the client, run kinit so that you have a fresh credential cache, then try to connect. Then run klist. Other than krbtgt/common.bankofamerica@common.bankofamerica.com, what service principal appears in the output? 3. On the client, run kvno SPRINC, where SPRINC is the answer to question 2. What is the output? -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Wrong principal in request error on gss_accept_sec_context()
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? -Original Message- From: Xie, Hugh Sent: Thursday, 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 -Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Xie, Hugh Sent: Monday, 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 --- -- 2 12/17/2014 15:30:08 mya...@common.bankofamerica.com 2. This is window client output recorded at the time: Cached Tickets: (2) #0 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: krbtgt/COMMON.BANKOFAMERICA.COM @ COMMON.BANKOFAMERICA.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40e0 - forwardable renewable initial pre_authen Start Time: 12/18/2014 13:13:36 (local) End Time: 12/18/2014 22:13:36 (local) Renew Time: 12/28/2014 13:13:36 (local) Session Key Type: RSADSI RC4-HMAC(NT) #1 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40a0 - forwardable renewable pre_authent Start Time: 12/18/2014 13:13:36 (local) End Time: 12/18/2014 21:33:36 (local) Renew Time: 12/28/2014 13:13:36 (local) Session Key Type: RSADSI RC4-HMAC(NT) 3. What is the window equivalent command on windows? -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Monday, January 05, 2015 5:12 PM To: Xie, Hugh; 'kerberos@mit.edu' Subject: Re: Wrong principal in request error 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, and I think some of my questions weren't clear enough. Let's start over. For the non-working server only: 1. On the server, run klist -k (or klist -k -t /path/to/keytab if the server is using a special keytab location). What is the output? 2. On the client, run kinit so that you have a fresh credential cache, then try to connect. Then run klist. Other than krbtgt/common.bankofamerica@common.bankofamerica.com, what service principal appears in the output? 3. On the client, run kvno SPRINC, where SPRINC is the answer to question 2. What is the output? -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Wrong principal in request error on gss_accept_sec_context()
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 you are using to generate the keytab entry is not generating the same key as the one present on the KDC. I am not personally very familiar with creating keytabs for use with Active Directory KDCs, but I know a lot of people use msktutil for that purpose, rather than ktutil. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Wrong principal in request error on gss_accept_sec_context()
To isolate this issue further, I set debugger to the following function that return KRB5KRB_AP_WRONG_PRINC ./lib/krb5/krb/srv_dec_tkt.c:krb5_server_decrypt_ticket_keytab() ./lib/krb5/krb/rd_req_dec.c:decrypt_ticket() ./lib/krb5/krb/pac.c:k5_pac_validate_client() ./lib/krb5/krb/s4u_creds.c:krb5_get_self_cred_from_kdc() Gdb does seems stop at any one of the functions. Please provide pointer. Thanks. -Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Xie, Hugh Sent: Monday, January 12, 2015 4:44 PM To: Greg Hudson; 'kerberos@mit.edu' 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 error still exists, did not make much difference. -Original Message- 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 $KRB5_KTNAME Keytab name: FILE: /tmp/myacct.keytab KVNO Timestamp Principal --- -- 2 12/17/2014 15:30:08 mya...@common.bankofamerica.com [In the klist output:] #1 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM If the client is authenticating to HTTP/host2.site123.baml.com then the server needs that key in its keytab, though it doesn't have to be listed under that name. From the information given so far, I cannot tell whether the myacct key ought to be the same as the HTTP/host2.site123.baml.com key through some kind of principal aliasing. I am particularly confused by these two statements: On Fri Dec 19 13:33:11 EST 2014: We are using the same account on both hosts the Principal in the keytab is myacct at COMMON.BANKOFAMERICA.COM On: Sat Dec 20 21:28:33 EST 2014 No it is different computer accounts. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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 error still exists, did not make much difference. -Original Message- 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 $KRB5_KTNAME Keytab name: FILE: /tmp/myacct.keytab KVNO Timestamp Principal --- -- 2 12/17/2014 15:30:08 mya...@common.bankofamerica.com [In the klist output:] #1 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM If the client is authenticating to HTTP/host2.site123.baml.com then the server needs that key in its keytab, though it doesn't have to be listed under that name. From the information given so far, I cannot tell whether the myacct key ought to be the same as the HTTP/host2.site123.baml.com key through some kind of principal aliasing. I am particularly confused by these two statements: On Fri Dec 19 13:33:11 EST 2014: We are using the same account on both hosts the Principal in the keytab is myacct at COMMON.BANKOFAMERICA.COM On: Sat Dec 20 21:28:33 EST 2014 No it is different computer accounts. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Wrong principal in request error 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, and I think some of my questions weren't clear enough. Let's start over. For the non-working server only: 1. On the server, run klist -k (or klist -k -t /path/to/keytab if the server is using a special keytab location). What is the output? 2. On the client, run kinit so that you have a fresh credential cache, then try to connect. Then run klist. Other than krbtgt/common.bankofamerica@common.bankofamerica.com, what service principal appears in the output? 3. On the client, run kvno SPRINC, where SPRINC is the answer to question 2. What is the output? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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 --- -- 2 12/17/2014 15:30:08 mya...@common.bankofamerica.com 2. This is window client output recorded at the time: Cached Tickets: (2) #0 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: krbtgt/COMMON.BANKOFAMERICA.COM @ COMMON.BANKOFAMERICA.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40e0 - forwardable renewable initial pre_authen Start Time: 12/18/2014 13:13:36 (local) End Time: 12/18/2014 22:13:36 (local) Renew Time: 12/28/2014 13:13:36 (local) Session Key Type: RSADSI RC4-HMAC(NT) #1 Client: winlogin @ COMMON.BANKOFAMERICA.COM Server: HTTP/host2.site123.baml.com @ COMMON.BANKOFAMERICA.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40a0 - forwardable renewable pre_authent Start Time: 12/18/2014 13:13:36 (local) End Time: 12/18/2014 21:33:36 (local) Renew Time: 12/28/2014 13:13:36 (local) Session Key Type: RSADSI RC4-HMAC(NT) 3. What is the window equivalent command on windows? -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Monday, January 05, 2015 5:12 PM To: Xie, Hugh; 'kerberos@mit.edu' Subject: Re: Wrong principal in request error 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, and I think some of my questions weren't clear enough. Let's start over. For the non-working server only: 1. On the server, run klist -k (or klist -k -t /path/to/keytab if the server is using a special keytab location). What is the output? 2. On the client, run kinit so that you have a fresh credential cache, then try to connect. Then run klist. Other than krbtgt/common.bankofamerica@common.bankofamerica.com, what service principal appears in the output? 3. On the client, run kvno SPRINC, where SPRINC is the answer to question 2. What is the output? -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Wrong principal in request error on gss_accept_sec_context()
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 @ COMMON.BANKOFAMERICA.COM I guess this is an Active Directory KDC, and you are using a single computer account for both hosts? (That's not the usual recommended practice, but I assume you have a reason for it.) How did you create the keytabs for the hosts? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Wrong principal in request error on gss_accept_sec_context()
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 123.150.123.123 myhost.bankdomain.com myhost Are there any other causes for this error? I am using krb5 1.11.5 Unfortunately several things can cause this error in 1.11. (In 1.13 we try harder to disambiguate.) Information which might help: * What do hostname and hostname -f say on each host? * What OS are these hosts running? * What server application are you getting the error from? If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context? * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Wrong principal in request error on gss_accept_sec_context()
* What do hostname and hostname -f say on each host? The working on are using host1.bankofamerica.com the non working one has host2.site123.baml.com. hostname and hostname -f returns same string on both hosts. In the KRB5_CONFIG of both hosts, default_realm is set to COMMON.BANKOFAMERICA.COM And the domain_realm is config from above host_name = COMMON.BANKOFAMERICA.COM * What OS are these hosts running? The working host is running EL5, the non working host is running EL6 * What server application are you getting the error from? If it's a custom application, what name was imported 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, GSS_C_NO_OID_SET, GSS_C_BOTH, state-server_creds, NULL, NULL); * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) I did this multiple times already. -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Friday, December 19, 2014 11:24 AM To: Xie, Hugh; kerberos@mit.edu Subject: Re: Wrong principal in request error on gss_accept_sec_context() 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 123.150.123.123 myhost.bankdomain.com myhost Are there any other causes for this error? I am using krb5 1.11.5 Unfortunately several things can cause this error in 1.11. (In 1.13 we try harder to disambiguate.) Information which might help: * What do hostname and hostname -f say on each host? * What OS are these hosts running? * What server application are you getting the error from? If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context? * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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 to the entries in the keytab on the non-working server? On 12/19/2014 11:50 AM, Xie, Hugh wrote: * What do hostname and hostname -f say on each host? The working on are using host1.bankofamerica.com the non working one has host2.site123.baml.com. hostname and hostname -f returns same string on both hosts. In the KRB5_CONFIG of both hosts, default_realm is set to COMMON.BANKOFAMERICA.COM And the domain_realm is config from above host_name = COMMON.BANKOFAMERICA.COM * What OS are these hosts running? The working host is running EL5, the non working host is running EL6 * What server application are you getting the error from? If it's a custom application, what name was imported 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, GSS_C_NO_OID_SET, GSS_C_BOTH, state-server_creds, NULL, NULL); * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) I did this multiple times already. -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Friday, December 19, 2014 11:24 AM To: Xie, Hugh; kerberos@mit.edu Subject: Re: Wrong principal in request error on gss_accept_sec_context() 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 123.150.123.123 myhost.bankdomain.com myhost Are there any other causes for this error? I am using krb5 1.11.5 Unfortunately several things can cause this error in 1.11. (In 1.13 we try harder to disambiguate.) Information which might help: * What do hostname and hostname -f say on each host? * What OS are these hosts running? * What server application are you getting the error from? If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context? * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Wrong principal in request error on gss_accept_sec_context()
We are using the same account on both hosts the Principal in the keytab is mya...@common.bankofamerica.com Klist return service principals are the same krbtgt/common.bankofamerica@common.bankofamerica.com on both host -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] 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 to the entries in the keytab on the non-working server? On 12/19/2014 11:50 AM, Xie, Hugh wrote: * What do hostname and hostname -f say on each host? The working on are using host1.bankofamerica.com the non working one has host2.site123.baml.com. hostname and hostname -f returns same string on both hosts. In the KRB5_CONFIG of both hosts, default_realm is set to COMMON.BANKOFAMERICA.COM And the domain_realm is config from above host_name = COMMON.BANKOFAMERICA.COM * What OS are these hosts running? The working host is running EL5, the non working host is running EL6 * What server application are you getting the error from? If it's a custom application, what name was imported 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, GSS_C_NO_OID_SET, GSS_C_BOTH, state-server_creds, NULL, NULL); * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) I did this multiple times already. -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Friday, December 19, 2014 11:24 AM To: Xie, Hugh; kerberos@mit.edu Subject: Re: Wrong principal in request error on gss_accept_sec_context() 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 123.150.123.123 myhost.bankdomain.com myhost Are there any other causes for this error? I am using krb5 1.11.5 Unfortunately several things can cause this error in 1.11. (In 1.13 we try harder to disambiguate.) Information which might help: * What do hostname and hostname -f say on each host? * What OS are these hosts running? * What server application are you getting the error from? If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context? * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Wrong principal in request error on gss_accept_sec_context()
On the client side two ticket shows up for either when connects for either hosts the krbtgt/COMMON.BANKOFAMERICA.COM @ 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 @ 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 the same account on both hosts the Principal in the keytab is mya...@common.bankofamerica.com Klist return service principals are the same krbtgt/common.bankofamerica@common.bankofamerica.com on both host -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] 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 to the entries in the keytab on the non-working server? On 12/19/2014 11:50 AM, Xie, Hugh wrote: * What do hostname and hostname -f say on each host? The working on are using host1.bankofamerica.com the non working one has host2.site123.baml.com. hostname and hostname -f returns same string on both hosts. In the KRB5_CONFIG of both hosts, default_realm is set to COMMON.BANKOFAMERICA.COM And the domain_realm is config from above host_name = COMMON.BANKOFAMERICA.COM * What OS are these hosts running? The working host is running EL5, the non working host is running EL6 * What server application are you getting the error from? If it's a custom application, what name was imported 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, GSS_C_NO_OID_SET, GSS_C_BOTH, state-server_creds, NULL, NULL); * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) I did this multiple times already. -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Friday, December 19, 2014 11:24 AM To: Xie, Hugh; kerberos@mit.edu Subject: Re: Wrong principal in request error on gss_accept_sec_context() 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 123.150.123.123 myhost.bankdomain.com myhost Are there any other causes for this error? I am using krb5 1.11.5 Unfortunately several things can cause this error in 1.11. (In 1.13 we try harder to disambiguate.) Information which might help: * What do hostname and hostname -f say on each host? * What OS are these hosts running? * What server application are you getting the error from? If it's a custom application, what name was imported to create the verifier_cred_handle argument of gss_accept_sec_context? * Did you recently re-key one of the hosts without retaining the old keytab? (If so, run kinit again on the client to flush any old service tickets.) -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you
Wrong principal in request error on gss_accept_sec_context()
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 Are there any other causes for this error? I am using krb5 1.11.5 Thanks. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential from gss_accept_sec_context()
Perhaps this is a bug. Gss_init_sec_context did return GSS_S_COMPLETE for me. -Original Message- From: Greg Hudson [ghud...@mit.edumailto:ghud...@mit.edu] Sent: Wednesday, October 08, 2014 11:10 PM Eastern Standard Time To: Xie, Hugh; Kerberos@mit.edu Subject: Re: Not getting delegation 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 gss_init_sec_context with delegate handle? Our implementation requires the context argument of gss_inquire_context to be an established context, although this isn't required by RFC 2743 or RFC 2744. I will file an issue. For the moment, don't inquire the context until gss_init_sec_context returns GSS_S_COMPLETE. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Not getting delegation credential from gss_accept_sec_context()
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 you're passing gss_inquire_context the gss_ctx_id_t itself and not a pointer to it. If you're still seeing a problem, you'll probably need to trace through it on your end. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential 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 switch the order to either 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, 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 you're passing gss_inquire_context the gss_ctx_id_t itself and not a pointer to it. If you're still seeing a problem, you'll probably need to trace through it on your end. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential from gss_accept_sec_context()
Correction. #3 is gss_release_buffer on output_token. -Original Message- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Xie, Hugh Sent: Thursday, October 09, 2014 1:45 PM To: Greg Hudson; 'Kerberos@mit.edu' Subject: RE: Not getting delegation credential 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 switch the order to either 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, 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 you're passing gss_inquire_context the gss_ctx_id_t itself and not a pointer to it. If you're still seeing a problem, you'll probably need to trace through it on your end. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential from 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 backtrace:
(gdb) backtrace
#0 kg_accept_krb5 (minor_status=0x7fffe2d4, context_handle=0x60a510,
verifier_cred_handle=0x0, input_token=0x60a520,
input_chan_bindings=0x0, src_name=0x7fffd748, mech_type=0x7fffd738,
output_token=0x7fffd870, ret_flags=0x7fffd758,
time_rec=0x0, delegated_cred_handle=0x7fffd750, exts=0x7fffd290) at
accept_sec_context.c:440
#1 0x2aaca23a in krb5_gss_accept_sec_context_ext
(minor_status=0x7fffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffd748,
mech_type=0x7fffd738, output_token=0x7fffd870,
ret_flags=0x7fffd758, time_rec=0x0,
delegated_cred_handle=0x7fffd750, exts=0x7fffd290) at
accept_sec_context.c:1369
#2 0x2aaca396 in krb5_gss_accept_sec_context
(minor_status=0x7fffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffd748,
mech_type=0x7fffd738, output_token=0x7fffd870,
ret_flags=0x7fffd758, time_rec=0x0,
delegated_cred_handle=0x7fffd750) at accept_sec_context.c:1398
#3 0x2aabcd90 in gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=optimized out,
verifier_cred_handle=optimized out, input_token_buffer=optimized out,
input_chan_bindings=optimized out, src_name=0x60c888,
mech_type=0x7fffddc8, output_token=0x7fffd870, ret_flags=0x60c880,
time_rec=0x0, d_cred=0x7fffdde0)
at g_accept_sec_context.c:220
#4 0x2aae0618 in acc_ctx_call_acc (tokflag=optimized out,
negState=optimized out, delegated_cred_handle=optimized out,
time_rec=optimized out, ret_flags=optimized out, mechtok_out=optimized
out, mech_type=optimized out, mechtok_in=optimized out,
spcred=optimized out, sc=optimized out, minor_status=optimized out)
at spnego_mech.c:1535
#5 spnego_gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=0x608420, verifier_cred_handle=0x52435f4f4e5f435f,
input_token=optimized out, input_chan_bindings=optimized out,
src_name=optimized out, mech_type=0x7fffddc8,
output_token=0x7fffe2a0, ret_flags=0x7fffdde8, time_rec=0x0,
delegated_cred_handle=0x7fffdde0) at spnego_mech.c:1703
#6 0x2aabcd90 in gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=optimized out,
verifier_cred_handle=optimized out, input_token_buffer=optimized out,
input_chan_bindings=optimized out, src_name=0x607020,
mech_type=0x0, output_token=0x7fffe2a0, ret_flags=0x7fffe29c,
time_rec=0x0, d_cred=0x7fffe288) at g_accept_sec_context.c:220
#7 0x004014ec in authenticate_gss_server_init (service=0x4016a7
HTTP, state=0x607010) at server_init.c:264
#8 0x00401544 in main () at server_init.c:299
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Monday, October 06, 2014 4:50 PM
To: Kerberos@mit.edu
Subject: Not getting delegation credential from gss_accept_sec_context()
Hi,
I am having trouble with S4U2Proxy. Looking into *accept_sec_context.c*, it has
:
* if (delegated_cred_handle != NULL
deleg_cred == NULL /* no unconstrained delegation */
cred-usage == GSS_C_BOTH
(ticket-enc_part2-flags TKT_FLG_FORWARDABLE)) {
/*
* Now, we always fabricate a delegated credentials handle
* containing the service ticket to ourselves, which can be
* used for S4U2Proxy.
*/
major_status = create_constrained_deleg_creds(minor_status, cred,
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 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 definite verified verifier_cred_handle before I
called gss_accept_sec_context(). And it is coming from a call:
*
maj_stat = gss_acquire_cred(min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
GSS_C_NO_OID_SET, GSS_C_BOTH,
state-server_creds, NULL, NULL);
*
So my assumption cred-usage flag should be GSS_C_BOTH.
Anyway, please let me know I can debug this issue.
Thanks.
--
This message, and any attachments, is for the intended recipient(s) only, may
contain
Re: Not getting delegation credential from gss_accept_sec_context()
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 this issue? Here are the full backtrace: It's hard to get much information out of this backtrace because so much is obscured by the optimizer. Based on the version number and the fact that the backtrace contains SPNEGO functions, I think the following is happening: * You call gss_acquire_cred(min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE, GSS_C_NO_OID_SET, GSS_C_BOTH, state-server_creds, NULL, NULL). In 1.10 and later, this would get creds for all mechanisms, but in 1.9 it only gets creds for the default mechanism, which is krb5. * You call gss_accept_sec_context with the client's token and the resulting cred. The mechglue detects that this is a SPNEGO token and searches for a SPNEGO cred within the verifier cred, but doesn't find one since it only contains a krb5 cred. In 1.10 this would result in an error, but in 1.9 it results in passing a null verifier cred to SPNEGO's gss_accept_sec_context. SPNEGO negotiates the krb5 mech, calls back into the mechglue and into krb5, which uses a default verifier cred and doesn't receive delegated creds. Upgrading to 1.10 or later would resolve this problem, but you can also work around this in 1.9 by explicitly passing a desired_mechs paremeter to gss_acquire_cred. The mech set should contain at least the SPNEGO OID, or perhaps SPNEGO and krb5. You'll have to define the SPNEGO OID yourself since we don't declare it in the public headers; the six bytes of the SPNEGO OID are \053\006\001\005\005\002. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential from gss_accept_sec_context()
Switched to 1.12 resolved this issue. Thanks.
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Wednesday, October 08, 2014 10:30 AM
To: Kerberos@mit.edu; Greg Hudson
Subject: RE: Not getting delegation credential from 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 backtrace:
(gdb) backtrace
#0 kg_accept_krb5 (minor_status=0x7fffe2d4, context_handle=0x60a510,
verifier_cred_handle=0x0, input_token=0x60a520,
input_chan_bindings=0x0, src_name=0x7fffd748, mech_type=0x7fffd738,
output_token=0x7fffd870, ret_flags=0x7fffd758,
time_rec=0x0, delegated_cred_handle=0x7fffd750, exts=0x7fffd290) at
accept_sec_context.c:440
#1 0x2aaca23a in krb5_gss_accept_sec_context_ext
(minor_status=0x7fffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffd748,
mech_type=0x7fffd738, output_token=0x7fffd870,
ret_flags=0x7fffd758, time_rec=0x0,
delegated_cred_handle=0x7fffd750, exts=0x7fffd290) at
accept_sec_context.c:1369
#2 0x2aaca396 in krb5_gss_accept_sec_context
(minor_status=0x7fffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffd748,
mech_type=0x7fffd738, output_token=0x7fffd870,
ret_flags=0x7fffd758, time_rec=0x0,
delegated_cred_handle=0x7fffd750) at accept_sec_context.c:1398
#3 0x2aabcd90 in gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=optimized out,
verifier_cred_handle=optimized out, input_token_buffer=optimized out,
input_chan_bindings=optimized out, src_name=0x60c888,
mech_type=0x7fffddc8, output_token=0x7fffd870, ret_flags=0x60c880,
time_rec=0x0, d_cred=0x7fffdde0)
at g_accept_sec_context.c:220
#4 0x2aae0618 in acc_ctx_call_acc (tokflag=optimized out,
negState=optimized out, delegated_cred_handle=optimized out,
time_rec=optimized out, ret_flags=optimized out, mechtok_out=optimized
out, mech_type=optimized out, mechtok_in=optimized out,
spcred=optimized out, sc=optimized out, minor_status=optimized out)
at spnego_mech.c:1535
#5 spnego_gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=0x608420, verifier_cred_handle=0x52435f4f4e5f435f,
input_token=optimized out, input_chan_bindings=optimized out,
src_name=optimized out, mech_type=0x7fffddc8,
output_token=0x7fffe2a0, ret_flags=0x7fffdde8, time_rec=0x0,
delegated_cred_handle=0x7fffdde0) at spnego_mech.c:1703
#6 0x2aabcd90 in gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=optimized out,
verifier_cred_handle=optimized out, input_token_buffer=optimized out,
input_chan_bindings=optimized out, src_name=0x607020,
mech_type=0x0, output_token=0x7fffe2a0, ret_flags=0x7fffe29c,
time_rec=0x0, d_cred=0x7fffe288) at g_accept_sec_context.c:220
#7 0x004014ec in authenticate_gss_server_init (service=0x4016a7
HTTP, state=0x607010) at server_init.c:264
#8 0x00401544 in main () at server_init.c:299
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Monday, October 06, 2014 4:50 PM
To: Kerberos@mit.edu
Subject: Not getting delegation credential from gss_accept_sec_context()
Hi,
I am having trouble with S4U2Proxy. Looking into *accept_sec_context.c*, it has
:
* if (delegated_cred_handle != NULL
deleg_cred == NULL /* no unconstrained delegation */
cred-usage == GSS_C_BOTH
(ticket-enc_part2-flags TKT_FLG_FORWARDABLE)) {
/*
* Now, we always fabricate a delegated credentials handle
* containing the service ticket to ourselves, which can be
* used for S4U2Proxy.
*/
major_status = create_constrained_deleg_creds(minor_status, cred,
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 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 definite verified verifier_cred_handle before I
called gss_accept_sec_context(). And it is coming from a call:
*
maj_stat = gss_acquire_cred(min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
GSS_C_NO_OID_SET
RE: Not getting delegation credential from gss_accept_sec_context()
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. This is not a problem
when I am not using delegated_cred_handle. When I attempt to pass the same
context handle from gss_accept_sec_context(), I got a segmentation error.
Can you tell me what context_handle to use?
Thanks again.
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Wednesday, October 08, 2014 1:29 PM
To: Kerberos@mit.edu; Greg Hudson
Subject: RE: Not getting delegation credential from gss_accept_sec_context()
Switched to 1.12 resolved this issue. Thanks.
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Wednesday, October 08, 2014 10:30 AM
To: Kerberos@mit.edu; Greg Hudson
Subject: RE: Not getting delegation credential from 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 backtrace:
(gdb) backtrace
#0 kg_accept_krb5 (minor_status=0x7fffe2d4, context_handle=0x60a510,
verifier_cred_handle=0x0, input_token=0x60a520,
input_chan_bindings=0x0, src_name=0x7fffd748, mech_type=0x7fffd738,
output_token=0x7fffd870, ret_flags=0x7fffd758,
time_rec=0x0, delegated_cred_handle=0x7fffd750, exts=0x7fffd290) at
accept_sec_context.c:440
#1 0x2aaca23a in krb5_gss_accept_sec_context_ext
(minor_status=0x7fffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffd748,
mech_type=0x7fffd738, output_token=0x7fffd870,
ret_flags=0x7fffd758, time_rec=0x0,
delegated_cred_handle=0x7fffd750, exts=0x7fffd290) at
accept_sec_context.c:1369
#2 0x2aaca396 in krb5_gss_accept_sec_context
(minor_status=0x7fffe2d4, context_handle=0x60a510, verifier_cred_handle=0x0,
input_token=0x60a520, input_chan_bindings=0x0, src_name=0x7fffd748,
mech_type=0x7fffd738, output_token=0x7fffd870,
ret_flags=0x7fffd758, time_rec=0x0,
delegated_cred_handle=0x7fffd750) at accept_sec_context.c:1398
#3 0x2aabcd90 in gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=optimized out,
verifier_cred_handle=optimized out, input_token_buffer=optimized out,
input_chan_bindings=optimized out, src_name=0x60c888,
mech_type=0x7fffddc8, output_token=0x7fffd870, ret_flags=0x60c880,
time_rec=0x0, d_cred=0x7fffdde0)
at g_accept_sec_context.c:220
#4 0x2aae0618 in acc_ctx_call_acc (tokflag=optimized out,
negState=optimized out, delegated_cred_handle=optimized out,
time_rec=optimized out, ret_flags=optimized out, mechtok_out=optimized
out, mech_type=optimized out, mechtok_in=optimized out,
spcred=optimized out, sc=optimized out, minor_status=optimized out)
at spnego_mech.c:1535
#5 spnego_gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=0x608420, verifier_cred_handle=0x52435f4f4e5f435f,
input_token=optimized out, input_chan_bindings=optimized out,
src_name=optimized out, mech_type=0x7fffddc8,
output_token=0x7fffe2a0, ret_flags=0x7fffdde8, time_rec=0x0,
delegated_cred_handle=0x7fffdde0) at spnego_mech.c:1703
#6 0x2aabcd90 in gss_accept_sec_context (minor_status=0x7fffe2d4,
context_handle=optimized out,
verifier_cred_handle=optimized out, input_token_buffer=optimized out,
input_chan_bindings=optimized out, src_name=0x607020,
mech_type=0x0, output_token=0x7fffe2a0, ret_flags=0x7fffe29c,
time_rec=0x0, d_cred=0x7fffe288) at g_accept_sec_context.c:220
#7 0x004014ec in authenticate_gss_server_init (service=0x4016a7
HTTP, state=0x607010) at server_init.c:264
#8 0x00401544 in main () at server_init.c:299
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Xie, Hugh
Sent: Monday, October 06, 2014 4:50 PM
To: Kerberos@mit.edu
Subject: Not getting delegation credential from gss_accept_sec_context()
Hi,
I am having trouble with S4U2Proxy. Looking into *accept_sec_context.c*, it has
:
* if (delegated_cred_handle != NULL
deleg_cred == NULL /* no unconstrained delegation */
cred-usage == GSS_C_BOTH
(ticket-enc_part2-flags TKT_FLG_FORWARDABLE)) {
/*
* Now, we always fabricate a delegated credentials handle
* containing the service ticket to ourselves, which can be
* used for S4U2Proxy.
*/
major_status
Re: Not getting delegation credential from gss_accept_sec_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 the context_handle is reinitialized to GSS_C_NO_CONTEXT. This is not a problem when I am not using delegated_cred_handle. When I attempt to pass the same context handle from gss_accept_sec_context(), I got a segmentation error. Can you tell me what context_handle to use? Just as when you initially call gss_accept_sec_context, you need to pass the address of a gss_ctx_id_t variable which was initialized to GSS_C_NO_CONTEXT. If you pass NULL, you will get the error you mentioned. Reusing the acceptor context is incorrect usage; there ought to be a safety check so that it results in an error instead of a seg fault, but there might not be. I will file a ticket if I can reproduce the issue. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential from gss_accept_sec_context()
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 security context for minor when I call gss_init_sec_context with delegated_cred_handle from gss_accept_sec_context. I do not get this error if I do not pass delegated_cred_handle. -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Wednesday, October 08, 2014 5:10 PM To: Xie, Hugh; Kerberos@mit.edu Subject: Re: Not getting delegation credential from gss_accept_sec_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 the context_handle is reinitialized to GSS_C_NO_CONTEXT. This is not a problem when I am not using delegated_cred_handle. When I attempt to pass the same context handle from gss_accept_sec_context(), I got a segmentation error. Can you tell me what context_handle to use? Just as when you initially call gss_accept_sec_context, you need to pass the address of a gss_ctx_id_t variable which was initialized to GSS_C_NO_CONTEXT. If you pass NULL, you will get the error you mentioned. Reusing the acceptor context is incorrect usage; there ought to be a safety check so that it results in an error instead of a seg fault, but there might not be. I will file a ticket if I can reproduce the issue. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Not getting delegation credential from gss_accept_sec_context()
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? -Original Message- From: kerberos-boun...@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()* 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 security context for minor when I call gss_init_sec_context with delegated_cred_handle from gss_accept_sec_context. I do not get this error if I do not pass delegated_cred_handle. -Original Message- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Wednesday, October 08, 2014 5:10 PM To: Xie, Hugh; Kerberos@mit.edu Subject: Re: Not getting delegation credential from gss_accept_sec_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 the context_handle is reinitialized to GSS_C_NO_CONTEXT. This is not a problem when I am not using delegated_cred_handle. When I attempt to pass the same context handle from gss_accept_sec_context(), I got a segmentation error. Can you tell me what context_handle to use? Just as when you initially call gss_accept_sec_context, you need to pass the address of a gss_ctx_id_t variable which was initialized to GSS_C_NO_CONTEXT. If you pass NULL, you will get the error you mentioned. Reusing the acceptor context is incorrect usage; there ought to be a safety check so that it results in an error instead of a seg fault, but there might not be. I will file a ticket if I can reproduce the issue. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Not getting delegation 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 gss_init_sec_context with delegate handle? Our implementation requires the context argument of gss_inquire_context to be an established context, although this isn't required by RFC 2743 or RFC 2744. I will file an issue. For the moment, don't inquire the context until gss_init_sec_context returns GSS_S_COMPLETE. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Not getting delegation credential from gss_accept_sec_context()
Hi,
I am having trouble with S4U2Proxy. Looking into *accept_sec_context.c*, it has
:
* if (delegated_cred_handle != NULL
deleg_cred == NULL /* no unconstrained delegation */
cred-usage == GSS_C_BOTH
(ticket-enc_part2-flags TKT_FLG_FORWARDABLE)) {
/*
* Now, we always fabricate a delegated credentials handle
* containing the service ticket to ourselves, which can be
* used for S4U2Proxy.
*/
major_status = create_constrained_deleg_creds(minor_status, cred,
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 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 definite verified verifier_cred_handle before I
called gss_accept_sec_context(). And it is coming from a call:
*
maj_stat = gss_acquire_cred(min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
GSS_C_NO_OID_SET, GSS_C_BOTH,
state-server_creds, NULL, NULL);
*
So my assumption cred-usage flag should be GSS_C_BOTH.
Anyway, please let me know I can debug this issue.
Thanks.
--
This message, and any attachments, is for the intended recipient(s) only, may
contain information that is privileged, confidential and/or proprietary and
subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
recipient, please delete this message.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Not getting delegation credential from gss_accept_sec_context()
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 definite verified verifier_cred_handle before I called gss_accept_sec_context(). And it is coming from a call: [...] Anyway, please let me know I can debug this issue. You haven't said what version of MIT krb5 you're using or on what platform. I would suggest either stepping through the mechglue gss_accept_sec_context (lib/gssapi/mechglue/g_accept_sec_context.c) in a debugger, or adding printfs to it. I don't see anything obviously wrong with your code snippet. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
hangs in gss_accept_sec_context call on Windows with krb5-1.9.5 libs
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 k5_os_mutex_lock(k5_os_mutex *m)
{
...
res = *WaitForSingleObject*(m-h, INFINITE);
...
}
Also the value for m_h is 0x. I saw that its an enum. So does this
mean initialization is not done properly?
When I debugged the code I could get following is the call stack:
iUnflagged 3600 0 Worker Thread _threadstartex k5_os_mutex_lock Normal
gssapi32.dll!k5_os_mutex_lock(k5_os_mutex * m) Line 651
gssapi32.dll!k5_mutex_lock_1(k5_mutex_t * m, k5_debug_loc l) Line
733 + 0xc bytes
gssapi32.dll!g_save() Line 96 + 0x1a bytes
gssapi32.dll!gssint_g_save_cred_id(g_set * vdb, gss_cred_id_struct *
cred) Line 246 + 0xf bytes
gssapi32.dll!acquire_cred(unsigned int * minor_status, const
acquire_cred_args * args, gss_cred_id_struct * * output_cred_handle,
unsigned int * time_rec) Line 613 + 0xe bytes
gssapi32.dll!krb5_gss_acquire_cred(unsigned int * minor_status,
gss_name_struct * desired_name, unsigned int time_req,
gss_OID_set_desc_struct * desired_mechs, int cred_usage, gss_cred_id_struct
* * output_cred_handle, gss_OID_set_desc_struct * * actual_mechs, unsigned
int * time_rec) Line 720 + 0x15 bytes
gssapi32.dll!kg_accept_krb5() Line 510 + 0x19 bytes
gssapi32.dll!krb5_gss_accept_sec_context_ext(unsigned int *
minor_status, gss_ctx_id_struct * * context_handle, gss_cred_id_struct *
verifier_cred_handle, gss_buffer_desc_struct * input_token,
gss_channel_bindings_struct * input_chan_bindings, gss_name_struct * *
src_name, gss_OID_desc_struct * * mech_type, gss_buffer_desc_struct *
output_token, unsigned int * ret_flags, unsigned int * time_rec,
gss_cred_id_struct * * delegated_cred_handle, _krb5_gss_ctx_ext_rec * exts)
Line 1347 + 0x35 bytes
gssapi32.dll!krb5_gss_accept_sec_context(unsigned int *
minor_status, gss_ctx_id_struct * * context_handle, gss_cred_id_struct *
verifier_cred_handle, gss_buffer_desc_struct * input_token,
gss_channel_bindings_struct * input_chan_bindings, gss_name_struct * *
src_name, gss_OID_desc_struct * * mech_type, gss_buffer_desc_struct *
output_token, unsigned int * ret_flags, unsigned int * time_rec,
gss_cred_id_struct * * delegated_cred_handle) Line 1383 + 0x35 bytes
gssapi32.dll!gss_accept_sec_context(unsigned int * minor_status,
gss_ctx_id_struct * * context_handle, gss_cred_id_struct *
verifier_cred_handle, gss_buffer_desc_struct * input_token_buffer,
gss_channel_bindings_struct * input_chan_bindings, gss_name_struct * *
src_name, gss_OID_desc_struct * * mech_type, gss_buffer_desc_struct *
output_token, unsigned int * ret_flags, unsigned int * time_rec,
gss_cred_id_struct * * d_cred) Line 208 + 0x49 bytes
gssapi32.dll!acc_ctx_call_acc(unsigned int * minor_status,
spnego_gss_ctx_id_rec * sc, spnego_gss_cred_id_rec * spcred,
gss_buffer_desc_struct * mechtok_in, gss_OID_desc_struct * * mech_type,
gss_buffer_desc_struct * mechtok_out, unsigned int * ret_flags, unsigned
int * time_rec, gss_cred_id_struct * * delegated_cred_handle, unsigned int
* negState, send_token_flag * tokflag) Line 1545 + 0x38 bytes
gssapi32.dll!spnego_gss_accept_sec_context(unsigned int *
minor_status, gss_ctx_id_struct * * context_handle, gss_cred_id_struct *
verifier_cred_handle, gss_buffer_desc_struct * input_token,
gss_channel_bindings_struct * input_chan_bindings, gss_name_struct * *
src_name, gss_OID_desc_struct * * mech_type, gss_buffer_desc_struct *
output_token, unsigned int * ret_flags, unsigned int * time_rec,
gss_cred_id_struct * * delegated_cred_handle) Line 1707 + 0x31 bytes
gssapi32.dll!gss_accept_sec_context(unsigned int * minor_status,
gss_ctx_id_struct * * context_handle, gss_cred_id_struct *
verifier_cred_handle, gss_buffer_desc_struct * input_token_buffer,
gss_channel_bindings_struct * input_chan_bindings, gss_name_struct * *
src_name, gss_OID_desc_struct * * mech_type, gss_buffer_desc_struct *
output_token, unsigned int * ret_flags, unsigned int * time_rec,
gss_cred_id_struct * * d_cred) Line 208 + 0x49 bytes /i
Please let me know if anyone has any idea.
Thanks,
Dipti
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: leaking rcache opens in gss_accept_sec_context
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 the context in gss_krb5_export_lucid_sec_context() - krb5_gss_delete_sec_context(), which fails with G_VALIDATE_FAILED. It also sets the context to GSS_C_NO_CONTEXT, so once we get to gss_delete_sec_context(), context validation fails there too. Aha. Yes, that's the bug you found a reference to. (And thank you for explaining why that bug wasn't resulting in gssd crashes for everyone in previous releases. I had forgotten about the pointer validation code.) I've attached the patch which is due for krb5 1.9.2. gss_delete_sec_context should be unnecessary when gss_export_lucid_sec_context succeeds. Of course, it's harmless given the way GSS handles contexts (nulling out the pointer when they are released). patch.txt Thank you, Greg. I can confirm that this fixes the problem we were seeing. It also fixes a leak when running without '-n', which was less obvious because we didn't open a new handle to the rcache each time. Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: leaking rcache opens in gss_accept_sec_context
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 cache for every context/cred created, eventually reaching ulimit. The files are never closed, and every so often the rcache is removed and re-written, so the handles themselves are to deleted files. The files should be closed in gss_delete_sec_context() (via gssint_delete_internal_sec_context - krb5_gss_delete_sec_context - krb5_auth_con_free - krb5_rc_close). Is it possible that svcgssd is leaking the security contexts? There is a behavior difference here depending on how the server invokes gss_accept_sec_context(). If the server imports a name and acquires credentials, the rcache handle is associated with the credential object. If the server uses the default credentials or name, the rcache handle is associated with the security context. If svcgssd leaks security contexts but not credentials, you would only see the rcache leak when -n is used. It shouldn't leak -- it roughly loops on 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() - krb5_gss_delete_sec_context(), which fails with G_VALIDATE_FAILED. It also sets the context to GSS_C_NO_CONTEXT, so once we get to gss_delete_sec_context(), context validation fails there too. I found your message to K.C. in May (http://marc.info/?t=13047050791r=1w=2). Do you have a patch we could try? Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: leaking rcache opens in gss_accept_sec_context
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() - krb5_gss_delete_sec_context(), which fails with G_VALIDATE_FAILED. It also sets the context to GSS_C_NO_CONTEXT, so once we get to gss_delete_sec_context(), context validation fails there too. Aha. Yes, that's the bug you found a reference to. (And thank you for explaining why that bug wasn't resulting in gssd crashes for everyone in previous releases. I had forgotten about the pointer validation code.) I've attached the patch which is due for krb5 1.9.2. gss_delete_sec_context should be unnecessary when gss_export_lucid_sec_context succeeds. Of course, it's harmless given the way GSS handles contexts (nulling out the pointer when they are released). commit 1d72f6deeb2a8445567228de6495264112294223 Author: ghudson ghudson@dc483132-0cff-0310-8789-dd5450dbe970 Date: Mon May 9 17:28:07 2011 + ticket: 6908 subject: Delete sec context properly in gss_krb5_export_lucid_sec_context target_version: 1.9.2 tags: pullup Since r21690, gss_krb5_export_lucid_sec_context() has been passing a union context to krb5_gss_delete_sec_context(), causing a crash as the krb5 routine attempts to interpret a union context structure as a krb5 GSS context. Call the mechglue gss_delete_sec_context instead. git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@24917 dc483132-0cff-0310-8789-dd5450dbe970 diff --git a/src/lib/gssapi/krb5/krb5_gss_glue.c b/src/lib/gssapi/krb5/krb5_gss_glue.c index bc3b7c7..0035d4f 100644 --- a/src/lib/gssapi/krb5/krb5_gss_glue.c +++ b/src/lib/gssapi/krb5/krb5_gss_glue.c @@ -196,7 +196,7 @@ gss_krb5_export_lucid_sec_context(OM_uint32 *minor_status, /* Clean up the context state (it is an error for * someone to attempt to use this context again) */ -(void)krb5_gss_delete_sec_context(minor_status, context_handle, NULL); +(void)gss_delete_sec_context(minor_status, context_handle, NULL); *context_handle = GSS_C_NO_CONTEXT; generic_gss_release_buffer_set(minor, data_set); Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: leaking rcache opens in gss_accept_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 reaching ulimit. The files are never closed, and every so often the rcache is removed and re-written, so the handles themselves are to deleted files. The files should be closed in gss_delete_sec_context() (via gssint_delete_internal_sec_context - krb5_gss_delete_sec_context - krb5_auth_con_free - krb5_rc_close). Is it possible that svcgssd is leaking the security contexts? There is a behavior difference here depending on how the server invokes gss_accept_sec_context(). If the server imports a name and acquires credentials, the rcache handle is associated with the credential object. If the server uses the default credentials or name, the rcache handle is associated with the security context. If svcgssd leaks security contexts but not credentials, you would only see the rcache leak when -n is used. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
leaking rcache opens in gss_accept_sec_context
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 verifier_cred_handle instead of a gss_cred that was created beforehand with gss_acquire_cred(). I believe that the NULL verifier_cred_handle causes the kerberos code to try to create creds - perhaps by trying to create a cred for each principal in the keytab.. I am not an expert in the kerberos code. 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 reaching ulimit. The files are never closed, and every so often the rcache is removed and re-written, so the handles themselves are to deleted files. Is it advisable to call gss_accept_sec_context with a NULL verifier_cred_handle, and if so -- what can we do to release resources/close rcache each time? Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Fwd: gss_accept_sec_context() error in v1.9
-- 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 is giving unknown error. major_status = gss_accept_sec_context(minor_status, context, server_credentials, receive_token, GSS_C_NO_CHANNEL_BINDINGS, NULL, NULL, send_token, flags, NULL, user_credentials); Error while accepting GSS context (Kerberos ticket is invalid). Major status = 851968 , minor status = 11 The error code does not tell us what's wrong. Anybody see this before? Is there any change that I need to be aware of? thanks, Michelle Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context() problem
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 whether this problem is resolved or not? Thanks, Paul Jiang Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Help: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 230
I have been trying to setup kerberos client on RedHat machine with Apache mod_auth_kerb. I have tested kerberos client configuration using kinit, klist etc. and its working and the Linux machine is getting tickets. But the problem is when I try to access the reousrce page from Windows (domain 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@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Help: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 230
Detailed error message from apache error log, we are on red hat enterprise 5 [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1432): [client *.*.*.*] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1432): [client *.*.*.*] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1147): [client *.*.*.*] Acquiring creds for h...@*.*.*.* [Tue Feb 03 10:41:21 2009] [debug] src/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. Minor code may provide more information (Unknown code krb5 230) On Tue, Feb 3, 2009 at 8:50 PM, Omair Sajid om...@omairsajid.com wrote: I have been trying to setup kerberos client on RedHat machine with Apache mod_auth_kerb. I have tested kerberos client configuration using kinit, klist etc. and its working and the Linux machine is getting tickets. But the problem is when I try to access the reousrce page from Windows (domain 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@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Help: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 230
On Feb 3, 2009, at 11:15, Omair Sajid wrote: Detailed error message from apache error log, we are on red hat enterprise 5 [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1432): [client *.*.*.*] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1432): [client *.*.*.*] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1147): [client *.*.*.*] Acquiring creds for h...@*.*.*.* [Tue Feb 03 10:41:21 2009] [debug] src/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. Minor code may provide more information (Unknown code krb5 230) There may be some problem with initialization causing the error strings not to be accessible. Error 230 in the krb5 table is KRB5_KT_KVNONOTFOUND, Key version number for principal in key table is incorrect. How did you set up the keytab file on the server? And, is the KDC for this realm an MIT KDC or Windows AD? (If it's AD, I'm not familiar with the proper procedure for setting up a keytab for an application server running MIT code, but I'm sure others on this list are.) Note that in the MIT code, the kadmin option for generating a keytab changes the key in the process, so if you ran it more than once (maybe on different machines?), then only the last one generated is going to be useful. Also, check in case the client showing the problem has old credentials for the service cached using an earlier key version number and maybe the server only has a newer key; logging out and back in on the Windows box should avoid that problem. Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Help: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 230
Hi Ken, I have asked the domain admin to give me details on how the key was generated will let you know once i have full details. Also can you point me to the krb5 error table from where you got the mapping for Error 230. Because when i google it i get something different. Also if there is some problem with keytab file then i assume that kinit using this keytab should not work. If i do kinit -k -t /usr/local/apache/conf/http_beren.krb5keytab HTTP/beren.grolmsnet.de then it works fine. I only get error if when going through apache. Also kinit u...@*.* also works fine red hat machine. I am new at this so please let me know if i am asking stupid questions or am missing something basic :) On Tue, Feb 3, 2009 at 9:29 PM, Ken Raeburn raeb...@mit.edu wrote: On Feb 3, 2009, at 11:15, Omair Sajid wrote: Detailed error message from apache error log, we are on red hat enterprise 5 [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1432): [client *.*.*.*] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1432): [client *.*.*.*] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Tue Feb 03 10:41:21 2009] [debug] src/mod_auth_kerb.c(1147): [client *.*.*.*] Acquiring creds for h...@*.*.*.* [Tue Feb 03 10:41:21 2009] [debug] src/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. Minor code may provide more information (Unknown code krb5 230) There may be some problem with initialization causing the error strings not to be accessible. Error 230 in the krb5 table is KRB5_KT_KVNONOTFOUND, Key version number for principal in key table is incorrect. How did you set up the keytab file on the server? And, is the KDC for this realm an MIT KDC or Windows AD? (If it's AD, I'm not familiar with the proper procedure for setting up a keytab for an application server running MIT code, but I'm sure others on this list are.) Note that in the MIT code, the kadmin option for generating a keytab changes the key in the process, so if you ran it more than once (maybe on different machines?), then only the last one generated is going to be useful. Also, check in case the client showing the problem has old credentials for the service cached using an earlier key version number and maybe the server only has a newer key; logging out and back in on the Windows box should avoid that problem. Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mod_auth_kerb: gss_accept_sec_context() failed
On Mon, Jan 19, 2009 at 11:32 AM, Michael Ströder mich...@stroeder.com wrote: Andrew Cobaugh wrote: On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder mich...@stroeder.com wrote: HI! I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly initialized. 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 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. Yes, I'm pretty sure. Krb5Keytab points to the file I've extracted with ktpass.exe and the command-line tool 'strings' extracts the right Kerberos realm, HTTP and fully-qualified domain name of the server. Look at the ktutil command. That's the proper way to inspect a keytab. You'll want to make sure the key version number (kvno) is the same as what's in AD. Actually, one simple way to test that the keytab is valid is to do something like: kinit -k -t /path/to/keytab HTTP/your server's fqdn It might also help to know what types of keys are associated with that principal. You can do that by looking at the output of klist -e after performing the kinit command above (assuming it succeeds). How can I gather more debug log messages? Set LogLevel debug in httpd.conf It also might be helpful to look at your Active Directory server logs to see what principal apache is trying to use. It might be that it's requesting something other than HTTP/fqdn. Also, if you're going to use mod_auth_kerb to do GSS, you'll need a patch so that mod_auth_kerb sets up the GSS environment correclty, so that your application will use the correct KRB5CCNAME: http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch Many thanks for this information! Also, just to clarify, that's only if you're doing SPNEGO. I had the same problem trying to do SPNEGO to allow IMP to connect to an IMAP server using GSSAPI (through php's imap_open() function). Perhaps I should prod the developers to actually add in the call to gss_krb5_ccache_name() --andy Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mod_auth_kerb: gss_accept_sec_context() failed
Michael Ströder wrote: Andrew Cobaugh wrote: On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder mich...@stroeder.com wrote: HI! I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly initialized. 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 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. Yes, I'm pretty sure. Krb5Keytab points to the file I've extracted with ktpass.exe and the command-line tool 'strings' extracts the right Kerberos realm, HTTP and fully-qualified domain name of the server. How can I gather more debug log messages? Well, I set LogLevel debug in httpd.conf now and got the following messages in Apache's error_log: -- snip -- [debug] src/mod_auth_kerb.c(1635): [client 10.1.1.5] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [debug] src/mod_auth_kerb.c(1635): [client 10.1.1.5] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [debug] src/mod_auth_kerb.c(1247): [client 10.1.1.5] Acquiring creds for HTTP/nb2.stroeder.lo...@dom2.adtest.local [debug] src/mod_auth_kerb.c(1392): [client 10.1.1.5] Verifying client data using KRB5 GSS-API [debug] src/mod_auth_kerb.c(1408): [client 10.1.1.5] Client didn't delegate us their credential [debug] src/mod_auth_kerb.c(1108): [client 10.1.1.5] GSS-API major_status:000d, minor_status:96c73a1f [error] [client 10.1.1.5] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, Decrypt integrity check failed) -- snip -- Hmm... Also, if you're going to use mod_auth_kerb to do GSS, you'll need a patch so that mod_auth_kerb sets up the GSS environment correclty, so that your application will use the correct KRB5CCNAME: http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch Many thanks for this information! I've applied this patch. Ciao, Michael. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
mod_auth_kerb: gss_accept_sec_context() failed
HI! I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly initialized. 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 information (, Decrypt integrity check failed) Any clue here? Many thanks in advance. Ciao, Michael. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mod_auth_kerb: gss_accept_sec_context() failed
On Fri, Jan 16, 2009 at 2:58 PM, Michael Ströder mich...@stroeder.com wrote: HI! I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly initialized. 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 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. Also, if you're going to use mod_auth_kerb to do GSS, you'll need a patch so that mod_auth_kerb sets up the GSS environment correclty, so that your application will use the correct KRB5CCNAME: http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch --andy Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context
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. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context fails intermittently
Greetings! I am writing a module for Apache that does Kerberos authentication as well as providing Basic authentication as a fallback and authorization via Apple's Directory Services. I have followed both Apple's sample code and the code from mod_auth_kerb and think I've got 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). Needless to say, this has me somewhat stumped. Does anyone know where else I can look to see what exactly it is not liking on the times that it fails? Thanks in advance! Nathan Mellis Application Developer Mission Aviation Fellowship [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context fails intermittently
No to try and rain on your parade but... Wouldn't it be easier to use the standard mod_auth_kerb lib and write an apple only directory service apache module (if it doesn't already exist), and set up the auth kerb as non-authoritative? Cheers Edward On Mon, 2008-01-21 at 10:55 -0700, Nathan Mellis wrote: Greetings! I am writing a module for Apache that does Kerberos authentication as well as providing Basic authentication as a fallback and authorization via Apple's Directory Services. I have followed both Apple's sample code and the code from mod_auth_kerb and think I've got 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). Needless to say, this has me somewhat stumped. Does anyone know where else I can look to see what exactly it is not liking on the times that it fails? Thanks in advance! Nathan Mellis Application Developer Mission Aviation Fellowship [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context
Hi, I am new to kerberos world.. so forgive my noviceness I have a KDC running on linux and my client server are also on linux.. After registering the user principals and service principals when client is connecting to server, I can see 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 only as far as -1765328157L... It looks like a big coincidence that we are getting that close an error to be an INCORRECT error Any pointers? Manoj -- View this message in context: http://www.nabble.com/gss_accept_sec_context-tf4736612.html#a13545270 Sent from the Kerberos - General mailing list archive at Nabble.com. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
On 11/2/07, Manoj Mohan [EMAIL PROTECTED] wrote: Hi, I am new to kerberos world.. so forgive my noviceness I have a KDC running on linux and my client server are also on linux.. After registering the user principals and service principals when client is connecting to server, I can see 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 only as far as -1765328157L... It looks like a big coincidence that we are getting that close an error to be an INCORRECT error Any pointers? Manoj From krb5.h: #define KRB5_KT_KVNONOTFOUND (-1765328154L) This indicates that the client is getting a service ticket which was produced with a key version (KVNO) that the server does not have in its keytab file. I'd assume that you did a 'ktadd' for the service and failed to update the keytab that the service is using. (Or the client has an old service ticket and the server's keytab no longer has that older version of the key.) Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
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 accept_context worked. What is the usual practice? Should we always do ktadd with -e option? Why is it generating 2 entries when I do only ktadd (without -e) .. when in my krb5.conf there is only one encryption listed like this: [libdefaults] default_realm = EXAMPLE.IBM.COM default_keytab_name = FILE:/etc/krb5.keytab 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 in the kdc configuration. If your service doesn't support all the enctypes listed there, then you must limit the list with the -e option when doing the ktadd. Another strange observation is that...when I add service key to keytab file via ktadd.. and then performed kinit for the service.. kinit fails like this: kinit sso_11x/lxvm-l141.ibm.com Password for sso_11x/[EMAIL PROTECTED]: kinit(v5): Password incorrect while getting initial credentials The password I provided is correct. It works only when i do kinit first followed by ktadd. The reverse is not working. What is the reason for this ? ktadd generates a new random key and puts it in both the keytab file and in the KDC's database. That key is not based on a password. In order to use the new random key with kinit, you need to specify: kinit -k -t keytab_file sso_11x/lxvm-l141.ibm.com Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
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 accept_context worked. What is the usual practice? Should we always do ktadd with -e option? Why is it generating 2 entries when I do only ktadd (without -e) .. when in my krb5.conf there is only one encryption listed like this: [libdefaults] default_realm = EXAMPLE.IBM.COM default_keytab_name = FILE:/etc/krb5.keytab 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 in the kdc configuration. If your service doesn't support all the enctypes listed there, then you must limit the list with the -e option when doing the ktadd. We wouldn't want to look at the *default* ticket encryption types on the server anyways, but the set of supported enctypes on the server. If that list isn't being used (as specified, or the compiled-in default), in addition to the KDC-side restrictions, it's probably a bug, I think. Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
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 in the kdc configuration. If your service doesn't support all the enctypes listed there, then you must limit the list with the -e option when doing the ktadd. Er, it's a bit more complicated than that. kadmin ktadd without a -e argument lets kadmind pick an enctype list, namely, the supported_enctypes list (note: that's the KDC-side setting of supported_enctypes). kadmin ktadd with a -e argument specifies which enctypes to use. On Solaris 10 and up it's a bit more complicated still: without a -e argument kadmin ktadd behaves as if you had used -e with the list of permitted_enctypes (note: that's the client-side setting of permitted_enctypes). And the Solaris 10 and up kadmind uses 1DES enctypes only for clients that use the randkey-without-enctypes RPC. Bottom-line: - when doing ktadd you really want to specify what enctypes to use or else default to the *local* permitted_enctypes value, and of the enctypes you do specify, if you do, at least one should be in listed in the local permitted_enctypes; - if you're using straight MIT krb5's kadmin client then you should just always use the -e argument to ktadd, always. I think MIT should change kadmin's ktadd command to work more or less as the Solaris one does. The above applies only to ktadd, not chpass. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
gss_accept_sec_context server principal
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 by the input token to gss_accept_sec_context). There are various reasons for wanting to do this. Migrating to DNS is one - we would like to isolate applications from naming changes on the client hosts (or the server hosts for that matter) so that application servers can accept tickets for either: service/short_name@MS.COM service/short_name[EMAIL PROTECTED] thereby, allowing various client/hosts to migrate to DNS independently. service is generally the name of the application. short_name is the short name (our current hostname resolution renders short names). This short name could either be an actual host name or a one of several VCS service name. In other words, there could be many permutations, and I would like avoid any brute force approaches where I try every possible server principal name. [of course, I would populate the application server's keytab file with all of the necessary keytab entries so that it can assume any of the above identities - in fact this works already for kshd/klogind, which of course are not written with GSSAPI] My first attempt was to specify GSS_C_NO_CREDENTIAL for the verifier credential handle. This appeared to reveal a bug in gss_accept_sec_context(): (I'll send a separate email to [EMAIL PROTECTED] about this). == start bug description == krb5_gss_accept_sec_context acquires a default cred via krb5_gss_acquire_cred, if the supplied verifier_cred handle is GSS_C_NO_CREDENTIAL - which is places in the variable cred_handle It then proceeds to try to validate verifier_cred_handle, which in my case is GSS_C_NO_CREDENTIAL, rather than the new obtained credential (cred_handle). So this fails unnecessarily. So I fix this so that it validates cred_handle (which it obtains) rather than verifier_cred_handle (GSS_C_NO_CREDENTIAL). == end bug description == Nonetheless, in obtaining a credential handle, krb5_gss_acquire_cred will determine the server principal name. As invoked by krb5_gss_accept_sec_context, it will obtain a handle to the credential based on logic for GSS_C_NO_NAME and GSS_C_ACCEPT (cred_usage supplied by krb5_gss_accept_sec_context). In doing so, it invokes krb5_sname_to_principal, which determine the default principal name based on hostname and sname arguments (both NULL). This results in a server principal name constructed from an sname of host and a hostname based on gethostname which is then resolved via gethostbyname/gethostbyaddr. krb5_gss_acquire_cred then attempts to extract the keytab entry for this principal. Of course, this is not what I want. Calling gss_acquire_cred from my application using GSS_C_NO_NAME has the same affect. Has anyone attempted to write a GSS-enabled application server that can assume more than one different identities, based on the server principal name specified in the client's ticket. Is there another approach that will allow me to do this? The only other thought I have is to try to extract the server principal name for the token supplied by the client. This, however, seems like I am breaking rules by not treating tokens as opaque objects. I haven't investigated this approach yet, I was hoping there was a more natural approach than this. Any suggestions are highly appreciated. Thanks, Cesar Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context server principal
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 based on Cesar the server principal named in the client's ticket Cesar (implicitly specified by the input token to Cesar gss_accept_sec_context). GSS_C_NO_CREDENTIAL will do this in 1.3. The patches would be mildly difficult for me to extract right now though. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Interpreting gss_accept_sec_context results
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 Thanks in anticipation Sergei Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
