Using the MSLSA krb5_ccache type with a non-Microsoft KDC
Douglas E. Engert
deengert at anl.gov
Fri Dec 19 11:37:14 EST 2003
Jeffrey Altman wrote:
>
> 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.
Thanks for the nice write up.
Yes I do that all the time, and can use either an AD realm, or an
MIT based realm.
May comments, questions may have been addressing to situation where
the SSPI/LSA will let you provide a userid and password
on the AuthIdentity parameter to the AcquireCredentialsHandle
but this gives you a local set of credentials I don't think you can
use these outside the application. If you can, this could
be used for kinit too. I think this is what the runas command is using.
So my original comments/questions maybe outside the scope of what
you where supporting in the modification.
I was using the feature with gssklog, msklog, and kx509 if the
user was on a machine not in a domain, and needed credentials
after logging in locally.
>
> 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
> >
> >
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the krbdev
mailing list