samba - Mar 2013 - Making Linux and domain users the same

I have a set of Linux boxes with (nearly) working Samba configurations.  Windows
users can get in and work with shares.  My one problem is that the local  user
"joe" is not the same as the domain user that logs into Samba.  And
that means that users cannot access their own home directories, unless I relax
the Linux permissions.

This is not surprising, given the way Samba was configured -- but the question
now is "how can I fix it?"  I have played with the usermap, but
haven't gotten that to work.  And I would prefer not to have to map every
user on every target box; there are a lot of them.  It seems likely that there
should be a global solution to this.

The evidence for the problem is clear.  Below is a listing of directory
containing two files:  one created under by the local Linux user, and one
created by the same user on a Windows box connecting to the share:

$ ls -l
total 4
-rw-r--r-- 1 joe    users        3 Mar  2 03:40 File_Created_In_Linux
-rwxrw-rw- 1 joe    domain users 3 Mar  1 13:12 File_Created_In_Windows
 
$ ls -n
total 4
-rw-r--r-- 1    12903      100 3 Mar  2 03:40 File_Created_In_Linux
-rwxrw-rw- 1 16777217 16777216 3 Mar  1 13:12 File_Created_In_Windows


And here is the Samba config:

[global]
        workgroup = XXXXX
        realm = XXXXX.com
        netbios aliases = XXXXX
        security = DOMAIN
        password server = XXXXX
        wins server = XXXXX
        ldap ssl = no
        idmap uid = 16777216-33554431
        idmap gid = 16777216-33554431
        template homedir = /usr/acct/%U
        template shell = /bin/tcsh
        winbind cache time = 5
        winbind use default domain = Yes
        create mask = 0777
        directory mask = 0777

[myshare]
        path = /shares/test
        read only = No

[homes]
        read only = No


--
Thanks in advance for any light you might shine on this.

On Sat, Mar 2, 2013 at 4:21 AM,  <org-samba at freed.com>
wrote:
> I have a set of Linux boxes with (nearly) working Samba configurations. 
Windows users can get in and work with shares.  My one problem is that the local
user "joe" is not the same as the domain user that logs into Samba. 
And that means that users cannot access their own home directories, unless I
relax the Linux permissions.
>
> This is not surprising, given the way Samba was configured -- but the
question now is "how can I fix it?"  I have played with the usermap,
but haven't gotten that to work.  And I would prefer not to have to map
every user on every target box; there are a lot of them.  It seems likely that
there should be a global solution to this.
>
> The evidence for the problem is clear.  Below is a listing of directory
containing two files:  one created under by the local Linux user, and one
created by the same user on a Windows box connecting to the share:
>
> $ ls -l
> total 4
> -rw-r--r-- 1 joe    users        3 Mar  2 03:40 File_Created_In_Linux
> -rwxrw-rw- 1 joe    domain users 3 Mar  1 13:12 File_Created_In_Windows
>
> $ ls -n
> total 4
> -rw-r--r-- 1    12903      100 3 Mar  2 03:40 File_Created_In_Linux
> -rwxrw-rw- 1 16777217 16777216 3 Mar  1 13:12 File_Created_In_Windows
>
>
> And here is the Samba config:
>
> [global]
>         workgroup = XXXXX
>         realm = XXXXX.com
>         netbios aliases = XXXXX
>         security = DOMAIN
>         password server = XXXXX
>         wins server = XXXXX
>         ldap ssl = no
>         idmap uid = 16777216-33554431
>         idmap gid = 16777216-33554431
>         template homedir = /usr/acct/%U
>         template shell = /bin/tcsh
>         winbind cache time = 5
>         winbind use default domain = Yes
>         create mask = 0777
>         directory mask = 0777
>
> [myshare]
>         path = /shares/test
>         read only = No
>
> [homes]
>         read only = No
>
>
> --
> Thanks in advance for any light you might shine on this.
Is your /etc/nsswitch.conf setup to use winbind?

John

