1st release of an LSA authentication package
Mon Nov 27 15:02:00 GMT 2006
On Mon, 27 Nov 2006, Corinna Vinschen wrote:
> Finally, after mulling over the idea to write an LSA authentication
> package for over 5 years and after 5 years of idly complaining about
> Microsoft's documention, I now managed to create an LSA authentication
> package to support our setuid implementation.
> I've checked the code in a couple of minutes ago. This new LSA
> authentication code has been tested on Windows 2000, XP, XP 64 bit,
> 2003 R2 64 bit and Vista RC2.
> This LSA authentication package is supposed to replace the subauth stuff
> entirely. For now I have only disabled subauthentication, but I intend
> to throw the code away at one point.
> So, what are the advantages of having an LSA authentication package?
> - The returned user token is matching the needs of all underlying OSes,
> especially the new concepts in Vista.
> - A real logon session gets created. Native calls to LookupAccountSid
> will return the correct domain\user combination (See the output of a
> native whoami.exe).
> - The user token is an interactive token, not a network token as
> returned by subauthentication.
> - The authentication package DLL can simply sit in /bin. The
> installation and registration of the authentication package only
> requires to tweak a registry key and rebooting.
> - This package comes complete with an installation script called
> - Using LSA authentication allows services like sshd to run under the
> SYSTEM account again. Using NtCreateToken requires SeCreateTokenPrivilege
> and starting with Windows 2003, services running under the SYSTEM
> account don't have this privilege anymore. So it was necessary to add
> special user accounts like sshd_server. LSA authentication only
> requires the SeTcbPrivilege, which SYSTEM is running with by default.
> - Under Vista, the user token contains everything necessary to support
> mandatory integrity control. It was *not* enough just to add a MIC
> SID to the group list and call NtCreateToken. The underlying mechanism
> is a bit more complicated. So, in the long run, the NtCreateToken
> method should only be a fallback to support NT 4. All other systems
> are better off with LSA authentication.
Thanks, Corinna! All of this sounds really cool, but...
> Anything else?
> - Yes. LSA authentication packages are loaded by LSASS.EXE at boot
> time. Consequentially it's impossible to replace the DLL without
> rebooting the machine. Which means, everybody having registered the
> Cygwin LSA auth package will always have to reboot after installing a
> new Cygwin DLL version. However, the cyglsa DLL is bound to the
> Cygwin version it's shipped with, so LSA authentication will fail
> until the machine has been rebooted.
This is making me quite uncomfortable. I really don't want to have to
reboot every time I update Cygwin (especially since there is no easy way
to detect from setup.exe that a reboot is needed if all Cygwin processes
are stopped). Would it be enough to just restart the "Net Logon" service?
Can this be done in the lsa/cygwin postinstall script?
I'll investigate the above when I can get my machine into a rebootable
state... Makes me wish I were running VMware...
|\ _,,,---,,_ firstname.lastname@example.org | email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
More information about the Cygwin-developers