samba - Oct 2004 - Samba 3.0.7 & adding machines. Wrong primary group.

Hi!

Some time ago (samba 3.0.1?) I added machines to my domain with 
'srvmrg.exe' and all went as I expect. IIRC.

If I am now adding machines, all machine-accounts have the initially group 
"users" set instead of "machines". But they should't.

| add machine script = useradd -d /dev/null -g machines -s /bin/false %u

This is, because even if adding machines to the Domain the "set primary 
group script" is called. But there is (or I see) no need for that.
Just when adding users to the Domain, this script is needed.

So, is this a "Bug" or a "Feature"?
Should I write a Bug-Report?

TIA.
-- 
    <) .--.
    )#=+  '
   /## |     .+.					Best regards, 
,,/###,|,,,,,,|,,,,					Michael

"set primary group script" is called either on client (Windows?)
request
or when SID of the primary group does not correspond to the primary 
group of the user account. The first one has nothing to do with Samba - 
it just responds to request. The second one can be caused either by 
change to the group mapping of this primary group or by some kind of bug 
in Samba. To know if it's really a bug you should provide smbd log with 
"log level = 5" from the moment computer is added to the domain till
the
moment "set primary group script" is called.

Igor

Michael Liebl wrote:
> Hi!
> 
> Some time ago (samba 3.0.1?) I added machines to my domain with 
> 'srvmrg.exe' and all went as I expect. IIRC.
> 
> If I am now adding machines, all machine-accounts have the initially group 
> "users" set instead of "machines". But they
should't.
> 
> | add machine script = useradd -d /dev/null -g machines -s /bin/false %u
> 
> This is, because even if adding machines to the Domain the "set
primary
> group script" is called. But there is (or I see) no need for that.
> Just when adding users to the Domain, this script is needed.
> 
> So, is this a "Bug" or a "Feature"?
> Should I write a Bug-Report?
> 
> TIA.

Michael Liebl wrote:
>A machine account has not to be in a primary Samba group I think. That
>would not make any sense to me.
>
>I saw in the log that Samba grep'd the primary Samba group for the
>machine$ (Domain Users) an then called "set primary group script".
>
>Should I add the Log to the List or directly to you?
>  
>
Feel free to send logs directly to me. I'll do my best looking through 
them and if I'm unsuccessful, I'll post summary of my findings as a 
reply so that anyone with better insight has easier time getting to the 
root of the problem.

Igor

Michael Liebl wrote:
> Domainname: MITTELERDE
>
>PDC:        ISENGART
>
>Machinename I added: TESTMACHINE
>
>My Command:
>add machine script = /usr/sbin/useradd -c Samba-Computer -d /dev/null  -g
machines -s /bin/false %u
>
>If I change 'set primary group script' to "/bin/true" the
machine will
>stay in Group machines, so the command works.
>
>After adding the machine, it has the primary unix group "domusr".
>
>Domain Users (S-1-5-21-1418210569-3342691074-3409555407-513) -> domusr
>
>Using:      Debian/unstable x86 Linux 2.6.5
>Samba:      Version 3.0.7-Debian
>            (Also I checked with FC2)
>
>If you need more info, please let me know.
>  
>
Interesting case... The request comes from Windows to update machine 
account with a bunch of new values and in this request RID of the 
primary group for the account (group_rid) is listed as 513 (0x201).

If you look at the 'fields_present' in the request you will notice that 
it requests almost all information to be updated - 09f827fa (this is a 
bitwise mask of fields to be updated). When I add a computer in my 
domain I have it only '00c4 fields_present : 01100002'. Note, that on 
the other hand I have similar set of data updates when I create normal 
user with usrmgr.exe: "00c4 fields_present : 08f827fa".

So, I suspect the problem is somewhere on Windows side. I haven't found 
any Domain Policy requiring all accounts to be in "Domain Users" group
which is the only thing which comes to my mind as a probably cause for 
the problem.

I hope somebody having more experience with different Domain/Windows 
configurations can help in this case.

Bellow is the relavent extracts from the (log level = 5) smbd log:

Igor

[2004/10/11 09:06:31, 3] rpc_server/srv_samr_nt.c:_samr_create_user(2245)
  _samr_create_user: Running the command `/usr/sbin/useradd -c 
Samba-Computer -d /dev/null  -g machines -G samba -s /bin/false 
testmachine$' gave 0
[2004/10/11 09:06:31, 5] lib/username.c:Get_Pwnam(293)
  Finding user testmachine$
..........
[2004/10/11 09:06:31, 5] passdb/pdb_tdb.c:tdb_update_sam(631)
  Storing (new) account testmachine$ with RID 5024
..........
[2004/10/11 09:06:31, 4] rpc_server/srv_pipe.c:api_rpcTNP(1534)
  api_rpcTNP: samr op 0x3a - api_rpcTNP: rpc command: SAMR_SET_USERINFO
..........
[2004/10/11 09:06:31, 5] rpc_parse/parse_prs.c:prs_uint32(635)
              00b8 user_rid      : 00000000
[2004/10/11 09:06:31, 5] rpc_parse/parse_prs.c:prs_uint32(635)
              00bc group_rid     : 00000201
[2004/10/11 09:06:31, 5] rpc_parse/parse_prs.c:prs_uint32(635)
              00c0 acb_info      : 00000080
[2004/10/11 09:06:31, 5] rpc_parse/parse_prs.c:prs_uint32(635)
              00c4 fields_present : 09f827fa
..........
[2004/10/11 09:06:31, 5] rpc_server/srv_samr_nt.c:_samr_set_userinfo(2977)
  _samr_set_userinfo: 
sid:S-1-5-21-1418210569-3342691074-3409555407-5024, level:23
[2004/10/11 09:06:31, 5] rpc_server/srv_samr_nt.c:set_user_info_23(2830)
  Attempting administrator password change (level 23) for user testmachine$
[2004/10/11 09:06:31, 5] rpc_server/srv_samr_nt.c:set_user_info_23(2850)
  Changing trust account or non-unix-user password, not updating /etc/passwd
[2004/10/11 09:06:31, 3] passdb/lookup_sid.c:fetch_gid_from_cache(247)
  fetch uid from cache 6000 -> S-1-5-21-1418210569-3342691074-3409555407-513
[2004/10/11 09:06:31, 3] groupdb/mapping.c:smb_set_primary_group(1189)
  smb_set_primary_group: Running the command `/usr/sbin/usermod -g 
domusr testmachine$' gave 0
[2004/10/11 09:06:31, 5] passdb/pdb_tdb.c:tdb_update_sam(631)
  Storing account testmachine$ with RID 5024