[Samba] Wither "uidNumber" and "gidNumber"? (was: Re: ldbedit: no matching records - cannot edit (newly-created user))

[Jim Seymour]

On Tue, 15 Sep 2015 12:38:11 +0100
Rowland Penny <rowlandpenny241155 at gmail.com> wrote:

> On 15/09/15 12:14, Jim Seymour wrote:
> > On Tue, 15 Sep 2015 10:36:10 +0200
> > mathias dufresne <infractory at gmail.com> wrote:
> >
[snip]
> >
> >> As far as I have understood winbind is not configurable for AD
> >> attributes used to build users for Linux systems, so your users
> >> will have a primary group set to primaryGroupID.
> > That would appear to be so.  And, in fact: I actually tried to
> > change my test user's primaryGroupID to another, and ldbedit
> > responded with "Unwilling to perform."
> 
> There is a way around this, the group must exist and the user must be
> a member of it, if both of these are true, then changing
> primaryGroupID to the RID of the new group should be possible.

Apparently not:

    $ ldbsearch -H /var/lib/samba/private/sam.ldb cn='someuser'
    # record 1
    dn: CN=someuser,CN=Users,DC=addc,DC=exampl,DC=com
    ...
    objectClass: user
    cn: someuser
    ...
    primaryGroupID: 513
    ...
    memberOf: CN=testgrp,CN=Users,DC=addc,DC=exampl,DC=com
    distinguishedName: CN=someuser,CN=Users,DC=addc,DC=exampl,DC=com

    $ ldbsearch -H /var/lib/samba/private/sam.ldb cn='testgrp'
    # record 1
    dn: CN=testgrp,CN=Users,DC=addc,DC=exampl,DC=com
    ...
    cn: testgrp
    gidNumber: 1011

Changing "someuser"s primaryGroupID...

    $ ldbedit -H /var/lib/samba/private/sam.ldb cn='someuser'
    # editing 1 records
    # record 1
    dn: CN=someuser,CN=Users,DC=addc,DC=exampl,DC=com
    ...
    primaryGroupID: 1011
    <exiting...>
    "/tmp/ldbedit.LBey1L" 43L, 1150C written
    failed to modify CN=someuser,CN=Users,DC=addc,DC=exampl,DC=com
     - error in module samldb: Unwilling to perform (53)


> I personally wouldn't bother though, just leave every bodies primary
> group as Domain Users.

Then every file and directory the user creates ends up with the same
group identity as every other user on the system.

> 
[snip]
> 
> You can create shares on the DC, it is just not recommended,

I do not understand this line of thinking.  If you have a server that
has more than enough snot to do it all: Why, for the love of Mary,
would you want to increase the number of points-of-failure,
administrative load, system complexity, electricity costs, heat load on
air handling systems... noise level... number of systems you need to
back up (and the resultant secure storage, both on- and off-site), etc?

[snip]
> problems
> come with things like the users homedir and shell, you cannot set
> them individually.

Are you suggesting elements such as unixHomeDirectory, loginShell, etc.
have no meaning, either?

> 
> > *sigh* This is typical of Microsoft Windows thinking: "A thing
> > cannot do more than one thing or it'll fall over."  But this
> > *isn't* an MS-Windows server and it *can* do more than one thing at
> > a time.
> 
> You can do more than one thing with a DC, it will not fall over.

But that seems to be the view everybody expresses: The AD DC can be
*only* the AD DC, and nothing else.  Can't serve files.  Can't serve
DNS (except for the AD DC zone).  Of course we know it can't serve real
LDAP, because the port's in use by a truncated LDAP service.

> 
> > If I can't work around this, somehow, it'll be a show-stopper and
> > Samba4 AD will have to go.  A shame, that would be, as it was
> > looking so positive before this.
> 
> You need to stop thinking in the 'I must do this the Unix way only',
> you need to accept that some of what microsoft came up with is okay 
> (admittedly not a lot :-) )

The more I'm exposed to AD, the more convinced I become the Evil Genius'
in Redmond have done it again: Managed to foist upon a computing public,
that long ago should have known better, yet another brain-damaged
"innovation." It's as if they looked at the Unix model and said "Ok:
Whatever they're doing: Do it a different way, as differently as
possible, even if doing that makes no sense at all."

> Stop thinking in terms of 'owner:group' on a file or dir, and think 
> 'user,user,user,user,and so on' or 'group, group,group,and so on' and 
> set the permissions with setfacl or from windows.

Whilst awaiting responses to the gidNumber question, I set about
experimenting with shared directories/shares.  E.g.: X number of users,
who are in various different primary groups, who have a shared
project/team directory.  So the all share a common supplemental group
identity.

It would seem Samba4 *entirely* ignores the SGID setting on directory
objects. And, apparently, the smb.conf "inherit permissions" directive
is, likewise, disregarded.

Without further reading (near the end of the day, and I was winging it)
I tried the old Samba3 "force" directives, and that appears to have
made the share disappear.

I hadn't posted about that because it's apparent I've some reading to
do, and I do try to work things out, for myself, first :)

> 
> > [snip]
> >> Now to answer to last mail from Rowland, primary group is important
> >> in UNIX world as this group is mainly used give group ownership of
> >> newly created files and folders.
> 
> You do not need a Unix primary group if you use windows ACLs

You do if you're working in a heterogeneous environment, with both Unix
and MS-Win users, some dual-booting between the two OS', sharing
storage.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.