[Samba] BUILTIN not mapping on DC

Achim Gottinger achim at ag-web.biz
Mon Apr 28 16:07:04 MDT 2014


Am 28.04.2014 23:39, schrieb Rowland Penny:
> On 28/04/14 22:23, Achim Gottinger wrote:
>> Am 28.04.2014 22:17, schrieb Rowland Penny:
>>> On 28/04/14 19:46, Achim Gottinger wrote:
>>>>
>>>> Am 28.04.2014 20:29, schrieb steve:
>>>>> On Mon, 2014-04-28 at 14:18 -0400, Ryan Bair wrote:
>>>>>> I'm hoping to find another way to resolve the issue, but how did 
>>>>>> you edit
>>>>>> the uid and gids in idmap.ldb? According to `ldbsearch -H 
>>>>>> ldaps://localhost
>>>>>> cn=Account\ Operators` I already have a GID assigned.
>>>>> Hi
>>>>> DNs in idmap.ldb use the SID as the CN
>>>>>
>>>>> You already have the SID for the group you want from your search. 
>>>>> Then:
>>>>> ldbedit --url=/path/to/privat/idmap.ldb cn=your.SID
>>>>> and replace the xidNumber attribute with the GID you have in the
>>>>> directory. Or whatever other value you want.
>>>>> HTH
>>>>> Steve
>>>>>
>>>>>
>>>> Steve kindly already explained how to edit idmal.
>>>>
>>>> If you only care about GPO acl's, you may replace the acl's 
>>>> BUILTIN\Administrator with Domain-Admins and BUILTIN\Autheticated 
>>>> Users with Domain-Users in the windows group policy editor and run 
>>>> samba-tools ntacl sysvolreset afterwards. Or give everyone read 
>>>> access.
>>>> On my side the problems arised becuase i use rsync to replicate 
>>>> sysvol between ADDX's and since the BUILTIN users/groups are 
>>>> ignored on the unix side (not showing up in getent passwd/group)
>>>> the uid's gid's are used when replicating. Since those are 
>>>> dynamical assigned different on each ADDCi get read erros on my 
>>>> windows clients trying to get the gpo's from ADDC other that the 
>>>> source addc i used for replication.
>>>> Easiest for me was to copy idmap.ldb from my source ADDC to the 
>>>> target addc's directly after joining to the domain.
>>>> An proper solution would be using the RID idmap backend for BUILTIN 
>>>> but i did not get that working.
>>>
>>> I do not think that your problem is with id-mapping, if I run the 
>>> commands that the OP ran, I get the exact same answers.
>>>
>>> If I run 'getfacl /var/lib/samba/sysvol/example.com' on one of my 
>>> DC's I get this:
>>>
>>> getfacl: Removing leading '/' from absolute path names
>>> # file: var/lib/samba/sysvol/example.com
>>> # owner: root
>>> # group: 3000000
>>> user::rwx
>>> user:root:rwx
>>> user:3000000:rwx
>>> user:3000001:r-x
>>> user:3000002:rwx
>>> user:3000003:r-x
>>> group::rwx
>>> group:3000000:rwx
>>> group:3000001:r-x
>>> group:3000002:rwx
>>> group:3000003:r-x
>>> mask::rwx
>>> other::---
>>> default:user::rwx
>>> default:user:root:rwx
>>> default:user:3000000:rwx
>>> default:user:3000001:r-x
>>> default:user:3000002:rwx
>>> default:user:3000003:r-x
>>> default:group::---
>>> default:group:3000000:rwx
>>> default:group:3000001:r-x
>>> default:group:3000002:rwx
>>> default:group:3000003:r-x
>>> default:mask::rwx
>>> default:other::---
>>>
>>> if I run the same command on my second DC, I get this:
>>>
>>> getfacl: Removing leading '/' from absolute path names
>>> # file: var/lib/samba/sysvol/example.com
>>> # owner: root
>>> # group: 3000000
>>> user::rwx
>>> user:root:rwx
>>> user:3000000:rwx
>>> user:3000012:r-x
>>> user:3000022:r-x
>>> user:3000023:rwx
>>> group::rwx
>>> group:3000000:rwx
>>> group:3000012:r-x
>>> group:3000022:r-x
>>> group:3000023:rwx
>>> mask::rwx
>>> other::---
>>> default:user::rwx
>>> default:user:root:rwx
>>> default:user:3000000:rwx
>>> default:user:3000012:r-x
>>> default:user:3000022:r-x
>>> default:user:3000023:rwx
>>> default:group::---
>>> default:group:3000000:rwx
>>> default:group:3000012:r-x
>>> default:group:3000022:r-x
>>> default:group:3000023:rwx
>>> default:mask::rwx
>>> default:other::---
>>>
>>> Now on the face of it, they are different, but if I open idmap.ldb 
>>> with ldbedit on the first DC and search for the numbers, we find this:
>>>
>>> 3000000 ---> CN=S-1-5-32-544
>>> 3000001 ---> CN=S-1-5-32-549
>>> 3000002 ---> CN=S-1-5-18
>>> 3000003 ---> CN=S-1-5-11
>>>
>>> now open idmap.ldb on the second DC and carry out the search with 
>>> the second set of numbers:
>>>
>>> 3000000 ---> CN=S-1-5-32-544
>>> 3000012 ---> CN=S-1-5-11
>>> 3000022 ---> CN=S-1-5-32-549
>>> 3000023 ---> CN=S-1-5-18
>>>
>>> and a bit more searching finds out that:
>>>
>>> CN=S-1-5-32-544 ---> Administrators
>>> CN=S-1-5-32-549 ---> Server Operators
>>> CN=S-1-5-18 ---> Local System
>>> CN=S-1-5-11 ---> Authenticated Users
>>>
>>> So your builtin groups should be getting mapped via their xidNumbers.
>>>
>>> As for the builtin users not showing up in getent passwd, only users 
>>> that have a uidNumber & gidNumber will be shown.
>>>
>>> Rowland
>> If i rsync the sysvol folder manual with -XAavz i get identical gid's 
>> on the target machine. These flags are the ones recommended here 
>> https://wiki.samba.org/index.php/SysVol_Replication.
>> Does your script involve additional logic mapping the gid's?
>
> Ah well, I am trying to write a script around cysnc2, so did not use 
> rsync, but the -A option to rsync should copy the ACL's, which would 
> be based on the windows groups, so I do not understand you saying that 
> you got identical gid's on the target machine, care to elaborate ?
>
>>
>> How can rsync map gid(source) -> sid -> gid(target) if the gid's no 
>> not resolve on a filesystem level?
>
> Because that is what idmap.ldb is for (amongst other things)
>
>>
>> On a sidenote , getent passwd lists users here which got ther uid's 
>> assigned via winbind without having an uidNumber in the corresponding 
>> ldap entry.
>>
>
> In which case you are probably using the rid backend, you would be 
> better of using uidNumber's, gidNumber's and the ad backend.
>
> Rowland
>
Doning my testings on the company network with different gid's in there 
idmap.ldb

