samba - Apr 2015 - [bug?] idmap.ldb xidNumber attributes overlap with existing users'/groups' uidNumber/gidNumber

Greetings, All!

I've discovered a nasty mismatch in my recently upgraded domain.
It seems that a number of builtin groups have mappings in idmap.ldb that
overlap with posixAccount mappings in the sam.ldb.
Namely,

# file: var/lib/samba/sysvol/ads.example.com/scripts/
# owner: root
# group: 544
user::rwx
user:root:rwx
group::rwx
group:544:rwx
group:30000:r-x
group:30001:rwx
group:EXAMPLE\134RemoteUsers:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:group::---
default:group:544:rwx
default:group:30000:r-x
default:group:30001:rwx
default:group:EXAMPLE\134RemoteUsers:r-x
default:mask::rwx
default:other::---


As you can see, the groups 544, 30000 and 30001 weren't resolved.
Something similar happens, if I'm trying to look at it from Windows side:

icacls \\dc1\netlogon\

544(BUILTIN\Administrators) and 30001(SYSTEM) are resolved properly, but for
30000, the error message is along the lines of "Unable to resolve SID into
account name".

But when I bring up GUI on the same share, it magically resolve SID's
into "Server Operators" which is matching the

# ldbsearch -s sub -H /var/lib/samba/private/idmap.ldb
'(|(xidNumber=30000)(xidNumber=30001))'

# record 1
dn: CN=S-1-5-32-549
cn: S-1-5-32-549
objectClass: sidMap
objectSid: S-1-5-32-549
type: ID_TYPE_BOTH
xidNumber: 30000
distinguishedName: CN=S-1-5-32-549

# record 2
dn: CN=S-1-5-18
cn: S-1-5-18
objectClass: sidMap
objectSid: S-1-5-18
type: ID_TYPE_BOTH
xidNumber: 30001
distinguishedName: CN=S-1-5-18


However, there lies the problem:

# getent passwd 30000 30001
EXAMPLE\domainuser:*:30000:513:User 1:/home/domainuser:/bin/bash
EXAMPLE\otheruser:*:30001:513:User 2:/home/otheruser:/bin/bash

It all looks much like if idmap assignment has been created before the users
(with their corresponding uidNumber's) were imported from old domain.

Should this be considered a bug, perhaps?

And how to best resolve this mess? Should I nuke idmap from the orbit and
recreate the maps anew?


-- 
With best regards,
Andrey Repin
Sunday, April 19, 2015 22:35:56

Sorry for my terrible english...

Greetings, All!
> I've discovered a nasty mismatch in my recently upgraded domain.
> It seems that a number of builtin groups have mappings in idmap.ldb that
> overlap with posixAccount mappings in the sam.ldb.
> Namely,
> # file: var/lib/samba/sysvol/ads.example.com/scripts/
> # owner: root
> # group: 544
> user::rwx
> user:root:rwx
> group::rwx
> group:544:rwx
> group:30000:r-x
> group:30001:rwx
> group:EXAMPLE\134RemoteUsers:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx
> default:group::---
> default:group:544:rwx
> default:group:30000:r-x
> default:group:30001:rwx
> default:group:EXAMPLE\134RemoteUsers:r-x
> default:mask::rwx
> default:other::---
Even more disturbing, when I took a closer look at it (i.e. getfacl -n),
turned out, the "EXAMPLE\RemoteUsers" group was in fact CN=S-1-5-11
(i.e. "Authenticated Users") according to idmap.

# ldbsearch -s sub -H /var/lib/samba/private/idmap.ldb
'(xidNumber=30002)'
# record 1
dn: CN=S-1-5-11
cn: S-1-5-11
objectClass: sidMap
objectSid: S-1-5-11
type: ID_TYPE_BOTH
xidNumber: 30002
distinguishedName: CN=S-1-5-11

# getent group 30002
EXAMPLE\RemoteUsers:*:30002:

# wbinfo -n 'TD-ART\RemoteUsers'
S-1-5-21-2871150808-3169547284-4194875288-61005 SID_DOM_GROUP (2)

So, in total, 3 groups have UIDs overlapping just in this very basic example.
> As you can see, the groups 544, 30000 and 30001 weren't resolved.
> Something similar happens, if I'm trying to look at it from Windows
side:
> icacls \\dc1\netlogon\
> 544(BUILTIN\Administrators) and 30001(SYSTEM) are resolved properly, but
for
> 30000, the error message is along the lines of "Unable to resolve SID
into
> account name".
> But when I bring up GUI on the same share, it magically resolve SID's
> into "Server Operators" which is matching the
> # ldbsearch -s sub -H /var/lib/samba/private/idmap.ldb
> '(|(xidNumber=30000)(xidNumber=30001))'
> # record 1
> dn: CN=S-1-5-32-549
> cn: S-1-5-32-549
> objectClass: sidMap
> objectSid: S-1-5-32-549
> type: ID_TYPE_BOTH
> xidNumber: 30000
> distinguishedName: CN=S-1-5-32-549
> # record 2
> dn: CN=S-1-5-18
> cn: S-1-5-18
> objectClass: sidMap
> objectSid: S-1-5-18
> type: ID_TYPE_BOTH
> xidNumber: 30001
> distinguishedName: CN=S-1-5-18
> However, there lies the problem:
> # getent passwd 30000 30001
> EXAMPLE\domainuser:*:30000:513:User 1:/home/domainuser:/bin/bash
> EXAMPLE\otheruser:*:30001:513:User 2:/home/otheruser:/bin/bash
> It all looks much like if idmap assignment has been created before the
users
> (with their corresponding uidNumber's) were imported from old domain.
> Should this be considered a bug, perhaps?
> And how to best resolve this mess? Should I nuke idmap from the orbit and
> recreate the maps anew?

-- 
With best regards,
Andrey Repin
Monday, April 20, 2015 01:51:48

Sorry for my terrible english...