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