[OpenAFS] When Using Kerberos5 is klog necessary?

[Chris McClimans]

It's kinda backwards here.
CS.TTU.EDU is my MIT Kerberos Realm and it trusts TTU.EDU which is the  
MS Active Directory Domain.
CS.TTU.EDU is a service principal domain, no user accounts.
I was looking into putting my service principal into the TTU.EDU AD.  
I've put in a request to get a keytab generated, but I'd rather keep  
control of my own realm and service principals if possible. Waiting on  
another organization to generate keytabs is a pain sometimes.
-chri

On Jan 22, 2004, at 4:48 PM, Christopher D. Clausen wrote:

> This should work, as we use it.
>
> (AD.UIUC.EDU is the MS Active Directory domain and it trusts the
> UIUC.EDU MIT Kerberos Realm.)
>
> cclausen@KBS-CDC C:\>unlog
> cclausen@KBS-CDC C:\>kdestroy
> cclausen@KBS-CDC C:\>tokens
> Tokens held by the Cache Manager:
>    --End of list --
> cclausen@KBS-CDC C:\>klist
> klist: No credentials cache found (ticket cache API:cclausen.krb5cc)
>
> Kerberos 4 ticket cache: API:krb4cc
> klist: No ticket file (tf_util)
> cclausen@KBS-CDC C:\>ms2mit
> cclausen@KBS-CDC C:\>gssklog
> cclausen@KBS-CDC C:\>tokens
> Tokens held by the Cache Manager:
> User cclausen's tokens for afs@acm.uiuc.edu [Expires Jan 23 02:07]
>    --End of list --
> cclausen@KBS-CDC C:\>klist
> Ticket cache: API:cclausen.krb5cc
> Default principal: cclausen@AD.UIUC.EDU
> Valid starting     Expires            Service principal
> 01/22/04 16:07:26  01/23/04 02:07:26  krbtgt/AD.UIUC.EDU@AD.UIUC.EDU
>         renew until 01/29/04 16:07:26
> 01/22/04 16:07:26  01/23/04 02:07:26  krbtgt/ACM.UIUC.EDU@AD.UIUC.EDU
>         renew until 01/29/04 16:07:26
> 01/22/04 16:43:21  01/23/04 02:07:26
> gssklog/mintaka.acm.uiuc.edu@ACM.UIUC.EDU
>         renew until 01/23/04 16:43:21
> Kerberos 4 ticket cache: API:krb4cc
> klist: No ticket file (tf_util)
>
>
> I did have to set the following registry key though to get it to work  
> in
> Windows 2003 Server:
> "The default behavior of the APIs used by MS2MIT have changed in  
> Win2k3.
> If you set
> HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\AllowTgtS 
> e
> ssionKey = 1 (REG_DWORD) Then ms2mit will be able to propagate the
> session key into the MIT cache"
>
> I don't have any XP machines, so I'm not sure if it is needed on  
> Windows
> XP.
>
> Also, you have to patch the Kerberos libraries on your AFS servers (or
> whicher machines run gssklogd) to support tickets from multiple realms.
> Doug Engert sent me the patch.   I'll forward it as a seperate message.
>
> <<CDC
> Christopher D. Clausen
> ACM@UIUC SysAdmin
>
>
> Chris McClimans <openafs-info@mcclimans.net> wrote:
>> David,
>> I'm using a similar setup here at TTU.
>> I have a CS.TTU.EDU mit realm with trust principals from the TTU.EDU
>> realm (an MS Active Directory) for user accounts.
>> I'm currently trying to find a decent solution from windows XP boxes
>> that are part of the TTU.EDU domain to automatically get tokens from
>> login. MIT leash/kinit + gssklog work however, ms2mit and gssklog
>> fail. Are you straight unixen in your department or do you have a
>> mixture like myself?
>> -chris
>>
>>
>>
>> On Dec 30, 2003, at 11:21 PM, David Botsch wrote:
>>
>>> I should add that here we have the additional complication of two
>>> kerberos
>>> realms. There is our realm/cell, and there is the realm used by the
>>> central
>>> computing on campus, here (and, of course, any used by any other
>>> departments).
>>>
>>> So, on our systems, if you want tokens/tickets in our cell, you klog.
>>> If you
>>> want tickets in the central realm, you kinit.
>>>
>>> So, switching to kinit for getting tokens/tickets causes other
>>> problems (in
>>> addition to the simple (heh) retraining of users problem).
>>>
>>> On Tue, Dec 30, 2003 at 10:34:00PM -0500, Ken Hornstein wrote:
>>>>> Why would I want to tell end users they have to type in two
>>>>> commands to
>>>>> get tokens instead of one? Most can barely handle just typing in
>>>>> "klog".
>>>>
>>>> Years ago, I added support to my kinit so that it runs aklog
>>>> automatically.
>>>> Works just fine.
>>>>
>>>> --Ken
>>>> _______________________________________________
>>>> OpenAFS-info mailing list
>>>> OpenAFS-info@openafs.org
>>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>> --
>>> ********************************
>>> David William Botsch
>>> Consultant/Advisor II
>>> CCMR Computing Facility
>>> dwb7@ccmr.cornell.edu
>>> ********************************
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>>
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>