SASL & GSSAPI [was Re: passdb redesign]
Mayers, Philip J
p.mayers at ic.ac.uk
Fri Nov 10 15:58:47 GMT 2000
Well - windows 2000 is a biggie. But, I'm assuming that when I get SNEGO
support in SMBD, any Samba<->Samba connection is going to be SNEGO, and
anyone who has a kerberos infrastructure will get all the advantages of a
GSSAPI solution such as single-signon smbclient/smbsh/smbmount support.
Combined with some mods I'm hoping to make to smbmount involving the
reporting of unix permissions and ACLs, it might be a competitive
alternative to GSSAPI-protected NFS.
The proposed API is only inflexible if it touches upon the authentication
side of things. If it's just a user info API, then it's fine. I must have
misinterpreted the pseudo-code... In fact, a quick glance back shows I did.
For a USER_INFO get/set API, it's fine, so I don't have any reservations
really. My thoughts about the authentication side of things are still
shaking themselves out though...
As for SASL:
dn:
currentTime: 20001110155124.0Z
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=<blah>
dsServiceName: CN=NTDS
Settings,CN=XXXXXX,CN=Servers,CN=XXX,CN=Sites,CN=Configuration,DC=<blah>
namingContexts: CN=Schema,CN=Configuration,DC=<blah>
namingContexts: CN=Configuration,DC=<blah>
namingContexts: DC=<blah>
defaultNamingContext: DC=<blah>
schemaNamingContext: CN=Schema,CN=Configuration,DC=<blah>
configurationNamingContext: CN=Configuration,DC=<blah>
rootDomainNamingContext: DC=<blah>
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.840.113556.1.4.801
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 1.2.840.113556.1.4.528
supportedControl: 1.2.840.113556.1.4.417
supportedControl: 1.2.840.113556.1.4.619
supportedControl: 1.2.840.113556.1.4.841
supportedControl: 1.2.840.113556.1.4.529
supportedControl: 1.2.840.113556.1.4.805
supportedControl: 1.2.840.113556.1.4.521
supportedControl: 1.2.840.113556.1.4.970
supportedControl: 1.2.840.113556.1.4.1338
supportedControl: 1.2.840.113556.1.4.474
supportedControl: 1.2.840.113556.1.4.1339
supportedControl: 1.2.840.113556.1.4.1340
supportedControl: 1.2.840.113556.1.4.1413
supportedLDAPVersion: 3
supportedLDAPVersion: 2
supportedLDAPPolicies: MaxPoolThreads
supportedLDAPPolicies: MaxDatagramRecv
supportedLDAPPolicies: MaxReceiveBuffer
supportedLDAPPolicies: InitRecvTimeout
supportedLDAPPolicies: MaxConnections
supportedLDAPPolicies: MaxConnIdleTime
supportedLDAPPolicies: MaxActiveQueries
supportedLDAPPolicies: MaxPageSize
supportedLDAPPolicies: MaxQueryDuration
supportedLDAPPolicies: MaxTempTableSize
supportedLDAPPolicies: MaxResultSetSize
supportedLDAPPolicies: MaxNotificationPerConn
highestCommittedUSN: 2834425
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
dnsHostName: xxxxxx.xx.xx.xx
ldapServiceName: xx.xx.xx:xxxxxx$@XXXXXXXX
serverName: CN=<blah>
supportedCapabilities: 1.2.840.113556.1.4.800
isSynchronized: TRUE
isGlobalCatalogReady: TRUE
So no, just GSSAPI and GSS-SPNEGO. IIRC, MS's SPNEGO implementation will
only choose between NTLM and GSSAPI, which is pretty lame... That
restriction might just exist in SMB though...
WRT the Unix side of things, re: your just-sent post, I quite agree - Samba
should use the OS-base security mechanisms. One question is, where (if at
all) would you put username mapping? I recommend outside the passdb API.
Regards,
Phil
+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+
-----Original Message-----
From: Gerald Carter [mailto:gcarter at valinux.com]
Sent: 10 November 2000 14:57
To: Mayers, Philip J
Cc: 'samba-technical at samba.org'
Subject: SASL & GSSAPI [was Re: passdb redesign]
"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
\/ 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 )
More information about the samba-technical
mailing list