On Mon, Jul 18, 2011 at 5:51 PM, Jordan Brown <jordan.br...@oracle.com> wrote: > On 07/18/11 15:29, Nico Williams wrote: >> 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.
So you give the customer a hook for this, and let them do what they have to to update NIS (or LDAP, or whatever). > 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. Yes. > 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. Are you sure that the issue isn't *how* you store them, rather than *that* you store them? We never had any other such issues with storing secrets (think of keytab files). Nico -- _______________________________________________ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
