[OpenAFS] aklog.exe tickling unwanted corp. AD servers
Jeffrey Altman
jaltman@secure-endpoints.com
Tue, 21 Dec 2010 14:45:19 -0500
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig85ECD3F76F0D10A18F940C3C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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?
>=20
> rcf.our.org
>=20
>> What is the role that rcf.our.org plays on this machine?
>=20
> Other than being the configured cell name, none.
>=20
>> What realm is the user principal from?
>=20
> 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.
>=20
>> What credential cache type is in use?
>=20
> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
> klist.exe: No credentials cache found (ticket cache
> API:jblaine@RCF.OUR.ORG)
>=20
> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\kinit.exe"
> jblaine@RCF.OUR.ORG
> Password for jblaine@RCF.OUR.ORG:
>=20
> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
> Ticket cache: API:jblaine@RCF.OUR.ORG
> Default principal: jblaine@RCF.OUR.ORG
>=20
> 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
>=20
> 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=
>=20
> C:\Users\jblaine>"c:\Program Files\MIT\Kerberos\bin\klist.exe"
> Ticket cache: API:jblaine@RCF.OUR.ORG
> Default principal: jblaine@RCF.OUR.ORG
>=20
> 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
>=20
> C:\Users\jblaine>"c:\Program Files\OpenAFS\Client\Program\tokens.exe"
>=20
> Tokens held by the Cache Manager:
>=20
> AFS device may not have started
>=20
> C:\Users\jblaine>
>=20
> [ AFS tray icon, as usual, says OpenAFS service cannot be ]
> [ reached. NIM -> Options -> AFS shows the service running. ]
>=20
>> 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 =3D RCF.OUR.ORG
>>>> forwardable =3D yes
>>>> ticket_lifetime =3D 7d
>>>> renew_lifetime =3D 14d
>>>> dns_lookup_realm =3D no
>>>> dns_lookup_kdc =3D no
>>>>
>>>> [appdefaults]
>>>> forwardable =3D yes
>>>>
>>>> [domain_realm]
>>>> .our.org =3D RCF.OUR.ORG
>>>>
>>>> [realms]
>>>> RCF.MITRE.ORG =3D {
>>>> kdc =3D rcf-kdc1.our.org
>>>> kdc =3D rcf-kdc2.our.org
>>>> kdc =3D rcf-kdc3.our.org
>>>> admin_server =3D rcf-kdc1.our.org
>>>> master_kdc =3D 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
>=20
--------------enig85ECD3F76F0D10A18F940C3C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJNEQPRAAoJENxm1CNJffh43VgH/097hvLeRqDBewozLYgD+heB
7Cc9zJZjo/HE/3pGR6syPOVSlLCn3j+CKFri9cSTg5lpN8GaiQwRI9y08Qruw3XH
KS46VoytlkJk2stf5+4JRzoHVkwuXIAoe0aMa4ANHnLxuG3UTxjuFWvUqFwJf63P
yYX3j63l+WFepl/RbFv4DBbZNTkn8TDxCYxwq63DwvBMsYJaB21jiA0ur/nmz1oa
bLClnY3W+PXhZYYuRsTlCDkUS49feUPANg5GBg1vsvUBeH1FYsLOwxEb/oBsL3zA
gvFrDMMzQXaEPAkAh04m/Gv9VhIp3MD6xNnx0kySQuMSs3x2RifR/1vxHNPbrTo=
=cZ+E
-----END PGP SIGNATURE-----
--------------enig85ECD3F76F0D10A18F940C3C--