Samba 3.0.32: GID leak in winbind caused by repeated winbind_allocate_gid() call for BUILTIN\Administrators creation in smbd

[Tim Prouty]

On Nov 6, 2008, at 8:52 AM, Volodymyr Khomenko wrote:

>> From one side, sid_to_gid() fails to find Builtin_Administrators  
>> group in winbind, so it tries to create it.
> Thus create_builtin_administrators()->pdb_create_builtin_alias()- 
> >winbind_allocate_gid() allocates new GID.
>> From other side, winbind don't suppose to create mappings for own  
>> domain - see idmap_can_map()
> (Builtin_Administrators = S-1-5-32-544 belongs to it), so sid_to_gid  
> will always fail:

I think I understand what you're saying, but to clarify, you're seeing  
the following series of events:

1) sid_to_gid(BUILTIN\Administrators) is failing to find find a gid.   
No new gid has been allocated at this point.

2) create_builtin_administrators calls pdb_create_builtin_alias, which  
calls winbindd_allocate_gid to allocate a new gid.  This returns  
successfully.

3) Next, pdb_add_group_mapping_entry is called.  This should add a new  
mapping from BUILTIN\Administrators to the gid that was just  
allocated.  This mapping is added to group_mapping.tdb.

4) Another user then attempts to login and create_local_nt_token is  
called again, but sid_to_gid isn't recognizing that there is now a  
mapping in group_mapping.tdb.

Is this correct?  If it is, it sounds like something at step 4 is  
going wrong.  You should be able to check to see if the mapping was  
successfully created by running "net groupmap list" or "net sam list  
builtin" after pdb_add_group_mapping_entry.  sid_to_gid should see the  
mapping in group_mapping.tdb, and return true when the second user  
logs in.

It's my understanding that Exanet has a clustered architecture, so you  
should make sure that group_mapping.tdb is accessible from all nodes.

-Tim