Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-09-06 Thread Nico Williams
On Mon, Aug 29, 2011 at 6:58 PM, Jordan Brown jordan.br...@oracle.com wrote:
 On 08/29/11 12:16, Marc Bevand wrote:
 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.

 As Nico said, we'd like to fix it too - or, rather, we'd like to add the
 feature of allowing Windows users to log in - but there's a bunch of issues
 and it just hasn't made it to the top of the stack.

Hey now, I'm glad Oracle wants to fix this, but surely I don't speak
for you guys ;)
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-09-06 Thread Nico Williams
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


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-09-06 Thread Nico Williams
On Fri, Sep 2, 2011 at 4:12 AM, Marc Bevand no-re...@opensolaris.org wrote:
 On my domain controller, I created an AD user account plus a keytab file for 
 this account using ktutil.exe, which was then copied to the Linux NFSv4 
 client as /etc/krb5.keytab. This client has the standard Kerberos tools 
 installed and is seen as being a Windows AD user by any Kerberized network 
 service.

 I think you are right, the username must be carried in some earlier NFSv4 
 packets I did not look at... Will inspect in more details later.

If you have Kebreros creds issued by AD then you should be able to
create files on a Solaris 11+ NFSv4 server and have the correct
ownership show up (i.e., the Windows user's SID, or the Unix UID that
you map it to, if any).

