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.
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.
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.
Created attachment 8008 [details] Screenshot of the error on windows
Problem remain unchanged in rc2. Addional Information: Also if I grant 'Full Access' to the group on the 'computers' container, it doesn't work.
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>).
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).
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.
> (In reply to comment #5) > > ldbsearch -H ldap://<ip> -Uadministrator '(cn=computer)' ntsecuritydescriptor I had a typo it's cn=computerS > Find attached.
What is the SID of this group ?
Can you also do the search without the --show-binary ? Thanks.
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
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.
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 ?
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?
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
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.
(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 ?
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.
(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
rc6 fixes this problem. I could successfully delegate the "join computers to domain" permission to a non-admin now. Many thanks.
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.
If I can provide you some more debuggings from my working rc6 environment, let me know. But here it works fine now.
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.
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.
*** This bug has been marked as a duplicate of bug 8909 ***
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.
(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.
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).
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)
I reopened this bug report, because the problem is not fixed by the patch (see my last comments).
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
(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.
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.
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
We are joining only to the Computer container by using the GUI.
(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?
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"?!
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.
(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.
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.
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?
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.
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,
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
(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.
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,
(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.
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.
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.
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!
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.