[Samba] Samba4 member of an another « Samba4 » domain

[steve]

On 15/04/13 03:17, François Lafont wrote:
> Le 14/04/2013 08:00, steve a écrit :
>
>>> Ok, if I understand, after a provision of a domain with samba-tool and
>>> the "--use-rfc2307" option, samba4 can support posixaccount etc. in
>>> its database, but I have to add the object class and the mandatory
>>> attributes myself.
>> It can do that whether you provision with --use-rfc2307 or not.
> Are you sure? In this case, I won't use this option.
99.99% it's just adding a bit to the schema so that you can add rfc2307 
bits from windows. I always do that from Linux can anyone add the 0.01% 
for us?
>
>> I
>> believe that it adds the possibility of adding the uid:gid from windows.
>> I've never used windows for this.
> Me too. I prefer to manage the AD in the samba server.
>
>> If you want to pull uid:gid from AD then you'll need to add uidNumber
>> and gidNumber for users and gidNumber for groups.
> And "memberUid" too for groups, isn't it?
No. AD uses the member attribute. Here is a group called staff where 
steve2 is its only member:

# record 1
dn: CN=staff,CN=Users,DC=hh3,DC=site
cn: staff
instanceType: 4
whenCreated: 20130414144050.0Z
uSNCreated: 3795
name: staff
objectGUID: 5267385f-c466-41f1-be7c-dddcb4640a33
objectSid: S-1-5-21-1555648365-2472922434-3126067274-1118
sAMAccountName: staff
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site
objectClass: top
objectClass: posixGroup
objectClass: group
gidNumber: 21118
member: CN=steve2,CN=Users,DC=hh3,DC=site
whenChanged: 20130414144415.0Z
uSNChanged: 3799
distinguishedName: CN=staff,CN=Users,DC=hh3,DC=site

The good news is that all that samba-tool looks after all this for you:
samba-tool group addmembers staff steve2

You can use e.g. sssd to pull the info:
getent group staff
staff:*:21118:steve2


>
>> All users which need
>> to login will need the attributes but there's no need to allocate
>> gidNumber to al the groups. Many of them have no meaning in Linux. e.g.
>> To begin with, just allocate a gidNumber to Domain Users. A good way to
>> decide which gidNumber to allocate is to take the RID of the group and
>> add, say, 20000 to keep it well away from local groups. As the RID of
>> Domain Users is 513 then our gidNumber becomes 20513.
>>
>> For users, we allocated our first user uidNumber 3000032 to avoid
>> collision with the xidnumbers which have to remain in idmap.
> I don't think that 3000032 is a good uidNumber because idmap seems to use the "3000000-4000000" range.
No. It doesn't matter. AD knows nothing about idmap.ldb but if you're 
happier, then use an even higher range;)

>
>>> # getent passwd Guest
>>> CHEZMOI\Guest:*:3000011:3000012::/home/CHEZMOI/Guest:/bin/false
>>>
>>> uid=3000011 although I have done no change in the Guest account.oming
>>> from /ur/
>> Those uid:gid pairs are coming from idmap. idmap is not part of AD and
>> confuses the issue for many of us. If you are going to add more DC's,
>> these uid:gid's  will change depending upon which DC you refer to.
>> Probably (almost certainly) not what you want.
> Absolutely. :)
>
>>> How choose Samba these uid/gid numbers (e.g 3000011/3000012) and how
>>> can I choose my uid/gid numbers in order that there is never conflict
>>> with uid/gid choose automatically by Samba?
>> That is best answered by looking at:
>> ldbsearch --url=/usr/local/samba/private/idmap.ldb
> Ok, it's a good answer indeed. And I can see:
>
> ----------------------------------------------------
> # ldbsearch --url=/usr/local/samba/private/idmap.ldb cn=config
> # record 1
> dn: CN=CONFIG
> cn: CONFIG
> lowerBound: 3000000
> upperBound: 4000000
> xidNumber: 3000017
> distinguishedName: CN=CONFIG
> ----------------------------------------------------
>
> Then, I understand that idmap uses the "3000000-4000000" range to assign xidNumber to the users and groups.
>
>> There, you'll see the sids with the xidnumber that Samba has allocated
>> to them. This xidnumber becomes the uid or gid depending upon whether
>> the object is a user, group or both. A basic set of objects has to
>> remain in idmap so leave it as it is after provision. If you add the
>> line idmap_ldb:use rfc2307 = Yes to smb.conf (which I believe the
>> provision has already done for you) then any new user or group object
>> that is created will not have an entry in idmap. You are then free to
>> add the necessary uid/gidNumbers to AD.
> Yes, indeed:
>
> ----------------------------------------------------
> # grep 'rfc' /usr/local/samba/etc/smb.conf
> 	idmap_ldb:use rfc2307 = yes
>
> # samba
> # samba-tool user add test4 "test4"
> User 'test4' created successfully
>
> # ldbsearch --url=/usr/local/samba/private/sam.ldb cn=test4 | grep -i objectsid
> objectSid: S-1-5-21-3840058276-1254623269-3939424142-1106
>
> # ldbsearch --url=/usr/local/samba/private/idmap.ldb cn=S-1-5-21-3840058276-1254623269-3939424142-1106
> # returned 0 records
> # 0 entries
> # 0 referrals
> ----------------------------------------------------
>
> But after this:
>
> ----------------------------------------------------
> # getent passwd test4
> CHEZMOI\test4:*:3000019:100::/home/CHEZMOI/test4:/bin/false
> ----------------------------------------------------
>
> the idmap entry is automatically created:
>
> ----------------------------------------------------
> # ldbsearch --url=/usr/local/samba/private/idmap.ldb cn=S-1-5-21-3840058276-1254623269-3939424142-1106
> # record 1
> dn: CN=S-1-5-21-3840058276-1254623269-3939424142-1106
> cn: S-1-5-21-3840058276-1254623269-3939424142-1106
> objectClass: sidMap
> objectSid: S-1-5-21-3840058276-1254623269-3939424142-1106
> type: ID_TYPE_BOTH
> xidNumber: 3000019
> distinguishedName: CN=S-1-5-21-3840058276-1254623269-3939424142-1106
> ----------------------------------------------------
>
> I have noticed that I have exactly the same behavior without the "idmap_ldb:use rfc2307 = yes" option. Then, I don't see exactly the meaning of this option...
Sorry. My bad explanation. Indeed, for each new user or group you create 
you always end up with an idmap entry too. What

idmap_ldb:use rfc2307 = yes

is saying is 'ignore idmap and give priority to AD'. Of course, the 
attributes must be there in the first place otherwise it will fall back 
to idmap again.  Exactly what we are trying to avoid at all costs. I had 
to prove this to myself by creating a user in AD with rfc2307 stuff and 
then deleting his entry in idmap. With the

idmap_ldb:use rfc2307 = yes
in place then no problem. All his stuff came from AD as expected:)

>>   Sorry, I can't access the list archive at the moment. The thread is
>> called 'Some clarification?'
> Ok, I see.
>
> Thanks a lot for yours explanations Steeve. It's become more clean in my mind. :)
>
I think we're speaking the same language now.
hth
Steve