However, ls -l and getacl on Linux may not work right at all.  Linux
has its own ID mapping story, and IIRC it's not really supported in
the Linux NFSv4 stack (but don't quote me on that; instead RTFM and
see if there's something you can do about this :).

Nico
--
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-09-02 Thread Marc Bevand
On my domain controller, I created an AD user account plus a keytab file for 
this account using ktutil.exe, which was then copied to the Linux NFSv4 client 
as /etc/krb5.keytab. This client has the standard Kerberos tools installed and 
is seen as being a Windows AD user by any Kerberized network service.

I think you are right, the username must be carried in some earlier NFSv4 
packets I did not look at... Will inspect in more details later.
-- 
This message posted from opensolaris.org
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-09-01 Thread Marc Bevand
Solaris 11 Express is snv_151a, and idmap does support the -V option.

I set the debug/mapping property to 2, refreshed idmap, (and additionally ran 
idmap flush), unfortunately I see no trace in the log when my NFSv4 client 
logs in and creates a file. I know the debugging options are correctly enabled 
because I see lines being logged when running ls -l locally on Solaris on 
files owned by AD users.

I looked at packet captures of the NFSv4 traffic and see no username like 
myu...@example.com being transmitted by the Linux client to the Solaris 
server, which is unexpected...
-- 
This message posted from opensolaris.org
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-09-01 Thread Jordan Brown

On 09/01/11 11:51, Marc Bevand wrote:

Solaris 11 Express is snv_151a, and idmap does support the -V option.

I set the debug/mapping property to 2, refreshed idmap, (and
additionally ran idmap flush), unfortunately I see no trace in the log
when my NFSv4 client logs in and creates a file. I know the debugging
options are correctly enabled because I see lines being logged when
running ls -l locally on Solaris on files owned by AD users.

I looked at packet captures of the NFSv4 traffic and see no username
like myu...@example.com being transmitted by the Linux client to the
Solaris server, which is unexpected...


Wait a second... how do you get a Linux system to log in via NFSv4 as a 
Windows user?


I suspect that if the name is carried anywhere, it's in the session startup 
messages rather than in the actual create message.

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-30 Thread Jordan Brown

On 08/29/11 21:28, Marc Bevand wrote:

So are you saying I should try after sharectl set -p 
nfsmapid_domain=any-other-name.com nfs and ownership should be handled correctly? I 
will try tomorrow.


That might work.  What *wouldn't* work in that configuration was any user 
that was only a UNIX user and was not a Windows user.


Although this particular interaction (NFSv4 and AD) has some rough edges, 
it *is* at least a bit sensible.  Domains define a space where a particular 
set of names is known.  Your NFSv4 domain name setting says which domain 
your UNIX user names are known in.  If you use the same names for NFSv4 and 
AD you are in a sense saying that the names are the same between the two, 
and normally (absent either setting the UNIX name service to use LDAP from 
the AD servers, or manually synchronizing the databases) that wouldn't be 
the case.  The best thing to do to make that work right is to set the UNIX 
name service to use AD LDAP, so that everybody in that domain is using the 
same directory.

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-30 Thread Marc Bevand
It did not work.

No matter what nfsmapid_domain is set to (any-other-name.com or example.com), 
files created on the ZFS file system by my Kerberized NFSv4 client always end 
up owned by nobody. I even rebooted the Solaris server and the client after 
each change to make sure I did not forget to reload a service, or was not 
accidentally re-using cached data somewhere.

Everything is so close to working with only Kerberos/AD... It is too bad that 
LDAP is still required for full integration.
-- 
This message posted from opensolaris.org
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-29 Thread Marc Bevand
This is correct.

When the Unix account myuser exists:

# id
uid=0(root) gid=0(root)
# su - myu...@example.com
su: No directory! Using home=/
$ id
uid=10111(myuser) gid=2147483691(Domain us...@example.com)

When it does _not_ exist:

$ id
uid=2147483650(myu...@example.com) gid=2147483691(Domain us...@example.com)
-- 
This message posted from opensolaris.org
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-29 Thread Marc Bevand
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.

With that explained, what about NFS (I use that too)? To summarize the tests I 
ran (when there is no Unix account myuser):

1. A file created remotely via CIFS (as myu...@example.com) ends up owned by 
myu...@example.com (good, as supported)
2. A file created locally (after su - myu...@example.com) ends up owned by 
nobody (unsupported scenario; caused by the code path mentioned by Jordan; but 
creating a Unix account myuser makes the file owned by myuser)
3. A file created remotely via NFSv4 (by a Kerberized NFS client authenticated 
as myu...@example.com) ends up owned by nobody instead of myu...@example.com 
(but creating a Unix account myuser makes the file owned by myuser)

What explains #3? Is this a supported scenario? I assume not, given that the 
same workaround (creating a Unix account myuser) is required to prevent files 
owned by nobody.
-- 
This message posted from opensolaris.org
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-29 Thread Jordan Brown

On 08/29/11 11:54, Marc Bevand wrote:

This is correct.

When the Unix account myuser exists:

# id
uid=0(root) gid=0(root)
# su - myu...@example.com
su: No directory! Using home=/
$ id
uid=10111(myuser) gid=2147483691(Domain us...@example.com)

When it does _not_ exist:

$ id
uid=2147483650(myu...@example.com) gid=2147483691(Domain us...@example.com)


OK, good.

So... as I've noted, using name@domain in a login-like context (including 
su) is not supported and I was surprised that it was possible.  Feel free 
to experiment, and I'm interested in the results, but you shouldn't expect 
any significant support in that area.  The fact that you're able to get as 
far as you do, that the su works, is a bit of an accident and oversight, 
not a deliberate feature.  We thought we'd made it so that you couldn't log 
in using name@domain style names.

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-29 Thread Jordan Brown

On 08/29/11 12:16, Marc Bevand wrote:

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 didn't say because it didn't seem like it'd be a useful piece of 
information, but it's in the macro VOPXID_MAP_CR in 
usr/src/uts/common/fs/vnode.c, used in quite a number of file-oriented 
operations.  It uses a dummy nobody credential when the file system in 
question doesn't advertise support for SIDs and the process credential has 
a SID.



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.


As Nico said, we'd like to fix it too - or, rather, we'd like to add the 
feature of allowing Windows users to log in - but there's a bunch of issues 
and it just hasn't made it to the top of the stack.


Note that if you're careful you can configure your system to use your AD 
server as its UNIX LDAP server, which brings you closer to being able to 
support these users without manually creating UNIX users.



With that explained, what about NFS (I use that too)? To summarize the
tests I ran (when there is no Unix account myuser):

1. A file created remotely via CIFS (as myu...@example.com) ends up
owned by myu...@example.com (good, as supported)


Yes.


2. A file created locally (after su - myu...@example.com) ends up owned by 
nobody
(unsupported scenario; caused by the code path mentioned by Jordan; but
creating a Unix account myuser makes the file owned by myuser)


Yes, this is what we've been discussing.


3. A file created remotely via NFSv4 (by a Kerberized NFS client authenticated 
as
myu...@example.com) ends up owned by nobody instead of
myu...@example.com (but creating a Unix account myuser makes the file
owned by myuser)

What explains #3? Is this a supported scenario? I assume not, given that
the same workaround (creating a Unix account myuser) is required to
prevent files owned by nobody.


Is example.com your AD domain?

If so, I believe this is intended to work, but I can't say that it's been 
exercised as much as one might like.


Also: if your NFSv4 domain has the same name as your AD domain, there's a 
conflict of sorts.  Names in that domain will be interpreted as UNIX names 
(rather than as AD names) and so if they don't exist in the UNIX namespace 
it's an error and they turn into nobody.

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-26 Thread Nico Williams
On Wed, Aug 24, 2011 at 4:44 PM, Marc Bevand no-re...@opensolaris.org wrote:
 I run Solaris 11 Express, successfully joined an AD domain with smbadm join 
 and with a proper Kerberos config like [1]. Can anybody tell me why files 
 created by these users locally (on Solaris itself, not through CIFS!) end up 
 with the ownership of 'nobody'?

 # id
 uid=0(root) gid=0(root)
 # su - myu...@example.com

Given the name-based mapping rules that you give below, do you have a
Unix user account called myuser?

It's possible that nss_ad is returning an ephemeral ID here even
though you have an actual name-based mapping to a Unix account.
That'd be a bug, though I don't quite see how that would happen.

 su: No directory! Using home=/
 $ id
 uid=2147491842(myu...@example.com) gid=2147483650(Domain us...@example.com)

This would indicate that no, you don't have a Unix myuser account.

 $ touch /tmp/test
 $ ls -l /tmp/test
 -rw-r--r--   1 nobody   nobody         0 Aug 24 14:28 /tmp/test

Right, tmpfs should not be able to handle ephemeral IDs, IIRC.

 It doesn't even involve CIFS and the typical id mapping complexity... Is the 
 system treating the ephemeral IDs of domain users as a special case and 
 converting them to 'nobody'? My idmap policy is pretty standard: it is just 
 used to map a few domain users who have local unix accounts by the same name:

The only components of the system involved here are: tmpfs, idmapd,
the name services (specifically nss_ad, assuming you don't have any
myu...@example.com in /etc/passwd!), and everything else that su -
someuser would imply (e.g., a user shell).  CIFS is not involved.
The mapping to nobody would be made by tmpfs.

We're probably missing some details though.

 # idmap list
 add     wingroup:*@example.com       unixgroup:*
 add     winuser:*@example.com        unixuser:*

 The most puzzling thing is that this Solaris server is also serving a share 
 using native CIFS support (zfs set sharesmb=on xxx), and ownership of files 
 created by remote users through CIFS is perfectly correct. I only encounter 
 this problem when creating files locally (I was hoping to give my users SSH 
 access to allow manipulating the files locally...)

