samba - May 2018 - syscolcheck error / Could not convert sid S-1-5-32-544 to uid

On Fri, 25 May 2018 15:07:57 +0100
Rowland Penny via samba <samba at lists.samba.org> wrote:
> > running "samba-tool ntacl sysvolcheck" doesn't fix this.
> 
> Well it wouldn't, they are both borked.
> 
> Just do administration from Windows 

OK, maybe this is something which should be mentioned in the wiki. The
reason I got to this was that I wanted to try sysvol replication. The wiki
mentions at
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
you should i.e. copy idmap.ldb from the first DC to the new DC and then run 
"samba-tool ntacl sysvolreset".

Is this instruction still valid?
> > S-1-5-32-544 is the Administrator group, which is a builtin group. I  
> 
> No, it is the 'Administrators' group
Yes, of course
> > noticed, that this group already existed in the Samba 3 OpenLDAP DIT
> > with gidNumber 514.   
> 
> If we take it that '514' is actually a windows RID, then the group
> should be Domain Guests.
Yeah, it was 544. It is Friday afternoon - maybe not the best time to
write technical mails;)
> From my experience, the only AD user/group in AD with a RID less than
> 1000 that should have a uidNumber or gidNumber is Domain Users.
> 
> > So my first idea was to remove those Posix attributes from the
> > problematic groups (I tried it on Backup Operators S-1-5-32-551), but
> > to no avail.  
> 
> Ah, you probably missed the magic incantation 'net cache flush' ;-)
That was it. Thank you.

Kind regards,

Henry

On Fri, 25 May 2018 16:39:22 +0200
Henry Jensen <hjensen at mailbox.org> wrote:
> 
> OK, maybe this is something which should be mentioned in the wiki. The
> reason I got to this was that I wanted to try sysvol replication. The
> wiki mentions at
>
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
> you should i.e. copy idmap.ldb from the first DC to the new DC and
> then run "samba-tool ntacl sysvolreset".
> 
> Is this instruction still valid?
The problem with sysvolcheck & sysvolreset is they have never used the
Owner, group and ACLs that windows uses. Having said that, as long as
no BULTIN or DOMAIN user or group (except Domain Users) has a uidNumber
or gidNumber AND you haven't added any extra GPOs, it will work, you
just have to ignore that error message.
When you add ANY extra GPOs, then never ever use sysvolcheck or
sysvolreset. You should also never give Domain Admins a gidNumber
attribute, this turns the windows group into a Unix group. You are now
probably thinking 'what?', a group is just a group, right ? Well, no,
a Windows group can do something that no Unix group can, it can own
files and directories and guess what needs to own files and directories
in sysvol ??
 
Rowland

On Fri, 25 May 2018 16:09:11 +0100
Rowland Penny via samba <samba at lists.samba.org> wrote:
> > OK, maybe this is something which should be mentioned in the wiki. The
> > reason I got to this was that I wanted to try sysvol replication. The
> > wiki mentions at
> >
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
> > you should i.e. copy idmap.ldb from the first DC to the new DC and
> > then run "samba-tool ntacl sysvolreset".
> > 
> > Is this instruction still valid?  
> 
> The problem with sysvolcheck & sysvolreset is they have never used the
> Owner, group and ACLs that windows uses. Having said that, as long as
> no BULTIN or DOMAIN user or group (except Domain Users) has a uidNumber
> or gidNumber AND you haven't added any extra GPOs, it will work, you
> just have to ignore that error message.
> When you add ANY extra GPOs, then never ever use sysvolcheck or
> sysvolreset. You should also never give Domain Admins a gidNumber
> attribute, this turns the windows group into a Unix group. You are now
> probably thinking 'what?', a group is just a group, right ? Well,
no,
> a Windows group can do something that no Unix group can, it can own
> files and directories and guess what needs to own files and directories
> in sysvol ??

Thanks again. This is something I will write in our internal admin wiki.


Kind Regards,

Henry

Hi Rowland

On 25 May 2018 at 16:09, Rowland Penny via samba <samba at
lists.samba.org>
wrote:
>
> The problem with sysvolcheck & sysvolreset is they have never used the
> Owner, group and ACLs that windows uses. Having said that, as long as
> no BULTIN or DOMAIN user or group (except Domain Users) has a uidNumber
> or gidNumber AND you haven't added any extra GPOs, it will work, you
> just have to ignore that error message.
> When you add ANY extra GPOs, then never ever use sysvolcheck or
> sysvolreset. You should also never give Domain Admins a gidNumber
> attribute, this turns the windows group into a Unix group. You are now
> probably thinking 'what?', a group is just a group, right ? Well,
no,
> a Windows group can do something that no Unix group can, it can own
> files and directories and guess what needs to own files and directories
> in sysvol ??

Thank you for the clear summary here, that really explains the issues.

I've spotted a section on the wiki that now appears out of date -
https://wiki.samba.org/index.php/FAQ#What_Does_The_permissions_for_this_GPO_in_the_SYSVOL_folder_are_inconsistent_with_those_in_Active_Directory_Mean.3F
contradicts what I believe is more current advice e.g. from Louis, to use
the Windows tools instead

Is there an 'owner' for any of this info on the wiki, or should I just
go
ahead and edit? (in this instance, perhaps remove that FAQ entry as it is
misleading now?)

Cheers

Jonathan

-- 
"If we knew what it was we were doing, it would not be called research,
would it?"
      - Albert Einstein

On 25 May 2018 at 17:09, Rowland Penny via samba <samba at
lists.samba.org>
wrote:
> On Fri, 25 May 2018 16:39:22 +0200
> Henry Jensen <hjensen at mailbox.org> wrote:
>
> >
> > OK, maybe this is something which should be mentioned in the wiki. The
> > reason I got to this was that I wanted to try sysvol replication. The
> > wiki mentions at
> > https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_
> Existing_Active_Directory
> > you should i.e. copy idmap.ldb from the first DC to the new DC and
> > then run "samba-tool ntacl sysvolreset".
> >
> > Is this instruction still valid?
>
> The problem with sysvolcheck & sysvolreset is they have never used the
> Owner, group and ACLs that windows uses. Having said that, as long as
> no BULTIN or DOMAIN user or group (except Domain Users) has a uidNumber
> or gidNumber AND you haven't added any extra GPOs, it will work, you
> just have to ignore that error message.
> When you add ANY extra GPOs, then never ever use sysvolcheck or
> sysvolreset. You should also never give Domain Admins a gidNumber
> attribute, this turns the windows group into a Unix group. You are now
> probably thinking 'what?', a group is just a group, right ? Well,
no,
> a Windows group can do something that no Unix group can, it can own
> files and directories and guess what needs to own files and directories
> in sysvol ??
>
>
Hi Rowland,

This indeed looks like very crucial information that should be part of the
wiki. Or maybe I just missed it.

Now, my domain admins group (as well as every other group) does have a
gidNumber, and my configuration (with many, many extra GPOs) is working
just fine. Well, maybe not "just" fine, I had to set "ignore
system acls no" in order for ACL's to work properly. But I ran
sysvolcheck and
sysvolreset many times with no issues.

I'm curious, do you consider it safe to now remove the gidNumber from all
groups except domain users? Would I break something?

Viktor