1st release of an LSA authentication package

Corinna Vinschen corinna-cygwin@cygwin.com
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
  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
  /bin/cyglsa-config.

- 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
  authentication DLL.
  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.

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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat



More information about the Cygwin-developers mailing list