Frank H
2004-Jul-20 00:09 UTC
[Samba] smbpasswd backend, group-per-user, and primary gid not a domain group
After changing from 2.x to 3.0 I get these messages: rpc_server/srv_util.c:get_domain_user_groups(376) get_domain_user_groups: primary gid of user [fred] is not a Domain group ! get_domain_user_groups: You should fix it, NT doesn't like that I understand why this is: fred's group needs to be mapped like so net groupmap modify ntgroup="Domain Users" unixgroup=<fred's group> The problem is this: each user is in a different group (i.e. fred's initial group, the one mentioned in /etc/passed, is fred) and I can only map one onto "Domain Users." I don't want to give up my "group-per-user, umask is always 2" system. I'm hoping to avoid a more complicated password backend, assuming that would even help. My best idea so far is to set everyone's initial group (the one in /etc/passwd) to "user" mapped to "Domain Users" and also add them to their personal group. Then home directories have to be setgid so files don't end up in group "user." But it's too easy to lose setgid bits. "mkdir /tmp/dir; mv /tmp/dir ~" and files made in ~/dir are now the wrong group. My questions are: Is there a clean solution using the smbpasswd file password backend and keeping the group-per-user plan? If I bite the bullet and go to ldapsam or tdbsam does that help? Do I even need to worry about this? "NT doesn't like that" sounds ominous, but everything seems to work. My clients are mainly W2K if that matters. Thanks.
Craig White
2004-Jul-20 00:34 UTC
[Samba] smbpasswd backend, group-per-user, and primary gid not a domain group
On Mon, 2004-07-19 at 17:09, Frank H wrote:> After changing from 2.x to 3.0 I get these messages: > > rpc_server/srv_util.c:get_domain_user_groups(376) > get_domain_user_groups: primary gid of user [fred] is not a Domain group ! > get_domain_user_groups: You should fix it, NT doesn't like that > > I understand why this is: fred's group needs to be mapped like so > > net groupmap modify ntgroup="Domain Users" unixgroup=<fred's group> > > The problem is this: each user is in a different group (i.e. fred's > initial group, the one mentioned in /etc/passed, is fred) and I can only > map one onto "Domain Users." > I don't want to give up my "group-per-user, umask is always 2" system. > I'm hoping to avoid a more complicated password backend, assuming that > would even help. > > My best idea so far is to set everyone's initial group (the one in > /etc/passwd) to "user" mapped to "Domain Users" and also add them > to their personal group. Then home directories have to be setgid so > files don't end up in group "user." But it's too easy to lose > setgid bits. "mkdir /tmp/dir; mv /tmp/dir ~" and files made > in ~/dir are now the wrong group. > > My questions are: > > Is there a clean solution using the smbpasswd file password backend > and keeping the group-per-user plan? > > If I bite the bullet and go to ldapsam or tdbsam does that help? > > Do I even need to worry about this? "NT doesn't like that" sounds > ominous, but everything seems to work. My clients are mainly W2K > if that matters.---- you are the chief - you make the call according to samba 3 How-to <http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html> smbpasswd This option allows continued use of the smbpasswd file that maintains a plain ASCII (text) layout that includes the MS Windows LanMan and NT encrypted passwords as well as a field that stores some account information. This form of password backend does not store any of the MS Windows NT/200x SAM (Security Account Manager) information required to provide the extended controls that are needed for more comprehensive inter-operation with MS Windows NT4/200x servers. This backend should be used only for backward compatibility with older versions of Samba. It may be deprecated in future releases. tdbsam This backend provides a rich database backend for local servers. This backend is not suitable for multiple Domain Controllers (i.e., PDC + one or more BDC) installations. The tdbsam password backend stores the old smbpasswd information plus the extended MS Windows NT / 200x SAM information into a binary format TDB (trivial database) file. The inclusion of the extended information makes it possible for Samba-3 to implement the same account and system access controls that are possible with MS Windows NT4/200x-based systems. The inclusion of the tdbsam capability is a direct response to user requests to allow simple site operation without the overhead of the complexities of running OpenLDAP. It is recommended to use this only for sites that have fewer than 250 users. For larger sites or implementations, the use of OpenLDAP or of Active Directory integration is strongly recommended. I would change to tdb but that's me. Craig
Maybe Matching Threads
- primary gid of user [desires] is not a Domain group !
- Samba 3.0.12 (gid of user [joe] doesn't exist) Weird error when Client logs on.
- Samba 3.0-alpha 18 with ldapsam backend and primary gid of user?
- Fw: Samba 3.0-alpha 18 with ldapsam backend and primary gid of user?
- Verbose Logs?