> Is your /etc/nsswitch.conf setup to use winbind?
Yes -- and winbindd is running.  

passwd:     files nis winbind
group:      files nis winbind

Without winbindd, I don't think Windows users could access the shares at
all.  It's a good question, though; you have reminded me to mention that the
users in question aren't actually "local," they come into the
system via NIS -- managed by a very old Solaris 6 machine.  (!)

Don't ask why we're doing it this way; I've inherited the network. 
I might be able to eliminate NIS authentication, but things are so entwined that
I'm reluctant to do so before I've updated some of the other systems.

(I don't think NIS changes anything about this question, but it's better
to have all the facts.)

----- Original Message -----
From: "John Drescher" <drescherjm at gmail.com>
To: org-samba at freed.com, "samba" <samba at lists.samba.org>
Sent: Saturday, March 2, 2013 7:38:56 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Samba] Making Linux and domain users the same

On Sat, Mar 2, 2013 at 4:21 AM,  <org-samba at freed.com>
wrote:
> I have a set of Linux boxes with (nearly) working Samba configurations. 
Windows users can get in and work with shares.  My one problem is that the local
user "joe" is not the same as the domain user that logs into Samba. 
And that means that users cannot access their own home directories, unless I
relax the Linux permissions.
>
> This is not surprising, given the way Samba was configured -- but the
question now is "how can I fix it?"  I have played with the usermap,
but haven't gotten that to work.  And I would prefer not to have to map
every user on every target box; there are a lot of them.  It seems likely that
there should be a global solution to this.
>
> The evidence for the problem is clear.  Below is a listing of directory
containing two files:  one created under by the local Linux user, and one
created by the same user on a Windows box connecting to the share:
>
> $ ls -l
> total 4
> -rw-r--r-- 1 joe    users        3 Mar  2 03:40 File_Created_In_Linux
> -rwxrw-rw- 1 joe    domain users 3 Mar  1 13:12 File_Created_In_Windows
>
> $ ls -n
> total 4
> -rw-r--r-- 1    12903      100 3 Mar  2 03:40 File_Created_In_Linux
> -rwxrw-rw- 1 16777217 16777216 3 Mar  1 13:12 File_Created_In_Windows
>
>
> And here is the Samba config:
>
> [global]
>         workgroup = XXXXX
>         realm = XXXXX.com
>         netbios aliases = XXXXX
>         security = DOMAIN
>         password server = XXXXX
>         wins server = XXXXX
>         ldap ssl = no
>         idmap uid = 16777216-33554431
>         idmap gid = 16777216-33554431
>         template homedir = /usr/acct/%U
>         template shell = /bin/tcsh
>         winbind cache time = 5
>         winbind use default domain = Yes
>         create mask = 0777
>         directory mask = 0777
>
> [myshare]
>         path = /shares/test
>         read only = No
>
> [homes]
>         read only = No
>
>
> --
> Thanks in advance for any light you might shine on this.
Is your /etc/nsswitch.conf setup to use winbind?

John

Hmm.  On second reading, I see you have me loading Identity Services for Unix on
the PDCs.  Not a big deal, but the PDCs are another admin's, ummm, domain. 
I don't want to touch them without without checking in first.  So this will
have to wait till Monday, at least.

----- Original Message -----
From: "Phil Freed" <url at freed.com>
To: "Tris Mabbs" <TM-Samba201302 at Firstgrade.Co.UK>
Sent: Saturday, March 2, 2013 7:06:29 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Samba] Making Linux and domain users the same

Thanks again, Tris.

Your notes seem most thorough.  I especially like the fact that you started with
a simple test so I would know when things were working; neat!  Based on this,
I'm about to embark on a two-hour tour -- one hour less than the ill-fated
S.S. Minnow, so maybe I'll be OK.

As for the setfacl script:  my plan was to set it up in cron on each of the key
systems.  That way if they added a user and forgot about permissions, it would
automagically fix things.  I hadn't thought about the IDMAP changing, but
the script can take care of that as well.

