Linkage dependencies

[Mayers, Philip J]

You're right, the correct phrase is "authorization". But, for Samba, where
is the appropriate place to put the authorization checks? Inside or outside
the authentication code. PAM does it outside, but logically as part of the
authentication.

[As for PAM - "our needs" are surely those of the Samba users. PAM is not
much use for authentication, but there's no reason the pam_time module
couldn't implement the Samba logon hours restriction, for example.
Personally I don't much care either way, but I know people want PAM support]

Other MSRPC mechs (all use LM/NT# IIRC):

NETLOGON Secure Channel
NETLOGON Pipe credential chain
9x SMB Password change (not MSRPC I know)
NT MSRPC Password change
MSCHAPv2 (not Samba related)
PDC/BDC replication (pre NETLOGON Secure Channel)

Yes, I'm familiar with the LDAP GSSAPI/SASL stuff - that's what I anticipate
using (although Win2K has an encoding issue with the SASL bind returning an
empty server creds data, rather than omitting it. I don't know if Kurt (of
OpenLDAP) fixed that or not...). As for rsync - you can of course run that
over SSH (aligning your 'replication' method with your PKI) or kerberised
SSH/RSH (aligning it with your Kerberos infrastructure... AGH! Mind
overload! :o)

rsync won't work for a binary DB though (I suspect) unless Samba closed the
authdb/accountdb down before doing rsync. That's assuming you're even using
a file-based backend though - what about SQL? Are we saying that each passdb
backend must supply it's own replication mechanisms?

To summarise:

Your passdb code (which looks good by the way) will probably have to store
the LM/NT# as well as logon hours, kickoff time, allowed workstations etc.
The authentication code can then either use external libraries/data
(kerberos & keytab in the case of GSSAPI, Radius secret key for Radius,
etc.) for non-LM/NT# based mechanisms.

The authentication code can use the "pdb_getusername_lmhash/nthash" calls
for any LM/NT# based mechanisms (presumably *before* doing any username
mapping). When a user is authenticated, the passdb code then does
authorization, username mapping, and so on. Does that sound OK?

Regards,
Phil

+----------------------------------+
| Phil Mayers, Network Support     |
| Centre for Computing Services    |
| Imperial College                 |
+----------------------------------+  

-----Original Message-----
From: Gerald Carter [mailto:gcarter at valinux.com]
Sent: 06 December 2000 14:36
To: Mayers, Philip J
Cc: 'samba-technical at samba.org'
Subject: Re: Linkage dependencies


"Mayers, Philip J" wrote:
> 
> Ideally the authentication API would fetch a 
> "user token" representing user info from the 
> account storage API, check some things like kickoff 
> times as the final step of authentication (PAM might 
> be worth looking into here) and then return the token 
> to Samba.

Checking things like kickoff time deals with authorization,
not authentication.  See other message I just sent.

> Let's enumerate the authentication mechanisms present in 
> SMB and MSRPC:
> 
> 1) Plaintext passwords - easily handled, very bad indeed
> 
> 2) LanMan hash of passwords, 
>
> 3) NT hash, same as above except the "hash" is more secure
> 
> 4) NTLMv2 - Similar, but using better hashing algorithms, 
> and there's a client-challenge data, which means "security 
> = server" will *NOT* work. Requires the server to have 
> access to the NT#

MS didn't get this right until NT 4SP6a is my understanding
(fyi)

> 5) LMv3 - as 4, requires the server to have access to 
> the LM#

I have never heard of ntlm v3

> 6) NTLMSSPv1 - require the NT# and/or LM#. I don't 
> know about NTLMSSPv2. 
>
> 7) GSSAPI (specifically RFC 2478, SPNEGO GSSAPI Mechanism) 
>
> Note: Just because Win2K doesn't support any 
> other mechanisms, doesn't mean we can't. We could 
> add other mechanisms (OTP support, SecureID, etc.) as 
> long as they've got specified GSSAPI mechanisms.

Right, but that comes later :-)

> Those are the basics. There are several more MSRPC 
> mechanisms, which just goes to show how badly thought 
> out MS-RPC really is. I count at least 4 other 
> significant authentication types used, all dependent 
> on the LM/NT#, and all different. Thanks a lot 
> Microsoft...

Specifically what other MS-RPC mechanisms 
are your talking about?

> So, what conclusions can we draw?
> 
> 1) Any authentication API must either
> 
> a) Provide *all* of the authentication mechanism support 
> that Samba does b) Provide a way to get the LM/NT#, and 
> we leave the authentication support in Samba

Samba should handle this to start with I think.  To get it 
up and running.  Then we will have a better idea of how to 
split it out and if it is feasible at all.  We need all the SMB
code in Samba for the most part to implement the necessary
authentication mechanisms (i.e. the challenge/response
method using the LanMan/NT hashes).

> b) is of course the only practical way to go. That said, I'd 
> be interested in taking NTLMSSP support out into a 
> separate library, since Internet Explorer supports it. 
> Kerberos TLS cipher suites would be ideal, but there
> we go...

Arrggghh!@!@#  Mind overload!!!!! :-)

> 2) Any authentication API must provide a way to accept 
> a Kerberos ticket and return what user/timespan 
> it gives authentication to. 

I'll take you word on Kerberos stuff.  I've not studied
it too much

> 1) What's the best way to make the LM/NT# available 
> to multiple Samba servers. In (what I'm going to 
> call) a samba-native domain, I recommend 
> replicated/distributed LDAP, using the host LDAP keytab 
> to get service tickets on behalf of Samba, and 
> SASL GSSAPI authentication to the LDAP directory, 
> with appropriate ACLs. I think this is how Win2K 
> does it.

Have you looked at the GSSAPI mechanisms as supported by 
the LDAP v3 rfcs (included as a SASL mechanism)?
And yes I believe you analysis is correct.

> "Downlevel" samba-native or "mixed-mode" samba/NT domains 
> can use smbpasswd and/or berkleydb storage, which 
> could be replicated using the standard PDC/BDC 
> replication mechanisms.

a replication protocol is really only necessary between 
Samba and NT.  rsync works fine for smbpasswd, ...

> 2) Where's the best place to put account restriction info? 
> In sambas code? In the user info storage db (called 
> either by Samba, or by the authentication API)? In 
> the authentication code?

See the auth and account control flags in PAM.  I think 
this is a good distinction between aUthentication and 
authorization.






Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com/  VA Linux Systems   gcarter at valinux.com
       http://www.samba.org/       SAMBA Team          jerry at samba.org
       http://www.plainjoe.org/                     jerry at plainjoe.org

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )