Bug 9267 - Can't delegate adding computers to domain
Can't delegate adding computers to domain
Status: RESOLVED FIXED
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.0.0rc5
x64 Windows XP
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on: 9740
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-08 11:58 UTC by Marc Muehlfeld
Modified: 2013-04-11 19:51 UTC (History)
4 users (show)

See Also:


Attachments
Level 10 debug logs (263.90 KB, application/octet-stream)
2012-10-08 12:00 UTC, Marc Muehlfeld
no flags Details
Screenshot of the created LDAP entry of the machine account (23.76 KB, image/png)
2012-10-08 12:01 UTC, Marc Muehlfeld
no flags Details
Screenshot of the error on windows (10.01 KB, image/png)
2012-10-08 12:01 UTC, Marc Muehlfeld
no flags Details
ldbsearch result for vm-09 (71.71 KB, text/plain)
2012-10-11 07:41 UTC, Marc Muehlfeld
no flags Details
ldbsearch on computerS (46.71 KB, text/plain)
2012-10-11 08:59 UTC, Marc Muehlfeld
no flags Details
Both ldbsearch without --show-binary (7.41 KB, text/plain)
2012-10-11 09:01 UTC, Marc Muehlfeld
no flags Details
proposed nt sd (2.48 KB, application/octet-stream)
2012-10-12 09:06 UTC, Matthieu Patou
no flags Details
Screenshot after samba_upgradeprovision first (10.73 KB, image/png)
2013-01-28 10:35 UTC, Marc Muehlfeld
no flags Details
Screenshot after dbcheck first (33.94 KB, image/png)
2013-01-28 10:37 UTC, Marc Muehlfeld
no flags Details
Screenshot before/after samba-tool dbcheck --fix and samba_upgradeprovision (165.64 KB, application/octet-stream)
2013-01-29 13:47 UTC, Marc Muehlfeld
no flags Details
Error Screenshot after dbcheck only (586.27 KB, text/plain)
2013-01-29 15:26 UTC, Marc Muehlfeld
no flags Details
samba_upgradeprovision test patch (1.37 KB, patch)
2013-02-01 16:47 UTC, Stefan Metzmacher
no flags Details
upgradeprovision patch to avoid auto-detection of 'alpha' releases (1.72 KB, patch)
2013-02-16 23:55 UTC, Andrew Bartlett
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2012-10-08 11:58:51 UTC
It's not possible to delegate the permission for "add computers to the domain" in ADUC. I followed the guide http://robiulislam.wordpress.com/2012/02/07/delegate-non-admin-account-to-add-workstations-to-domain/ to configure the delegation.

But when I try to join as one of the members of this group, I get the error:

> The computer failed to join the domain "muc". Please contact your
> domain administrator and indicate that the computer failed to
> update the dnsHostName and/or servicePrincipalName (SPN) attribute
> in its Active Directory computer account. Once the problem is
> resolved, you may join the computer to the "muc" domain.

The machine entry appears in ADUC, but with an red X. And the computer isn't part of the domain. If I pre-create the account in ADUC it's exactly the same.

I think delegation is an important feature for s4. No one want to give domain admin passwords to all helpdesk employees.
Comment 1 Marc Muehlfeld 2012-10-08 12:00:01 UTC
Created attachment 8006 [details]
Level 10 debug logs

Logfiles of trying to add a machine to the domain as user (technik), who is member of the group (ComputerToDomainAdmins) I've delegated.
Comment 2 Marc Muehlfeld 2012-10-08 12:01:31 UTC
Created attachment 8007 [details]
Screenshot of the created LDAP entry of the machine account

This is what is created in LDAP, when I try to add a machine to the domain.
Comment 3 Marc Muehlfeld 2012-10-08 12:01:49 UTC
Created attachment 8008 [details]
Screenshot of the error on windows
Comment 4 Marc Muehlfeld 2012-10-10 07:14:05 UTC
Problem remain unchanged in rc2.