But ouch!  This is sloppy, sloppy, sloppy; a most unsatisfactory way of doing
business.  If it were not for the time limitations, I would never consider it
beyond a temporary band-aid.

Thanks, and wish me luck.

----- Original Message -----
From: "Tris Mabbs" <TM-Samba201302 at Firstgrade.Co.UK>
To: "Phil Freed" <url at freed.com>
Sent: Saturday, March 2, 2013 6:22:35 PM GMT -05:00 US/Canada Eastern
Subject: RE: [Samba] Making Linux and domain users the same

Hiya Phil,

Glad the message may have been of some interest or use :-)

"If you mean we need a separate LDAP server, I can set that up" - no,
no need for that, your PDC will quite happily be doing that for you already and
that should be sufficient.
The only issue you *might* have with using it is if you do have to disable VLVs
within LDAP (and you may not - depends largely on your Linux LDAP client if I
remember rightly), you may have problems if you're also running
"Exchange 2010" - "Exchange" tends to require VLVs enabled
for looking up address books and the like.  If you're not running
"Exchange", it won't be a problem even if you do have to disable
VLVs.

Best thing is follow the Linux doc.s to setup LDAP (if it isn't already, and
from the sound of things it may be in your inherited setup!); if you hit
problems, search the M$ KBs for disabling VLV (I think M$ call it "Virtual
List View").  It's something like run "adsiedit.msc", expand
"Configuration[DomainController]", expand
"CN=Configuration,DC=DomainName", expand "CN=Services",
expand "CNWindows NT"; right-click "CN=Directory Service"
and pick "Properties, in "Attributes", click
"msds-Other-Settings" and pick "Edit"; scroll through the
values until you find any "DisableVLVSupport=x" (where 'x'=0)
and change 'x' to 1; if there is no "DisableVLVSupport="
entry, create one and set it to 1.  Or something like that; you may not even
need to do it.

It's all actually somewhat less complicated than it sounds ...  If you can
get the LDAP client configuration correct, and figure out what you actually need
from the example I posted, it should all just snap into place and start working.
Then you'll sit back, scratch your head and think "Well, if it was that
easy, why couldn't I get it working before?" :-)
Been there, done that - took be bloomin' ages to get a configuration that
worked properly in our setup but now I have it all looks so simple!

"... abandon this and write a setfacl script to allow both users to access
files in the home directories ..." - ah, yes - word of warning about that
...  The IDMAP mappings are (potentially) transitory, so you may find that
suddenly people can't access things again ...  By then, of course,
you'll have forgotten how and why you did it (if you're anything like
me) and it'll be even more frustrating ...

It really does all work very well, when you have it working - until then,
it's a right b!tch ...

Still, I'm sure you'll get there :-)

Good luck!

Tris.

That did it!  Thank you very much.  For the benefit of those who come after,
here's a bit more detail:

If your Windows domain is WINDOMAIN, add these two lines to the global section
of your smb.conf file:

        idmap config windomain : backend  = nss
        idmap config windomain : range = 1000-999999


This mapped the windows domain users to "local" NIS-based Unix users. 
This is what we needed, as users could now manipulate files in their own home
directories from their Windows boxes.

Notes:
1)  In the idmap statements, the domain must (apparently) be lowercase.

2) In the range statement, make sure that the range of numbers includes all the
UIDs of your users.  In our case, we had a user with a Unix UID of 96  (bad
sysadmin!  bad!), so my idmap range was actually 96-999999.  I didn't
confirm that this was necessary.

3)  Caveat:  One thing was missing:  this does *not* fix the user's primary
group membership.  On our system, for instance, local users belong to the group
"user", but /Samba users belong to the group "domain users".
I haven't checked to see if they are also members of "user" (or of
other Unix groups that the local user belongs to), since this wasn't
something we needed.




----- Original Message -----
From: "TAKAHASHI Motonobu" <monyo at monyo.com>
To: org-samba at freed.com
Cc: samba at lists.samba.org, TM-Samba201302 at Firstgrade.Co.UK
Sent: Sunday, March 3, 2013 1:30:52 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Samba] Making Linux and domain users the same

From: org-samba at freed.com
Date: Sat, 2 Mar 2013 08:44:34 -0500 (EST)
>> Is your /etc/nsswitch.conf setup to use winbind?
> 
> Yes -- and winbindd is running.  
>> $ ls -n
>> total 4
>> -rw-r--r-- 1    12903      100 3 Mar  2 03:40 File_Created_In_Linux
>> -rwxrw-rw- 1 16777217 16777216 3 Mar  1 13:12 File_Created_In_Windows
> 
> And:
> 
>> [global]
>>         idmap uid = 16777216-33554431
> 
> So your "joe" user is picking up an "IDMAP"ped UID. 
That's expected
>> behaviour unless Samba is told any other way to map the name to a Unix
>> UID - it needs to get that information from somewhere.
Use idmap_nss instead of idmap_tdb (default).

idmap_nss picks uid/gid from /etc/passwd or its altinatives (such as NIS),
instead of generating its own value.

---
TAKAHASHI Motonobu <monyo at monyo.com> / @damemonyo 
                   facebook.com/takahashi.motonobu

Thanks once again, Tris.  As you see from the previous message, it turns out
that there was a simple method to get what I needed.  But I still appreciate
your help, and the time you took to describe a complex solution in careful
detail.

----- Original Message -----
From: "Tris Mabbs" <TM-Samba201302 at Firstgrade.Co.UK>
To: "Phil Freed" <url at freed.com>
Sent: Saturday, March 2, 2013 6:22:35 PM GMT -05:00 US/Canada Eastern
Subject: RE: [Samba] Making Linux and domain users the same

Hiya Phil,

Glad the message may have been of some interest or use :-)

"If you mean we need a separate LDAP server, I can set that up" - no,
no need for that, your PDC will quite happily be doing that for you already and
that should be sufficient.
The only issue you *might* have with using it is if you do have to disable VLVs
within LDAP (and you may not - depends largely on your Linux LDAP client if I
remember rightly), you may have problems if you're also running
"Exchange 2010" - "Exchange" tends to require VLVs enabled
for looking up address books and the like.  If you're not running
"Exchange", it won't be a problem even if you do have to disable
VLVs.

Best thing is follow the Linux doc.s to setup LDAP (if it isn't already, and
from the sound of things it may be in your inherited setup!); if you hit
problems, search the M$ KBs for disabling VLV (I think M$ call it "Virtual
List View").  It's something like run "adsiedit.msc", expand
"Configuration[DomainController]", expand
"CN=Configuration,DC=DomainName", expand "CN=Services",
expand "CNWindows NT"; right-click "CN=Directory Service"
and pick "Properties, in "Attributes", click
"msds-Other-Settings" and pick "Edit"; scroll through the
values until you find any "DisableVLVSupport=x" (where 'x'=0)
and change 'x' to 1; if there is no "DisableVLVSupport="
entry, create one and set it to 1.  Or something like that; you may not even
need to do it.

It's all actually somewhat less complicated than it sounds ...  If you can
get the LDAP client configuration correct, and figure out what you actually need
from the example I posted, it should all just snap into place and start working.
Then you'll sit back, scratch your head and think "Well, if it was that
easy, why couldn't I get it working before?" :-)
Been there, done that - took be bloomin' ages to get a configuration that
worked properly in our setup but now I have it all looks so simple!

"... abandon this and write a setfacl script to allow both users to access
files in the home directories ..." - ah, yes - word of warning about that
...  The IDMAP mappings are (potentially) transitory, so you may find that
suddenly people can't access things again ...  By then, of course,
you'll have forgotten how and why you did it (if you're anything like
me) and it'll be even more frustrating ...

It really does all work very well, when you have it working - until then,
it's a right b!tch ...

Still, I'm sure you'll get there :-)

Good luck!

Tris.