[Samba] idmap configuration after initial deployment needed?

[steve]

On 15/10/14 23:01, Rowland Penny wrote:
> On 15/10/14 21:48, steve wrote:
>> On 15/10/14 22:24, Rowland Penny wrote:
>>> On 15/10/14 21:00, James wrote:
>>>> Hi Steve,
>>>>
>>>>     It was based on the discussion using unison and rsync. I did
>>>> attempt to use the sysvol reset command but it had no effect on my
>>>> issue. I fixed the ACL's by going into each users redirected folder
>>>> from a Windows workstation. Right clicking the affected folder and
>>>> deleting the user or group from the security tab. After deletion I
>>>> added the user or group permissions back.
>>>>
>>>> On 10/15/2014 3:50 PM, steve wrote:
>>>>> On 15/10/14 17:51, Rowland Penny wrote:
>>>>>> On 15/10/14 16:24, James wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>>     Using Ubuntu 12.04 with Samba 4.1.11. I'm currently redirecting
>>>>>>> windows folders to a Samba DC. This DC is not the one that was
>>>>>>> deployed first. Based on discussions from another thread I copied
>>>>>>> the
>>>>>>> idmap.ldb from the initial DC to the others that are deployed. I
>>>>>>> noticed upon doing so the file permissions on the shares were
>>>>>>> broken.
>>>>>
>>>>> Hi
>>>>> Not sure which thread you read, but you should copy the db and then
>>>>> run sysvolreset. I thought that this had appeared in the wiki
>>>>> recently.
>>>>>
>>>>>>> As in existing users were unable to see their documents or make
>>>>>> modifications to them. I deleted them from the ACL list and reapplied
>>>>>>> their appropriate permissions. This corrected that issue.
>>>>>
>>>>> How did you effect, 'reapplied appropriate permissions'? samba-tool?
>>>>> José
>>>>>
>>>>>
>>>>>>>
>>>>>>>     I also noticed that an issue I had with applying GPO's to
>>>>>>> users at
>>>>>>> remote sites was now working again after making this change. With
>>>>>>> all
>>>>>>> that being said. I was under the impressions that I only needed
>>>>>>> to add
>>>>>>> idmap configurations to my smb.conf if I was using a member
>>>>>>> server to
>>>>>>> handle shares from linux/unix users or workstations. I appear to be
>>>>>>> wrong?  Thanks for any assistance.
>>>>>>>
>>>>>> The problem starts with what microsoft calls 'Well-known security
>>>>>> identifiers', these are mapped on the DC  to xidNumbers, now where
>>>>>> ever
>>>>>> you go in AD, on a windows machine  'S-1-5-32-544' is the
>>>>>> Administrators
>>>>>> group, but as I said, on the DC this is mapped to an xidNumber, only
>>>>>> problem is that you do not seem to get the same xidNumber on every
>>>>>> samba4 DC, this is why idmap.ldb needs to copied from the first DC.
>>>>>>
>>>>>> There was some talk about mapping these SID's to a set group of
>>>>>> numbers,
>>>>>> but that is as far as it got, the problem being just what numbers to
>>>>>> map
>>>>>> them to or how to map them so that samba admins could choose the
>>>>>> starting base.
>>>>>>
>>>>>> Rowland
>>>>>
>>>>
>>> I Think I understand what happened, not only do the builtin users &
>>> groups get mapped to a xidNumber, but so do any users & groups. So when
>>> you copied the idmap.ldb to another machine, the users xidNumber's
>>> changed as well.
>> OK. Got it. You must copy the db _immediately_ after the domain is
>> created, _before_ you have added any users or groups and use that copy
>> only. If the domain is created without rfc2307, users and groups have
>> an xidNumber stored, not nice;)
>>
>>>
>>> Now this wouldn't be a problem with sysvol because the permissions can
>>> be reset with samba-tool, but there doesn't seem to be anyway to reset
>>> directed folders, other than the way you found by  removing them and
>>> then re-adding, which would reset them to the numbers that are now in
>>> idmap.ldb.
>>>
>>> Rowland
>> @Rowland: does this mean that the idmap copy workaround will only work
>> with rfc2307 stored in the AD? The discussion over here ATM is that
>> this will never work for non rfc2307 domains because the idmap db is
>> never replicated. ?? Sorry, it's late; collapsing into spanglish
>> drivel with the onlookers:(
>
> Hi Steve, I think that if it is done as you suggest and copy idmap.ldb
> as soon as the join is made,
Thanks Rowland
** confirm, the idmap database that is copied after the join is made is 
from the first DC immediately after the domain is created. This works 
for domains with and without provisioning with rfc2307. BUT with the 
following proviso for non rfc2307 domains:

On a side note, isn't this lack of idmap replication the reason that any 
method other than ad fails for winbind in a multi DC enviroment? DC's 
which didn't pick up the addition of a user will not have the idmap 
xidNumber for that user and so will return nonsense?

Does anyone know (devs?) if the hard coded builtins or some form of 
official guideline on rfc2307 which prevents this sort of traffic here 
will make it into 4.2?
Cheers,
Steve


  then there shouldn't be any problems. The
> problem only arose because the OP redirecting user folders and then
> copied idmap.ldb over from another DC.
>
> Of course the real cure would be for idmap.ldb to be replicated when the
> new DC is joined, I personally think that the devs missed this because
> they were concentrating on making the join work just like a windows DC
> join and idmap.ldb has nothing to do with AD, it's a Unix thing ;-)
>
> Rowland