On 07/19/11 04:05 AM, Jordan Brown wrote:
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".
I'm saying it is a means of mapping windows UIDs to Unix. I thought the
result cloud be used to authenticate via LDAP, but I overlooked the
password hashing.
Similarly, you're saying
"workgroup mode" (no Active Directory) in the same context as "LDAP ...
widely used to authenticate Windows users" (implies Active Directory).
No, LDAP != Active Directory, at least for NT4 domains.
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.)
That assumption is flawed (at least in our case), why would we use two
name services? Our configuration uses an NT4 domain with a Samba PDC.
I think this setup is fairly common where there are overlapping sets of
Unix and Windows users and a Unix based infrastructure. Your typical
Unix admin is fairly AD averse!
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.
Thank you for the detail, it makes a lot of sense. I guess what's
really missing is support for NT4 domains.
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.
I've seen attempts at that, not pretty!
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).
It does, thank you.
Now I have to come up with a solution of our environment....
--
Ian.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