These are the acl's on the target machine

# file: var/lib/samba/sysvol/domain.local/
# owner: 0
# group: 544
user::rwx
user:0:rwx
user:3000000:r-x
user:3000001:rwx
user:3000002:r-x
group::rwx
group:544:rwx
group:3000000:r-x
group:3000001:rwx
group:3000002:r-x
mask::rwx
other::---
default:user::rwx
default:user:0:rwx
default:user:3000000:r-x
default:user:3000001:rwx
default:user:3000002:r-x
default:group::---
default:group:544:rwx
default:group:3000000:r-x
default:group:3000001:rwx
default:group:3000002:r-x
default:mask::rwx
default:other::---

After rsync based sysvol replication they are identical on the target 
machine, which has an different mapping. You are right that on the 
windows side of things idmap.ldb does the gid->sid mapping, but on the 
unix side it's done via winbind here.

/etc/nsswitch.conf

passwd:         files winbind
group:          files winbind
shadow:         files winbind

hosts:          files dns wins
networks:       files

/etc/samba/smb.conf

[global]
         workgroup = DOMAIN
         realm = domain.local
         netbios name = server
         server role = active directory domain controller
         dns forwarder = 192.168.190.200
         idmap_ldb:use rfc2307 = yes
         log level = 1
         strict allocate = yes
         acl:read=false
         template shell = /bin/bash
         deadtime = 10
         socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=120 
TCP_KEEPINTVL=10 TCP_KEEPCNT=5
         ea support = yes
         store dos attributes = yes
         map readonly = no
         map archive = no
         map system = no
         map hidden = no
         idmap config * : range = 3000000-4000000

If an user has an uidNumber defined in ldap "getent passwd", "ls" etc. 
use that number if none is defined winbind assignes one and makes an 
mapping entry in idmap.ldb. BUILTIN users and groups also get their 
mappings but do not resolve, guess because they do not exist in ldap?

Running wbinfo --gid-info for an BUILTIN group results in

failed to call wbcGetgrgid: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for gid 3000000

But works fine for groups having an entry in ldap and idmap.ldb.

ACL's for sysvol are also stored in ldap so running samba-tool ntacl 
sysvolreset on the target machine fixes all the mappings afterwards it 
looks like this on the target machine. Do you run sysvolreset after each 
sync?

# file: var/lib/samba/sysvol/gsg.local/
# owner: 0
# group: 544
user::rwx
user:0:rwx
user:3000014:r-x
user:3000019:rwx
user:3000033:r-x
group::rwx
group:544:rwx
group:3000014:r-x
group:3000019:rwx
group:3000033:r-x
mask::rwx
other::---
default:user::rwx
default:user:0:rwx
default:user:3000014:r-x
default:user:3000019:rwx
default:user:3000033:r-x
default:group::---
default:group:544:rwx
default:group:3000014:r-x
default:group:3000019:rwx
default:group:3000033:r-x
default:mask::rwx
default:other::---



More information about the samba mailing list