Re: [Samba] smbpasswd backend, group-per-user, and primary gid not a domain group

[Frank H]

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
...
Craig White wrote:
I would change to tdb but that's me.
...
To sum up my experience, in case it helps anyone...  This is with 3.0.3.
Changing to the tdbsam password backend is utterly painless.  (Thank you
samba developers.)  Apart from the fact that the smbpasswd file password
backend is deprecated, tdbsam is better in that it allows you to set a
user's primary group with pdbedit.  You can set your group to "domain admin"
and you'll be an administrator when you log into Windows - no messing with
"net groupmap" or unix groups required.  When I do this however, samba still
logs the message shown above!  I know my group setting is working because
otherwise I wouldn't be an administrator when I log in.  So I think
producing the message in this case is a bug.
I had one other problem due to a mismatch between the pdbedit man page and
the behavior of the program.  The man page says the -r flag is not needed
but I found I could not change my group without it.
Finally, for what it's worth, I've been running for over a month with
"NT doesn't like that" with w2k clients and I'm not aware of any problems.
--
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba

Re: [Samba] smbpasswd backend, group-per-user, and primary gid not a domain group

[Craig White]

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=
> 
> 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

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

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba

[Samba] smbpasswd backend, group-per-user, and primary gid not a domain group

[Frank H]

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=
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.
--
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba