On 07/18/11 02:27, Ian Collins wrote:
On 07/18/11 09:04 PM, Chris Ridd wrote:
On 18 Jul 2011, at 08:39, Ian Collins wrote:

Hello,

I'm investigating replacing Samba in an organisation with about 1000
users (most have both Unix and windows accounts) that still uses an NT4
domain. All authentication is through Solaris based LDAP.

I am struggling to see a way, given the lack of LDAP support in
workgroup mode. I'm also wondering why LDAP isn't supported when it is
so widely used to authenticate windows users.

Has anyone managed this?
It *is* a rather annoying restriction. FWIW I think you can get away with
just having a user entry in /var/smb/smbpasswd on the server with the
rest of the user's details coming from LDAP. I'm not sure if that's a bug
or not, but it is useful.

So if there was a way to build the smbpasswd file without using passwd(1)
and its partner in crime pam_smb_passwd.so that might well do the job.

Cheers, I might be able to get away with that, but keeping 1000+ users in
sync is a pain.

I don't see what's hard about LDAP authentication in workgroup mode given
directory based mapping.

I'm confused. You're saying "directory based mapping" in the same sentence as "workgroup mode". "Directory based mapping" implies Active Directory; "workgroup mode" means "no Active Directory". Similarly, you're saying "workgroup mode" (no Active Directory) in the same context as "LDAP ... widely used to authenticate Windows users" (implies Active Directory).

There *is* a limitation - arguably a bug, but it was deliberate at the time - that in workgroup mode you can't use SMB to authenticate as a user whose records are from LDAP or NIS. You can only use locally-defined users, users defined in /etc/passwd. The assumption was that if you're using enterprise-class name service in the UNIX world, you'd also be using enterprise-class name service in the Windows world (that is, Active Directory). (Actually, the limitation is also present in domain mode, but is less interesting there.)

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 interface by which the password gets entered by the user, turned into an NT hash, and stored. The implementation chosen is to interpose on the normal UNIX password-set function... which is, by and large, only usable on locally-defined users. That's arguably a gap that should be corrected: there should be a way to explicitly store the NT-style hash for a user who exists in LDAP or NIS. Adding such a thing would allow you to set up LDAP-based or NIS-based users for SMB access. However, you'd still have to more-or-less manually maintain those NT-hash passwords locally, because your LDAP and NIS servers don't store them.

BTW, Windows systems don't use LDAP for authentication. With Active Directory, they use Kerberos. You could, in theory, set up Kerberos, LDAP, and related systems to simulate enough of Active Directory that a client would try to authenticate using Kerberos, but at that point, well, you've implemented Active Directory and you no longer have a "workgroup" environment.

Does that help to clarify the situation? 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).
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss

Reply via email to