Samba4: idmap replication between 2 DC's

[steve]

On 12/07/12 10:19, Gémes Géza wrote:
> 2012-07-12 09:10 keltezéssel, steve írta:
>> On 12/07/12 08:02, Gémes Géza wrote:
>>> 2012-07-12 07:46 keltezéssel, steve írta:
>>>> On 11/07/12 23:45, Gémes Géza wrote:
>>>>> 2012-07-11 21:44 keltezéssel, steve írta:
>>>>>> On 11/07/12 21:23, Gémes Géza wrote:
>>>>>>> 2012-07-11 10:58 keltezéssel, steve írta:
>>>>>>>> Hi
>>>>>>>> Is it possible to get idmap.ldb replicated across 2 DC's as well as
>>>>>>>> the directory partitions?
>>>>>>>>
>>>>>>>> I make changes to id mappings for our Linux users. This is not a
>>>>>>>> problem with NFS, but becomes an issue when Linux users are
>>>>>>>> working on
>>>>>>>> cifs mounted shares. The uidNumber issued by DC2 is not the same as
>>>>>>>> the uidNumber issued by DC1.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Steve
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>> If you put
>>>>>>> idmap_ldb:use rfc2307 = yes
>>>>>>> in your smb.conf then setting the uids gids in AD will guarantee
>>>>>>> that
>>>>>>> they are the same across your samba4/s3fs servers, because then they
>>>>>>> will get that from AD instead of their private idmap (with a
>>>>>>> fail-back
>>>>>>> to idmap, if the entry has no uid/gid set).
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Geza
>>>>>> Hi Geza
>>>>>> I don't think
>>>>>>  idmap_ldb:use rfc2307 = yes
>>>>>> works in Samba4 with s3fs
>>>>>>
>>>>>> It doesn't appear as an option in
>>>>>>  testparm -v either
>>>>>>
>>>>>> It doesn't have any effect here even though we store all our rfc2307
>>>>>> information in the directory.
>>>>>>
>>>>>> Quote from the other thread:
>>>>>> 's3fs and the Samba4 DC use a different winbindd implementation to
>>>>>> the
>>>>>> one that Christof is patching.  For that reason, these patches simply
>>>>>> won't have any benefit for you on the Samba4 DC.
>>>>>> Cheers
>>>>>> Andrew Bartlett'
>>>>>>
>>>>>> Geza, does it work for you?
>>>>> Yes, but my test domain was upgraded from samba3 in which case the
>>>>> provision automatically puts idmap_ldb:use rfc2307 = yes in smb.conf
>>>>>
>>>>> I don't know s3fs where does sid<->xid operations, but with wbinfo
>>>>> I've
>>>>> checked and the information is retrieved from AD.
>>>>>
>>>>> Regards
>>>>>
>>>>> Geza
>>>> Hi Geza.
>>>>
>>>> That's frustrating. We are not using winbindd (but are using winbind
>>>> if you see what I mean). Is there anything else you have in smb.conf
>>>> that would affect this? Our nsswitch settings are:
>>>> passwd: files ldap
>>>> group: files ldap
>>>> and our smb.conf is:
>>>> [global]
>>>>     server role = domain controller
>>>>     workgroup = MARINA
>>>>     realm = hh3.site
>>>>     netbios name = HH1
>>>>     passdb backend = samba4
>>>>     idmap_ldb:use rfc2307 = yes
>>>>
>>>>  On the PDC idmap mappings are the same as those in the AD (we have a
>>>> script that does this when we add e.g. a new group). Even though it
>>>> works and users and groups are correctly mapped from on eithr DC, we
>>>> would like the mappings to come from AD rather than idmap. mainly for
>>>> the sake of maintenance and readability.
>>>>
>>>> Is there any way we can do this?
>>>> Cheers,
>>>> Steve
>>>>
>>> Hi Steve,
>>>
>>> Now I'm completely confused: In theory idmap_ldb:use rfc2307 = yes would
>>> free you from having to mess with the idmap.ldb. Just have the correct
>>> uids/gids in the directory, and they should be picked by samba (maybe
>>> you are using an older version? support for this is quite recent).
>>>
>>> Regards
>>>
>>> Geza
>>
>> Hi Geza
>> So am I. Andrew's comment about
>>  idmap_ldb:use rfc2307 = yes
>> not applying to s3fs with AD (see above) makes it even more confusing.
>>
>> I'm not using an older version, this is a git from a few days ago.
>>
>> Geza, from your coders pov, does the code suggest that it _does_ work
>> with s3fs and AD?
>>
>> All our rfc2307 attributes and classes are stored in AD. nss-ldapd
>> pulls them out fine for Linux NFS clients. However, despite having
>> idmap_ldb:use rfc2307 = yes in smb.conf, wbinfo -i user still shows
>> what's in idmap.
>>
>> On our PDC we have scripts which change the gidNumber for newly
>> created groups. The script changes both the idmap xidNumber and AD
>> gidNumber. On a replicated second DC also with idmap_ldb:use rfc2307 =
>> yes, the gidNumber is _not_ coming from AD, only from idmap.
>>
>> Is there any way we can confir what should happen?
>> Cheers,
>> Steve
> Hi Steve,
>
> wbinfo is unrelated to s3fs, it is a command from the winbind suite. So
> if it is not pulling the attrs from AD with idmap_ldb:use rfc2307 = yes
> then I can imagine a few cases:
> 1. wbinfo is not from your samba 4 install (check your PATH)
samba -V
Version 4.0.0beta4-GIT-d81e206
wbinfo --version
Version 4.0.0beta4-GIT-d81e206

