Bug 918537

I think

        idmap backend = nss
        idmap config TESTDOMAIN:backend = nss
        idmap config *:backend = nss

should be

        idmap config TESTDOMAIN : backend = nss
        idmap config * : backend = nss

IIRC the spaces before the : is important.


However I still don't fully understand the problem

you have /home/user1/mydirectory which is user1:group1

user2 is also in the group1 and wants to access /home/user1/mydirectory. Aren't users locked in the home directory if they connect to [homes] so how can he access it?

Hi Andreas,

I had the spaces in the config before but it makes no difference.

user1 and user2 have group1 as primary group.

If for example user1 has his home directory permissions set to 0750, user2 should have access to them. This works fine under Linux.

If however user2 maps users1's home directory using samba, this no longer works with samba 3.6 (worked fine with 3.5).

It seems samba no longer recognises the windows 'user2' as unix user2. From the changelog it seems Samba 3.6 redid the entire idmap thing again so I asusme the error is somewhere down that line.

Also, when I run testparm -v, the output shows that 'idmap backend = tdb', although I have it set to 'idmap backend = nss' in the config. This parameter is deprecated in 3.6, but is should still honor it when set.

Regards,

Rik

idmap config * : backend = nss

is what counts. That's the default backend.

> If however user2 maps users1's home directory using samba, this no longer works with samba 3.6 (worked fine with 3.5).

How is this 'mapping' done.


Could you give me more details how to reproduce this?

See also:

https://www.samba.org/~asn/reporting_samba_bugs.txt

Hi,

(In reply to comment #3)
> > If however user2 maps users1's home directory using samba, this no longer works with samba 3.6 (worked fine with 3.5).
> 
> How is this 'mapping' done.

We map the network drive from a Windows 7 machine (joined to the AD domain), by logging in as user2, and then map the network drive from the samba server (joined to the same AD domain):

\\SAMBA-SERVER\user1

We have the users defined in AD. The same users are also defined locally on the samba server. So winbind should check the local users to do the SID<->uid mapping, and winbind is not needed in /etc/nsswitch.conf.

> Could you give me more details how to reproduce this?

The following procedure should mimic our production environment and reproduce the bug:

1. Set up an AD domain 'TESTDOMAIN' and create two domain users 'user1' and 'user2'.
2. Set up a RHEL 6.3 server and create two local users 'user1' and 'user2'. Make them member of the same group. Set the permissions on the home directory of user1 to 0750.
3. Install samba 3.5 and configure it as explained in the initial bug info.
4. Join the samba server to the domain
5. Start winbind and smb service
6. Use a windows (7) machine that is also joined to TESTDOMAIN and log in as user2. Map a network drive and enter \\SAMBA-SERVER\user1 as the network path.
7. Verify that you can see the files in user1's home directory. Disconnect the network drive.
8. Upgrade the samba server to RHEL 6.4, with samba 3.6
9. Repeat step 6 and 7. User user2 no longer has access to user1's home directory.

Regards,

Rik

Hi,

I've done some further debugging and it seems winbind can map the unix uid to the SID, but not the other way around:

For example:

# wbinfo -n mangel
S-1-5-21-1203271654-1849719538-6498272-7860 SID_USER (1)

# wbinfo -S S-1-5-21-1203271654-1849719538-6498272-7860
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-21-1203271654-1849719538-6498272-7860 to uid

On samba 3.5 this works:

# wbinfo -S S-1-5-21-1203271654-1849719538-6498272-7860
2117

So my guess is it's the 'idmap backend' / 'idmap config' parameter that doesn't work correctly.

Regards,

Rik

This bug seems similar to https://bugzilla.samba.org/show_bug.cgi?id=8676

In our case we are using the nss backend.

While trying to reproduce it with 3.6 (which I can) I could not get that very same scenario to work with 3.5.10 neither. Which Samba version exactly was the 3.5 version where it was all working for you ?

Hi Guenther,

We are currently using 3.5.10-125.el6.x86_64 and it works on this version.

I'll try to reproduce this myself on a test machine.

Regards,

Rik

Hi Guenther,

I've tried it again on a test system and can reproduce it (works on 3.5, fails on 3.6) as follows:

1. Install a minimal RHEL 6.4. A minimal install does not include samba so I took the 6.4 release.
2. Configure the 6.3 repo and install samba{,-winbind,-winbind-clients} and its dependencies from _only_ the 6.3 repo (6.4 repo disabled). This pulls in libtdb and libtalloc from 6.3
3. Add local users to the system that have an account in the AD domain with the same name. In this case 'rtheys' and 'mangel'.

adduser -g 100 rtheys
adduser -g 100 mangel

4. Create a test directory:

install -d -m 750 -o mangel -g users /srv/testdir

5. Configure /etc/krb.conf to add the kdc's for our AD realm.
6. Make Dan Walsh cry a little and disable SELinux for now: setenforce 0
7. Disable firewall for now: service iptables stop
8. Create basic smb.conf (I'll attach this one)
9. Confirm with testparm that the config is good
10. Join the domain

net ads join -U user_with_rights_to_add_host
net ads testjoin

-> join is good.

11. start samba and winbind

service winbind start
service smb start

12. Use the wbinfo command to test:

[root@samba-test samba]# wbinfo -n mangel
S-1-5-21-1203271654-1849719538-6498272-7860 SID_USER (1)

--> returns SID of user mangel in AD -> GOOD

# Check if we can get the unix UID of this SID"
[root@samba-test samba]# wbinfo -S S-1-5-21-1203271654-1849719538-6498272-7860
501

--> returns UID of local user we created --> GOOD

# Same test for other user:
[root@samba-test samba]# wbinfo -n rtheys
S-1-5-21-1203271654-1849719538-6498272-11133 SID_USER (1)
[root@samba-test samba]# wbinfo -S S-1-5-21-1203271654-1849719538-6498272-11133
500

--> GOOD.

13. Upgrade the samba*, libtdb, libtalloc packages to 6.4 versions (3.6.9-151) and restart winbind and smb to be sure

14. Return the commands from step 12:

[root@samba-test samba]# wbinfo -n mangel
S-1-5-21-1203271654-1849719538-6498272-7860 SID_USER (1)

-> so far so good

[root@samba-test samba]# wbinfo -S S-1-5-21-1203271654-1849719538-6498272-7860
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-21-1203271654-1849719538-6498272-7860 to uid

==> fails to return the local uid for the specified SID ==> BAD !

# Same result for other user.

[root@samba-test samba]#  wbinfo -n rtheys
S-1-5-21-1203271654-1849719538-6498272-11133 SID_USER (1)
[root@samba-test samba]# wbinfo -S S-1-5-21-1203271654-1849719538-6498272-11133
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-21-1203271654-1849719538-6498272-11133 to uid



Let me know if you need other info to reproduce this.

Regards,

Rik

Created attachment 775169 [details]
smb.conf used in comment 10

This is the smb.conf file used in comment 10

Ok, I think I see what is going on:

You need to set the range for the nss backend (which was not necessary in 3.5) as well now.

When I add "idmap config * : range = 100-999999999" in my test configuration, stop winbindd, remove gencache.tdb and winbindd_cache.tdb (please dont remove this file when you rely on the winbind offline capabilities), restart winbind then it works for me. I also tested to connect with user2 to the user1 homeshare and list directory contents which worked.

For the "range" setting, also see examples in the idmap_nss(8) manpage.

Does this resolve your problem as well ?

Hi Guenther,

Setting the range indeed seems to fix the wbinfo calls. I've implemented the change on one of our lesser used samba servers to see if it also resolves the issue with the permissions, but I assume it does.

Thanks for looking into this!

Regards,

Rik

As we got positive feedback that everything works after fixing the configuration of the idmapping we are closing this bug.