[Samba] User mapping?

[Simon Matthews]

On 8/8/20 12:09 PM, Rowland penny via samba wrote:
> On 08/08/2020 19:43, Simon Matthews wrote:
>> On 8/8/20 12:21 AM, Rowland penny via samba wrote:
>>> On 07/08/2020 22:44, Simon Matthews via samba wrote:
>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>> This is where your problems start, you do not have enough lines, I
>>>>>> would expect something like this:
>>>>>>
>>>>>>     idmap config * : backend = tdb
>>>>>>     idmap config * : range = 100000-9999999
>>>>>>     idmap config BLUE : backend = rid
>>>>>>     idmap config BLUE : range = 500-99999
>>>>>>
>>>>>>
>>>>>>>
>>>> No, I was wrong about this. The name mapping is correct but the
>>>> numeric
>>>> IDs are different, so I still have permission issues:
>>>>
>>>> # ls -al
>>>> total 28
>>>> drwxrwxrwx.  4 <user> blue 4096 Aug  7 14:40 .
>>>> drwxr-xr-x. 12 <user> blue 4096 Aug  6 13:06 ..
>>>> drwxr-xr-x.  2 <user> blue 4096 Aug  7 14:40 New folder
>>>>
>>>> "New folder" is an empty folder I created from the Windows machine
>>>> after
>>>> setting the directory perms to 777. However, when we look at the
>>>> actual
>>>> UIDs:
>>>>
>>>> # ls -aln
>>>> total 28
>>>> drwxrwxrwx.  4     2002      441 4096 Aug  7 14:40 .
>>>> drwxr-xr-x. 12     2002      441 4096 Aug  6 13:06 ..
>>>> drwxr-xr-x.  2 16777216 16777222 4096 Aug  7 14:40 New folder
>>>
>>> Try running 'net cache flush'
>>>
>>> Also, the numbers I supplied were examples, you may need to tweak
>>> them. The 'rid' backend calculates the the Unix ID from the users RID
>>> with this formula:
>>>
>>> ID = RID + LOW_RANGE_ID
>>>
>>> Which from the range I posted becomes:
>>>
>>> ID = RID + 500
>>>
>>> So, if a user has the RID 1000, they should have the ID '1500'
>>>
>>> 1500 = 1000 + 500
>>>
>>> The '*' range is for the Well Known Sids and anything outside the
>>> domain
>>>
>>> These numbers will probably not match any users you have /etc/passwd
>>> (mind you, you shouldn't have any users in /etc/passwd)
>>>
>>> Rowland
>>>
>>>
>>>
>> I really appreciate the help.
>>
>> Running 'net cache flush' helped so that the Linux client actually saw
>> "<user>" as a valid id.
>>
>> On the client I now see :
>>
>> # id <user>
>> uid=1578(<user>) gid=1595(blue)
>> groups=1595(blue),1578(<user>),1693(h5-w7-gui-qt5-2),1695(h5-win7-32-1),1608(h5-win7-64-1),1719(simon-w10),1672(h4-win7-gui),1702(h3-win8-gui),1697(h2-win7-64-1),1692(h5-w7-gui-qt5-1),1707(h7-win7-64-1),1708(h7-win7-64-2),1700(h3-win7-gui-1),1726(h7-win7-gui-3),1684(h3-win7-gui-2),1739(h8-win7-64-1),1741(h8-win7-64-2),1579(w2k8-1),1611(h6-win7-64-1),1743(h8-win7-gui-1),1745(h8-win7-64-1c)
>>
>>
>> Apart from <user> all of the groups are related to machine accounts.
>>
>> Can you confirm for me that the settings you suggested are for the Samba
>> domain MEMBER and not on the server?
> Yes, on the client, you shouldn't use the PDC as a fileserver.
>>
>> The id of 2002 was what I had put (but now removed) from /etc/passwd --
>> it matched the network-wide id for that user. On the Linux machines, we
>> have IDs that go up to 4000.
>>
>> I also configured id mapping in nfs and everything seems to work nicely
>> to map this user to uid 1578 over NFS and locally. Incidentally, I only
>> need this one user's ids to match.
>>
>> I still see 16777216 as the ID of files newly created by the the Windows
>> client (after all the changes).   I have the following in
>> /etc/nsswitch.conf:
>>
>> passwd:     files sss winbind
>> shadow:     files sss winbind
>> group:      files sss winbind
>
> yum remove sssd*
>
With all the help you gave me, I have got it working. Thank you.

I think part of my struggle was due to not re-starting the relevant
processes.

Simon


Blue Pearl Software, Inc. will collect and process information about you that may be subject to data protection laws. For more information about how we use and disclose your personal information, how we protect your information, our legal basis to use your information, your rights and who you can contact, please refer to the relevant sections of our Privacy note at www.bluepearlsoftware.com/privacypolicy.