Sam Hartman wrote: > > IN the first cut of KFW 4.0 we're going to have a per-user ccapi process like > we do today. > > However I want to document some discussions with Jeff Altman on why > we eventually want to strongly consider one ccapi cache server for the > entire system. > > There are two issues. The first is getting credentials from the login > process into the ccapi and the second is termination of the ccapi. > > THere is not a reliable way of getting some code you write executed in > every new login session. Today we're using login scripts. They don't > always get run. For example they do not get run in sessions created > by scheduled tasks. Login scripts are also not executed when the desktop is unlocked which prevents being able to automatically refresh credentials in response to a manual Ctrl-Alt-Del or unlocking the screen saver.
Login scripts are also not run for remote connections that start processes for a user but do not create a desktop. > > The other challenge is knowing when to terminate the ccapi server. > Typically, if I understand this correctly, the ccapi server terminates > when it receives a logout notification. However there are classes of > sessions that do not log out until all processes in the session > terminate. This creates a catch-22. When "RUNAS" is used, a new logon session is created that shares the current desktop. The logon session is not terminated until all processes within the session terminate. For a normal interactive desktop session the shell (explorer.exe) will close all processes in the session. For sessions created with RUNAS, there is no shell to manage the child processes. Instead, the command being executed by RUNAS is started directly. If it in turn causes another process such as the ccapi server to start and does not shut it down, then the logon session will never terminate. I guess we could add code to the ccapi server process to periodically enumerate all processes and determine if it is the last one in the current session and if so have it terminate. Although, that may require privileges that the process does not in fact possess. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
