Re: [Samba] idmap problems
- Date: Wed, 2 Jan 2019 09:11:32 +0000
- From: Rowland Penny via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] idmap problems
On Wed, 2 Jan 2019 00:29:07 +0000
Rob Mason via samba <samba@xxxxxxxxxxxxxxx> 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.
> 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
> 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
> 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
> 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
> # getent group
> 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
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'
To unsubscribe from this list go to the following URL and read the