[RFC] Authentication Rewrite

[Andrew Bartlett]

Attached is a basic attempt to let people know what I am intending to do
with my 'Authentication Rewrite'.  It is by no means a formal document
(particularly given its title :-), but I hope it might draw some
comments.

For ideas on what the implementaion might look like: it will look much
like my 'authenticaiton rewrite' patches, but it won't have the same
ties to the RPC structures.

Andrew Bartlett

-- 
Andrew Bartlett
abartlet at pcug.org.au
abartlet at samba.org
-------------- next part --------------

The Great Authentication Rewrite of 2001
========================================

Over a the last little while I have been looking at the current state
of Samba's authentication.   Its a mess and in desperate need of a
rewrite, and has been the cause of inconsistent policy and  security
holes in the past (null passwords).  This attempts to address the
situation, by  implementing a standard interface.

Interface
=========

The interface is implemetd in terms of data structures, where these
are filled in as much as possible  by the calling process.   These
structures bear a remarkable similarly to the RPC structures I used in
my previous efforts in this area, but are notably different - and as a
core system component are defined within Samba, and not subject to
outside redefinition.

To authenticate a user in reply.c / srv_netlogon_nt.c / chpasswd.c and
wherever else we are checking  passwords, simply call

check_password(user_info, &server_info)

where user_info is an RPC like struct containing things like: 
- the challenge, 
- username,  
- requested username (it matters for NTLMv2),
- domain, requested domain (likewise) 
- and the passwords.

The user_info can contain multiple password schemes in the one
structure, but only those indicated as valid will be processed.  This
allows the existing password_ok() interface to function, as it doesn't
have any idea what type NTLM/LM password it is, so it can just fill in
both.  This may not been needed and might change.

The server_info struct will contain stuff like: 
- the user's Full Name
- a pamh for making setcred and session calls on (the setup and
   account calls will be done by then) 
- the session key (for srv_netlogon_nt.c)  
- and anything else I decide the authentication client code needs 
  to know.

In particular it will contain the NT_STATUS code returned by the
authentication server.  I may also include  a pointer to the actual
returns from the domain logon attempt, if we end up using this for a
proxy-DC setup.

(Note on proxy-DC ideas:  If we have the authenticion info from a
client, even via a domain logon, there is nothing to stop us shipping
this off to another domain, and this code will make this VERY easy.
This  also may already be implemented, but I can't see it in my CVS...)

I hope the interface will also deal with Trusted domains, but I need
some more info on how that works.

So as to further avoid code duplication, another even more abstract
interface will be available:

check_password_and_munge(user_info, &server_info)

will allow the username and domain mapping to be abstracted away,
which should avoid things like the bug in chgpasswd.c where the
username is simply lowercased, not GetPwnam()ed.  Calls to this
function will take the same structure, only the requested fields need
be filled in.

Implementation
 ==============

The implementation will deal with all authentications, including SHARE
level (outside code will still need to determine the username), USER
level, SERVER level (small hack required, specified challenge must be
one  sent by server) and DOMAIN level security.  Fallback to local can
be arranged as normal.

I have created a few new files, to separate this functionality into a
single logical component.

include/auth.h contains the type definitions, and smbd/auth.c contains
the interface and functionality.

au th.c may be split into 4, the generic interface, and the 3
authentication back ends.

This design allow for a lot of flexibility in the implementation -
including default domains/no default domains as per the team's
requirements.


Andrew Bartlett 1-Jul-2001