Linkage dependencies

[Gerald Carter]

"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 )