[Samba] winbind and group permissions

[Gaiseric Vandal]

In my environment, I also support NFS services so keeping uid/gid's consistent between machines for both unix/nfs and samba/winbind users is key.   If a windows user "jsmith" connected to a samba server, unix permissions for "jsmith" were enforced  appropriately (samba would match up the name), and I could manage permissions with unix tools.  However, if I tried settings permissions via windows, samba would try to set permissions for the "Windows" jsmith you would have a UID from the winbind range and not the "correct" unix uid.    Windows jsmith and unix jsmith were not treated as the same user.  Obviously not an issue for you.


Initially my samba PDC was 3.0.x   I used winbind to support domain trust with a Windows 2003 PDC-based domain.    I eventually switched to an LDAP backend for winbind to keep allocations consistent across all samba servers (DC's and member servers.)   Even with LDAP backend, there is some local caching in TBD files.   And tdbdump is a useful tool to diagnose the process.  What I found was that "wbinfo -u" and "wbinfo -g" would work, and when I ran "getent passwd" and "getent group" both the idmap table (in ldap in my case, prob winbind_idmap tdb file in your case) would get populated and a local idmap cache file would also get populated.   However, this seemd to be a one time thing.  Once the cache timeout expired, the local cache would not be repopulated.  I would have to delete the idmap entries in ldap and the appropriate tdb files.

When I upgraded to samba 3.4.x, the cache timeout issue went away.  However, what I found was that NEW idmap entries would not be created.   Since user list in the trusted domain almost never changes this didn't really matter-  if I added an account in the trusted domain I could manually use my ldap editor to add the corresponding idmap entry in ldap.   (A lot easier than editing and TBD file.) 

If you look at the man page for wbinfo, you will see there is an option to allocate uid's and gid's, and to manually set a uid-to-sid or gid-to-sid mapping.     You may want to manually try creating a gid-to-sid mapping for one group and seeing if that group shows up in "getent group."  It is not really a solution but it may provide some additional insight.




-----Original Message-----
From: Bob Miller [mailto:bob at computerisms.ca] 
Sent: Monday, January 03, 2011 10:51 PM
To: gaiseric.vandal at gmail.com
Cc: samba at lists.samba.org
Subject: Re: [Samba] winbind and group permissions

Gaiseric,
thank you sooo much for the reply....
I will make comments inline:

On Mon, 2011-01-03 at 20:06 -0500, Gaiseric Vandal wrote:
> Winbind is used for allowing unix things like file system access, getent
> passwd and getent group to handle windows users (windows users and groups
> get unix uid's and gid's allocated.)

To say this another way; getent maps users/groups and their respective
uids/gids/sids, winbind is what determines if those uids/gids have
permission to do what is being requested?

>     I don't use winbind to login to a
> unix system as a windows user but I do use it to allow the unix file system
> on a samba server to handle file perms for windows users.  Winbind would
> have nothing to do with subnet issues.

So wbinfo commands are not affected by working across a vpn...

> WINS (Windows Internet Naming Service, or something like that) is really
> useful for having a windows client (e.g. an  XP machine) find a Windows
> server (a Samba server or a real Windows server)-   this is really useful
> when subnet issues are involved, and actually a WINS server should be a
> standard item even on a local network.

Understood and agreed, I always enable wins server even on the simplest
samba installs.

>     Depending on your VPN, your
> "remote" client may have a virtual NIC on the "office" LAN.   

The VPN is an openswan site-to-site tunnel.  I have just spent the last
hour or two checking, double-checking, re-double-checking,
triple-checking, and re-triple-checking that everything is in order.
All traffic from several different protocols are travelling in both
directions without restriction.  I never say never with networks and
computers, but I am quite certain this is not the problem.

> The big problem I found with Samba member servers and winbind was that the
> "Windows" user on a member server might have a unix uid or gid that is not
> consistent with the PDC or other member servers.   But this doesn't seem to
> be your problem. 

As I understand it, having a map be consistent across multiple samba
servers is required in the case of BDCs and PDCs, where a BDC may be
required to authorize a user on behalf of the PDC.  In that case, the
BDC must have the same info as the PDC else a user may end up with
different access to different files depending on which member server it
connects too.  I also understand it to be that using ldap will nicely
work around this problem.  
In my case, there is only one PDC, and my member server is purely a
client that is not going to share anything, so as I understand it, that
is not a concern here.

> 
> Can you post your smb.conf section for the idmap settings?  

Very gladly, and anything else you think might be useful to look at:

This is from the PDC (debian - samba=3.5.6):
;winbind
idmap backend = tdb
idmap uid = 15000-20000
idmap gid = 15000-20000
;winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
winbind cache time = 300
template homedir =
template shell = /bin/false

This is from the DMC (ubuntu - samba=3.4.7):

;Workstation Settings
idmap backend = tdb
idmap uid = 15000-20000
idmap gid = 15000-20000
wins server = 192.168.150.10
;winbind use default domain = yes
winbind enum groups = yes
winbind enum users = yes
password server = 192.168.150.10
template shell = /bin/bash 
template homedir = /home/%D/%U 

Some notes: I did have it set up more like your file at first, using
idmap config instead of idmap alloc.  Two days ago I read every line of
the man page, and set it up without the idmap config, and instead used
the plain idmap parameters.  It seemed to me that this was a better
implementation of the 'Keep It Simple' principle.
I read a post that suggested that if the uid and gid idmap were not "all
encompassing" enough that groups and users would not get displayed.  I
have increased the range and moved the winbind_cache.tdb and
idmap_cache.tdb to create new ones, but no joy. 
I have commented the default domain directive so as to tell what whether
wbinfo -u is returning a local user or a domain user.  
as far as I know all other winbind settings are default values.
I can make the rest of the file available and other stuff as well.

> The syntax for
> samba 3.0.x, 3.2.x, 3.3.x, and 3.4.x varies.   The docs on samba.org may not
> be current so you should check man pages for idmap_tdb etc.   Some versions
> may let you spec "idmap uid =xxxx-yyyy " and "idmap gid =xxxx-yyyy" 
> 
> 
> I have the following entry (samba 3.4.x with LDAP backend)-  
> 
> idmap alloc backend = ldap
> idmap alloc config:ldap_url = ldap://ldapserver1.mydomain.com
> idmap alloc config:ldap_base_dn = ou=alloc,ou=idmap,o=mydomain.com
> idmap alloc config:ldap_user_dn = cn=xxxxxx
> idmap alloc config:range = 50000 - 79999
> 
> 
> 
> I have some issues with getting new id's allocated, but it  you have users
> working but not groups , at least winbind allocation is generally working. 

I spent a considerable amount of time investigating the possibility of
wiping all the group allocations that exist so far on the server and
trying to make it rebuild them all from the ground up. things like net
cache flush and net groupmap cleanup did not make an apparent
difference.  I would think that removing the correct tdb file would make
that happen, however, all of my experimentation in that area led to
making the situation worse.  Given that this is a production environment
and re-adding all the machines to the domain is not an option, I am
pretty nervous playing on this path.

Speaking of removing tdb files, many posts suggested the just deleting
them all and starting over fixes problems just like this one.  however,
as stated already, I am worried that the consequences of such actions
would hurt me more than no action at all.

Another thing that occurred to me is that perhaps I need to manually
create some group mappings, but I am still investigating what is
supposed to be there vs what is there vs what isn't there.

Thank you again for having a look at this, I cannot express enough
gratitude for having a bit of help on this...


> Hello,
> 
> I have spent the last week and a bit searching google and reading
> documentation trying to get this figured.  At this point, I have read
> the same things so many times, I am not even sure I would notice the
> answer any more.... time to ask for some help.  
> Having gone through what seems like hundreds of posts, I have begun to
> see where the problem gets lost in the information provided when posts
> are really large.  To this end, I will try to keep this as short as
> possible by not posting all my configs and logs (though I can certainly
> make all of that available).  It takes considerable time to go through
> everything and I don't expect anyone to do that, so I am not looking for
> someone to review every config file and log entry, but I am hoping
> someone can say what they have done to troubleshoot similar
> situations.  
> 
> The situation:
> I have a network of ~50 XP machines all authenticating to a Samba PDC.
> This has been working without flaw for the last two years.  There are
> three shares; a public one that all users have access too, individual
> shares for each user that can only be accessed by the user, and a
> departmental share that contains folders that are governed by group
> ownerships.  The PDC runs debian, and has samba 3.5.6 installed, and the
> XP workstations all seem to be working as expected.  I am not using
> ldap.
> 
> The goal:
> More computers are required, so we have been going through the retired
> computers and pulling out a number of them that are suitable for running
> ubuntu.  We need these ubuntu machines to authenticate against the PDC,
> and the shares should be mounted automatically on login.
> 
> The added challenge:
> Since the office where the LAN exists is closed over the holiday break
> and there are no existing ubuntu workstations on that LAN, I am forced
> to get the test ubuntu workstation to work over a vpn.  This is soon a
> requirement anyway, but for the time being, I cannot remove the vpn from
> the mix.  I do have ssh access to the Samba PDC, and can vnc to windows
> workstations inside the network.  Given that the vast majority of
> everything seems to be working, I am doubtful the vpn is the problem,
> however it must be mentioned in the name of giving a complete picture...
> 
> The path I have followed:
> Documentation has me understanding that in order to authenticate across
> different subnets or as a DMS or DMC, winbind is the answer.  I have
> configured winbind as per the online Samba 3 documentation.  There are
> also a prolific number of tutorials on the web that I have consulted,
> though most of them seem to be geared towards having an MS ADS instead
> of a Samba PDC.  
> On the PDC, I have modified the nsswitch.conf file to have passwd and
> group use compat winbind (tried file winbind too, same effect).  I have
> also configured in there the hosts entry to use wins.  
> On the ubuntu workstation, I have done the same with the nsswitch.conf
> file, and I have modified the pam.d/common-auth and pam.d/common-account
> files to use winbind.  I have installed pam_mount for the auto-mounting
> part and modified the pam.d files accordingly.
> 
> What works and what doesn't:
> On the ubuntu workstation, I can log into gdm using my domain
> credentials.  pam_mount successfully mounts the shares as expected.
> However, when I try to access the folders in the departmental share that
> are governed by group permissions, I am denied access.  At this point, I
> do not log out of gdm on the workstation reliably either, but that is
> not the problem I am working on at the moment.
> On the workstation and PDC, it seems I can successfully use all wbinfo
> commands except -g (ie, wbinfo -t, -a, -G, -Y, -S, -s, -n, etc all work
> as expected).
> 
> my troubleshooting so far:
> On the ubuntu workstation, I can issue wbinfo -u and I get expected
> results like DOM\user.name, and I get as many as I expect to get.
> However, wbinfo -g returns nothing, no error and no groups.  getent
> passwd returns contents of the local password folder and the list of DOM
> \user.names as expected.  getent group returns only the contents
> of /etc/group.
> When I su to my domain user, it tells me it cannot get the names of my
> groups, yet I can use wbinfo to retrieve this information:
> 
> root at TEST1:~# su - DOM\\bob.miller
> reenter password for pam_mount:
> groups: cannot find name for group ID 15004
> groups: cannot find name for group ID 15005
> groups: cannot find name for group ID 15006
> DOM\bob.miller at TEST1:~$ i=$(wbinfo -G 15004); wbinfo -s $i
> DOM\accpac 4
> DOM\bob.miller at TEST1:~$ i=$(wbinfo -G 15005); wbinfo -s $i
> DOM\public 4
> DOM\bob.miller at TEST1:~$ i=$(wbinfo -G 15006); wbinfo -s $i
> DOM\it 4
> 
> Permissions on the workstation are like so:
> 
> DOM\bob.miller at TEST1:~/Departments$ ls -al
> d---rws--- 14 DOM\bob.miller DOM\none    0 2010-12-29 13:22 Finance
> d---rws---  9 DOM\bob.miller DOM\none    0 2010-12-14 15:24 IT
> 
> and permissions on the server are like so:
> 
> d---rws--- 14 root accpac     4096 2010-12-29 13:22 Finance
> d---rws---  9 root it         4096 2010-12-14 15:24 IT
> 
> On the PDC, wbinfo -u returns only the contents of the passwd file, and
> wbinfo -g returns nothing, as the workstation.  I am not sure if this is
> entirely unexpected, I have read a number of posts that seem to allude
> to the idea that winbind does not work the same on a PDC as it does on a
> member server or member client.  getent passwd and getent group on the
> PDC both return only local content from their respective files.  I have
> tried modifying the pam.d files on the PDC as well to force winbind to
> work, but it has had no effect.
> 
> Logging on the PDC also reveals some other clues, however my ability to
> interpret them is lacking and plugging them into google isn't revealing
> a lot of direction.  For example, I see this frequently:
> 
> process_request: Handling async request 12356:SID_TO_GID
> sid to gid S-1-5-2
> Cache entry with key = IDMAP/SID2GID/S-1-5-2 couldn't be found 
> find_lookup_domain_from_sid(S-1-5-2)
> calling find_domain_from_sid
> Could not find domain for sid S-1-5-2
> Could not convert sid S-1-5-2: NT_STATUS_NONE_MAPPED
> 
> However, I cannot make sense of where it is getting that SID from, or
> what it is supposed to be mapping too.  As far as I know, that is not a
> legal sid.  Net groupmap list also shows a list of all groups with their
> SIDs, of course that one does not show up.  
> 
> I also see things like:
> 
> wcache_fetch_seqnum: DOM not found
> could not fetch seqnum for domain DOM
> wcache_fetch_seqnum: BUILTIN not found
> could not fetch seqnum for domain BUILTIN
> 
> When I increase winbind logging to 10 and try to trace all that happens,
> on both workstation and PDC, it seems that winbind makes a query, gets a
> null response and passes it on.  This essentially results in winbind not
> throwing any errors to fix.  It makes a query, gets an answer, and gives
> it to the client, everything working normally.
> 
> Conclusion:
> Given that the PDC seems to be having questionable behaviour of its own,
> I am not sure if I am dealing with a problem on the PDC, on the
> workstation, or if for some reason some packets aren't being passed
> across the VPN.  Obviously there is something wrong with the groups
> situation, however, it seems that everything I try to work out where
> they are broken results in something that works.
> I would really really appreciate if someone could just put down some
> thoughts about this.  I have the distinct feeling the answer is in my
> fingers already, but I just don't see it...
> 
> Thank you for any thoughts you can share...
> 
> Bob Miller
> 334-7117/660-5315
> http://computerisms.ca
> bob at computerisms.ca
> Network, Internet, Server,
> and Open Source Solutions
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 

Bob Miller
334-7117/660-5315
http://computerisms.ca
bob at computerisms.ca
Network, Internet, Server,
and Open Source Solutions