KFW and Vista

Jeffrey Altman jaltman at secure-endpoints.com
Wed Nov 29 19:35:22 EST 2006

Jeffrey Hutzelman wrote:
> On Thursday, November 23, 2006 07:47:01 AM -0500 Jeffrey Altman 
> <jaltman at secure-endpoints.com> wrote:
>> applications
>> are not permitted to modify the contents of the %WinDir% directory tree.
>> Any changes will be reverted.
> So what's the problem?  Kerberos is not an "application"; it is system 
> software.  Ordinary users should not be modifying the conf files we're 
> talking about; only administrative users should be doing that.
> If I understand what you're saying correctly, is that the virtualization of 
> %WinDir% and \Program Files\ is not layered, so non-privileged code doesn't 
> even get to _see_ the contents of the real directories; instead they see a 
> tree of empty stuff.
> Except I can't imagine that is actually true, because it would make it 
> impossible for an administrator to install a traditional non-vista-aware 
> application in a way that makes it available for all users of the system.

We already have this problem on 64-bit Windows.  The 32-bit applications
do not get to see the real \Program Files\ directory.  Instead, they are
redirected to the \Program Files (x86) directory.  This causes a problem
for the CellServDB file which must be accessed by tools such as the AFS
Control Panel, the AFS System Tray Tool, and Network Identity Manager,
and the command line tools.

For the moment, adminstrators must maintain two separate copies of the
CellServDB file.

We are going to have an equivalent problem for %WinDir% for 64-bit Vista

>> (3) if you build for Vista, can the resulting binaries be executed
>>     on Vista?
> The answer to this one had better be "YES".  For which occurance of "Vista" 
> should we be reading "XP" ?

The second one.

Right now we build Network Identity Manager for XP and it can't be used
on Windows 2000.  Instead we must build a separate set of Windows 2000
specific netidmgr.exe and nidmgr32.dll files.  This is because otherwise
undefined entry points in the Common Controls library prevent it from
being loaded.

>> Now in the Vista SDK, symbols are being selectively defined
>> based upon the OS version you are building the application for.
> So it's impossible to build an application that uses appropriate interfaces 
> based on a run-time test to determine if it's running on Vista or XP?  Ugh. 
> Again, I have trouble believing it's that bad, given that they appear to 
> have gotten this right for device drivers for several years and through 
> several WDM versions.

Its not impossible, but it does mean that you can't link against a
Common Controls library at build time.  Instead you would have to access
its functions in a much more manual process.  I do not want to take this

>> I'm suggesting drawing the line at Vista partly because the use of the
>> Vista SDK requires it but also because the user experience on Vista
>> is going to be different from the older OS versions anyway.
> I actually find the latter argument somewhat compelling, especially if the 
> feature set and user experience are expected to diverge further in the 
> future.

The User Account Control feature of Vista is going to require changes in
the user experience.  This is going to require application redesign for
OpenAFS and KFW.  Here is a link that provides details on how Microsoft
expects the user experience to change.


The primary change for KFW is that the Kerberos Configuration File
Editor that has been a part of Leash and NetIDMgr is going to be have be
separated into a new process or into a COM control that can be executed
as "Administrator" since even the "Administrator" account will not be
running normal processes with "Administrator" bits.

I also want NetIDMgr to be able to make use of the new Aero user
interface.  Doing so will require building KFW specifically for Vista.

For OpenAFS, the existing Control Panel and NetIDMgr plug-in require
redesign in order to support the Vista User Account Control user experience.

Jeffrey Altman

More information about the krbdev mailing list