> 2. wbinfo/winbind is from an older version (not quite probable, but
> worth checking)
> 3. there could be still hidden requirements (I've checked with my
> freshly classicupgrade provisioned domain, where everything works as
> expected):
> 3A. My idmap.ldb contains entries just for the well known RIDs, maybe it
> would be worth to delete all other entries (after making a backup of
> course)

On DC1 idmap.ldb contains hundreds of entries. On DC2 it only contains 
the well known RID's aling with an xidNumber. Each time we issue a 
wbinfo -i <user>, an entry uis added to idmap.ldb with the correct SID 
of the <user> but with a totally unrelated xidNumber.

> 3B. The only posix related attr from a freshly migrated user looks like:
> uidNumber: 1002
> and the objectclasses are:
> objectClass: top
> objectClass: posixAccount
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> Maybe you should check if you misses some of them.
>

I create a posix group on DC1:

dn: CN=staff,CN=Users,DC=hh3,DC=site
cn: staff
instanceType: 4
whenCreated: 20120629203306.0Z
uSNCreated: 3736
name: staff
objectGUID: 9ffbead2-b2d1-44c8-b306-4dfdbb756c50
objectSid: S-1-5-21-3605328179-531901682-1830711284-1108
sAMAccountName: staff
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site
objectClass: top
objectClass: posixGroup
objectClass: group
gidNumber: 21108
member: CN=steve2,CN=Users,DC=hh3,DC=site
member: CN=lynn2,CN=Users,DC=hh3,DC=site
member: CN=s4,CN=Users,DC=hh3,DC=site
whenChanged: 20120705161529.0Z
uSNChanged: 5142
distinguishedName: CN=staff,CN=Users,DC=hh3,DC=site

It replicates perfectly to DC2 (apart from the uSN entries)

On DC1:
getent group staff
staff:*:21108

wbinfo --group-info=staff
staff:*:21108:

idmap:
# record 123
dn: CN=S-1-5-21-3605328179-531901682-1830711284-1108
cn: S-1-5-21-3605328179-531901682-1830711284-1108
objectClass: sidMap
objectSid: S-1-5-21-3605328179-531901682-1830711284-1108
type: ID_TYPE_BOTH
xidNumber: 21108
distinguishedName: CN=S-1-5-21-3605328179-531901682-1830711284-1108

On DC2:
getent group staff
staff:*:21108

wbinfo --group-info=staff
staff:*:3000011:

idmap:
# record 11
dn: CN=S-1-5-21-3605328179-531901682-1830711284-1108
cn: S-1-5-21-3605328179-531901682-1830711284-1108
objectClass: sidMap
objectSid: S-1-5-21-3605328179-531901682-1830711284-1108
type: ID_TYPE_BOTH
xidNumber: 3000011
distinguishedName: CN=S-1-5-21-3605328179-531901682-1830711284-1108

Am I doing anything wrong?
Why can't the xidNumbers be the same on both DC's?

It make administration more painful to have different id's.

The id numbers are NOT being take from AD, they are being taken from idmap.

Cheers,
Steve