Re: AFS Server on Windows now works - please test new builds

"Douglas E. Engert" <[email protected]>
Newsgroups gmane.comp.file-systems.openafs.devel.win32
Message-ID <[email protected]>

Jeffrey Altman wrote:
> 
> I have uploaded new test builds dated 20040402 to
> 
>     /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/
>     http://web.mit.edu/~jaltman/Public/OpenAFS/
> 
> The major changes since 1.3.62 are the following:
> 
>     * All of the resource files have been restructured to adhere to
>       a set of rules IBM implemented for loading string resources.
>       These rules had either been forgotten or were not discovered
>       by folks working on the OpenAFS sources.  The end result was
>       memory corruption.  This is primary item which was preventing
>       the AFS Server from working.
>     * Increased the size of the maximum ticket size stored in a token
>       from 344 bytes to 4096.  Increased the buffers used to convey
>       messages between the pioctl() caller and the SMB Server from
>       1000 bytes to 8196.  The code appeared to have been writing
>       above the top of the stack by quite a few number of bytes.
>       (please let me know if this solves the afsd_service.exe crashing
>       when the service is shutdown.)  The increased ticket size is
>       necessary for the next item.

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. 


>     * 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. 


> 
> Do not enforce the funky 8dot3 pattern matching rule that the first "."
> is special when using long file names.  (you must use "*.*" and not "*")
> Instead only enforce it when performing 8dot3 searches.
> 
> Note:  The following items are known to be horribly broken in this build:
> 
>     * The AFS Shell Extensions menu is entirely non-functional
>     * The installer launches the AFS Server Configuration tool on an upgrade
>       in a mode which forces server configuration as opposed to management.
>     * Every other reported bug in the OpenAFS Request Tracker
> 
> When installing the AFS Server note the following things:
> 
>     * if you are installing the AFS Server on a machine which has the
>       loopback
>       adapter installed, you must add an entry into the
>         %WINDIR%\System32\Drivers\Etc\Hosts
>       file for the IP Address you chose to use
>     * you must have an empty NTFS partition available before you start the
>       installation process
>     * do not turn on Freelance mode when installing the AFS Server
>     * The "afs" password you enter on the first screen must match the
>       password
>       you specify in the Active Directory or the KDC.  This password will be
>       entered into the local kaserver database for you in case you are not
>       using KFW.
>     * Performance sucks when the client and the server are both on the same
>       machine and you are writing to a read-write volume
> 
> Enjoy!!!!

-- 

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.