This is a discussion on RE: GSS_ACCEPT_SECURITY_CONTEXT - Kerberos ; Thanks Jeff.. Sorry for the lack of details. Here is what I am doing. Runtime Environment: 1. Linux Server Hosting KDC 2. Windows 2003 server running IIS in a workgroup environment as Application Server 3. Windows XP as workstation running ...
Thanks Jeff.. Sorry for the lack of details.
Here is what I am doing.
1. Linux Server Hosting KDC
2. Windows 2003 server running IIS in a workgroup environment as
3. Windows XP as workstation running IE 6.0
4. Workstation has been joined to Linux realm
In our Single Signon Solution,
1. The user will login to workstation (Kerberos realm on the linux)
2. Open IE and will invoke a page on the IIS
3. During the above process we like to authenticate the user using
So I am implementing an ISAPI filter which will filter all the request
to the IIS.
Step by step Handshake and ISAPI FILTER functionality
1. Check the incoming request's authentication header
2. If not Negotiate(Kerberos) then reject (401) and request a Negotiate
3. Since IE is logged on the realm and the KDC have a service principal
for the http service on the application server, IE will send a page
request with Negotiate authentication header (this will contains SPNEGO
token, which is wrapper over AP-REQ in a base64 encoded format) -- (IE
will set the GSS_C_MUTUAL Authentication flag (0x02)-- I have verified
that using the network sniffer ethereal)
4. Upon receving the valid SPNEGO token, ISAPI parse the token and
establish a security context by supplying the appropriate keytab and
5. After that I invoing gss_accept_security_context with appropriate
parameter and expected to get a return token with AP-REP.
6. But just got the GSS_S_COMPLETE with a output token that contains the
logged in user principal.
From: Jeffrey Hutzelman [mailto:email@example.com]
Sent: Tuesday, September 27, 2005 9:42 AM
To: Balakrishnan, Sivakumar; firstname.lastname@example.org
Cc: Jeffrey Hutzelman
Subject: Re: GSS_ACCEPT_SECURITY_CONTEXT
On Tuesday, September 27, 2005 10:11:56 AM -0500 "Balakrishnan,
> I am trying to implement a custom Kerberos authentication for my IIS
> application using an ISAPI filter. I am expecting the
> gss_accept_security_context tor return me AP-REP if I passed a input
> token(contains AP-REQ) with mutual_authentication flag set in its
> AP-options. But in my program the gss_accept_security_context returns
> GSS-S-Complete but when I parse the output token it just contains the
> Input principal and didn't contains a APP-REP.
It's unclear here whether the context token you're passing in is one you
got from another GSSAPI, or one you constructed yourself. The AP-REQ
by the Kerberos GSSAPI mechanism uses a special "checksum" which
additional data used in negotiating the GSSAPI context (see RFC4121,
section 4.1.1, or RFC1964 section 1.1.1). Part of this data includes
bits indicating which GSSAPI-level options were requested by the
application. In order for mutual authentication to happen, the 0x02 bit
these flags must be set.
At the GSSAPI level, the way to do this is to make sure that the
mutual_req_flag (in C, GSS_C_MUTUAL_FLAG) is set in the call to
-- Jeffrey T. Hutzelman (N3NHS)
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Kerberos mailing list Kerberos@mit.edu