Idmap in samba3 -> samba4 environment

Hi everybody,

during a migration ucs4 samba3 - to samba4 ad, we had some messages about missing idmap settings for domain * in the logfile:

idmap range not specified for domain '*'

The migration itself seems to finish successful. The problem is, that files, created by a Windows User on a Windows PC do all have the id 3000000, instead of the users name. Trying to figure out what happens, it seems that only users in the Builtin Group “Domain Admins” are affected.

What is the needed setting for samba/idmap/range?
In our configuration this ucs variable is empty.

It looks as if it’s the same like this bug https://forge.univention.org/bugzilla/show_bug.cgi?id=36821

Cheers

Sebastian

Hi Sebastian,

Posix-IDs in the 3000000 region are assigned by Samba/AD on the fly whenever a file is written with ACLs that refer to an account (user or group) for which it cannot find an “official” Posix-ID in its idmap database. For regular uses this should not happen. I would recommend to check the output of the following two commands to confirm that the SIDs are the same in OpenLDAP and Samba/AD:

univention-ldapsearch uid= sambaSID
univention-s4search sAMAccountName= objectSid

If they are the same, which they should, you could check

univention-s4connector-list-rejected

to see if the S4-Connector had a problem synchronizing the account. That would be the first steps to assess the situation. Please make sure to anonymize all private info from the output before you post output to this public forum.

Cheers,
Arvid

Hi Arvid,

thank you very much for your message. The SIDs are equal as the should. There aren’t any rejects listed by the s4connector as well.
If I understand it correctly, there should be an object for the group “Domain Admins” in samba’s idmap database, right?

Cheers
Sebastian

Mosu wrote:

I see. However, you won’t be able to keep using your NT-style domain indefinitely, and problems such as this one make it all the more urgent.

I know for sure, that we have to migrate to samba4. Actually, with issues like that one here concerning idmap, it’s a bit more difficult to evaluate, if everything else still works, after migration %)

About your idmap issue: do the files have correct owners & groups at the moment? If so you could look into using getfacl before the migration for dumping the ACLs & owner information into a text file and using setfacl after the migration for restoring the owner. That might work as getfacl stores the user/group names instead of their numeric IDs. if the IDs change but the names stay stable during the migration, using the information from getfacl afterwards should work.

As far as I can see, the files have correct owners and groups right now. We could sight it when new files have been created, after the migration. It seems only files created by users in the domain admins group are affected. Well, I am afraid that there are some more files’n folders created by Users in that group, eg GPOs.

Cheers
Sebastian

Hey,

Then using the approach I’ve described might work:

  • Run cd /path/to/files; getfacl -R . > ~/acls.txt prior to the migration
  • Migrate
  • Run cd /path/to/files; setfacl --set-file ~/acls.txt afterwards
  • Check file ownership & permissions

Ideally you should test that in a separate installation, e.g. by cloning your existing server (hopefully it’s a virtual machine) into a lab/test network.

Kind regards,
mosu

Hey Mosu,

existing files are not involved. It only happens after the migration, when new files are created.

Of course, we tested it in our test-environment.

Cheers
Sebastian

Hey,

oops, sorry, I misunderstood that part. Do you still have that migrated test setup so that we can run a couple of tests on it?

Kind regards,
mosu

Hey Mosu,

well, I deleted it the other day. 8-/ … I rebuilded it, and it’s exactly the same situation now. Newly created files from a user in the domain users group have the owner 300000.

Cheers
Sebastian

Hey,

alright, so let’s get to the bottom of this. Please show me the output of the following commands from your test installation:

net getdomainsid
univention-s4search --cross-ncs cn='Domain Admins' objectSid
univention-ldapsearch cn='Domain Admins' sambaSid
univention-s4connector-list-rejected
ldbsearch -H /var/lib/samba/private/idmap.ldb CN=$(net getdomainsid | sed -e 's/.* //')-512

Thanks.

mosu

Hey,

these things look quite normal to me:

root@ucsmaster:~# net getdomainsid
SID for domain HBI is: S-1-5-21-677538019-1864647526-2656929208
root@ucsmaster:~# univention-s4search --cross-ncs cn='Domain Admins' objectSid
# record 1
dn: CN=Domain Admins,CN=Groups,dc=some,dc=thing
objectSid: S-1-5-21-677538019-1864647526-2656929208-512

# returned 1 records
# 1 entries
# 0 referrals
root@ucsmaster:~# univention-ldapsearch cn='Domain Admins' sambaSid
# extended LDIF
#
# LDAPv3
# base  (default) with scope subtree
# filter: cn=Domain Admins
# requesting: sambaSid
#

# Domain Admins, groups, some.thing
dn: cn=Domain Admins,cn=groups,dc=some,dc=thing
sambaSID: S-1-5-21-677538019-1864647526-2656929208-512

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
root@ucsmaster:~# univention-s4connector-list-rejected

UCS rejected


S4 rejected


There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.


        last synced USN: 7858
ldbsearch -H /var/lib/samba/private/idmap.ldb CN=$(net getdomainsid | sed -e 's/.* //')-512
# record 1
dn: CN=S-1-5-21-677538019-1864647526-2656929208-512
cn: S-1-5-21-677538019-1864647526-2656929208-512
objectClass: sidMap
objectSid: S-1-5-21-677538019-1864647526-2656929208-512
type: ID_TYPE_GID
xidNumber: 5000
distinguishedName: CN=S-1-5-21-677538019-1864647526-2656929208-512

