SoC 2006 (Login Framework)

[Justin Haygood]

There are three integrated systems needed for authentication in ReactOS:

1. Winlogin
2. MSGINA (ROSGINA would work better, no?)
3. Some sort of Identity Management system with support for local and
remote authentication (remote can come with SMB support later)

Tiers 2 & 3 can be developed and tested on a non ReactOS system (aka a
real Windows system) initially (tho with the code staying in the ROS
Subversion tree), while Tier 1 is ReactOS specific.

I thus see three stages (aligned with the systems mentioned above):

1. Identity Management System with basic tools (get Setup to use it, at
least some basic command line tools to add and remove users and change
passwords, no need for a UI yet)

2. A ROSGINA that uses the Identity Management System

3. Get Winlogin back up and running and using the ROSGINA for
authentication.

Since its stage 1:

The identity management system's sole purpose is to create a
cross-subsystem, ReactOS-wide way to authenticate users. How each
subsystem uses the information provided is up to the individual
subsystem. As such, I see a database (Berkerly DB or Sqlite) of users
(and possibly a separate one with groups) with some basic metadata
describing the user:

1. Username
1. Real Name / Nickname
2. Encrypted Password (encrypted with a choice of algorithms, AES,
Blowfish, etc..)
4. Groups user belongs in (by name)

Any other metadata that should be stored in the authentication database?

The identity management system's API can be quite simple:

BOOL AuthenticateUserA( LPCSTR username, LPCSTR password );
BOOL AuthenticateUserW( LPCWSTR username, LPCWSTR password );

Basically, returning a TRUE if the particular user is valid and FALSE
otherwise. Other APIs to get other metadata can come later?

Any other ideas?

--Justin Haygood
justin.haygood(a)gmail.com

[Thomas Weidenmueller]

>   1. Winlogin 
We have a very basic winlogon in base\system\winlogon, it also has basic
code to load msgina.dll and provide a very very basic SaS loop (that is
used to display the GUI on the secured desktops and vor authentication
related messages)

>   2. MSGINA (ROSGINA would work better, no?) 
No, we need to stick to the name msgina.dll. There's a super-basic
version implemented in dll\win32\msgina

>   3. Some sort of Identity Management system with
> support for local and
>  remote authentication (remote can come with SMB support later) 
"Identity Management" is lsass.exe, which doesn't really exist in ros.
Many of the security APIs make lsa calls, which is capable of performing
authentication and also remote authentication.

>   Tiers 2 & 3 can be developed and tested on a non
> ReactOS system (aka a
>  real Windows system) initially (tho with the code staying in the ROS
>  Subversion tree), while Tier 1 is ReactOS specific. 
3) won't be able to be testable in windows as what you're talking about
is advapi32.dll + lsass.exe. That's how authentication and user
management is handled. Unfortunately lsass.exe doesn't exists in ros as
of now. We're going to have to work around these problems by adding some
hacks (ie. only "enumerate" one account, the administrator account etc.

>   1. Identity Management System with basic tools (get
> Setup to use it, at
>  least some basic command line tools to add and remove users and change
>  passwords, no need for a UI yet) 
Unfortunately to add, remove and change users you'd have to use
netapi32.dll (ie. NetUserAdd, NetUserChangePassword, ...). This DLL
doesn't exist anytime soon. A custom identity management system in ros
is out of question as we'd require lsass.exe to be implemented. That's
too much for your task, and we don't even have the RPC system working
well enough to accomplish this.
>   
>  2. A ROSGINA that uses the Identity Management System 
msgina.dll should just use the publicly documented functions of
kernel32, advapi32, netapi32, ... For the purpose of your project, we
might just hardcode some values, etc in these DLLs to get it working.

>   3. Get Winlogin back up and running and using the
> ROSGINA for
>  authentication. 
Winlogon already is able to load msgina.dll. However it's very
incomplete as it only calls very few of msgina's exported Wlx*
functions. msgina should export at least all documented Wlx* functions.

>   The identity management system's sole purpose is
> to create a
>  cross-subsystem, ReactOS-wide way to authenticate users. How each
>  subsystem uses the information provided is up to the individual
>  subsystem. 
These functions are all documented and we should not add a reactos
specific implementation (See LogonUser(Ex), CreateProcessAsUser,
ImpersonateLoggedOnUser, .... These is used to perform authentication
and we should not invent our own set.

>   As such, I see a database (Berkerly DB or Sqlite) of
> users
>  (and possibly a separate one with groups) with some basic metadata
>  describing the user: 
The users are managed and saved in the registry (SAM database), it's
located in HKLM/SAM. I'm not familiar with the format etc, but we lack
lsa and sam for user managment. This is why for the purpose of your task
we'll just make quick&dirty implementations of the required APIs to add
some fake implementation. Implementing a lsass.exe, sam etc is way too
much for your task.

>   The identity management system's API can be quite
> simple:
>  
>  BOOL AuthenticateUserA( LPCSTR username, LPCSTR password );
>  BOOL AuthenticateUserW( LPCWSTR username, LPCWSTR password ); 
As I mentioned above, rolling our own APIs is not desirable, you're
going to have to use LogonUser(Ex) and CreateProcessAsUser for
authentication.

I advice you to take a look at the documentation of the mentioned APIs
since they're fairly complex. Also you should read about the interface
between winlogon and msgina, the functions start with the Wlx prefix,
WlxInitialize for example. Remember that we need a SaS (that's basically
a window message loop on the secured desktops) that is required for APIs
like WlxSasNotify. Also you should take a look at our winlogon
implementation. It's very basic but also it gives you an idea of how the
architecture should look like.

I hope this email helps you a bit more. Sorry for replying a bit late, I
was going out a lot this weekend :)

Best Regards,
Thomas

[Klemens Friedl]

If you want to explore the SAM registry part, which is only viewable
with the "Local System" account.

One way to gain access to the SAM and Security keys is to execute the
registry.exe in the local system account. PsExec from
http://www.sysinternals.com supports an option that enables you to
launch a process in the local system account.

Download the psexec tool (freeware) from sysinternals.com and execute
the following command with the help of cmd.exe:

psexec -s -i -d c:\windows\regedit.exe

Then browse to:

HKEY_LOCAL_MACHINE -> SAM


Another way to gain access, is to reset the registry security
settings, but this will waken the system's security!


btw. the "Windows Internals 4th edtion" book has some chapters about
login process and security.

[Justin Haygood]

And the coding begins :)

