Subject: RE: Crossrealm Referal

From: "John Brezak" <[email-masked]>
Date: Mon, 19 Feb 2001 18:30:09 -0800

Questions below.

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2001 12:51 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Crossrealm Referal
> 
> 
> 
> John Brezak wrote:
> > > 
> > > If you don't know what I'm talking about:
> > > Take a standalone (i.e. domain-less and directory-less) W2K
> > > pro and attach it to a MIT Kerberos KDC.  Create a Kerberos 
> > > hostbased service principal for this workstation and try to 
> > > (a) install these credentials on the W2K machine and (b) try 
> > > to accept security contexts with these credentials on the W2K 
> > > machine using Microsoft's Kerberos.
> > > -- It's impossible!
> > 
> > [Jbrezak] You can take a standalone Win2000 server and 
> configure it to 
> > authenticate users presenting Kerberos credentials from a 
> MIT Kerberos 
> > realm. Microsoft does test this as an interop scenario. 
> Local accounts 
> > need to managed to provide authorization identity and need to be 
> > mapped to the Kerberos principal name. The computer must be 
> configured 
> > to a Kerberos
> > realm and the computer password must be set to the password 
> used in the
> > host principal for the computer.
> 
> I know how that works.  This is what I meant by "attaching a 
> standalone W2K pro to an MIT KDC.
> 
> Now what doesn't work is to create a hostbased service 
> principal like "sample/w2kpro.f.q.d.n" in the MIT KDC 
> database and configure the W2K machine so that an application 
> can request the credentials for "sample/w2kpro.f.q.d.n" and 
> accept security context from initiators that use 
> "sample/w2kpro.f.q.d.n" as the target name.

[Jbrezak] What identity is the client running under? The sample
client must be run under a logon context that has a kerberos
identity in order to use kerberos to authenticate to the
sample service.

> 
> 
> It sounds like there is a special hack in place that could 
> make it work for the "host/f.q.d.n" principal, but this is 
> *NOT* the service principal that I want.  (Eventually you 
> still have a copy of the following: ).
> 
> Martin Rex wrote (on 29-Jun-2000):
> > C:\ksetup
> > default realm = WDF.SAP-AG.DE (external)
> > WDF.SAP-AG.DE:
> >       kdc = uw1048.wdf.sap-ag.de
> > Mapping [email-masked] to d019080.
> > Mapping d019080/[email-masked] to d019080.
> > 
> > 
> > 
> > F:\sspigss>gssserver d019080/p35956n5.wdf.sap-ag.de mypasswd
> > WDF.SAP-AG.DE
> > reading token length: -1 of 4 bytes read
> > 
> > 
> > F:\sspigss>gssclient localhost d019080 Hallo
> > LoadLib = 77BE5629
> > checking localhost...calling host localhost, name d019080,
> > msg "Hallo".
> > Sending init_sec_context token (size=451)... continue needed...
> > Received accept_sec_context token (size=114)...
> > 
> > 
> > Block Size is 8, inbuffer = 6
> > Signature verified.

[Jbrezak] What identity are you logged on with when running this
Instance of gssclient?

> > 
> > 
> > F:\sspigss>gssclient localhost d019080/p35956n5.wdf.sap-ag.de Hallo 
> > LoadLib = 77BE5629 checking localhost...calling host localhost, name
> > d019080/p35956n5.wdf.sap-ag.de
> > , msg "Hallo".
> > Sending init_sec_context token (size=481)... continue needed...
> > Received accept_sec_context token (size=101)...
> > 
> > Sending init_sec_context token (size=499)... continue needed... 
> > Received accept_sec_context token (size=101)...
> > 
> > GSS-API error initializing context: 80090322
> > GSS-API error initializing context: 0
> 
[Jbrezak] What identity are you logged here?