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

Reply via email to