Addional Information: Also if I grant 'Full Access' to the group on the 'computers' container, it doesn't work.
Comment 5 Matthieu Patou 2012-10-11 05:26:52 UTC
Marc,

It seems that you are trying to add the computer in the CN=Computer container.
Can you do the following queries:

ldbsearch -H ldap://<ip> -Uadministrator '(cn=computer)' ntsecuritydescriptor 
--show-binary

ldbsearch -H ldap://<ip> -Uadministrator '(cn=vm-09)' ntsecuritydescriptor --show-binary

Given the logs I highly suspect that ACLs are not marked as inherited to the the childs because while reading the logs it seems that it's just the modify that is failing.
Can you also join a workstation with the admin then change the security right on this object so that this group has the write validated writes then do
ldbedit -H ldap://<ip> -Uuser_from_th_group '(cn=<cn of the computer>)' dnshostname ServicePrincipalName
and change the hostname and add a spn (ie FOO/<shorthostname>).
Comment 6 Marc Muehlfeld 2012-10-11 07:31:22 UTC
Matthieu, I sended you a level 10 debug log, keytab export and network capture to your mail address (was created on a new provisioned test system. So the keytab contains no real passwords).
Comment 7 Marc Muehlfeld 2012-10-11 07:41:33 UTC
Created attachment 8043 [details]
ldbsearch result for vm-09

