Bug 6760 - Samba4 fails returns empty SACL/DACL in LDAP although being not empty in the LDB
Summary: Samba4 fails returns empty SACL/DACL in LDAP although being not empty in the LDB
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
URL:
Keywords:
Depends on:
Blocks: 6600
  Show dependency treegraph
 
Reported: 2009-09-25 03:14 UTC by Matthieu Patou
Modified: 2009-10-04 16:19 UTC (History)
1 user (show)

See Also:


Attachments
Capture showing empty DACL/SACL when shouldn't (11.91 KB, application/octet-stream)
2009-09-25 03:14 UTC, Matthieu Patou
no flags Details
Capture showing correct DACL/SACL after LDBEDIT (11.92 KB, application/octet-stream)
2009-09-25 03:15 UTC, Matthieu Patou
no flags Details
keytabs for decrypting captures (1.58 KB, application/octet-stream)
2009-09-25 03:15 UTC, Matthieu Patou
no flags Details
script to show difference between a good and a bad provision (20.46 KB, text/x-python)
2009-09-25 03:16 UTC, Matthieu Patou
no flags Details
full log of the diffprov (78.70 KB, text/x-log)
2009-09-25 03:17 UTC, Matthieu Patou
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2009-09-25 03:14:16 UTC
Problem occurs with a fresh provision and is shown by the group policy management tool (gpmc.msc).
Clicking on the delegation tab give the message "an error has occured".

When looking at the LDAP traffic it appears that the DACL and SACL returned for the policy container are empty whereas in the LDAP they are not and log level 10 reveal that samba4 is fetching something not empty as well (check trace pbntacl)

After doing a simple ldbedit -H sam.ldb, we receive a message saying that 140 have been modified even if nothing has been touched.
Starting from this moment the delegation tab is showing the ACL for the policy as it should and the NTACL returned in LDAP call is ok (check trace pbntacl_aclok)

After a deep inspection with diffprov script (attached)
It apprears that the SDDL for the object is the same before and after LDB edit.
But other  parameter from DACL/SACL are different as the extract bellow just show it (revision is 0 before 4 after).

CN={D034B81B-69D9-43BC-A3B6-D91B29AE22D8},CN=Policies,CN=System,DC=samba4,DC=corp
nTSecurityDescriptor
Same sddl for bad and good
SD for bad
revision 1
type 39956
owner sid S-1-5-21-718463037-488991067-1482376005-512
group sid S-1-5-21-718463037-488991067-1482376005-512
sacl revision:0
sacl size:120
sacl #ace:2
dacl revision:0
dacl size:356
dacl #ace:12

SD for good
revision 1
type 39956
owner sid S-1-5-21-718463037-488991067-1482376005-512
group sid S-1-5-21-718463037-488991067-1482376005-512
sacl revision:4
sacl size:120
sacl #ace:2
dacl revision:4
dacl size:356
dacl #ace:12

The tool was used like this 
./diffprov.py --good ~/samba4corpafterldbedit --bad ~/samba4corpbeforeldbedit  --debugall
Comment 1 Matthieu Patou 2009-09-25 03:14:54 UTC
Created attachment 4741 [details]
Capture showing empty DACL/SACL when shouldn't
Comment 2 Matthieu Patou 2009-09-25 03:15:32 UTC
Created attachment 4742 [details]
Capture showing correct DACL/SACL after LDBEDIT
Comment 3 Matthieu Patou 2009-09-25 03:15:57 UTC
Created attachment 4743 [details]
keytabs for decrypting captures
Comment 4 Matthieu Patou 2009-09-25 03:16:59 UTC
Created attachment 4744 [details]
script to show difference between a good and a bad provision
Comment 5 Matthieu Patou 2009-09-25 03:17:27 UTC
Created attachment 4745 [details]
full log of the diffprov
Comment 6 Matthias Dieter Wallnöfer 2009-09-25 05:51:00 UTC
I CC also Nadezha to those bugs since she is our AD ACL expert.
Comment 7 Matthieu Patou 2009-09-25 12:15:41 UTC
I updated to a *very* recent commit: 76d836570e22c8916a00c723d86eb3be3d706223 and the problem is still there !
Comment 8 Matthias Dieter Wallnöfer 2009-09-28 10:53:34 UTC
This should be fixed now, ekacnet. Please close!
Comment 9 Matthieu Patou 2009-09-28 15:41:41 UTC
I'am not sure that this 5acd8bc01b23d6fc3d83eea9c3307feb7210879f changset has fixed the thing as I've tried, with a very up to date changset (2e989ba), to provision a test s4 and I've still some modifications on the nTSecurityDescriptor:

/usr/local/src/tests4/source4/bin/ldbedit -H sam.ldb -b "CN=Configuration,DC=foo,DC=bar" nTSecurityDescriptor
# 0 adds  1567 modifies  0 deletes

And the provision show me that I did it with the changeset I expect to be ...

oEMInformation: Provisioned by SAMBA 4.0.0alpha9-GIT-2e989ba

Comment 10 Matthieu Patou 2009-10-04 16:19:05 UTC
After a verification and a talk with Nadya on IRC it appears that now DACL and SACL are ok but the first ldbedit on sam.ldb files will modify one more time SD to add/remove some options.

These options are ignored right now by Windows and a real test confirm that with or without this options the error message is not present any more in GPMC.