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:
...
BUILTIN\administrators:x:3000000:
BUILTIN\users:x:3000009:
BUILTIN\guests:x:3000005:
BUILTIN\account operators:x:3000037:
BUILTIN\server operators:x:3000001:
BUILTIN\print operators:x:3000038:
BUILTIN\backup operators:x:3000039:
BUILTIN\replicator:x:3000040:
BUILTIN\pre-windows 2000 compatible access:x:3000016:
BUILTIN\remote desktop users:x:3000041:
BUILTIN\network configuration operators:x:3000042:
BUILTIN\incoming forest trust builders:x:3000043:
BUILTIN\performance monitor users:x:3000044:
BUILTIN\performance log users:x:3000045:
BUILTIN\windows authorization access group:x:3000046:
BUILTIN\terminal server license servers:x:3000047:
BUILTIN\distributed com users:x:3000048:
BUILTIN\iis_iusrs:x:3000049:
BUILTIN\cryptographic operators:x:3000050:
BUILTIN\event log readers:x:3000051:
BUILTIN\certificate service dcom access:x:3000052:
SAMDOM\cert publishers:x:3000053:
SAMDOM \ras and ias servers:x:3000054:
SAMDOM \allowed rodc password replication group:x:3000055:
SAMDOM \denied rodc password replication group:x:3000005:
SAMDOM \dnsadmins:x:3000056:
SAMDOM \enterprise read-only domain controllers:x:3000057:
SAMDOM \domain admins:x:3000008:
SAMDOM \domain users:x:60001:
SAMDOM \domain guests:x:3000002:
SAMDOM \domain computers:x:3000018:
SAMDOM \domain controllers:x:3000028:
SAMDOM \schema admins:x:3000007:
SAMDOM \enterprise admins:x:3000006:
SAMDOM \group policy creator owners:x:3000004:
SAMDOM \read-only domain controllers:x:3000058:
SAMDOM \dnsupdateproxy:x:3000059:
# getent passwd
root:x:0:0:root:/root:/bin/bash
...
SAMDOM\administrator:*:0:60001::/home/SAMDOM/administrator:/bin/bash
SAMDOM\guest:*:3000001:60001::/home/SAMDOM/guest:/bin/bash
SAMDOM\krbtgt:*:3000036:60001::/home/SAMDOM/krbtgt:/bin/bash
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
root:x:0:0:root:/root:/bin/bash
...
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
# 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???
Thanks
--
Rob Mason
Acasta Ltd - A Crown Commercial Service Supplier. CyberEssentials Certified
QGCE013.
Registered in England 6619191. 42 Pitt Street, Barnsley, S70 1BB. VAT Registered
934 6797 75.
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/falseWhy, 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