Bug 7403 - ACL module: Permission denied when creating a site as non-default administrator
Summary: ACL module: Permission denied when creating a site as non-default administrator
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Nadezhda Ivanova
QA Contact: samba4-qa@samba.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-01 16:12 UTC by Matthieu Patou
Modified: 2011-01-18 14:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2010-05-01 16:12:01 UTC
At the opposite it's the case in Windows 2008r2.

After tracing a xp client talking to a w2k8r2 server, it appear that the client is creating the site object + the server container and the NTDS Site setting.

Something in the s4 answers didn't invite an xp client to do the same.
Comment 1 Matthieu Patou 2010-05-01 16:51:41 UTC
It turns out that with a user of the "Domain admins" group you can create a site but the NTDS and Server container are forbidden (Access control denied).
Comment 2 Matthias Dieter Wallnöfer 2010-05-10 05:18:26 UTC
Nadia, could you look at this: when some member of the "Domain Admins" group but not the default admin tries to create a site, only the site object itself but not the underlying containers (NTDS Settings, Servers, Licensing) will be created.

Reason: ACL module: insufficient access rights
Comment 3 Nadezhda Ivanova 2010-05-10 05:20:05 UTC
Will take a look, thanks.

Comment 4 Matthias Dieter Wallnöfer 2010-09-11 13:15:52 UTC
Nadia, I've detected the problem:

The Sites container on Windows Server doesn't use the unmodified default security descriptor from the schema. It removes from it the "Domain Admins" full permission ACE and instead adds a special permission ACE for the "Enterprise Admins".
We will somehow need to match this behaviour - but no idea why MS chose to override the default security descriptor.
Comment 5 Matthias Dieter Wallnöfer 2010-10-23 15:58:18 UTC
Well, I've managed to fix the security descriptor of the "CN=Sites" object we setting a manual one as it is apparently done also on Windows.

Now you are able to create sites when you are an enterprise administrator (member of "Enterprise Admins" group).

The membership of the "Domain Admins" group alone still doesn't work since there is a bug in the security descriptor inheritance: if you have the ONLY_INHERITED flag set then normally it isn't copied to the child objects (to illustrate this think at "this matters for all my children but not for me" then the children should say "this matters for all my own children and me").

Nadya would be nice if you could fix this in "create_descriptor.c".
Comment 6 Nadezhda Ivanova 2010-10-24 08:18:35 UTC
The Inherit Only flag does not have any effect on whether the ACE is passed on to the children, it only means that the ACE does not apply to the current object, at least that is my understanding. Inheritance depends only on CI, OI or P flags. I will take a look of course but I do not think this is the issue...
Comment 7 Matthias Dieter Wallnöfer 2011-01-14 03:29:11 UTC
Nadya: I've noticed that with commit 980f68a6f26070270313a4c7a4c0430f2bb3f078 the ACL inheritance behaviour changed. But now we differ even more from the "ideal" security descriptor for "CN=Sites" than before - so the inheritance is still somehow wrong.

Please assure yourself with an ldbsearch with attribute "nTSecurityDescriptor" against both s4 and Windows on CN=Sites,CN=Configuration,DC=...
Comment 8 Nadezhda Ivanova 2011-01-14 03:43:33 UTC
Matthias: I am currently working to assure inheritance is correct. The commit you mention is absolutely necessary to provide correct behavior, as proven by the tests I included. The difference is caused by another issue I am currently fixing, and is not a result of the last commit.   
Comment 9 Matthias Dieter Wallnöfer 2011-01-14 03:50:09 UTC
Ah thanks - don't worry. I wanted only to publish my results from the last investigation.

(In reply to comment #8)
> Matthias: I am currently working to assure inheritance is correct. The commit
> you mention is absolutely necessary to provide correct behavior, as proven by
> the tests I included. The difference is caused by another issue I am currently
> fixing, and is not a result of the last commit.   
> 

Comment 10 Matthias Dieter Wallnöfer 2011-01-18 14:45:52 UTC
I think we are done with this one.

Possibly there could be some way to later remove the from my side manually introduced "CN=Sites" descriptor - when Nadya has all differences fixed.