[OpenAFS] Re: AFS and Windows PAC data still and issue?
Douglas E. Engert
Fri, 27 Jul 2007 17:29:53 -0500
John W. Sopko Jr. wrote:
> Douglas E. Engert wrote:
>> John W. Sopko Jr. wrote:
>>> I have been testing AFS using Windows 2003 SP2 as the KDC.
>>> Things seem to be working fine with OpenAFS 1.4.4 linux
>>> clients using kinit/aklog and Red Hat pam_krb5afs module.
>>> Also things seem to work fine with the Windows 1.5.21 afs
>>> client and kfw 3.2 on Windows XP clients.
>>> Is the PAC data still an issue with the latest OpenAFS release?
>>> Is the issue the PAC data that is put in the afs/cell.name
>>> service principal breaks older clients? Thanks for any input.
>> Could still be an issue with older clients, that had a limit around 1k?
>> OpenAFS added code to allow 12K, but I also saw a Microsoft article
>> that raised their limit to 14K!
>> But since AFS does not need the PAC you could tell AD 2003 to not send
>> The original patch was:
>> It adds another bit to the userAccountControl
>> You can get your AD admin to set this bit in the afs service account.
> The afs/cell.name service principal only belongs to the standard
> "domain users" group, (I think this is standard), and I do not believe
> the afs service principal will need to be in any other groups. Thus
> the PAC data for the service principal should not be growing. And as
> long as it is less then 12k this should not cause a problem,
> sound correct?
Nope. The PAC is the SUID and list of groups the user is in.
So it depends on how many groups the *user* is in.
The NO_AUTH_REQUIRED is set on the afs account to tell AD to not
copy the user's PAC from the user's TGT to the afs service ticket.
You could get an idea of how big the ticket could be looking at
the size of a kerberos ticket cache.
The PAC is in the TGT and is copied by the KDC to the service ticket.
ls -l cachefilename
Assume the AFS token is about this size.
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439