(In reply to comment #5)
> ldbsearch -H ldap://<ip> -Uadministrator '(cn=computer)' ntsecuritydescriptor 
> --show-binary

# Referral
ref: ldap://muc.medizinische-genetik.de/CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de

# Referral
ref: ldap://muc.medizinische-genetik.de/DC=DomainDnsZones,DC=muc,DC=medizinische-genetik,DC=de

# Referral
ref: ldap://muc.medizinische-genetik.de/DC=ForestDnsZones,DC=muc,DC=medizinische-genetik,DC=de

# returned 3 records
# 0 entries
# 3 referrals





> ldbsearch -H ldap://<ip> -Uadministrator '(cn=vm-09)' ntsecuritydescriptor
> --show-binary

Find attached.
Comment 8 Matthieu Patou 2012-10-11 08:45:21 UTC
> (In reply to comment #5)
> > ldbsearch -H ldap://<ip> -Uadministrator '(cn=computer)' ntsecuritydescriptor 
I had a typo it's cn=computerS 
> Find attached.
Comment 9 Matthieu Patou 2012-10-11 08:47:07 UTC
What is the SID of this group ?
Comment 10 Matthieu Patou 2012-10-11 08:51:30 UTC
Can you also do the search without the --show-binary ? 

Thanks.
Comment 11 Marc Muehlfeld 2012-10-11 08:59:00 UTC
Created attachment 8044 [details]
ldbsearch on computerS

(In reply to comment #8)
> I had a typo it's cn=computerS 

Find the new log attached.



> What is the SID of this group ?

S-1-5-21-1362721961-1801182073-732966438-17214
Comment 12 Marc Muehlfeld 2012-10-11 09:01:38 UTC
Created attachment 8045 [details]
Both ldbsearch without --show-binary

Can you also do the search without the --show-binary ? 

Find both outputs in the attached file.
Comment 13 Matthieu Patou 2012-10-12 08:43:38 UTC
OK I did a first analysis, I think we have a bug !

Here are the ACE that relates to your group (bug report best viewed with a text-area, in firefox you can resize it)

(OA;CIIO;SW;f3a64788-5306-11d1-a9c5-0000f80367c1  ;bf967a86-0de6-11d0-a285-00aa003049e2;S-1-5-21-1362721961-1801182073-732966438-17214)
(OA;CIIO;SW;72e39547-7b18-11d1-adef-00c04fd8d5cd  ;bf967a86-0de6-11d0-a285-00aa003049e2;S-1-5-21-1362721961-1801182073-732966438-17214)
(OA;CIIO;RPWP;4c164200-20c0-11d0-a768-00aa006e0529;bf967a86-0de6-11d0-a285-00aa003049e2;S-1-5-21-1362721961-1801182073-732966438-17214)
(OA;CIIO;CR;00299570-246d-11d0-a768-00aa006e0529  ;bf967a86-0de6-11d0-a285-00aa003049e2;S-1-5-21-1362721961-1801182073-732966438-17214)
(OA;CI;CC;bf967a86-0de6-11d0-a285-00aa003049e2;                                        ;S-1-5-21-1362721961-1801182073-732966438-17214)

The first two ACE I didn't analyzed them carefully because I'm pretty sure they don't count they give the self write on the attribute set defined by the GUID after SW;, so basically this will only apply when the account that has the sid S-1-5-21-1362721961-1801182073-732966438-17214 is try to do something.

Third ACE is related to account control and password reset, check the following command 
./bin/ldbsearch -H ldap://<ip> --cross-ncs '(attributeSecurityGUID=4c164200-20c0-11d0-a768-00aa006e0529)' dn

The forth one is the one that should grant the user in the 17214 group the right but we fail to honor it (I think).

I need more time to read the ACL module and reread MS-ADTS.
Also I would like to finish some stuff related to domain join in Windows 2012.

How urgent is it for you ?
Comment 14 Marc Muehlfeld 2012-10-12 08:51:15 UTC
Many thanks for analyzing the issue.


(In reply to comment #13)
> How urgent is it for you ?

It's not high critical in my environment - more disturbing. Because everytime a computer is (re-)installed, the helpdesk users need someone with domain admin permissions let the machine join the domain. And during the next time there will be many reinstallations with Win7.

But I think delegation is something that would be important to be in the final s4 release (incl. User/GPO delegation). Because many domain admins want to give their password to all helpdesk users.

Is there any save workaround to delegate? Like with samba-tool?
Comment 15 Matthieu Patou 2012-10-12 09:05:16 UTC
In your test domain try to replace the security descriptor for the CN=Computers object by the one I attached to this bug.

Be sure to backup your environment I might have made a mistake in the ACLs
Comment 16 Matthieu Patou 2012-10-12 09:06:51 UTC
Created attachment 8048 [details]
proposed nt sd

Use ldbedit -H ldap://<ip> '(cn=computers)' ntsecuritydescriptor to edit the SD,

I strongly recommend to copy and paste the ACL that I crafted.
Comment 17 Matthieu Patou 2012-10-22 04:32:52 UTC
(In reply to comment #15)
> In your test domain try to replace the security descriptor for the CN=Computers
> object by the one I attached to this bug.
> 
> Be sure to backup your environment I might have made a mistake in the ACLs

Any news on this ?
Comment 18 Marc Muehlfeld 2012-10-22 05:59:25 UTC
Sorry. It seems I haven't saved my comment yesterday.

I upgraded to rc3, where the problem is still the same.


I replaced the ntsecuritydescriptor on my test environment with the one you provided to me. But then I still can't join the domain as member of the group who should. But I must confess, that I'm not 100% sure, if I did it right.


If you are working on this issue and need more debugs/etc., we can meet in IRC. Just let me know.
Comment 19 Matthieu Patou 2012-10-22 06:03:54 UTC
(In reply to comment #18)
> Sorry. It seems I haven't saved my comment yesterday.
> 
> I upgraded to rc3, where the problem is still the same.
> 
That's expected ...
> 
> I replaced the ntsecuritydescriptor on my test environment with the one you
> provided to me. But then I still can't join the domain as member of the group
> who should. But I must confess, that I'm not 100% sure, if I did it right.
> 
ok let's see 
> 
> If you are working on this issue and need more debugs/etc., we can meet in IRC.
> Just let m know.
I'm ekacnet on  samba-technical I'm in the east cost of US
Comment 20 Marc Muehlfeld 2012-12-06 12:59:39 UTC
rc6 fixes this problem.

I could successfully delegate the "join computers to domain" permission to a non-admin now.

Many thanks.
Comment 21 Matthieu Patou 2012-12-08 05:14:06 UTC
I'm a bit surprised because ihmo the problem is still here (or I did a wrong analysis).
As I think that in order to work we need to check SEC_ADS_CONTROL_ACCESS for the right 4c164200-20c0-11d0-a768-00aa006e0529 when we just check SEC_ADS_WRITE_PROP.

I will monitor this more closely.
Comment 22 Marc Muehlfeld 2012-12-09 15:03:08 UTC
If I can provide you some more debuggings from my working rc6 environment, let me know. But here it works fine now.
Comment 23 Marc Muehlfeld 2012-12-11 13:41:11 UTC
I have to reopen this bug report. It's not finally fixed.

Last week I had joined XP machines, what worked great for delegated non-domain-admins. Today I tried joining with the same user account two W7 machines, and it failes.

So currently it seems only to work on XP, not W7.
Comment 24 Marc Muehlfeld 2013-01-03 13:33:52 UTC
I found out someting new:

If I add 'acl:search = no' to my smb.conf, the joining machines to the domain for delegated users work's on Win7, too.
Comment 25 Stefan Metzmacher 2013-01-27 14:36:02 UTC

*** This bug has been marked as a duplicate of bug 8909 ***
Comment 26 Marc Muehlfeld 2013-01-28 09:28:10 UTC
I tried the latest version from master today. But problem is still existing unchanged: Joining (as a delegated group) XP works, Win7 doesn't.

So this bug is not fixed yet.
Comment 27 Stefan Metzmacher 2013-01-28 09:37:45 UTC
(In reply to comment #26)
> I tried the latest version from master today. But problem is still existing
> unchanged: Joining (as a delegated group) XP works, Win7 doesn't.
> 
> So this bug is not fixed yet.

Have you tested it with a new provisioned domain or an existing domain?

For existing domains 'samba_upgradeprovision' and 'samba-tool dbcheck --fix'
is needed, but create backups before doing running them. I'm not sure
about the best order to run them.
Comment 28 Marc Muehlfeld 2013-01-28 10:35:02 UTC
Created attachment 8504 [details]
Screenshot after samba_upgradeprovision first

When I frist run 'samba_upgradeprovision' and then 'samba-tool dbcheck --fix', I can't join W7 (haven't tested XP any more), I get an error that its only allowed on the PDC (see screenshot).
Comment 29 Marc Muehlfeld 2013-01-28 10:37:14 UTC
Created attachment 8505 [details]
Screenshot after dbcheck first

When I frist run 'samba-tool dbcheck --fix' first, I get:
# samba-tool dbcheck --fix
Checking 913 objects
Fix nTSecurityDescriptor on CN=kfast,CN=Users,DC=muc,DC=medizinische-genetik,DC=de? [y/N/all/none] all
Fixed attribute 'nTSecurityDescriptor' of 'CN=kfast,CN=Users,DC=muc,DC=medizinische-genetik,DC=de'

...
...
...


Checked 913 objects (227 errors)



I had let all errors fixed. Then I run 'samba_upgradeprovision' after that:


# samba_upgradeprovision
Creating a reference provision
No IPv6 address will be assigned
Copy privilege
Update base samdb by searching difference with reference one
Update of secrets.ldb
Update machine account
Fixing very old provision SD
Upgrade finished!
Reopening samdb to trigger reindexing if needed after modification
Reindexing finished




But I still can't join W7 (also XP not tested any more yet). The error now was different: Access denied (joining as domain admin still works. But not the group I have delegated to)
Comment 30 Marc Muehlfeld 2013-01-28 20:50:45 UTC
I reopened this bug report, because the problem is not fixed by the patch (see my last comments).
Comment 31 Björn Baumbach 2013-01-29 12:05:03 UTC
Hi!

I tried to delegate the following permissions to a new user in a newly provisioned AD. The Samba version is 4.0-test 7ba52a1.

Permissions:
- Reset Password
- Read and write Account Restrictions
- Validated write to DNS host name
- Validated write to service principal name

I did the delegation via the dsa.msc from a Windows Server 2012.

In the first case I delegated the permissions on the "Computers" container and tried a typical join with a Windows7 Client via the Computer-Settings and the user.

The second case I created a new OU, delegated the same permissions on the new OU for the user and joined the Windows7 into the special OU.

There were no problems in both cases.

Björn
Comment 32 Björn Baumbach 2013-01-29 12:52:05 UTC
(In reply to comment #31)
> I tried to delegate the following permissions to a new user in a newly
> provisioned AD. 

I followed the guide mentioned in the bug description.
Comment 33 Marc Muehlfeld 2013-01-29 13:47:21 UTC
Created attachment 8516 [details]
Screenshot before/after samba-tool dbcheck --fix and samba_upgradeprovision

After your last post I reset my 1:1 copy from production to see what could be the problem and I found it:

Currently we are running 4.0.1 and all databases are on that version. Then I upgraded via 'make install' to the master version from yesterday (4.1.0pre1-GIT-bb3238b).

If I start now samba without running dbcheck and samba_upgradeprovision, I see in the ADUC console, that my group, I have delegated (ComputerToDomainAdmins) to, is still there. Remember: we are already on 4.1.0pre1-GIT-bb3238b.

Then I shutdown samba, run 'samba-tool dbcheck --fix' (and answer with 'all') and then 'samba_upgradeprovision'. Now I start samba again.

If I look now in ADUC again, then I see, that my delegation is gone. That of course explains, why I get the permission denied error on W7 (XP I haven't tried any more). :-) I attached a screenshot of both.

So one or both of the commands reset all ACLs back to defaults. Is this an expected feature? If yes, it should be marked in the changelog.


Then I delegated again the permission as written in the linked tutorial to my group. Now delegation works again.
Comment 34 Björn Baumbach 2013-01-29 14:11:09 UTC
I was asked for the command, that I used to join to a specific OU:

netdom join WIN7ClientName /d:my.domain /OU:OU=specialou,DC=my,DC=domain /ud:user4delegation /pd:Passw0rd
Comment 35 Marc Muehlfeld 2013-01-29 14:16:02 UTC
We are joining only to the Computer container by using the GUI.
Comment 36 Stefan Metzmacher 2013-01-29 14:26:31 UTC
(In reply to comment #33)
> Created attachment 8516 [details]
> Screenshot before/after samba-tool dbcheck --fix and samba_upgradeprovision
> 
> After your last post I reset my 1:1 copy from production to see what could be
> the problem and I found it:
> 
> Currently we are running 4.0.1 and all databases are on that version. Then I
> upgraded via 'make install' to the master version from yesterday
> (4.1.0pre1-GIT-bb3238b).
> 
> If I start now samba without running dbcheck and samba_upgradeprovision, I see
> in the ADUC console, that my group, I have delegated (ComputerToDomainAdmins)
> to, is still there. Remember: we are already on 4.1.0pre1-GIT-bb3238b.
> 
> Then I shutdown samba, run 'samba-tool dbcheck --fix' (and answer with 'all')
> and then 'samba_upgradeprovision'. Now I start samba again.
> 
> If I look now in ADUC again, then I see, that my delegation is gone. That of
> course explains, why I get the permission denied error on W7 (XP I haven't
> tried any more). :-) I attached a screenshot of both.
> 
> So one or both of the commands reset all ACLs back to defaults. Is this an
> expected feature? If yes, it should be marked in the changelog.
> 
> 
> Then I delegated again the permission as written in the linked tutorial to my
> group. Now delegation works again.

Ah, ok, many thanks for debugging this!

samba_upgradeprovision resets the nTSecurityDescriptor on some wellknown
objects incl. "CN=Users", "CN=Computers" and "OU=Domain Controllers".

To my knowledge this should only happen if the nTSecurityDescriptor value
has still a value which was generated by the initial provision.

Matthieu, do you have an idea why this dns endup in the 'dnToRecalculate'
dict?

Marc, could you retest this, by using just dbcheck?
Comment 37 Marc Muehlfeld 2013-01-29 15:26:52 UTC
Created attachment 8517 [details]
Error Screenshot after dbcheck only

Just for information: I migrated our samba 3.5.something domain to samba AD with s4beta8. And since that we updated always to all new rc/versions.




# samba-tool dbcheck --fix
Checking 913 objects
Fix nTSecurityDescriptor on CN=kfast,CN=Users,DC=muc,DC=medizinische-genetik,DC=de? [y/N/all/none] all
Fixed attribute 'nTSecurityDescriptor' of 'CN=kfast,CN=Users,DC=muc,DC=medizinische-genetik,DC=de'
...
...
...
Checked 913 objects (227 errors)



Then I start samba. The delegated group is still on the Computer container. When I try to join a Win7 machine now, I get an error "wrong parameter"



Just for re-checking: Then I run 'samba_upgradeprovision':

# samba_upgradeprovision
Creating a reference provision
No IPv6 address will be assigned
Copy privilege
Update base samdb by searching difference with reference one
Update of secrets.ldb
Update machine account
Fixing very old provision SD
Upgrade finished!
Reopening samdb to trigger reindexing if needed after modification



And then I start samba again: The delegated group was removed from the security tab and I can join only as domain admin again.

But now when I try to join as a member of the group (which isn't there any more), I get "Ein an das System angeschlossenes Gerät funktioniert nicht mehr". Last time it was "access denied"?!
Comment 38 Stefan Metzmacher 2013-02-01 16:47:17 UTC
Created attachment 8525 [details]
samba_upgradeprovision test patch

Marc can you check if this patch matches your desired behavior,
that the modified nTSecurityDescriptor doesn't get replaced.
Comment 39 Andrew Bartlett 2013-02-01 21:07:47 UTC
(In reply to comment #38)
> Created attachment 8525 [details]
> samba_upgradeprovision test patch
> 
> Marc can you check if this patch matches your desired behavior,
> that the modified nTSecurityDescriptor doesn't get replaced.

With this we might need to make sure we recommend samba_upgradeprovision before dbcheck.  Ideally (clearly not for 4.0.3 at this point) we need to get dbcheck to offer upgradeprovision first if we detect we need it.
Comment 40 Marc Muehlfeld 2013-02-03 16:06:26 UTC
I'm sorry to say, but the patch, doesn't help.

I applied it to my test environment (4.1.0pre1-GIT-bb3238b). The databases I used, where a copy from my 4.0.1 live environment, which haven't been touched by a newer version yet). Then I run:

# samba_upgradeprovision
Creating a reference provision
No IPv6 address will be assigned
Copy privilege
Update base samdb by searching difference with reference one
Update of secrets.ldb
Update machine account
Fixing very old provision SD
Upgrade finished!
Reopening samdb to trigger reindexing if needed after modification
Reindexing finished


and after that:

# samba-tool dbcheck --fix
Checking 913 objects
Checked 913 objects (0 errors)


But the group I have delegated to, was already removed out of the security tab of ADUC after I had run samba_upgradeprovision.
Comment 41 Marc Muehlfeld 2013-02-11 19:32:31 UTC
I wanted to ask: If I re-setup the delegation by hand, can I then simply update to 4.0.3?

Is it required to run samba_upgradeprovision and/or samba-tool dbcheck at all when upgrading from 4.0.2? I haven't seen anything about this two commands in the WHATSNEW.txt of 4.0.3, when upgrading.

Or should 4.0.2 users currently not upgrade?
Comment 42 Andrew Bartlett 2013-02-16 11:30:46 UTC
My investigations show that samba_upgradeprovision totally rewrote the SDs for all the well known DNs, due to an incorrect regex that only considered samba alpha versions.  The betas and releases were treated as pre alpha9.

That would explain your modified SD being wiped. 

I expect to make some progress on this soon.
Comment 43 Andrew Bartlett 2013-02-16 23:55:08 UTC
Created attachment 8562 [details]
upgradeprovision patch to avoid auto-detection of 'alpha' releases

Can you please try running, with this patch applied

samba_upgradeprovision --full
samba-tool dbcheck --cross-ncs --fix --yes

This should fix the security descriptors, yet preserve the changes you have made.

Verifying this will greatly assist us in confirming this patch is correct, or understanding how much work remains. 

Thanks,
Comment 44 Marc Muehlfeld 2013-02-17 10:15:11 UTC
To which samba version I can apply the patch? I tried it with 4.0.2:

# patch -p 1 < andrew.patch
patching file source4/scripting/bin/samba_upgradeprovision
Hunk #1 succeeded at 178 (offset -12 lines).
Hunk #2 FAILED at 1828.
Hunk #3 FAILED at 1927.
2 out of 3 hunks FAILED -- saving rejects to file source4/scripting/bin/samba_upgradeprovision.rej

and 4.0.3 sources:
# patch -p 1 < andrew.patch
patching file source4/scripting/bin/samba_upgradeprovision
Hunk #1 succeeded at 196 (offset 6 lines).
Hunk #2 FAILED at 1828.
Hunk #3 FAILED at 1927.
2 out of 3 hunks FAILED -- saving rejects to file source4/scripting/bin/samba_upgradeprovision.rej
Comment 45 Andrew Bartlett 2013-02-17 10:57:32 UTC
(In reply to comment #44)
> To which samba version I can apply the patch? I tried it with 4.0.2:
> 
> # patch -p 1 < andrew.patch
> patching file source4/scripting/bin/samba_upgradeprovision
> Hunk #1 succeeded at 178 (offset -12 lines).
> Hunk #2 FAILED at 1828.
> Hunk #3 FAILED at 1927.
> 2 out of 3 hunks FAILED -- saving rejects to file
> source4/scripting/bin/samba_upgradeprovision.rej
> 
> and 4.0.3 sources:
> # patch -p 1 < andrew.patch
> patching file source4/scripting/bin/samba_upgradeprovision
> Hunk #1 succeeded at 196 (offset 6 lines).
> Hunk #2 FAILED at 1828.
> Hunk #3 FAILED at 1927.
> 2 out of 3 hunks FAILED -- saving rejects to file
> source4/scripting/bin/samba_upgradeprovision.rej

The patch is against my upgradeprovision branch, and might apply against master.  This is still a work in progress, but I wanted to share what I found in case it was practical to test.
Comment 46 Andrew Bartlett 2013-02-17 12:12:50 UTC
So, I agree attaching a patch against a random branch wasn't particularly helpful.

If you can try a git branch, then you can try the 'upgradeprovision' branch in git://git.samba.org/abartlet/samba.git

eg

git clone git://git.samba.org/samba.git
git remote add abartlet git://git.samba.org/abartlet/samba.git
git fetch abartlet
git checkout abartlet/upgradeprovision -b upgradeprovision

That patch is included in this branch.

Thanks,
Comment 47 Marc Muehlfeld 2013-02-17 15:42:27 UTC
(In reply to comment #46)
> git clone git://git.samba.org/samba.git
> git remote add abartlet git://git.samba.org/abartlet/samba.git
> git fetch abartlet
> git checkout abartlet/upgradeprovision -b upgradeprovision



# samba_upgradeprovision --full
Creating a reference provision
No IPv6 address will be assigned
Update base samdb by searching difference with reference one
Starting update of samdb
There are 2 missing objects
Reloading a merged schema, which might trigger reindexing so please be patient
Schema reloaded!
There are 0 changed objects
Update of samdb finished
Update of secrets.ldb
Update machine account
Some (default) security descriptors (SDs) have changed, recalculating them
Upgrade finished!
Reopening samdb to trigger reindexing if needed after modification
Reindexing finished



# samba-tool dbcheck --cross-ncs --fix --yes
Checking 4157 objects
ERROR: incorrect GUID component for objectCategory in object CN=6961d884-ae1a-4966-9c81-c1d38a00a0b5,CN=Partitions,CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de - <GUID=f7a3f0e4-f11b-44fb-8378-4288c3cac010>;CN=Cross-Ref,CN=Schema,CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de
Change DN to <GUID=cdd9be2b-c04d-4c8d-ab4f-cb39ba91fc99>;CN=Cross-Ref,CN=Schema,CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de? [YES]
Fixed incorrect GUID on attribute objectCategory
ERROR: incorrect GUID component for objectCategory in object CN=d9b3b4bb-b1ee-42a5-b2d8-cc34698c939f,CN=Partitions,CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de - <GUID=f7a3f0e4-f11b-44fb-8378-4288c3cac010>;CN=Cross-Ref,CN=Schema,CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de
Change DN to <GUID=cdd9be2b-c04d-4c8d-ab4f-cb39ba91fc99>;CN=Cross-Ref,CN=Schema,CN=Configuration,DC=muc,DC=medizinische-genetik,DC=de? [YES]
Fixed incorrect GUID on attribute objectCategory
Fix nTSecurityDescriptor on CN=NTDS Quotas,DC=DomainDnsZones,DC=muc,DC=medizinische-genetik,DC=de? [YES]
Fixed attribute 'nTSecurityDescriptor' of 'CN=NTDS Quotas,DC=DomainDnsZones,DC=muc,DC=medizinische-genetik,DC=de'

Fix nTSecurityDescriptor on CN=NTDS Quotas,DC=ForestDnsZones,DC=muc,DC=medizinische-genetik,DC=de? [YES]
Fixed attribute 'nTSecurityDescriptor' of 'CN=NTDS Quotas,DC=ForestDnsZones,DC=muc,DC=medizinische-genetik,DC=de'

Checked 4157 objects (4 errors)





But after I had started samba again, the ou=Computer container had again (I guess) default security entries. The group I had delegated to, at least, was gone again.



Then I reset my test environment back again to 4.0.2: Everything was fine again (group was back). Then I "make install" your branch again and run only "samba_upgradeprovision --full". After that I started samba (without running the "samba-tool dbcheck"). But ADUC won't let me in (wrong username/password). But after I had rebooted my VM, I could logon and open ADUC again. But there was already the additional group on ou=Computers gone.


Let me know if I can provide you further debugging information/logs/etc.
Comment 48 Andrew Bartlett 2013-02-17 22:36:55 UTC
Thank you for your patience.  As you would have noticed, I'm still trying to get to grips with the full implications of this powerful tool (samba_upgradeprovision).

dbcheck will not, on it's own, alter your ACLs (it only fixes up incorrect inheritance, by re-running our inheritance algorithms).   

I will continue working on this.  Even if in the end we do not recommend this tool, we need to make it less destructive, particularly in it's default mode of operation.
Comment 49 Marc Muehlfeld 2013-02-18 08:59:53 UTC
Currently I have no need to update. 4.0.2 works fine here and I see no issues. So for me it's OK to wait a bit longer.

Thanks for working on this so hard.
Comment 50 Stefan Metzmacher 2013-04-09 08:04:52 UTC
samba-tool dbcheck --reset-well-known-acls
from bug #9740 is the proposed fix for the problem with
provisions from versions < 4.0.3.

samba_upgradeprovision should not be used!
Comment 51 Marc Muehlfeld 2013-04-11 19:51:03 UTC
Just wanted to give feedback:
I updated from 4.0.4 to 4.0.5 and run
# samba-tool dbcheck --reset-well-known-acls
I let fix all. But I had to run the command twice to get all fixed (Andrew told me on IRC that I should open a new bug about that, what I've done). After that my delegation was gone. But after I re-created it, everything worked fine (join as member of a group I delegated to the CN=computer container).

So everything is working here.

Many thanks for the good work and fixing this.