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@gmail.com
- 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)
- 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
- 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.
- 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.
- 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.
- 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
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.
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:
- 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)
- 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
- 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.
- 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.
- 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.
- 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.
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Justin Haygood -
Klemens Friedl -
Thomas Weidenmueller