On Sun, 8 Apr 2018 14:44:30 +0100
Clemente Aguiar <ca-mlsamba at arditi.pt> wrote:
> Às 13:51 de 08-04-2018, Rowland Penny escreveu:
> > On Sun, 8 Apr 2018 13:22:28 +0100
> > Clemente Aguiar via samba <samba at lists.samba.org> wrote:
> >
> >> The samba was created by Zentyal system (http://www.zentyal.org).
> >>
> >> Here is smb.conf:
> >>
> >> [global]
> >> workgroup = arditi
> >> realm = ARDITI.PT
> >> netbios name = hera
> >> server string = Zentyal Server
> >> server role = dc
> >> server role check:inhibit = yes
> >> server services = -dns
> >> server signing = auto
> >> dsdb:schema update allowed = yes
> >> ldap server require strong auth = no
> >> drs:max object sync = 1200
> >>
> >> idmap_ldb:use rfc2307 = yes
> >>
> >> winbind enum users = yes
> >> winbind enum groups = yes
> >> template shell = /bin/bash
> >> template homedir = /home/%U
> >>
> >> interfaces = lo,eth0
> >> bind interfaces only = yes
> >>
> >> map to guest = Bad User
> >>
> >> log level = 3
> >> log file = /var/log/samba/samba.log
> >> max log size = 100000
> >>
> >> include = /etc/samba/shares.conf
> >>
> >> [netlogon]
> >> path = /var/lib/samba/sysvol/arditi.pt/scripts
> >> browspid_to_procid: messaging_dgm_get_unique failed: No such
> >> file or directoryeable = no read only = yes
> >>
> >> [sysvol]
> >> path = /var/lib/samba/sysvol
> >> read only = no
> > It is running as an AD DC and the IDs you showed are not in the
> > '3000000' range, so this means one of two things, either
idmap.ldb
> > has been messed with (not recommended) or the users and groups have
> > been given uidNumber and gidNumber attributes (with very low
> > numbers, again not recommended).
> > I think it is more likely to be the later and if so, there is a bug
> > for this: https://bugzilla.samba.org/show_bug.cgi?id=13054#
> >
> > Rowland
> Rowland,
>
> Thank you for the quick answer.
>
> The thing is that this Zentyal server is a few years old and has been
> through a few upgrades.
> In the begging Zentyal was based Samba3 + OpenLDAP (if I am not
> mistaken), and eventually changed to Samba4.
> The new users and groups have IDs in the '3000000' range, but old
> users and groups have IDs in the '2000' range.
> So I think the low IDs are remnants of the old version which where
> kept even though the system was upgraded. And I think that the double
> gID for users is also related to remnants of the old system and the
> successive upgrades.
>
> 1)
>
> You mentioned that uidNumber and gidNumber attributes with very low
> numbers are not recommended.
> Is there anything I can do about that at this point in time?
It used to be thought that using such low numbers wasn't a problem, but
time has shown otherwise ;-)
The problem is that Linux uses numbers below 1000 for system users &
groups and then starts local users & groups at 1000, there is then the
problem of the BUILTIN users & groups and users & groups from outside
the domain. You could add them after the range for the domain, but if
the range chosen is too low, it could interfere with the domain range if
this grows too large. So, the advice is to allow a range above 3000
but below 10000 for the BUILTIN etc domain and then start the AD
domain users & groups at 10000 (which is where Windows started them)
Of course this only really comes into play if you have any Unix domain
members. If nobody actually logs into the DC and you only store things
in shares and access them from windows, you might as well stick to the
xidNumbers in idmap.ldb (i.e. the 3000000 numbers)
Whether you can do anything about this now, sort of depends on
how many users you have and if you really want to fix it ;-)
If you do want to fix it and only use windows (the zentyal DC is the
only Unix machine) then just remove the uidNumber & gidNumber
attributes, but you will need to fix file ownership.
>
> 2)
>
> I looked at the bug you sent and and the behaviour is similar.
>
> If I run:
>
> # net cache flush"
>
> all seems "correct" (gID 2513 is shown),
>
> # wbinfo --group-info="domain users"
> ARDITI\domain users:x:2513:
>
> but if do any query with the gID 1901, such as:
>
> # wbinfo --gid-info 1901
> ARDITI\domain users:x:1901:
>
> then I get the following:
>
> # wbinfo --group-info="domain users"
> ARDITI\domain users:x:1901:
>
> I can I fix this "permanently", i.e get rid of second gID (1901)?
Yes, that confirms it, see above.
Rowland