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

[Douglas E. Engert]

I have a similar issue today. While testing what happens
if the the power settings are changed to put the machine
to sleep over lunch.

Using Windows 7 64-bit
OpenAFS-1.5.7200
NetIDMgr 2.0.0.304

After coming back after lunch, the machine was asleep,
and I logged back on. The AFS client lock icon was broken,
the AFS console said the services was running, but I could
not start it, or stop it. AFS access was not working.

aklog -d showed what you are seeing. (I think it was the
same error.) But we use a principal of afs/anl.gov@ANL.GOV

(My mail files are in AFS so I had to restart the system
before writing this e-mail, and I should have written down
more information.)

The point being, I have had no problems at all with AFS on
W7 64, until I change the power option from never to 30
minutes for the test.

Could sleep mode have caused your problem?

Is there some issue with the cache manager coming out of sleep mode?


On 12/20/2010 2: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
>
>

-- 

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