samba - Oct 2003 - Samba 3.0.0 -- ACLs are unusable due to UID/SID mapping weirdness :(

Hi,

I am sure somebody asks this question about once a week. Since I have 
not found an answer I assume the worst -- it just does not work.

So, here goes my problem. I am testing Samba 3.0.0. I have got UNIX and 
Windows domain users matching each other one-to-one. The server is 
running with "security = domain". Everything works fine and all
Windows
users connecting to Samba get mapped into their respective UNIX user 
ids. Everything is nice, simple and consistent.

Now I want to enable ACLs and fortunately the host OS supports them 
fine. Here the trouble starts. It looks like ACLs refuse to work in the 
absense of winbindd. So I start winbindd and... get random mapping of NT 
domain accounts into UNIX ids in the range of "idmap uid/gid".

So, for example, if I create a file from the windows side it gets 
ownership of:

solovam/uid=1001

on the UNIX side. Windows says the owner is:

\SAMBA-SERVER\solovam

Which is already strange, I expect \DOMAIN\solovam like on all NT boxes.

If I try to add and ACL entry for myself to this file, I get a POSIX acl 
entry for:

???/uid=40000

which is what winbindd assigned for my SID. At this point Windows says 
this was an ACL entry for user:

\DOMAIN\solovam

So, this is basically the problem. When I connect to Samba server I 
connect as \DOMAIN\solovam and use domain password. The files I create 
belong to my UNIX account "solovam". At the same time if I check 
ownership, I see that I act as \SAMBA-SERVER\solovam! If I try to change 
ACLs, I am back to being \DOMAIN\solovam, but my SID is now mapped by 
winbindd to something randomly selected.

Well, there are a lot of funny implications at this point (like change 
UNIX permissions to 000 and try to add "full control" ACL for the
domain
user, which resets UNIX permissions again!), but the bottom line is that 
Samba in this area is completely broken and horribly inconsistent.

I hope I am missing something really obvious, but after a day of looking 
at documentation I doubt it is so.

-- 

Anton Solovyev

On Mon, 20 Oct 2003, Anton Solovyev wrote:

Having read your posting, I believe I need your help to fix our
documentation. Are you willing to help me to do that?
> Hi,
>
> I am sure somebody asks this question about once a week. Since I have
> not found an answer I assume the worst -- it just does not work.
Please do not assume that because something does not work the way you have
tried it that this means that Samba is broken. That is a bit like failing
a driving test and then claiming that the test vehicle must have been
defective!

Have you read the Samba-HOWTO-Collection.pdf? Did you understand it all?
Did you red the chapter on Group Mapping? Did it help you any? What do we
need to add to the documentation to help someone else to understand the
issues and to help them to find a solution.

I need your feedback to help improve our documentation. Perhaps it is all
wrong. It could be you know!
> So, here goes my problem. I am testing Samba 3.0.0. I have got UNIX and
> Windows domain users matching each other one-to-one.
Here we go! What do you mean by: "users matching each other
one-to-one"?
Please explain this fully. I do not want to jump to conclusions, but my
reading is that you have added users to the Samba server while it is a
domain member server. Is my interpretation correct?
> The server is running with "security = domain". Everything works
fine
> and all Windows users connecting to Samba get mapped into their
> respective UNIX user ids. Everything is nice, simple and consistent.
So you have a Windows NT4 Domain, or Active Directory? I can't really tell
from your description. It does matter - it would certainly help me to help
you. I have to tell people time and again that my crystal ball is worn out
and my guessing is lousy! :)

How did you "join the domain"? What precise steps did you take? Help
me to
reproduce your problem!

What information can you glean from the samba log files to confirm that
"everything is nice, simple and consistent"?
> Now I want to enable ACLs and fortunately the host OS supports them
> fine. Here the trouble starts. It looks like ACLs refuse to work in the
> absense of winbindd.
Precisely, which user identities (or group identities) do you want to
include in the ACLs? Accounts that are in /etc/passwd on the Samba server,
or Domain Accounts?

