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

Tue Sep 15 12:53:36 UTC 2015

On 15/09/15 13:23, Jim Seymour wrote:
> On Tue, 15 Sep 2015 12:38:11 +0100
> Rowland Penny <rowlandpenny241155 at gmail.com> wrote:
>
>
>>> 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)

No, don't use the groups gidNumber, use its RID

Find the groups objectSid, it will look like this:

objectSid: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1633

The number you need is the one on the end, it is known as the 'RID' or 
Relative ID, it is unique in the domain, so you would change '513' to 
(in this case) '1633'

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

Yes but you don't allow Domain Users any access etc via ACLs

>
> [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, yes, but only on the DC, they work everywhere else, I actually 
reported a bug report on this when Samba stopped using the builtin 
winbind and moved to a separate winbinnd, but no result so far. This is 
one of the reasons why it is not recommended to use the DC as a fileserver.

>
>>> *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.

Samba 4 running as an AD DC is trying to do everything that a windows DC 
does, therefore it has to work like a windows DC, but quite a lot of 
what you can do with LDAP can still be done with Samba 4.

>>> 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."

You could be on to something there :-D

>> 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 :)

I am fairly sure I have said this, forget Unix permissions 'ugo' and 
only use ACLs, they have greater scope.

Rowland

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