Linkage dependencies

Mayers, Philip J p.mayers at
Wed Dec 6 09:58:45 GMT 2000

Yep, they're different things in my mind, but there are some

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

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

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?

There are other questions. I'm hoping to provoke some discussion though.



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

-----Original Message-----
From: Gerald Carter [mailto:gcarter at]
Sent: 05 December 2000 19:52
To: Mayers, Philip J
Cc: 'samba-technical at'
Subject: Re: Linkage dependencies

"Mayers, Philip J" wrote:
> Well, the current extsec code uses:
> prs_init
> prs_give_memory
> prs_offset
> {init,smb_io_}rpc_auth_verifier
> {init,smb_io_}rpc_auth_ntlmssp_{neg,chal,resp}
> The files that these are in (and hence their .o's) 
> use functions from passdb, which aren't needed, and 
> other stuff which is. This might be good
> time to discuss abstracting out the authentication 
> APIs.

authentication APIs vs. account storage APIs?  These are 
different things in my mind.

I'm up for discussion.  Bring it on! :-)

   /\  Gerald (Jerry) Carter                     Professional Services
 \/  VA Linux Systems   gcarter at       SAMBA Team          jerry at                     jerry at

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

More information about the samba-technical mailing list