[Samba] idmap problems

[Rowland Penny]

On Wed, 2 Jan 2019 00:29:07 +0000
Rob Mason via samba <samba at lists.samba.org> wrote:

> I've spent some time updating, upgrading and generally consolidating
> an old Samba AD. I've managed to remove a very old unsupported (4.2)
> Samba AD DC following migration to a  couple of new DC's - that seems
> to have worked out OK. Workstation logons and GPO's working fine.
> 
> I'm now left with one problem after joining a new Samba (4.5.12)
> member server to the domain for file sharing - the idmaps are
> inconsistent (I suspect this is a remnant from how the old DC was
> originally built). This is giving me problems setting up file shares.
> 
> [global]
>         workgroup = SAMDOM
>         realm = SAMDOM.INTRA
>         netbios name = FILESERVER
>         security = ADS
>         dns forwarder = 192.168.200.1
>         winbind nss info = rfc2307
>         idmap config * : backend = tdb
>         idmap config * : range = 3000-5900
>         idmap config SAMDOM:backend = ad
>         idmap config SAMDOM:schema_mode = rfc2307
>         idmap config SAMDOM:range = 6000-9999999
>         template homedir = /home/%U
>         template shell = /bin/bash
>         winbind use default domain = true
>         winbind offline logon = false
>         winbind enum users = yes
>         winbind enum groups = yes
>         vfs objects = acl_xattr
>         map acl inherit = Yes
>         store dos attributes = Yes
>         # the user.map contains just one mapping for
> root-admininstrator username map = /etc/samba/user.map
> [test123]
>         path = /data
>         read only = no
> 
> My problem is that the builtin accounts and domains accounts are
> mixed within the same ranges. Domain users appeared to originally
> start at 30000, with domain groups from 60000. Somewhere along the
> way, perhaps during upgrade, the idmaps have gotten mixed. As a
> consequence, I cannot create shares as the member server is not
> enumerating the builtin accounts (except the group 'domain users'
> with gid of 60001).
> 
> The following output shows the current mapping from the AD DC::
> 
> # getent group
> root:x:0:
> ...

> SAMDOM \domain admins:x:3000008:

This shows that 'Domain Admins' doesn't have a 'gidNumer' attribute

> SAMDOM \domain users:x:60001:

Whilst 'Domain Users' does

> 
> # getent passwd

> SAMDOM\user1:*:30002:60001::/home/SAMDOM/user1:/bin/bash
> SAMDOM\user2:*:30007:60001::/home/SAMDOM/user2:/bin/bash
> SAMDOM\user3:*:30008:60001::/home/SAMDOM/user3:/bin/bash
> SAMDOM\user4:*:30009:60001::/home/SAMDOM/user4:/bin/bash
> 
> Now on the member server::
> 
> # getent passwd

> user1:*:30009:60001:User1:/home/ user1:/bin/false
> user2:*:30008:60001: User1:/home/ user2:/bin/false
> user3:*:30002:60001: User1:/home/ user3:/bin/bash
> user4:*:30007:60001: User1:/home/ user4:/bin/false

Why, if the users have have a 'uidNumber' attribute, are they different
between the DC and the Unix domain member ?
Also, why isn't the template shell being used on the Unix domain
member ?

> 
> # getent group
> root:x:0:
> ...
> domain users:x:60001:
> 
> I don't see Domain Admins or other groups and builtin users on the
> member server. This means I cannot grant Domain admins ownership of
> directories when I create shares. Does this mean I will have to
> manually re-map the uid/gid attributes in the AD DC???
> 

I would suggest creating a new group e.g. Unix Admins, add this group
to Domain Admins, give the new group a gidNumber attribute and use this
group on Unix instead of Domain Admins.

OK, you have problems, one being that you don't understand the
differences between how idmap works on a DC and a Unix domain member.

on a DC, the ID mapping is done in idmap.ldb using 'xidNumber'
attributes (the '3000000' numbers) and these will be different on each
DC.

On a Unix domain member using the winbind 'ad' backend, you will need
to add 'uidNumber' & 'gidNumber' attributes. These numbers will need to
be inside the range you set in smb.conf (in your case '6000-9999999')
anything outside the range will be ignored.
You do not need to use different ranges for users & groups.

If you do give a user a 'uidNumber' attribute, or a group a 'gidNumber'
attribute, these will be used on a DC instead of the 'xidNumber'
attributes, though you will probably need to run 'net cache flush'

Rowland