[OpenAFS] aklog.exe tickling unwanted corp. AD servers

[Jeff Blaine]

On 12/21/2010 2:45 PM, Jeffrey Altman wrote:
> The failure to obtain tokens is because of the famous Win7 netbios name
> lookup bug.
>
> What are the domains associated with your vldb servers?  Can any of them
> be resolved to the corporate realm?

The VLDB servers are all Solaris boxes, serving for the
cell rcf.our.org.  They're all of the form hostN.our.org
and have IP addresses dating back 15 years.  They all
resolve properly via corporate DNS (I tested just now
to make sure).

> On 12/21/2010 12:16 PM, Jeff Blaine wrote:
>> On 12/21/2010 9:38 AM, Jeffrey Altman wrote:
>>> What is the default cell for the machine?
>>
>> rcf.our.org
>>
>>> What is the role that rcf.our.org plays on this machine?
>>
>> Other than being the configured cell name, none.
>>
>>> What realm is the user principal from?
>>
>> I'm not exactly sure what you're asking here.  RCF.OUR.ORG is
>> the configured default KfW realm and is where my krb5
>> credentials came from, for jblaine.
>>
>>> What credential cache type is in use?
>>
>> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
>> klist.exe: No credentials cache found (ticket cache
>> API:jblaine@RCF.OUR.ORG)
>>
>> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\kinit.exe"
>> jblaine@RCF.OUR.ORG
>> Password for jblaine@RCF.OUR.ORG:
>>
>> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
>> Ticket cache: API:jblaine@RCF.OUR.ORG
>> Default principal: jblaine@RCF.OUR.ORG
>>
>> Valid starting     Expires            Service principal
>> 12/21/10 10:32:30  12/28/10 10:32:30  krbtgt/RCF.OUR.ORG@RCF.OUR.ORG
>>          renew until 01/04/11 10:32:30
>>
>> C:\Users\jblaine>"c:\Program Files\OpenAFS\Client\Program\aklog.exe" -c
>> rcf.our.org -k RCF.OUR.ORG -d
>> Authenticating to cell rcf.our.org.
>> Getting v5 tickets: afs/rcf.our.org@RCF.OUR.ORG
>> Getting v5 tickets: afs@RCF.OUR.ORG
>> About to resolve name jblaine@RCF.OUR.ORG to id
>> Id 26560
>> Set username to jblaine@RCF.OUR.ORG
>> Getting tokens.
>> aklog.exe: ktc 7 (11862791) while obtaining tokens for cell rcf.our.org
>>
>> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
>> Ticket cache: API:jblaine@RCF.OUR.ORG
>> Default principal: jblaine@RCF.OUR.ORG
>>
>> Valid starting     Expires            Service principal
>> 12/21/10 10:32:30  12/28/10 10:32:30  krbtgt/RCF.OUR.ORG@RCF.OUR.ORG
>>          renew until 01/04/11 10:32:30
>> 12/21/10 10:32:56  12/28/10 10:32:30  afs@RCF.OUR.ORG
>>          renew until 01/04/11 10:32:30
>>
>> C:\Users\jblaine>"c:\Program Files\OpenAFS\Client\Program\tokens.exe"
>>
>> Tokens held by the Cache Manager:
>>
>> AFS device may not have started
>>
>> C:\Users\jblaine>
>>
>> [  AFS tray icon, as usual, says OpenAFS service cannot be    ]
>> [  reached.  NIM ->  Options ->  AFS shows the service running. ]
>>
>>> On 12/20/2010 3:26 PM, Jeff Blaine wrote:
>>>> Windows 7 64-bit (yeah, I know...)
>>>> OpenAFS 1.5.78 64-bit
>>>> KfW 3.2.2 with latest released Secure Endpoints NIM
>>>>
>>>> I can't figure out why
>>>>
>>>>       aklog.exe -d -c rcf.our.org -k RCF.OUR.ORG
>>>>       Authenticating to cell rcf.our.org.
>>>>       Getting v5 tickets: afs/rcf.our.org@RCF.OUR.ORG
>>>>       Getting v5 tickets: afs@RCF.OUR.ORG
>>>>       About to resolve name jblaine@RCF.OUR.ORG to id
>>>>       Id 26560
>>>>       Set username to jblaine@RCF.OUR.ORG
>>>>       Getting tokens.
>>>>       aklog.exe: ktc 7 (11862791) while obtaining tokens for
>>>>       cell rcf.our.org
>>>>
>>>> ...regardless of the final error, ends up generating Kerberos
>>>> packets toward our corporate AD server(s).
>>>>
>>>> C:\Windows\krb5.ini is as follows:
>>>>
>>>>> [libdefaults]
>>>>>       default_realm = RCF.OUR.ORG
>>>>>       forwardable = yes
>>>>>       ticket_lifetime = 7d
>>>>>       renew_lifetime = 14d
>>>>>       dns_lookup_realm = no
>>>>>       dns_lookup_kdc = no
>>>>>
>>>>> [appdefaults]
>>>>>       forwardable = yes
>>>>>
>>>>> [domain_realm]
>>>>>       .our.org = RCF.OUR.ORG
>>>>>
>>>>> [realms]
>>>>>       RCF.MITRE.ORG = {
>>>>>           kdc = rcf-kdc1.our.org
>>>>>           kdc = rcf-kdc2.our.org
>>>>>           kdc = rcf-kdc3.our.org
>>>>>           admin_server = rcf-kdc1.our.org
>>>>>           master_kdc = rcf-kdc1.our.org
>>>>> }
>>>>
>>>> The aklog.exe Wireshark capture from above shows the following:
>>>>
>>>>       DNS 'A' query for rcf-kdc1.our.org
>>>>       response
>>>>
>>>>       DNS 'A' query for rcf-kdc2.our.org
>>>>       response
>>>>
>>>>       DNS 'A' query for rcf-kdc3.our.org
>>>>       response
>>>>
>>>>       TGS_REQ to rcf-kdc1.our.org for afs/rcf.mitre.org
>>>>       response: "principal unknown afs/rcf.our.org" as expected,
>>>>                 because we use afs@RCF.OUR.ORG and it works fine.
>>>>
>>>>       DNS 'A' query for rcf-kdc1.our.org
>>>>       response
>>>>
>>>>       DNS 'A' query for rcf-kdc2.our.org
>>>>       response
>>>>
>>>>       DNS 'A' query for rcf-kdc3.our.org
>>>>       response
>>>>
>>>>       TGS_REQ to rcf-kdc1.our.org for afs/rcf.our.org
>>>>       response : "principal unknown afs/rcf.our.org" (why again?)
>>>>
>>>>       DNS 'A' query for rcf-kdc1.our.org
>>>>       response
>>>>
>>>>       netbios-ssn packet to 10.254.254.253 (MSLA)
>>>>
>>>>       microsoft-ds packet to 10.254.254.253 (MSLA)
>>>>
>>>>       query to corporate AD server port 88 (Kerberos) SYN
>>>>
>>>>
>>>>       [ ... some more corporate Kerberos junk that is not relevant ]
>>>>       [ to what I want to do                                       ]
>>>>
>>>> Does this make any sense?
>>>>
>>>> Note that I do not see anywhere in the packets where a TGS_REQ
>>>> was made for 'afs@RCF.OUR.ORG'
>>>> _______________________________________________
>>>> 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
>>
>