If you have a johndoe account in the Samba /etc/passwd, and a johndoe
account on the Domain as well, then you need to realise that they are two
totally different users. One is machine local and tied to the SID of your
Samba server, the other is Domain Global, and is tied to the Domain SID.
Do you recognize that?

If you want to be able to use Domain accounts then you must have winbindd
running.
> So I start winbindd and... get random mapping of NT domain accounts into
> UNIX ids in the range of "idmap uid/gid".
>
> So, for example, if I create a file from the windows side it gets
> ownership of:
>
> solovam/uid=1001
>
> on the UNIX side. Windows says the owner is:
>
> \SAMBA-SERVER\solovam
>
> Which is already strange, I expect \DOMAIN\solovam like on all NT boxes.
No. As I mentioned, a Samba server /etc/passwd account called 'solocam'
is
an entirely different user account from user 'solovam' on a Domain
Controller.
> If I try to add and ACL entry for myself to this file, I get a POSIX acl
> entry for:
>
> ???/uid=40000
Thanks to NSS (entry in /etc/nsswitch.conf) this is a domain account.
> which is what winbindd assigned for my SID. At this point Windows says
> this was an ACL entry for user:
>
> \DOMAIN\solovam
Right. As expected.
> So, this is basically the problem. When I connect to Samba server I
> connect as \DOMAIN\solovam and use domain password. The files I create
> belong to my UNIX account "solovam". At the same time if I check
> ownership, I see that I act as \SAMBA-SERVER\solovam! If I try to change
> ACLs, I am back to being \DOMAIN\solovam, but my SID is now mapped by
> winbindd to something randomly selected.
Nope. I already explained that.
> Well, there are a lot of funny implications at this point (like change
> UNIX permissions to 000 and try to add "full control" ACL for the
domain
> user, which resets UNIX permissions again!), but the bottom line is that
> Samba in this area is completely broken and horribly inconsistent.
Alternatively, could it possibly be that your understanding of how this
ought to work is "completely uninformed", or "completely
unrealistic", or
maybe "just a little bit off".
> I hope I am missing something really obvious, but after a day of looking
> at documentation I doubt it is so.
What documentation did you look at? What documentation (specific pages
etc.) did you look at that allowed you to come to the conclusions you have
arrived at.

Maybe, just maybe, your conclusions are perfectly valid and "the
documentation is completely wrong". Which ever it is, will you help me to
fix it?

Thanks.

- John T.
-- 
John H Terpstra
Email: jht@samba.org

> > By "consistent and simple" I mean,  something like --
"you have a
> > Windows user that needs to get to a Samba share? Create a UNIX account
> > with the *same name* and you will get an smbd process with the UID and
> > hence the permissions of that user accessing the files on the server
> > (ok not always). The authentication will be done on the NT side
though".
>
> Nope. You should use winbind for that. Any other way will cause you
> problems when you try to use ACLs.

I think I understand at least a part of Anton's issue.  It's one that
I've
been thinking about as we deploy Samba 3.0.  We never really thought much
about ACLs until now and have never run winbindd.  The problem boils down
to this:  We currently have a group of seven Samba/NFS file servers which
are members of a Windows domain.  The Windows usernames and group names
are synchronized.  The numeric UIDs and GIDs are uniform across all of
them by virtue of the fact that they have a common /etc/passwd.  We want
to jump on the ACL bandwagon and do things right using winbindd.
However, in a distributed environment the official way of mapping SIDs to
UIDs consistently across the servers involves an 'idmap backend'.  All
of
the idmap backends involve ldap.  It is frustrating that I have to
introduce the overhead of deploying an LDAP server and populate it with
UID mappings even though the file servers already have an /etc/passwd
which has enough information to map numeric Unix UIDs consistently.

I know idmap'ing was a hot topic during development so you have probably
already considered all of this.  At the time, watching the discussion I
didn't follow it all but now starting to consider deployment the issues
are becoming clearer.

--Eric