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 . 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!
$ 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