With samba 3.5.11 it was possible for regular users (not Domain Admins) to join a DC if the SeMachineAccountPrivilege was granted to them: root@master:~# net rpc rights grant -U Administrator%password \ bob SeMachineAccountPrivilege root@master:~# net rpc join -U bob%password Joined domain TESTDOM. With samba 3.6.6 this does not work any more: root@master:~# net rpc join -U bob%password error setting trust account password: NT_STATUS_ACCESS_DENIED Unable to join domain TESTDOM.
Can you get me a debug level 10 log from the command please ? Jeremy.
Created attachment 7718 [details] level 10 logs
Ok, I'm looking into this - thanks for the logs. I have a theory, it's to do with mapping the max_desired_access not being done correctly when OpenUser is called as root... Still working on this. Jeremy.
Ok, my original theory was incorrect. I need more data here. The problem is that the client is requesting samr_OpenUser() on the existing user machine account with a required access mask of "max desired access". max desired access is being mapped to a desired access mask of 0x0002035b as we can see by this debug message in the log. se_map_generic(): mapped mask 0xa0000000 to 0x0002035b This leads to a call of the access_check_object() function, which should check if the user token attached to the open RPC pipe contains the SEC_PRIV_MACHINE_ACCOUNT privilege, and if so it should add in the additional GENERIC_RIGHTS_USER_WRITE set of access bits, which contains : const int GENERIC_RIGHTS_USER_WRITE = (STANDARD_RIGHTS_WRITE_ACCESS | SAMR_USER_ACCESS_CHANGE_PASSWORD | SAMR_USER_ACCESS_SET_LOC_COM | SAMR_USER_ACCESS_SET_ATTRIBUTES | SAMR_USER_ACCESS_SET_PASSWORD | SAMR_USER_ACCESS_CHANGE_GROUP_MEMBERSHIP); /* 0x000204e4 */ The required bit here is SAMR_USER_ACCESS_SET_PASSWORD, 0x80, which is the bit that the operation is being failed on. Now if access_check_object() adds in these extra access mask bits due to the user having the SEC_PRIV_MACHINE_ACCOUNT privilege, we should see the following debug message in the log: DEBUG(4,("access_check_object: user rights access mask [0x%x]\n", rights_mask)); We don't see this message, which means that the following code inside access_check_object() isn't finding that the user has the privilege: /* check privileges; certain SAM access bits should be overridden by privileges (mostly having to do with creating/modifying/deleting users and groups) */ if ((needed_priv_1 != SEC_PRIV_INVALID && security_token_has_privilege(token, needed_priv_1)) || (needed_priv_2 != SEC_PRIV_INVALID && security_token_has_privilege(token, needed_priv_2))) { priv_granted = true; saved_mask = (des_access & rights_mask); des_access &= ~saved_mask; DEBUG(4,("access_check_object: user rights access mask [0x%x]\n", rights_mask)); } which basically means the user doesn't have the SEC_PRIV_MACHINE_ACCOUNT privilege, or at least Samba doesn't think so..
Created attachment 7740 [details] Test that will give me more info. Arvid, can you apply this patch and then re-run the net join command with debug level 10 log. This should show me what is wrong with the security token attached to the pipe struct (and maybe give me a clue as to why is doesn't have the SEC_PRIV_MACHINE_ACCOUNT privilege needed to make this work. Thanks ! Jeremy.
I had to adjust the patch to get some output: acb_info does not have ACB_WSTRUST set but (ACB_SVRTRUST|ACB_DOMTRUST) instead, so I added your debug code in that code block as well. This is the output: =============================================================================[2011/12/17 07:38:35.417242, 10] rpc_server/samr/srv_samr_nt.c:2255(_samr_OpenUser) _samr_OpenUser: srvtrust/domtrust account open. user security token : [2011/12/17 07:38:35.417277, 10] ../libcli/security/security_token.c:63(security_token_debug) Security token SIDs (9): SID[ 0]: S-1-5-21-861941570-1634457251-3974523304-5010 SID[ 1]: S-1-5-21-861941570-1634457251-3974523304-513 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 SID[ 5]: S-1-22-1-2005 SID[ 6]: S-1-22-2-5001 SID[ 7]: S-1-22-2-5022 SID[ 8]: S-1-22-2-5020 Privileges (0x 10): Privilege[ 0]: SeMachineAccountPrivilege Rights (0x 0): [2011/12/17 07:38:35.417489, 4] rpc_server/srv_access_check.c:104(access_check_object) _samr_OpenUser: access GRANTED (requested: 0x0002035b, granted: 0x0002035b) ============================================================================= RID 5010 is the user. 2005 is the posix uid of the user, 5001 the posix gid assigned to the primary group, 5022 ist the posix gid assigned to "Everyone", and 5020 is the gid of "Authenticated Users" (all in passdb ldap). In case it matters: The user has sambaAcctFlags: [U ] and the machine account has sambaAcctFlags: [S ]. Maybe it's important to note that I did this test on the PDC, where the following settings control the smb.conf: ; domain security = user domain logons = yes domain master = yes preferred master = yes local master = yes In case you think I'm barking at the wrong tree, I may test this on a BDC or member if it helps.
Jeremy, Feel free to ping me on this if you want any assistance/review.
OK ! Progress. This : "I had to adjust the patch to get some output: acb_info does not have ACB_WSTRUST set but (ACB_SVRTRUST|ACB_DOMTRUST) instead" tells me a lot ! You're trying to add a client machine into the domain as a domain member, not as a domain trust - correct ? So the issue is that the abc_info is incorrect - it's already set to a trust account, not a workstation account. In the log you sent this machine account already exists - and isn't a workstation account. Modifying trust accounts is restricted to members of Domain Admins, not regular users with SeMachineAccountPrivilege. So Samba seems to be doing the right thing here. The token attached to the user connected to the SAMR pipe is perfectly correct, it has the SeMachineAccountPrivilege (which was what I was wondering about). It's the account type you're trying to modify that is incorrect. When did this machine account get created ? How did it get created ? On the DC can you try removing this machine account before trying the domain join again from the client with that machine account name ? Jeremy.
> You're trying to add a client machine into the domain as a domain member, > not as a domain trust - correct ? Yes, my test case was trying to (re-)join a DC with "net rpc join". > So the issue is that the abc_info is incorrect - it's already set to a trust > account, not a workstation account. In the log you sent this machine account > already exists - and isn't a workstation account. > > Modifying trust accounts is restricted to members of Domain Admins, not > regular users with SeMachineAccountPrivilege. So Samba seems to be doing the > right thing here. > > The token attached to the user connected to the SAMR pipe is perfectly > correct, it has the SeMachineAccountPrivilege (which was what I was wondering > about). It's the account type you're trying to modify that is incorrect. Ok, fine, I understand, I checked it, it works for Memberservers, regardless if the accounts exist or not. The change in behaviour I referred to here is, that it does not work any longer for DCs (neither initial nor re-join). As I understand your explanation, this is expected behaviour, and for my case that's currently enough.
Ok, thanks. Yes - the code is explicitly configured to only allow Domain Admins to modify DC and trust accounts, and I think that's what is intended. Closing this one as INVALID. Thanks ! Jeremy.