When machine joins samba4 domain its PrimaryGroupID is set to S-1-5-21domain-513 (Domain Users) instead of S-1-5-21domain-515 (Domain Computers).
Well, it is normal that a vanilla computer account (object derived from objectclass "computer") has per default 513 (Domain Users) as primaryGroupID. But the primary group should change to 515 (Domain Computers) when a join has been performed.
Well, I retried to join a machine to s4 (my Win2000 box) and it just worked (it got 515 as primary group id). So please explain: how do you join a machine? The creation of a computer object alone isn't a join (consider also comment #1). What is the operating system of the client?
the OS of the client is Windows 7 Professional (x64). The join is performed through MDT (Microsoft Deployment Toolkit) using visual basic script ZTIDomainJoin.wsf which calls JoinDomainOrWorkgroup function to join the domain. I specify MachineOU to add the account to a different than default place, but i have noticed this bug when the Computer account was created in default CN=Computers container (without using MachineOU). I have tried different domain join methods, i.e. using windows GUI wizard -> Computer Name -> Change and powershell's Add-Computer utility and running bin/ldbsearch -H /usr/local/samba/private/sam.ldb CN=ITLYYY primaryGroupID sfterwards gives me in both cases: # record 1 dn: CN=ITLYYY,OU=Domain Computers,DC=<mydomain> primaryGroupID: 513 I do get the following error in samba logs (i'm not sure if they are related): Failed to modify record CN=ITLYYY,OU=Domain Computers,DC=<mydomain> error in module acl: insufficient access rights (50) This happens after the join and restart
Okay. So your problem is due to an error in our ACL module. I assign this to our ACL module specialist Nadia. And I image it does only happen when you aren't the default administrator.
Thx :) I am performing a join as Domain Administrator (i.e. MYDOMNAME\Administrator) though
Really strange - since using the default domain administrator you should never run into such problems. Are your s4 version and the provision recent?
roughly week old. I will build one from GIT tomorrow, provision again from scratch and let you know the result
Hello Matthias, I'm encline to say me too. But unfortunately it's a bit more complicated. I have checked two provisions, in one all my workstation are in the Domain Computer group. In the other my XP workstation is in the Domain Computer group but windows 7 i386 is in the Domain User group.
Could this be Windows 7 thing? Anyways i will try to join XP wrkstation to the domain and see how that fares
Just to confirm, that on a new provision (using standard CN=Computers and Windows GUI to join) Windows XP SP3 x86 machines have the right PrimaryGroup of 515 assigned after the join. Again for Windows 7 its 513 - so it seems like its a Windows 7 specific problem
Ah, thanks - so it is Windows 7 specific. Reassigning to default assignee.
Ahh the plot thickens - using my old provision and joining XP machine (machine OU in different place) to it gives 513, but maybe the bug got fixed since that. On a clean provision XP join gets the correct group Windows 7 does not
I'm not so sure that's it's just a w7 bug only, there is high probability that's it's the same with windows 2008r2 (they share the same kernel). We don't know about Windows server 2003 as a domain member or about vista or Windows 2008. It can still be a ACLs problem. Lukaz, can you start a samba4 DC with debug level 10: <path_to_s4>/bin/samba -i -M single -d 10 >log and make a w7 join the domain (so if the workstation was already in the domain you have to make it leave + remove the computer object).
Matthieu, You are right the problem might extend to other OS'es but so far i have tested XP and Windows 7 only. I will post d10 log tomorrow. Would you like me to see how the join behaves when Server 2003 (R2), Vista, Server 2008 and Server 2008 R2 are joined to the domain?
Created attachment 5732 [details] Level 10 debug log file Matthieu, As requested attched is the log file
Well this didn't appear in the log that you send me. "I do get the following error in samba logs (i'm not sure if they are related): Failed to modify record CN=ITLYYY,OU=Domain Computers,DC=<mydomain> error in module acl: insufficient access rights (50) This happens after the join and restart" Also I see the the add request is : AddRequest dn: CN=ITLYYY,CN=Computers,DC=mytest,DC=samba4dom,DC=comAddRequest: dn: [CN=ITLYYY,CN=Computers,DC=mytest,DC=samba4dom,DC=com] ldb: start ldb transaction (nesting: 0) ldb: ldb_trace_request: (schema_load)->start_transaction ldb: ldb_trace_next_request: (repl_meta_data)->start_transaction ldb: ldb_trace_next_request: (partition)->start_transaction ldb: partition_start_trans() -> (metadata partition) ldb: ldb_trace_next_request: (tdb)->start_transaction ldb: ldb_trace_next_request: (tdb)->extended ldb: partition_start_trans() -> CN=Schema,CN=Configuration,DC=mytest,DC=samba4dom,DC=com ldb: ldb_trace_next_request: (tdb)->start_transaction ldb: partition_start_trans() -> CN=Configuration,DC=mytest,DC=samba4dom,DC=com ldb: ldb_trace_next_request: (tdb)->start_transaction ldb: partition_start_trans() -> DC=mytest,DC=samba4dom,DC=com ldb: ldb_trace_next_request: (tdb)->start_transaction ldb: start ldb transaction error: (null) ldb: ldb_trace_request: ADD dn: CN=ITLYYY,CN=Computers,DC=mytest,DC=samba4dom,DC=com changetype: add objectClass: Computer SamAccountName: ITLYYY$ userAccountControl: 4096 DnsHostName: ITLYYY.mytest.samba4dom.com ServicePrincipalName: HOST/ITLYYY.mytest.samba4dom.com ServicePrincipalName: RestrictedKrbHost/ITLYYY.mytest.samba4dom.com ServicePrincipalName: HOST/ITLYYY ServicePrincipalName: RestrictedKrbHost/ITLYYY unicodePwd:: IgAlAEoAOAA3AG0AYwBsAGIANwBRAF0APAB3ADwAOQBnAEwAbQAnAD0AOgAwAGQAP wA5ADAAeQArAHMAeABVAEkAQABaACoARQB2AEMAYwA0AE0APwBPAC0AcgBJAFMAJQBdAHEASgA0AC 0AMwBcAGoAeQBXAGoAeQAvAC8ASQAvAD0AegBDADoAKwAoAFAAUQBeAE4AXQAqAGAALgBHAFUASgA uAGAAbAApAHYAQgA3ACQAYABwAEwAdwBKAEAANwBzAFIATABsACIAOgBGAHYAXABYAFkANQB5ADMA VAAoAEkAXwA+AEgANAAqAHQARwAiAA== I didn't made the same trace with XP but maybe xp is providing the group. Lukaz, can you be kind enough to provide me the same trace but when joining a xp workstation ?
Created attachment 5733 [details] Another d10 log dump, this time including restart of the machine Attached the log file from another join of w7 - this time it includes restart and boot of it
Created attachment 5734 [details] d10 log dump of the xp machine joining the domain Attached is the log file of XP SP3 (x86) joining the domain - this includes the restart afterwards
abartlet, do you have an idea? I checked the logfiles but didn't notice anything special.
Logs are not exactly the same the xp log has already the object present so it is just "modified". In this situation analysis is more complicated !
I dig a little bit in the code. Normaly it's createuser2 which allow to set primary group id to 515 if the object is of the class computer. But also we have the function samldb_fill_object in samldb.c which set the primary object to 513 if the created object is from the class user (and computer are also of the object class user). I have the impression that w7 and xp are following different code path (that's pretty clear as in the log samldb_add is not called by xp) which result to w7 being concidered as a user mostly. As it was first said, we must do torture test that show this behavior. But to do so we have to understand how xp and w7 are creating users (for xp it seems to be samr for w7 that's still mistery).
Lukasz, could you retest this? I think this should have been fixed by me.
Hi Matthias, I have removed an existing account from ldb and re-joined the domain. Unfortunately the machines primary group is still Domain Users rather than Domain Computers :(
Matthias when did you commit this fix? Was it in the last couple of days?
I thought that the following two commits (http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=7f424155e62d04d23bb1c825ecd546eed18725e0, http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=1e52e72e409a3a5b52e4f75b985122ac94d8aa4a) could have been fixed it. They introduce the "userAccountControl" -> "primaryGroupID" mapping for newly created accounts. But it is also possible that Windows 7 makes use of this mechanism on already existing entries (through an "userAccountControl" change). Unfortunately there we don't support it yet. I will see if I can introduce it also there.
Matthias, My provision is older than that, and I'm currently having problems upgrading it. So it is possible that your patch fixes this issue ;) and as soon as I manage to upgrade i will confirm if that is the case.
Matthias, Just to confirm that with latest master this bug has been fixed (for me anyways). Now Windows 7 workstations when joining the domain seem to have right 515 primaryGroupID assigned to it.
Nice, thanks for your collaboration!