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? 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:[email protected]) > > C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\kinit.exe" > [email protected] > Password for [email protected]: > > C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe" > Ticket cache: API:[email protected] > Default principal: [email protected] > > Valid starting Expires Service principal > 12/21/10 10:32:30 12/28/10 10:32:30 krbtgt/[email protected] > 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/[email protected] > Getting v5 tickets: [email protected] > About to resolve name [email protected] to id > Id 26560 > Set username to [email protected] > 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:[email protected] > Default principal: [email protected] > > Valid starting Expires Service principal > 12/21/10 10:32:30 12/28/10 10:32:30 krbtgt/[email protected] > renew until 01/04/11 10:32:30 > 12/21/10 10:32:56 12/28/10 10:32:30 [email protected] > 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/[email protected] >>> Getting v5 tickets: [email protected] >>> About to resolve name [email protected] to id >>> Id 26560 >>> Set username to [email protected] >>> 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 [email protected] 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 '[email protected]' >>> _______________________________________________ >>> OpenAFS-info mailing list >>> [email protected] >>> https://lists.openafs.org/mailman/listinfo/openafs-info >>> >> > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info >
signature.asc
Description: OpenPGP digital signature
