On Mon, Aug 29, 2011 at 2:16 PM, Marc Bevand <no-re...@opensolaris.org> wrote: > Nico wrote: >> Given the name-based mapping rules that you give below, do you have a Unix >> user account called "myuser"? > > In this test, no, I did not have a Unix account "myuser". Therefore it is not > a bug in nss_ad. > > As Jordan concluded, not having a Unix account "myuser" is officially > unsupported, and my strange observation is explained by the fact there _is_ a > code path (affecting both tmpfs and ZFS, but Jordan did not say where > exactly) mapping myu...@example.com to nobody. I wish Oracle would fix this. > In the mean time I can live with having to create the local Unix account to > prevent files owned by nobody.
Not speaking for Oracle today, but recalling what was and wasn't supported... This is the deal: LOCAL ACCESS (shell, desktop): must have Unix account, and if you want to use Windows accounts then you must use name-based mapping (or directory-based name mapping) to Unix accounts. Same goes for groups. REMOTE ACCESS via NFSv4 and CIFS: need not have a Unix account/group for every SID, heck, need not have any Unix accounts/groups besides the default ones. Remember, at the time we developed this Sun was aiming for a storage appliance that had no local access as such, therefore local access issues had a much lower priority. If you want local access then you are constrained by the fact that we did not finish Windows integration for local access, leaving you to map Windows security entities to Unix security entities. Regarding NFSv4 issues... It's critical to understand what the client is and what it supports. Very few NFSv4 clients (and servers) support more than a single domain for users and groups. Windows NFSv4 clients and servers can generally be expected to support Windows users and groups from across an AD forest (including trusted forests), and, perhaps, with additional mapping facilities, one or more Unix domains. Non-Windows NFSv4 clients and servers generally support a single domain. The only exception when I was at Sun/Oracle was Solaris, whose NFSv4 implementation could handle one Unix domain and all domains in a single AD forest (including trusted forests). Specifically, NFSv4 has two aspects relating to IDs and interop: subject credentials, and object ownership and ACL. For the former you can get interop from non-Windows clients to Windows and Solaris NFSv4 servers by simply using Kerberos credentials issued by AD -- this is because the IDs are embedded in the krb5 tickets in a way that's opaque to the client. For the latter you can only get interop between implementations that understand multiple domains, and specifically AD domains. Nico -- _______________________________________________ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
