Linux acls uses wrong gid for domain groups, but numerical gids ok

Question

Please see edit below, as it turns out that the problem is with uid/gid to sid mapping and shows a workaround that will help understand the problem more quickly.

---

We have a Ubuntu 11.04 server machine (lets's call it data) joined to Windows Domain with tools provided by likewise-open So far so good, because i am able to:

1. Log on to machine with AD credentials
2. Set permissions for files and folders with extended ACLs and they work. So by setting "Domain Admins" permission on the folder, i can log onto machine with different domain admin account and access that folder.

So the computer itself understands which domain groups i am member of and can correctly handle permissions.

But the problem is when i want to access files from samba share. Windows doesn't seem to understand that we are talking about same "Domain Admins" or any other domain user/group.

Details

The home folder has is acl-enabled

My share as it's in smb.conf:

[home]
        path = /home/local/MYDOMAIN
        browsable = yes
        guest ok = no
        read only = no
        writeable = yes
        valid users = MYDOMAIN\Administrator, @MYDOMAIN\"Domain Users", @MYDOMAIN\"Domain Admins"
        write list = @MYDOMAIN\"Domain Users", @MYDOMAIN\"Domain Admins"
        nt acl support = yes
        create mask = 700
        directory mask = 700
        hide dot files = yes

So far so good, i can access the share given that folder has read/execute permissions bits set for "others"

So lets try to access test_directory with domain permissions set. I remove any unix permissions:

janis.veinbergs@data:/home/local/MYDOMAIN$ whoami
janis.veinbergs
janis.veinbergs@data:/home/local/MYDOMAIN$ id janis.veinbergs
...1319633408(domain^admins)...
janis.veinbergs@data:/home/local/MYDOMAIN$ cd /home/local/MYDOMAIN
janis.veinbergs@data:/home/local/MYDOMAIN$ sudo chown root:root ./test_directory/
janis.veinbergs@data:/home/local/MYDOMAIN$ sudo chmod 700 ./test_directory/

So on the machine, if i try

ls ./test_directory/

Obviously, i get

ls: cannot open directory ./test_directory/: Permission denied

So i add all permissions for "Domain Admins". (I could have skipped the MYDOMAIN\ thing, because MYDOMAIN is the default domain for the machine)

$ sudo setfacl -m g:MYDOMAIN\\"Domain Admins":rwx ./test_directory/

I can do things in the directory

$ echo "yay" >> ./test_directory/test.txt
$ ls ./test_directory/
test.txt

So far so good, data understands domain groups.

But if i try to access that share on windows machine (from powershell):

PS> whoami
mydomain\janis.veinbergs
PS> gci \\data\home\test_directory
Get-ChildItem : Access to the path '\\data\home\test_directory' is denied.

Now, from data, i'll add permissions for others, so i can access that folder from windows:

$ sudo chmod o+rx ./test_directory/

Now, from windows, i can see files:

PS> gci \\data\home\test_directory


    Directory: \\data\home\test_directory


Mode                LastWriteTime     Length Name                                                                                      
----                -------------     ------ ----                                                                                      
-----       2012.02.06.     14:56          4 test.txt  

Now i can view permissions in properties window (localized, but you can get the idea)

I wonder why it shows Unix Group\domain^admins rather than MYDOMAIN\domain^admins ? What am i missing here and how to make it work?

EDIT: Found a workaround

I'v found a workaround and possible cause but don't know how to resolve It turns out that some wrong mapping between id's are happening.

If i look up the sid-to-gid mapping with wbinfo for MYDOMAIN\Domain Admins group i find that the mapped unix gid is 10010. And this if i set permissions using gid, not the name, the permissions works and windows understands them:

$ sudo setfacl -m g:10010:rwx ./test_directory/

When i enumerate permissions in numerical form, to see gid's and sid's, i see that when settings permissions like MYDOMAIN\"Domain Admins", it actually uses a different GID

$ getfacl -n ./test_directory/
# file: test_directory/
# owner: 0
# group: 0
user::rwx
group::r-x
group:10010:rwx  <-- this is the actual GID mapping for MYDOMAIN\\"Domain Admins" group (setfacl -m g:10010:rwx) and it works when browsing share with windows
group:1319633408:rwx <-- this entry is when setting permission like setfacl -m g:MYDOMAIN\\"Domain Admins":rwx
mask::rwx
other::---

I then looked at my idmap configuration in smb.conf:

   idmap domains = ALL
   idmap config ALL:backend = lwicompat_v4
   idmap config ALL:default = yes
   idmap config ALL:readonly = yes
   idmap uid = 10000-33554431
   idmap gid = 10000-33554431

I see that the gid from ACL entry 1319633408 doesn't go into the defined scope. So i tried extending scope to 10000-3355443100, restarted smbd, but it still didn't work.

So now i have a workaround, to set permissions using gid's, sid's, but thats not user friendly. What should i do to fix this?

Solution

It turns out that i still had to install likewise-cifs support.

It was a matter of executing these commands:

$ /opt/likewise/bin/samba-interop-install --install
$ service smbd restart
$ service winbind restart

Credits to Likewise Open 6 & Samba - A Better Open Source File Server

Now when mapping SID-to-GID, i get back the correct GID likewise uses instead of the short one 10010:

sudo wbinfo -n "Domain Admins"
<i get long SID: S-...-512>
wbinfo -Y S-...-512
1319633408

Comments

[Admin]

Should this be migrated to ubuntu.stackexchange.com? Maybe will recieve more attention there :)

[Janis Veinbergs]

Thank you for the effort, the issue has been solved. I'v provided an answer.