ldap lpPassword and ntPassword fields

Allen Reese allen at driversoft.com
Tue Dec 15 20:32:57 GMT 1998


I missed exports for that last message.  There is a minor way around it.

SASL, can be used to encrypt the Auth transaction. I just worked some more
on the SecurityServices document and came up witha point around the
export.  Make the SecurityServices a wrapper alot like SSH does.  Then no
Product has to support it outright.  SecurityServices could do port
Wrapping:

Client:137-> |SS:4000->Server:4000->SS->| Server->137
Where everything between the pipes done by the TCP Wrapper
(SecurityServices).  That way, If you can get SecurityServices and run it,
no problem if you can't, still no problem.  ;)

Hope that helps.

Allen Reese
Senior Software Engineer
Driversoft, Inc.
allen at driversoft.com

On Tue, 15 Dec 1998, Luke Kenneth Casson Leighton wrote:

> > On Wed, 16 Dec 1998, Jean Francois Micouleau wrote:
> > 
> > > 
> > > 
> > > On Wed, 16 Dec 1998, Matthew Chapman wrote:
> > > 
> > > > Yep, ok, but some people will want to point Samba at existing LDAP servers
> > > > somewhere else. If you recommend replicating to a local LDAP server than
> > > > the replication happens in the clear which isn't nice either...
> > > 
> > > I agree. BTW, replication is more to off-load an LDAP server when reading
> > > entries. Because when you modify a record it's always on the main LDAP
> > > server.
> > > 
> > > For people using LDAP servers only compliant to the version 2 protocol,
> > > the datas are transmitted in clear text form.
> > > 
> > > LDAP protocol version 3 include some crypting solutions based on SSL/TLS
> > >  IIRC.
> > Yep it does.
> > 
> > You use SASL to get the authentication credentials, then you can use those
> > creds to authenticate and startup a SSL/TLS/Kerebos connection.
> > 
> > What would be really nice, is being able to say authenticate using ldap,
> > and possibly get a Secure connection out of that which other protocols can
> > run over.  ;)
> > 
> > This could be done with a wrapper, like ssh does.  You run the security
> > provider as a service, then the client box will talk over this layer
> > without knowing it's there.
> > So say ports 137,138,139 would be rerouted through the security service
> > then out to the server through the security service then back to 137,138,
> > or 139.
> 
> at this point you get into export restrictions.  encryption of ordinary
> user data makes samba "un-re-exportable" by u.s. mirror sites.
> 
> however, according to one certain respected lawyer's interpretation of the
> us export restrictions (don't remember the name), if the data is
> "authentication tokens" then the restrictions do not apply.  as soon as
> you start encrypting "user data" then they certainly do apply.
> 



More information about the samba-technical mailing list