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:[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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