As Jordan says, running Unix user processes as Windows user IDs puts
you in uncharted territory -- I certainly wanted to get to where that
would be supported, but when I was at Sun (then Oracle) we never got
around to it, and so, though it is possible to run processes with
ephemeral IDs as e/r/suid and e/r/sgid, this is not supported.
There's a lot of system components that would require modification to
make this work right, such as: tmpfs, utmpx/wtmpx, lastlog, nss_ad
(which doesn't have, for example, _getgroupsbymember() support, IIRC),
and so on.

Local access to files with SIDs in their security descriptors is
supported, but only from processes with non-ephemeral IDs for e/r/suid
and e/r/sgid, and only when the files are on ZFS.

Note that when I speak of supported I really mean that something was
or was not supported when I was at Sun/Oracle.  I can't speak to what
is or isn't supported now, but given what Jordan has said I think it's
pretty clear that either what you want is not supported or there is a
bug in nss_ad(5).

Nico
--
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-25 Thread Jordan Brown

On 08/25/11 16:12, Jordan Brown wrote:

The ZFS behavior is easy to explain. If there's a mapping between the
Windows account and the UNIX account, we use the UNIX account in file
metadata.


In fact, I suspect (and verification is left as an exercise for the reader) 
that in this case when you log in as name@domain, you will find that your 
process's user ID ends up as the normal UNIX userid, not the ephemeral ID.

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-24 Thread Jordan Brown

On 08/24/11 14:44, Marc Bevand wrote:

I run Solaris 11 Express, successfully joined an AD domain with smbadm
join and with a proper Kerberos config like [1]. Can anybody tell me
why files created by these users locally (on Solaris itself, not through
CIFS!) end up with the ownership of 'nobody'?

# id uid=0(root) gid=0(root)
# su - myu...@example.com
su: No directory!
Using home=/
$ id uid=2147491842(myu...@example.com) gid=2147483650(Domain us...@example.com)
$ touch /tmp/test
$ ls -l /tmp/test
-rw-r--r--   1 nobody   nobody 0 Aug 24 14:28 /tmp/test


Oh, wow, you're off in uncharted territory.

You've got ad in your nsswitch.conf, right?

ad (and so the names that it handles, like myu...@example.com) isn't 
intended for Solaris login.  It's intended only to allow you to see and 
manipulate Windows identities using tools like ls -l and chown.  It 
takes care to prevent login by setting the encrypted password to *NP*.


However, you're using su as root, and so you're bypassing the password 
check and getting to a shell as a Windows user with an ephemeral ID.  We've 
thought about supporting that case, but we know that there are a number of 
problems with it and we thought that people couldn't get there.


What you're seeing is that tmpfs, the file system that supports /tmp, 
doesn't support Windows identities in its file metadata.  If you were to do 
your experiment in a ZFS file system you would probably get the file 
metadata behavior that you expect.


However, again, running an interactive shell as a Windows user is not 
supported and there may be any number of issues.


If you want to have your Windows users log into your Solaris system, you 
need to arrange for them to have UNIX accounts, and you need to map the 
Windows identities to the corresponding UNIX accounts.  Probably the best 
way to do that (though a little tricky) is to set up Microsoft's Identity 
Management for UNIX on your AD server and populate things like user IDs, 
shell selections, home directories, and so on in your AD data.  You can 
then configure idmap to use IDMU (which is easy) and that will get your 
Windows and UNIX accounts equated.  You would also need to configure the 
ldap name service switch back end to use the AD server, with schema 
mapping to match the AD server schema up with the schema that the ldap 
back end needs.  You would also configure Solaris Kerberos to authenticate 
against AD, and configure Solaris PAM to use Kerberos.  (Getting those 
right is tricky.)  If you got all of that working, you'd have a pretty 
fully integrated environment.  Your users would be able to use SMB from 
Windows and would be able to log in and get a shell using their 
Pre-Windows-2000 logon id and their regular password.


___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss


Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain

2011-08-24 Thread Marc Bevand
Yes, I have ad:
$ grep -w ad /etc/nsswitch.conf 
passwd: files ad
group:  files ad

My problem is not caused by tmpfs, because I observe the same behavior with zfs.

Something else that disproves your theory (sorry :D) is that tmpfs is perfectly 
capable of recording AD ownership: I can chown myu...@example.com /tmp/file 
as root (which makes sense because a filesystem only sees 32-bit UIDs; it 
doesn't care if they are ephemeral).

Even more puzzling: after creating a local Unix account 'myuser' matching the 
AD account name (so that idmap bidirectionally maps them), my commands end up 
with the file owned by 'nobody' on tmpfs but 'myuser' on zfs. Why does zfs 
behave differently when this local account exists?

Actually, as a workaround, creating local accounts is fine for my needs. But I 
would definitely like an explanation of what is going on with these ephemeral 
IDs... I suspect Solaris has a code path that, sometimes but not always, 
intentionally maps them to nobody, when the right thing to do would be to not 
interfere with them (ie. pass them as is to the filesystem).
-- 
This message posted from opensolaris.org
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss