Using the MSLSA krb5_ccache type with a non-Microsoft KDC

[Jeffrey Altman]

Doug:

My short and sweet answer is that the MSLSA krb5_ccache type can only
be used to access the current user's logon session principal.  If you
can login to Windows using the Kerberos LSA then you may want to
consider setting KRB5CCNAME=MSLSA: in the environment for the session.

You are able to logon to Windows using the Kerberos LSA if your machine
is part of a Windows 2000 or Windows 2003 Active Directory domain. 

You are also able to logon to Windows using the Kerberos LSA if your
machine has been configured to authenticate to a non-Microsoft KDC
such as MIT.  The instructions for configuring a Windows 2000 XP
workstation to authenticate to a non-Microsoft KDC are documented
in TechNet somewhere. 

In brief:

   1. Install the Windows 2000 or XP support tools in order to obtain
      the tools: KSETUP.EXE and KTPASS.EXE.
   2. Install the Windows 2000 or XP Resource Kit to obtain the tools
      KERBTRAY.EXE and KLIST.EXE
   3. Add Realms and associated KDCs with: *KSETUP /AddKdc <realm>
      [<kdcname>]*.  If you leave off the <kdcname> DNS SRV records will
      be used.
   4. Specify the password change service host for the realm with:
      *KSETUP /AddKpasswd <realm> <Kpwdhost>*
   5. Assign the realm of the local machine with: *KSETUP /SetRealm
      <realm>* where realm must be all upper case. 
   6. Assign the local machine's password with: *KSETUP
      /SetComputerPassword <Password>
      *
   7. Specify the capabilities of the Realm KDC with: *KSETUP
      /SetRealmFlags <realm> <flag> [<flag> ...]* where flags may be
      *None, SendAddress, TcpSupported, Delegate, *and *NcSupported*,
   8. Map principal names to local accounts with: *KSETUP /MapUser
      <principal> <account>*

On the MIT KDC, you must then create service principals using the 
"Password" assigned to the machine.  So far the minimum list of 
principals required appear to be for a machine named "thinkpad" in the 
realm "KRB5.COLUMBIA.EDU" with a domain name of "kermit.columbia.edu":

    * host/thinkpad at KRB5.COLUMBIA.EDU
    * host/thinkpad.krb5.columbia.edu at KRB5.COLUMBIA.EDU
    * host/thinkpad.kermit.columbia.edu at KRB5.COLUMBIA.EDU
    * cifs/thinkpad at KRB5.COLUMBIA.EDU
    * cifs/thinkpad.krb5.columbia.edu at KRB5.COLUMBIA.EDU
    * cifs/thinkpad.kermit.columbia.edu at KRB5.COLUMBIA.EDU
    * cifs/THINKPAD-AFS at KRB5.COLUMBIA.EDU (if using OpenAFS)

There may very well be other serivces for which principals must be 
created depending on what you are running on the local machine.

It is very important to note that while you can successfully log into a 
Windows workstation by authenticating to the KDC without creating a host 
key; the logon session you receive will not be a Kerberos Logon 
Session.  There will be no Kerberos principal and no LSA cache to access.

The result of my KSETUP configuration looks like this:

    [C:\4\4NT]ksetup
    default realm = KRB5.COLUMBIA.EDU (external)
    ATHENA.MIT.EDU:
            kdc = kerberos.mit.edu
            kdc = kerberos-1.mit.edu
            kdc = kerberos-2.mit.edu
            kdc = kerberos-3.mit.edu
            Realm Flags = 0x0 none
    CC.COLUMBIA.EDU:
            kdc = kerberos.cc.columbia.edu
            Realm Flags = 0x0 none
    GRAND.CENTRAL.ORG:
            kdc = penn.central.org
            kdc = grand-opening.mit.edu
            Realm Flags = 0x0 none
    KRB5.COLUMBIA.EDU:
            kdc = yclept.kermit.columbia.edu
            Realm Flags = 0x0 none
    OPENAFS.ORG:
            kdc = virtue.openafs.org
            Realm Flags = 0x0 none
    RAEBURN.ORG:
            (no kdc entries for this realm)
            Realm Flags = 0x0 none
    Mapping jaltman at KRB5.COLUMBIA.EDU to jaltman.
    Mapping jaltman at CC.COLUMBIA.EDU to jaltman.
    Mapping jaltman at ATHENA.MIT.EDU to jaltman.
    Mapping all users (*) to a local account by the same name (*).

With this configuration I was able to successful obtain cross realm 
tickets for afs/iamx.com at IAMX.COM via the cross realm trust between 
KRB5.COLUMBIA.EDU and IAMX.COM.  The KDC for IAMX.COM was found using 
DNS SRV records even though IAMX.COM was not configured using KSETUP.

Jeffrey Altman


Douglas E. Engert wrote:

>Jeff, 
>This sounds like I good idea, and I see you have committed a change 
>last night. 
>
>Since the LSA will not be using the krb5.ini file, are there other
>requirements such as running the MS ksetup command so it matches what's
>in the krb5.ini? 
>
>>From some tests I had done for msklog using the LSA on a machine 
>which is not a member of the domain or any domain, to get a TGT for 
>a user who is in a domain, the LSA would use LDAP to do some lookup, 
>as well as port 88 to get the TGT. Whereas the MIT kinit only needed
>port 88. This has firewall implications. 
>
>If the KDC was not an MS AD, the LSA would need to have the ksetup 
>run to add the realm and kdc names. 
>
>There are surely other combinations of KDCs, DNS registration of the
>realm and KDCs, which might need to be spelled out as well
>  
>