1st release of an LSA authentication package
Mon Nov 27 13:53:00 GMT 2006
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
- 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.
And the drawbacks?
- As for subauthentication, this will not run on NT4 and earlier.
The problem is that Windows provides a secure32.dll only starting
with Windows 2000. Secure32.dll is the DLL supposed to export the
necessary functions like LsaLogonUser. There is a secur32.dll
for NT 4, shipped with the DSclient package (Active directory client
extension for NT 4, downloadable from microsoft.com), but that
secur32.dll does not export the functions necessary for the client
side of LSA authentication, unfortunately.
- As for subauthentication, you have to have a 64 bit version of the
However, I have added a script to build the 64 bit DLL, and I have
added a precompiled binary 64 bit DLL to the new lsaauth directory.
`make install' installs both DLLs and cyglsa-config checks if it's
running on a 32 bit or 64 bit system. Depending on that test, it
registers either cyglsa.dll or cyglsa64.dll.
- 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.
- Obviously, the 64 bit DLL in the repository has to be rebuilt for
each new Cygwin release. I really hope we get a 64 bit enabled
GCC at one point, so we can drop the requirement of having to build
the 64 bit DLL using Visual C++.
Please give it a try. It's really not difficult to install, especially
when using the cyglsa-config script.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-developers