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

Tue Sep 15 12:48:57 UTC 2015

In one word: virtualisation.
That's what I was thinking about when I start speaking about splitting your
environment. In 21th century virtualisation is working quiet well, there
are different offers which are ready for production, some are proprietary
solution, some are open source.

Using virtualisation no more issue with used port (as the LDAP one you
spoke about), no issue your system which must be configured for everything
works well together, you configure your systems for they do their own job,
use others services as expected.
You make a mistake? You don't lose all your services.

For sure virtualisation needs time. Time to learn it, time to deploy it,
time to manage it in a way not too time-hungry. Once this is done, you just
earn time. It's an investment.

2015-09-15 14:23 GMT+02:00 Jim Seymour <jseymour at linxnet.com>:

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