wellknown and uid/gid interactions on multi DC samba AD domain

[steve]

On Wed, 2014-05-14 at 14:26 +0200, Daniele Dario wrote:
> Hi again,
> 
> On mer, 2014-05-14 at 12:33 +0200, steve wrote:
> > On Wed, 2014-05-14 at 12:23 +0200, Daniele Dario wrote:
> > > 
> > 
> > > 
> > > Now as you said the uids/gids are the same on the 2 DCs so again thanks.
> > > 
> > Well done.
> > 
> > > I have a question about the sysvol: I noticed that the group of the
> > > sysvol folder is different on the two DCs.
> > > On the 1st DC (4.1.0):
> > > [root at kdc01:locks]# ls -n sysvol/
> > > total 8
> > > drwxrwx---+ 4 0 4 4096 Sep 24  2012 saitel.loc
> > > 
> > > On the 2nd DC (4.1.7):
> > > [root at kdc03:locks]# ls -n sysvol/
> > > total 8
> > > drwxrwx---+ 4 0 3000000 4096 May  8 16:18 saitel.loc
> > > 
> > > [root at kdc03:locks]# wbinfo -G 3000000
> > > S-1-5-32-544
> > > [root at kdc03:locks]# wbinfo -s S-1-5-32-544
> > > BUILTIN\Administrators 4
> > > 
> > > If I read it correctly BUILTIN\Administrators should be mapped as 4 so
> > > same as on the other one.
> > What does S-1-5-32-544 look like in the respective idmap.ldb dbs?
> 
> On kdc01 I get
> # record 53
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_GID
> xidNumber: 4
> distinguishedName: CN=S-1-5-32-544
> 
> On kdc03 I have
> # record 44
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_BOTH
> xidNumber: 3000000
> distinguishedName: CN=S-1-5-32-544
> 
> so they look different for the xidNumber and maybe worst for type!
> 
> > > 
> > > Did I forgot something?
> > > 
> > > Regards,
> > > Daniele.
> > > 
> > How does sysvol get from DC1 to DC2?
> > 
> > Try samba-tool ntacl sysvolreset on both
> > then compare the output of getfacl
> > 
> > Do gpos work if you lose DC2?
> > HTH
> > Steve
> > 
> > 
> 
> I made a sysvolreset on both DCs before replaying.
> 
> comparing the getfacl results there's something wrong because now
> something is overlapping:
> 
> [root at kdc03:locks]# getfacl -e sysvol
> # file: sysvol
> # owner: root
> # group: 3000000
> user::rwx
> user:root:rwx			#effective:rwx
> user:3000000:rwx		#effective:rwx
> user:3000012:r-x		#effective:r-x
> user:3000017:r-x		#effective:r-x
> user:3000018:rwx		#effective:rwx
> group::rwx			#effective:rwx
> group:3000000:rwx		#effective:rwx
> group:3000012:r-x		#effective:r-x
> group:3000017:r-x		#effective:r-x
> group:3000018:rwx		#effective:rwx
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx		#effective:rwx
> default:user:3000000:rwx	#effective:rwx
> default:user:3000012:r-x	#effective:r-x
> default:user:3000017:r-x	#effective:r-x
> default:user:3000018:rwx	#effective:rwx
> default:group::---		#effective:---
> default:group:3000000:rwx	#effective:rwx
> default:group:3000012:r-x	#effective:r-x
> default:group:3000017:r-x	#effective:r-x
> default:group:3000018:rwx	#effective:rwx
> default:mask::rwx
> default:other::---
> 
> which seems correct but on kdc01:
> 
> [root at kdc01:/usr/local/samba/var/locks]# getfacl -e sysvol
> # file: sysvol
> # owner: root
> # group: adm
> user::rwx
> user:root:rwx			#effective:rwx
> group::rwx			#effective:rwx
> group:adm:rwx			#effective:rwx
> group:3000006:r-x		#effective:r-x
> group:SAITEL\134Schema\040Admins:rwx#effective:rwx
> group:3000008:r-x		#effective:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx		#effective:rwx
> default:group::---		#effective:---
> default:group:adm:rwx		#effective:rwx
> default:group:3000006:r-x	#effective:r-x
> default:group:SAITEL\134Schema\040Admins:rw#effective:rwx
> default:group:3000008:r-x	#effective:r-x
> default:mask::rwx
> default:other::---
> 
> Looking at which groups are involved, I see that on kdc03 I have
> 3000000 => BUILTIN\Administrators 4
> 3000012 => NT AUTHORITY\Authenticated Users 5
> 3000017 => BUILTIN\Server Operators 4
> 3000018 => NT AUTHORITY\SYSTEM 5
> which seems to be reasonable (are them?)
> 
> On kdc01 I see
> 4       => local adm group
> 3000006 => BUILTIN\Server Operators 4
> 3000007 => SAITEL\Schema Admins 2 (OVERLAPPED adding my group)
> 3000008 => NT AUTHORITY\Authenticated Users 5
> 
> @Rowland: 
> 
> >
> > Hi, you never posted just what distro you are using (or if you did, I 
> > missed it), but mapping Administrators to '4' is not a good idea, I 
> > learnt the hard way with 'Domain Users' !!
> 
> I'm working with ubuntu 12.04 server (kdc01 is a 32 bit VM with samba
> 4.1.0 and kdc03 is a 64 bit physical machine with samba 4.1.7)
> I provisioned the domain on kdc01 adding anything to what stated in the
> wiki (at least on the time i provisioned) so it was not my choice to map
> Administrators to '4', it was by default I think.
> 
> > 
> > On Debian based distro's '4' is the adm group, so mapping to this,
> would 
> > seem a good idea, but not when you really start to think about it. If 
> > you use winbind with the 'ad' backend you will have to set the domain 
> > range to start at '0' to pull these low end users/groups, not a good
> idea.
> > 
> > I do not recommend mapping the majority of windows groups with 
> > gidNumber's, except for Domain Users & Domain Admins, and I would
> also 
> > suggest that you decide on just where your range is going to start 
> > (4000001 is a good place) then map the two windows groups to the
> start 
> > of this range.
> > 
> > Rowland
> > 
> 
> So let me ask if I got it right:
> - only add gidNumber to Domain Users & Domain Admins and not to the
> groups I create?
You must also add gidNumber to the groups you create.

> - start mapping from 4000000 to avoid overlapping with windows
> users/groups?
> 
Yes.
> Another question: would it be possible to "remap" the BUILTIN
> \Administrators group to a value different from '4'?
Yes, just change the xidNumber.
> And anyway I cannot preserve the same gidNuber for the Windows groups so
> rsyncing sysvol will brake the folder and would need to perform a
> sysvolreset am I right?
Yes, BUT be careful because your xidNumbers for the builtin groups are
already different between dc01 and dc03:( Maybe we've overlooked
something but as we said in the last post, the only way we've
successfully got sysvol rsynced is by the idmap db transfer.
> 
> Again thanks for your help,
> Daniele.
>