On 07/18/11 15:29, Nico Williams wrote:
On Mon, Jul 18, 2011 at 11:05 AM, Jordan Brown<jordan.br...@oracle.com> wrote:
The *implementation* reason for it is twofold: First, workgroup-mode
authentication is based on NT hashed passwords. A UNIX system doesn't store
the clear text of your password, only a UNIX-style one-way hash of the
password, and so cannot generate an NT hashed password to do its side of the
authentication. The only way to do that authentication is to get the
cleartext password, do an NT-style hash on it, and store that NT-style
hashed password. You can't take an existing UNIX system, slap an SMB server
on it, and have authentication just work; the UNIX system simply doesn't
have the information that it needs. Second, there needs to be some user
To be fair we had the same problem with Kerberos. The way this is
solved is to create the necessary information. For Kerberos one way
to do that is to use the pam_krb5_migrate(5) module. You could
implement the same solution for a NIS or RFC2307bis+ based
"workgroup".
The problem is getting the required write access to the name service. It
might be possible to get better behavior in some cases, but my bet is that
we couldn't get anywhere near 100%. For instance, I'm pretty sure that
Oracle's internal NIS infrastructure is populated from some other database,
and that there's simply no way to write to it.
BTW, Windows systems don't use LDAP for authentication. With Active
Directory, they use Kerberos. You could, in theory, set up Kerberos, LDAP,
Or PKI.
Does Windows support any PKI-based authentication? But no matter, really
the point is that it would be quite difficult to set up enough
infrastructure to convince a Windows client to use Kerberos authentication,
without fully emulating Active Directory.
As best I can tell, it's partly a
questionable limitation (no way to manage NT-hash passwords for non-local
users) and partially a limitation imposed by the mismatch between the two
authentication systems (UNIX-hash-based and NT-hash-based).
One could argue that it's a shortcoming of Solaris. The question is:
does Oracle (or the Illumos community) care to address this? I don't
see why they should.
We could, in theory, augment our various directory subsystems to directly
support NT hashes, maintaining them whenever a user is created or a
password is changed. We could then change Solaris to take advantage of
that information.
However, it's worth noting that the fact that NT hashes need to be kept
secret already gives our security people heartburn, even in the very
limited way that we support them today (in an only-root-can-read file).
Putting them into a directory in a secure way would be ... tricky.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
