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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig56B873D274FD062F56AA41F3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The problem isn't with OpenAFS, it is with the Windows 7 netbios name
resolution.  It breaks when the network adapter link drops which will
happen when you suspend the machine.

On 12/21/2010 2:34 PM, Douglas E. Engert wrote:
> 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.
>=20
> Using Windows 7 64-bit
> OpenAFS-1.5.7200
> NetIDMgr 2.0.0.304
>=20
> 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.
>=20
> 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
>=20
> (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.)
>=20
> 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.
>=20
> Could sleep mode have caused your problem?
>=20
> Is there some issue with the cache manager coming out of sleep mode?
>=20
>=20
> 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 =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
>>
>>
>=20


--------------enig56B873D274FD062F56AA41F3
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)

iQEcBAEBAgAGBQJNEQQmAAoJENxm1CNJffh4PjcIAJcn8Ef4OOeIlC+z/ck0EZ2b
pZ+t9zI6pCw8Rx9CnY7ocXrJYvkpYu2ohs/JPbAYe3/lk6sKGO78eODWvQjKwe79
CjoAYwERSY9a0n5x25FAKj/Qun/IXsr1iU5i9gzkqf8//gfJih7ZbIxCSl1Xj0bP
n15osRTVTS5jkrwjkFZdw8xrlRBd8CrOKucumX28e6uN5kIc312gcOTnWL8+Kjv/
Cg1IS4uMvcU3SFqKdGuw+uDyIr8Pu6juriipl5naQQgOcOYX4ONSKvTWDqVRdpd1
m6hUfONjmlu/U7C7AzP7RvFRbtIzzqIalIw3zOq1wMy7IFvvJUb8kQh49yNsDFY=
=3a5E
-----END PGP SIGNATURE-----

--------------enig56B873D274FD062F56AA41F3--