[Samba] Issues with migrated SYSVOL GPOs

[Matthieu Patou]

Hello Andreas,

On 03/22/2012 01:31 AM, Andreas Oster wrote:
> Hello all,
>
> some time ago I've posted on samba.internals but did get no answer to my
> question. I hope that someone on this list can give me some help.
>
> I have migrated a Win2k AD to samba4 and copied SYSVOL as decribed in
> this post:
>
> https://lists.samba.org/archive/samba-technical/2011-October/080026.html
>
> Now I have the problem that only the builtin Administrator can
> sucessfull modify/add GPOs. Users which are assigned to the
> "domain admin" group can open/view GPOs but when trying to change
> anything an error message pops up stating that the user is not allowed
> to do it. Unfortunately the GPO does not work anymore afterwards and
> needs to be rebuild by the administrator.
I'm pretty sure that the problem you have is the following, the default 
group for the administrator user is 'administrators' and so on the *ix 
side file are group owned by this group.
Members of the domain admin group get an access denied while trying to 
store the file because they are not seen as member of the administrators 
group (which is the case) and because other group membership that should 
give them write access are not translated to posix acls.
The way to solve it to give the group membership to either "domain 
admins" or "enterprise admins" and make sure that they can write.
In order to get the gid for this group you can use wbinfo 
--group-info="domain admins".
The second problem you'll face is that you can create new policy by 
default with just admin users. This is due to a limitation of the 
posix/acl layer, the root of the problem is that when the group policy 
console try to create the new policy it creates a folder and the ACLs 
specified by windows set the group ownership to domain users and the 
user ownership to "domain admins" as ACLs for domain users are limited 
posix rights are translated to rx so when it tries to create a GPT.INI 
file, Windows is denied to do so because at the end the user hasn't the 
right to write in this newly created dir (directory_user != user && 
directory_group_right forbid write).

The way to solve this problem is to force the directory mask to be 775, 
it's not the most elegant situation but it works.

Matthieu.

-- 
Matthieu Patou
Samba Team
http://samba.org