Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
On 07/19/11 01:26 PM, Jordan Brown wrote: On 07/18/11 16:14, Ian Collins wrote: Another alternative I have been investigating at home is Windows authentication with LDAP. I can log into my test VM using pGina, the next step is to access shares... I'm not familiar with that variation. Is it a stock Windows feature, or are you using some kind of third-party authentication component? See http://www.pgina.org/index.php/About -- Ian. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
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. Chris ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
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
Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
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. 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: Nah, just interpose on normal login :) 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. That would have to get fixed, but it's not *that* hard. 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. 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. Right. (It's LDAP + Kerberos + DNS + various MSRPCs.) 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). 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. Nico -- ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
On 07/18/11 14:40, Ian Collins wrote: 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. Yes, but do NT4 domains use LDAP for authentication? I can only barely spell NT4, but I was under the impression that the addition of LDAP was one of the significant differences between NT4 domains and AD. 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). That assumption is flawed (at least in our case), Sure. Like I said, it's arguably a bug in the design. It's just not a bug in the sense that it's working the way that the designers intended. There are two relevant CRs, and one that's related, that you could maybe track or could reference if you open a support case. (Sorry, I don't know whether CRs are publicly visible these days, or how you would look at them.) 7047401 Make NIS/LDAP and workgroups play nice together This is on a system in workgroup mode, you should be able to log in to a NIS- or LDAP- based UNIX account. It would presumably involve a set NT password user interface. 6803321 Support for LDAP directory based passwords in workgroup mode Apparently some tools can store NT hashes in LDAP. This requests support for that. This makes me very nervous, because unlike UNIX password hashes, NT hashes have to be kept secret. If you have the NT hash value, you can log in as the user; you don't need the actual password. This means that such a directory scheme must either have very carefully managed security (so that only authorized processes can retrieve the NT hash) or could be used only in an environment that does not require actual security. 6931475 NIS/LDAP user and groups should be resolvable via SMB This is only related. Right now we have a restriction that names that are from NIS/LDAP aren't resolvable when you look at file metadata. I guess what's really missing is support for NT4 domains. Yes... support for NT4 domains has been on the wish list for a long time, but never quite high enough priority to make it happen. Given that AD came in with Windows 2000, over ten years ago, I have to suspect that the priority for NT4 domains won't be rising. (That's not any kind of official statement... just an observation that if they weren't considered critical last year, it seems pretty unlikely that they'll be considered critical next year. It's not like NT4 market share is increasing.) ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
On 07/19/11 10:41 AM, Jordan Brown wrote: On 07/18/11 14:40, Ian Collins wrote: 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. Yes, but do NT4 domains use LDAP for authentication? I can only barely spell NT4, but I was under the impression that the addition of LDAP was one of the significant differences between NT4 domains and AD. I have to admit that Windows authentication does my head in, but I believe all that is required is an LDAP server and a PDC. Samba 3 can be the PDC. 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). That assumption is flawed (at least in our case), Sure. Like I said, it's arguably a bug in the design. It's just not a bug in the sense that it's working the way that the designers intended. There are two relevant CRs, and one that's related, that you could maybe track or could reference if you open a support case. (Sorry, I don't know whether CRs are publicly visible these days, or how you would look at them.) 7047401 Make NIS/LDAP and workgroups play nice together This is on a system in workgroup mode, you should be able to log in to a NIS- or LDAP- based UNIX account. It would presumably involve a set NT password user interface. Thanks, I'll do battle with the Oracle support site and track that one. I'll look into raising a support case with my client. They do use a home brew set NT password (web) user interface! 6803321 Support for LDAP directory based passwords in workgroup mode Apparently some tools can store NT hashes in LDAP. This requests support for that. This makes me very nervous, because unlike UNIX password hashes, NT hashes have to be kept secret. If you have the NT hash value, you can log in as the user; you don't need the actual password. This means that such a directory scheme must either have very carefully managed security (so that only authorized processes can retrieve the NT hash) or could be used only in an environment that does not require actual security. Shudder... I guess what's really missing is support for NT4 domains. Yes... support for NT4 domains has been on the wish list for a long time, but never quite high enough priority to make it happen. Given that AD came in with Windows 2000, over ten years ago, I have to suspect that the priority for NT4 domains won't be rising. (That's not any kind of official statement... just an observation that if they weren't considered critical last year, it seems pretty unlikely that they'll be considered critical next year. It's not like NT4 market share is increasing.) But I do wonder how many predominantly Unix/Linux sites use them as a quick and easy name service along with Samba? I certainly wouldn't want to set up (and presumably pay for the privilege) an AD domain when I have an existing LDAP or NIS service. -- Ian. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Using CIFS in a fairly large organisation without Active Directory
On Mon, Jul 18, 2011 at 8:25 PM, Jordan Brown jordan.br...@oracle.com wrote: So you give the customer a hook for this, and let them do what they have to to update NIS (or LDAP, or whatever). Possibly, but mostly I consider the let the customer cobble together their own solution to be an answer for the 1980s, not for the 2000s. Uh, well, many organizations have legacy going back a long time. They tend to build and integrate parts of their infrastructure on their own, so I suppose you could say you don't want their business. But I suggest that when you can give people hooks that allow them enough freedom to use your product, you win. The trick is to find the right boundaries. Just to be clear: I'm not advocating this particular solution. I don't think you should care very much about workgroup mode with NIS/LDAP. I'm answering only your point about customization. Nico -- ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
