SASL & GSSAPI [was Re: passdb redesign]

Gerald Carter gcarter at
Fri Nov 10 14:56:46 GMT 2000

"Mayers, Philip J" wrote:
> I see two levels of isolation possible:
> 1) All NT-type information stored in a passdb, SMBD 
> still handling the Unix side of things
> e.g.
> setuid(pdb_get_uid(SAM_ACCOUNT_HND*));
> 2) All information stored in a passdb, SMBD calls 
> generic functions in the passdb API to do 
> user-related things.
> pdb_switchtouser(SAM_ACCOUNT_HND*);

ok.  I was not planning on the second functionality.  Seems
to be a little out of scope.

> It's worth noting that in one years time, I predict 
> the majority of authentications to Samba will be 
> SNEGO-based, with GSSAPI tokens. 

And you are basing this belief on Windows 2000 
deployments?  I'm just asking.  Not antagonizing
at all.  Curious.

> The design of the current passdb API or the new one 
> will restrict what can be done. It's important to 
> distinguish getting user *information* from actually 
> authenticating and authorising a user. I believe they 
> are separate and have very little inter-dependency.

Yes.  They are different functions.  The passdb has 
nothing to do with authentication nor authorization
really.  Only persistent storage for user information.

How do you see the proposed API as inflexible?

> I suggest you drop all password/authtoken checking 
> capabilities from your current passdb API, and make 
> it purely an informational one. But bear in mind, 
> the authentication API (which is basically going to need 
> to be an extended GSSAPI-style API) will have 
> some interactions with the informational data.

Phil,  the API I am proposing performing no authentication.
That is at a higher level.  The API is only for USER_INFO
struct manipulation and access to/from persistent storage.

> If you haven't already, look at the SSPI or GSSAPI 

I have looked over GSSAPI (although not as in depth 
as SASL).

> The advantage of that being that we can plug in 
> additional mechanisms completely independently 
> of Microsoft  - how about a PGP auth mechanism for 
> Samba? Easy, specify  a GSSAPI mechanism for it. 
> SecureID? Easy too.

ok.  So here is a question.  LDAPv3 supports SASL (as 
defined in RFC2251).  MS's Active Directory is LDAP v3 
compliant so we assume it supports SASL.  Has anyone
looked to see what other SASL mechanisms are supported
(i.e. supportedSASLMechanisms attribute under the 
rootDSE)?  Is GSSAPI the only one?  

I really need to go back and read the GSSAPI specs again
I think.  I just had about a dozen questions pop up.

Cheers, jerry
   /\  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