Bug 7441 - Windows 7: join operation doesn't change primary group id to 515 (domain computers)
Windows 7: join operation doesn't change primary group id to 515 (domain comp...
Product: Samba 4.0
Classification: Unclassified
All Windows 7
: P3 normal
: ---
Assigned To: Andrew Bartlett
Depends on:
  Show dependency treegraph
Reported: 2010-05-19 11:42 UTC by Lukasz Zalewski
Modified: 2010-09-15 10:24 UTC (History)
1 user (show)

See Also:

Level 10 debug log file (152.11 KB, application/x-gzip)
2010-05-24 04:38 UTC, Lukasz Zalewski
no flags Details
Another d10 log dump, this time including restart of the machine (252.76 KB, application/x-gzip)
2010-05-24 06:00 UTC, Lukasz Zalewski
no flags Details
d10 log dump of the xp machine joining the domain (238.11 KB, application/x-gzip)
2010-05-24 06:35 UTC, Lukasz Zalewski
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukasz Zalewski 2010-05-19 11:42:27 UTC
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).
Comment 1 Matthias Dieter Wallnöfer 2010-05-20 03:30:25 UTC
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.
Comment 2 Matthias Dieter Wallnöfer 2010-05-20 03:41:15 UTC
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?
Comment 3 Lukasz Zalewski 2010-05-20 04:19:29 UTC
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
Comment 4 Matthias Dieter Wallnöfer 2010-05-20 04:23:59 UTC
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.
Comment 5 Lukasz Zalewski 2010-05-20 04:27:30 UTC
Thx :)
I am performing a join as Domain Administrator (i.e. MYDOMNAME\Administrator) though
Comment 6 Matthias Dieter Wallnöfer 2010-05-20 15:52:43 UTC
Really strange - since using the default domain administrator you should never run into such problems. Are your s4 version and the provision recent?
Comment 7 Lukasz Zalewski 2010-05-20 16:23:36 UTC
roughly week old. I will build one from GIT tomorrow, provision again from scratch and let you know the result
Comment 8 Matthieu Patou 2010-05-21 04:47:38 UTC
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.
Comment 9 Lukasz Zalewski 2010-05-21 05:04:38 UTC
Could this be Windows 7 thing? Anyways i will try to join XP wrkstation to the domain and see how that fares
Comment 10 Lukasz Zalewski 2010-05-21 09:42:59 UTC
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
Comment 11 Matthias Dieter Wallnöfer 2010-05-21 10:40:55 UTC
Ah, thanks - so it is Windows 7 specific. Reassigning to default assignee.
Comment 12 Lukasz Zalewski 2010-05-21 10:42:57 UTC
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
Comment 13 Matthieu Patou 2010-05-21 23:54:39 UTC
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).
Comment 14 Lukasz Zalewski 2010-05-23 06:59:48 UTC
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?
Comment 15 Lukasz Zalewski 2010-05-24 04:38:51 UTC
Created attachment 5732 [details]
Level 10 debug log file

As requested attched is the log file
Comment 16 Matthieu Patou 2010-05-24 05:22:20 UTC
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

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 ?
Comment 17 Lukasz Zalewski 2010-05-24 06:00:25 UTC
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
Comment 18 Lukasz Zalewski 2010-05-24 06:35:17 UTC
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
Comment 19 Matthias Dieter Wallnöfer 2010-05-31 05:11:08 UTC
abartlet, do you have an idea? I checked the logfiles but didn't notice anything special.
Comment 20 Matthieu Patou 2010-05-31 06:02:41 UTC
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 !
Comment 21 Matthieu Patou 2010-05-31 07:20:00 UTC
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).
Comment 22 Matthias Dieter Wallnöfer 2010-09-14 11:34:01 UTC
Lukasz, could you retest this? I think this should have been fixed by me.
Comment 23 Lukasz Zalewski 2010-09-14 11:47:06 UTC
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 :(
Comment 24 Lukasz Zalewski 2010-09-14 12:04:56 UTC
Matthias when did you commit this fix? Was it in the last couple of days?
Comment 25 Matthias Dieter Wallnöfer 2010-09-14 16:03:17 UTC
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.
Comment 26 Lukasz Zalewski 2010-09-14 16:07:44 UTC
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.
Comment 27 Lukasz Zalewski 2010-09-15 09:18:05 UTC
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.
Comment 28 Matthias Dieter Wallnöfer 2010-09-15 10:24:31 UTC
Nice, thanks for your collaboration!