Linkage dependencies

[Simo Sorce]

On Wed, 6 Dec 2000, Mayers, Philip J wrote:

> Yep, they're different things in my mind, but there are some
> interdependencies.
>
> 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.
>
> Let's enumerate the authentication mechanisms present in SMB and MSRPC:
>
> 1) Plaintext passwords - easily handled, very bad indeed
>
> 2) LanMan hash of passwords, used to encrypt a random 8-byte challenge - the
> server must have access to the LanMan hash, *or* must use a
> man-in-the-middle approach of connecting to another server/PDC, passing it's
> challenge onto the client, and passing the reply back to the server/PDC
>
> 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#
>
> 5) LMv3 - as 4, requires the server to have access to the LM#
>
> 6) NTLMSSPv1 - require the NT# and/or LM#. I don't know about NTLMSSPv2.
>
> 7) GSSAPI (specifically RFC 2478, SPNEGO GSSAPI Mechanism) - this will
> negotiate one of two mechanisms under Win2K, NTLMSSP and Kerberos5. K5
> passes AP_REQ tickets, NTLMSSP does ordinary NTLMSSP. 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.
>
>
> 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...
>
> 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
>
> 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...
>
> 2) Any authentication API must provide a way to accept a Kerberos ticket and
> return what user/timespan it gives authentication to. This is krb5_gss_*
> calls (in MIT at least), but we'll need an SPNEGO ASN.1 parser/encoder to
> extract the ASN.1 data. If the data is SPNEGO, we
>
> a) Install a hook to intercept
> .1.3.1.crappy.unregister.microsoft.ntlmssp.oid
> b) Check for unencapsulated NTLMSSP first, and pass that off to the
> aforementioned library
> c) Otherwise, pass the blob to the SPNEGO library (which will call back into
> us for encapsulated NTLMSSP)
>
>
> What questions are left unanswered?
>
> 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.

As Samba aim to support also Win2k domains implementing a third
(samba-only) way would be useless, so win2k way may be just good.

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

I think Berkleydb is not so portable and does not add anything to tdb!
Also I think standard PDC/BDC replication should be supported only when
you have mixed samba/NT DCs in the same domain (if ever ;).

>
> 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?

user level restriction info (time, workstation ... maybe adding IP?) are
yet in passdb so why moving it?

> There are other questions. I'm hoping to provoke some discussion though.
>
> Thoughts?
>
> Regards,
> Phil
>

ciao,
Simo.

--
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
-----------------------------------------------------------------
Be happy, use Linux!