[Samba] idmap configuration after initial deployment needed?

[James]

Just for clarity sake. I did provision with rfc2307. Made sure to add 
'idmap_ldb:use rfc2307 = yes' on all DC's as well. Since I use folder 
redirection it appears I will continue to have problems going forward 
with my current setup. Am I correct in this assumption?

On 10/15/2014 5:01 PM, 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, 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

-- 
-James