# returned 1 records
# 1 entries
# 0 referrals

Cheers
Sebastian

Hey,

yeah, those results look fine to me, too.

Can you please search through the Samba 4 LDAP (univention-s4search --cross-ncs | less), the OpenLDAP (univention-ldapsearch | less), the idmap database (ldbsearch -H /var/lib/samba/private/idmap.ldb | less) and /etc/group and look for any other entries called domain admins?

A couple more questions so that I understand the effect correctly:

  1. On a newly-created file, which one is set to 300000+ — the user ID or the group ID? Both?
  2. Does it happen with all users in the group Domain Admins? Just one/a few?

Kind regards,
mosu

Hey,

I couldn’t find any other entries called “Domain Admins” in these databases.

It’s the user ID. The group ID looks fine. All users in the group “Domain Admins” are affected.
What surprises is the output of getfacl. The acls of the directory where the samba share is, looks like this:

getfacl /shares/temp/
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: shares/temp/
# owner: root
# group: Domain\040Users
user::rwx
group::rwx
other::r-x

When I create a folder via Windows, the acls of that folder look like this:

getfacl /shares/temp/Neuer\ Ordner/
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: shares/temp/Neuer Ordner/
# owner: 3000000
# group: Domain\040Users
user::rwx
group::rwx
group:Domain\040Users:rwx
group:3000000:rwx
mask::rwx
other::--x
default:user::rwx
default:user:3000000:rwx
default:group::rwx
default:group:Domain\040Users:rwx
default:mask::rwx
default:other::--x

I don’t have a glint where these defaults come from. The corresponding part of the smb.conf looks like this:

[Temp]
path = /shares/temp
vfs objects = acl_xattr
msdfs root = no
writeable = yes
browseable = yes
public = no
dos filemode = no
hide unreadable = no
create mode = 0761
directory mode = 0771
force create mode = 00
force directory mode = 00
locking = 1
blocking locks = 1
strict locking = 0
oplocks = 1
level2 oplocks = 1
fake oplocks = 0
csc policy = manual
nt acl support = 1
inherit acls = 0
write list = @"Domain Users"
inherit owner = no
inherit permissions = no

Cheers
Sebastian

Hey,

is there by any chance a user and a group that have the same name in your source system (before the migration to Samba 4)?

Can you try the following experiment:

  1. Remove the user from the Domain Admins group.
  2. Create a file or directory and observe its ACLs/ownership information.
  3. Re-add the user to the Domain Admins group.
  4. Create another file or directory and observe its ACLs/ownership information.

Kind regards,
mosu

Before I tried to upgrade I checked some things:

root@ucsmaster:~# /usr/share/univention-directory-manager-tools/proof_uniqueMembers
Checking if users are member of their primary group...
Checked 198 posixAccounts, fixed 0 issues.
Checking if group-members exist...
Checked 200 posixGroups, fixed 0 issues.
root@ucsmaster:~# getent group|grep "Domain Admins"
Domain Admins:*:5000:oneuser,Administrator,anotherone,domainadmin
root@ucsmaster:~# getent passwd |grep "Domain Admins"
root@ucsmaster:~# 

If I remove the user from the group, the acls look fine. As soon as I re-add the user, it’s messed up again.

Cheers
Sebastian

Alright. Can you please post a screenshot of Windows Explorer showing the advanced ACL properties for one of those files where the owner is 300000 (right-click on it, “Properties”, “Security” tab, “Advanced”)?

Sure :slight_smile: In Windows everything looks fine, i’d say.
Screenshot_test-windows_2018-02-15_11:04:08

Hey,

yeah, that looks fine to me. And I’m running out of ideas at the moment. Sorry :frowning:

mosu

Hey mosu,

thank you very much for your support and help!

I’ve found out, that disabeling nt-acl support on samba-side, works around that behaviour for some of our shares, where we don’t nessesary need acls.

One last question: Does the 3000000er sidMap have to be in /var/lib/samba/private/idmap.ldb ? Because we have an entry for that:

# record 288
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_BOTH
xidNumber: 3000000
distinguishedName: CN=S-1-5-32-544

Cheers

Hey,

Ooooh, now it gets interesting!

That SID is for the built-in group Administrators. Can you please check if that one exists and its SID is if it does?

univention-s4search --cross-ncs cn=administrators dn objectsid
univention-ldapsearch cn=administrators dn gidnumber sambasid

Thanks.

mosu

Yes. Both univention-s4search and univention-ldapsearch bring an entry. If understand it correctly: When a group is a Windows Buildin Group it is not nessesary having this group in openldap, right? In other words, the group “domain admins” has objectlass called “sambaGroupType” wich the “administrators” group didn’t.

root@ucsmaster:~# univention-s4search --cross-ncs cn=administrators dn objectsid
# record 1
dn: CN=Administrators,CN=Builtin,dc=some,dc=thing
objectSid: S-1-5-32-544

# returned 1 records
# 1 entries
# 0 referrals
root@ucsmaster:~# univention-ldapsearch cn=administrators dn gidnumber sambasid
# extended LDIF
#
# LDAPv3
# base  (default) with scope subtree
# filter: cn=administrators
# requesting: dn gidnumber sambasid
#

# Administrators, groups, some.thing
dn: cn=Administrators,cn=groups,dc=some,dc=thing
gidNumber: 5010

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
Mastodon