I delved into MSGINA to figure out what documented APIs it did
implement, but incompletely, and what APIs it implemented only via a
stub, and what APIs are left.

Initial patches coming sometime soonish (not today).

Details: http://soc2006.justinhaygood.com/?q=node/3 (Yes, I'm blogging
my progress so that people can see it publically outside of this list).

On Mon, 2006-05-29 at 10:25 +0200, Thomas Weidenmueller wrote:

> >   1. Winlogin
>  
>  We have a very basic winlogon in base\system\winlogon, it also has basic
>  code to load msgina.dll and provide a very very basic SaS loop (that is
>  used to display the GUI on the secured desktops and vor authentication
>  related messages)
>  
> >   2. MSGINA (ROSGINA would work better, no?) 
>
>  No, we need to stick to the name msgina.dll. There's a super-basic
>  version implemented in dll\win32\msgina
>  
> >   3. Some sort of Identity Management system with
> > support for local and
> >  remote authentication (remote can come with SMB support later) 
>  
>  "Identity Management" is lsass.exe, which doesn't really exist in ros.
>  Many of the security APIs make lsa calls, which is capable of performing
>  authentication and also remote authentication.
>  
> >   Tiers 2 & 3 can be developed and tested on a
> > non ReactOS system (aka a
> >  real Windows system) initially (tho with the code staying in the ROS
> >  Subversion tree), while Tier 1 is ReactOS specific. 
>  
>  3) won't be able to be testable in windows as what you're talking about
>  is advapi32.dll + lsass.exe. That's how authentication and user
>  management is handled. Unfortunately lsass.exe doesn't exists in ros as
>  of now. We're going to have to work around these problems by adding some
>  hacks (ie. only "enumerate" one account, the administrator account etc.
>  
> >   1. Identity Management System with basic tools
> > (get Setup to use it, at
> >  least some basic command line tools to add and remove users and change
> >  passwords, no need for a UI yet) 
>  
>  Unfortunately to add, remove and change users you'd have to use
>  netapi32.dll (ie. NetUserAdd, NetUserChangePassword, ...). This DLL
>  doesn't exist anytime soon. A custom identity management system in ros
>  is out of question as we'd require lsass.exe to be implemented. That's
>  too much for your task, and we don't even have the RPC system working
>  well enough to accomplish this.
> >   
> >  2. A ROSGINA that uses the Identity Management System 
>  
>  msgina.dll should just use the publicly documented functions of
>  kernel32, advapi32, netapi32, ... For the purpose of your project, we
>  might just hardcode some values, etc in these DLLs to get it working.
>  
> >   3. Get Winlogin back up and running and using the
> > ROSGINA for
> >  authentication. 
>  
>  Winlogon already is able to load msgina.dll. However it's very
>  incomplete as it only calls very few of msgina's exported Wlx*
>  functions. msgina should export at least all documented Wlx* functions.
>  
> >   The identity management system's sole purpose
> > is to create a
> >  cross-subsystem, ReactOS-wide way to authenticate users. How each
> >  subsystem uses the information provided is up to the individual
> >  subsystem. 
>  
>  These functions are all documented and we should not add a reactos
>  specific implementation (See LogonUser(Ex), CreateProcessAsUser,
>  ImpersonateLoggedOnUser, .... These is used to perform authentication
>  and we should not invent our own set.
>  
> >   As such, I see a database (Berkerly DB or Sqlite)
> > of users
> >  (and possibly a separate one with groups) with some basic metadata
> >  describing the user: 
>  
>  The users are managed and saved in the registry (SAM database), it's
>  located in HKLM/SAM. I'm not familiar with the format etc, but we lack
>  lsa and sam for user managment. This is why for the purpose of your task
>  we'll just make quick&dirty implementations of the required APIs to add
>  some fake implementation. Implementing a lsass.exe, sam etc is way too
>  much for your task.
>  
> >   The identity management system's API can be
> > quite simple:
> >  
> >  BOOL AuthenticateUserA( LPCSTR username, LPCSTR password );
> >  BOOL AuthenticateUserW( LPCWSTR username, LPCWSTR password ); 
>  
>  As I mentioned above, rolling our own APIs is not desirable, you're
>  going to have to use LogonUser(Ex) and CreateProcessAsUser for
>  authentication.
>  
>  I advice you to take a look at the documentation of the mentioned APIs
>  since they're fairly complex. Also you should read about the interface
>  between winlogon and msgina, the functions start with the Wlx prefix,
>  WlxInitialize for example. Remember that we need a SaS (that's basically
>  a window message loop on the secured desktops) that is required for APIs
>  like WlxSasNotify. Also you should take a look at our winlogon
>  implementation. It's very basic but also it gives you an idea of how the
>  architecture should look like.
>  
>  I hope this email helps you a bit more. Sorry for replying a bit late, I
>  was going out a lot this weekend :)
>  
>  Best Regards,
>  Thomas
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev