Cross realm auth with MS Server 2003 and MIT kerb

[Douglas E. Engert]

BarBaar wrote:

> deengert at anl.gov ("Douglas E. Engert") wrote in message news:<41767A4D.9050807 at anl.gov>...
> 
>>So let me get this straight. You have two realms, TEST.NL (AD)
>>and TEST2.NL MIT based.
>>
>>The user is testor at TEST2.NL.
>>
>>The workstation i.e. server in this case is XP box with pricipal
>>host/yourxp at TEST.NL abecause it is a member of the domain.
>>
>>What should happen when you try and login to the XP
>>machine:
>>
>>    workstaiton requests TGT from TEST2.NL
>>
>>    workstation decrypts using the password.
>>
>>    workstaitons trys to use this TGT to get cross realm TGT for the
>>    realm of the workstaion.
>>
>>    workstation uses this cross realm to get service ticket
>>    for its principal.
>>
>>    Workstation then uses PAC from ticket to map you to the
>>    correct account on the workstaiton.
>>
>>
>>So any number of things could be wrong. Since you are trying
>>to use a MIT generated ticket it does not have a PAC. So when
>>the workstation tries to determine what local account you are
>>authorized for, it can't figure this out.
>>
>>There is some way to tell AD that it can accept a Kerberos ticket
>>from an MIT realm as authentication to an AD account. This might
>>be what is missing. In this case the cross realm TGT would then
>>have PAC information that the workstation could ten use.
>>
>>

This sounds like the main problem, but you may be seeing other
problems too. See the note from swbell <kerygma2 at swbell.net> on this.


>>Another simpler test to start with is have an XP workstation that
>>is not part of a domain, but is registered with the MIT realm.
>>(My W2000 machine is like this. we do just the opposite, use the AD
>>principals to logon to unix.) Then run the ksetup and add the mapping
>>to local accounts and ad a principal for host/nondomainworkstation at TEST2.NL.
>>Then you can use a user principal from either TEST.NL or TEST2.NL to
>>login to the workstation. This would verify that your cross realm
>>keys are correct in one direction.
>>
>>
> 
> 
> Hi,
> 
> I found the following message on my w2k3 AD:
> 
> 10/21/2004	11:48:35 AM	Kerberos	Error	None	3	N/A	BART	"A Kerberos
> Error Message was received:
>          on logon session 
>  Client Time: 
>  Server Time: 9:48:35.0000 10/21/2004 Z
>  Error Code: 0xd KDC_ERR_BADOPTION
>  Extended Error: 0xc00000bb KLIN(0)
>  Client Realm: 
>  Client Name: 
>  Server Realm: TEST.NL
>  Server Name: host/bart.test.nl
>  Target Name: host/bart.test.nl at TEST.NL
>  Error Text: 
>  File: 9
>  Line: ab8
>  Error Data is in record data."
> 10/21/2004	11:33:35 AM	Kerberos	Error	None	3	N/A	BART	"A Kerberos
> Error Message was received:
>          on logon session 
>  Client Time: 
>  Server Time: 9:33:35.0000 10/21/2004 Z
>  Error Code: 0xd KDC_ERR_BADOPTION
>  Extended Error: 0xc00000bb KLIN(0)
>  Client Realm: 
>  Client Name: 
>  Server Realm: TEST.NL
>  Server Name: host/bart.test.nl
>  Target Name: host/bart.test.nl at TEST.NL
>  Error Text: 
>  File: 9
>  Line: ab8
>  Error Data is in record data."
> 

Jeff said earlier it was the KDC rejecting a message. Since all the realm
names listed above are for TEST.NL that would be the AD.

It could be that since your TGT does not have a PAC, and can not
map your principal to an AD account it would not issue you a service
ticket. (But don't hold me to this.)

Some other testing that could be done:

Use the MS kerbtray and or klist to look at tickets.

Run ethereal to see network packets including some Kerberos.

Rather then trying to debug from windows login, logon as a local
user so you have no other tickets, then use the runas command
which will try and get tickets much like the login does. YOu can then watch
the network trafic.  When this works then try the login.


> This messeage also appears when I try it all the other way around:
> first authenticate on the w2k3-domain, and then try to open a
> kerberized SSH session to the linux box (which is in another realm)...
> 

Hmmm, that should work, I do that all the time. Whose SSH client and server?
But if the ssh client is using SSPI for GSSAPI, it may not know what realm
the server is in. SecureCRT can let you specify a SPN as
host@<unix.host.name>@<realmofhost> i.e. it can let the client specify the
realm of the host, as the AD forest does not know where it is.

> Something tells me this is about the infamous PAC-field. Is that
> correct?

The above no.

> 
> I also found this link: http://support.microsoft.com/?kbid=832572 But
> it is only for w2k.

This is not what you want. It tells the AD to not add a PAC to tickets
for selected services, i.e. non Windows services on UNIX that don't
want the PAC or cnat handle the large ticket with a PAC.
Also it should work on W2003 I think it has a misprint, where it says
twice:
  "Microsoft Windows 2000 Enterprise Edition"
  "Microsoft Windows 2000 Enterprise Edition"
I think the second should say 2003.
The Keywords  have "kbwinserv2003presp1" and "kbwin2000presp5fix"
which implies to me that it will be part of W2003 SP1 and W2000 SP5

> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444