Re: AFS Server on Windows now works - please test new builds
Jeffrey Altman <[email protected]>
| Newsgroups | gmane.comp.file-systems.openafs.devel.win32 |
|---|---|
| Organization | No Longer Affiliated with Columbia University in the City of New York |
| Message-ID | <[email protected]> |
Douglas E. Engert wrote: >I read somewhere that in 2003 the Microsoft max ticket size was increased from >8000 to 12000 bytes. You may wish to consider this too. > >As a side note, Microsoft has been promissing a mod for AD 2003 to be able >to issue service tickets without a PAC. We even tested it. But it is still >not packaged as a hotfix I have been asking for this since August. >(I will bug them again.) Your above change makes this mod less critical, >at least for AFS. > Such a fix is really meaningless unless MS agrees to back port it to Windows 2000. Upgrading from 2000 to 2003 is not something a majority of sites will be willing to do. The effort is too great. Sites running 2000 will more than likely wait for the next major Server OS release to make a decision. >> * When obtaining AFS Tokens via KFW, krb524 is no longer required. >> Instead the raw Kerberos 5 ticket is used in its entirety. This >> is extremely important as it allows us to use pure Kerberos 5 KDCs >> as the source of the AFS authentication. The use of 4096 byte long >> tickets will allow tickets produced by all versions of Microsoft >> Active Directory to be used. >> >> create a user account. >> designate it DES only >> disable pre-auth >> specify its UPN to be "afs@realm" >> assign a SPN of "afs/cellname" to the UPN with setspn.exe >> >> * >> > >Working on msklog yesterday, which almost does the same thing as above, I think >I found a bug in openafs src/rxkad/ticket5.c This is used on the >AFS servers. In the krb5_des_decrypt routine, the variable ret is not initilized. >If the etype is not ETYPE_DES_CBC_CRC, no cksum_fun is set, >so ret is never set. ret is then used as the return code which may be garbage. > >This means that a des-cbc-md5 ticket may be rejected. >I am still looking at this. > Although I certainly can examine this issue, this list is not the appropriate place for this report. Please file bug reports to [email protected] so they may be tracked in RT and not be forgotten. Thanks.