Idmap in samba3 -> samba4 environment

UCS - Univention Corporate Server
,
#21

Hey,

No, that’s wrong — the group must exist in OpenLDAP, too. What’s interesting is that your group is in container cn=groups instead of cn=Builtin and lacks a sambaSID. For comparison, here’s what my group looks like:

# Administrators, Builtin, mbu-test.intranet
dn: cn=Administrators,cn=Builtin,dc=mbu-test,dc=intranet
sambaSID: S-1-5-32-544
gidNumber: 5051

Is administrators a group you had before you started the migration? If so, it might be worth a try to reset your test environment to before the migration, remove the group and migrate again.

Another possible way forward might be:

  1. Move the administrators group to the cn=builtin container.
  2. Add the sambaSID attribute.
  3. Remove the mapping for 300000 from the idmap database.
  4. Check that the idmap database has the correct mapping for the newly-moved administrators group.

Kind regards,
mosu

#22

Well, it seems we have a lot of Buildin groups in our environment, located in group container instead of Buildin container. Is there a list with all the Buildin groups, and it’s location in ldap? For testing purposes I checked the ldap of the univention demo system https://demo.univention.de/univention/management/#module=udm:navigation:0:

The administrators group exists in our samba3 environment. For what reason, I cannot say.
Cheers
Sebastian

#23

Hey,

None that I know of. Checking the demo system or any freshly-installed, Samba4-based one is what I’d have done, too.

If you’re not comfortable with removing it, then we could go down that other road, if you want. First let’s check if there’s an idmap entry for the OpenLDAP group ID of that administrators group:

ldbsearch -H /var/lib/samba/private/idmap.ldb xidnumber=5010

Next add the sambaSID attribute to the entry in the OpenLDAP. Save the following as add-sambaSID.ldif (change the DN to your actual base DN, of course):

dn: cn=Administrators,cn=groups,dc=some,dc=thing
changetype: modify
add: sambaSID
sambaSID: S-1-5-32-544

Now apply it:

ldapmodify -x -D cn=admin,$(ucr get ldap/base) -y /etc/ldap.secret -f add-sambaSID.ldif

Observe if /var/log/univention/connector-s4.log shows any errors about syncing that group afterwards.

Now change that idmap entry to point to the correct Unix group ID:

ldbedit -H /var/lib/samba/private/idmap.ldb CN=S-1-5-32-544

Replace xidNumber=3000000 with xidNumber=5010, save & exit the editor.

Restart Samba (or the whole server) — just in case.

Depending on the first ldbsearch I asked you about in this post and potential S4 connector rejects (see univention-s4connector-list-rejected), we may have to do some more work.

I cannot really test everything I write here before posting, especially the modifications. Hopefully nothing’s too broken :slight_smile:

mosu

#24

Actually, I moved the administrators group to CN=Buildin and added the sambaGroupMap objectclass. Then I checked the ldb-database. The entry with the 3000000 xidNumber was gone :o)
Then I restarted all the systems in the test environment. Unfortunatly it’s still the same thing.

There are no rejects from s4-connector.

#25

I wonder, what are all these AD Buildin Groups for in our samba3 environment? Wouldn’t it be the best to delete them all in LDAP before migration?

#26

Hey,

I cannot really say if that would make it better or worse, to be honest.

So the idmap entry for 3000000 is gone now? OK. However, is the sambaSID set for the OpenLDAP entry?

And what’s the output of the following commands now:

ucr get connector/s4/mapping/group/grouptype
ldbsearch -H /var/lib/samba/private/idmap.ldb xidnumber=5010
ldbsearch -H /var/lib/samba/private/idmap.ldb objectSid=S-1-5-32-544

It’s likely you still have to add/update an idmap entry for the group, and you definitely need the OpenLDAP entry for cn=administrators to have sambaSID set correctly.

Kind regards,
mosu

#27

Hello,

the idmap entry 3000000 is gone, yes. The sambaSID is S-1-5-32-544

false

root@ucsmaster:~# ldbsearch -H /var/lib/samba/private/idmap.ldb xidnumber=5010
# record 1
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_GID
xidNumber: 5010
distinguishedName: CN=S-1-5-32-544

BTW: Checking Univentions Best Practice Samba https://wiki.univention.de/index.php?title=Best_Practice_Samba_4_Migration#Samba_SIDs shows, that we don’t have a group “Users” in our LDAP. I’d say, thats not a good idea :slight_smile: … trying to add this in cn=Buildin

Cheers
Sebastian

#28

Hey,

This means that the cn=Builtin sub-tree is not synchronized between OpenLDAP and Samba4 (see /etc/univention/connector/s4/mapping.py, it should contain cn=Builtin… in the global_ignore_subtree variable near the top). This is the default. You can change that to true in order to synchronize all groups.

That’s good, that’s good.

Have you added the sambaSID attribute in the OpenLDAP as I’ve described here? If not, please do so.

Afterwards reboot your UCS server & Windows client and try creating files as a meber of Domain Admins again.

Kind regards,
mosu

#29

Well, I used an LDAP Editor. Then I wanted to change the attributes in idmap.ldb - but it allready had changed its parameters. I think because of the listener?

The funny thing is, it’s still the same behaviour.

Do you think it would be better to change the connector/s4/mapping/group/grouptype parameter to true? Just to ensure that all mandatory groups are in place?

Cheers
Sebastian

#30

Hey,

well, it’s worth a try, but I wouldn’t get my hopes up. I’m pretty much out of ideas at this point.

Kind regards,
mosu

#31

Hi,

this topic is a bit old, for sure. Anyway, in the meantime I found the solution. The problem was a missing sambaSID object class of the group object “Administrators” in LDAP. I added the class and the mandatory attributes in the form S-1-5-21-our-domain-sid-544. This solved the problem with users in group “Administrators” that couldn’t be mapped on linux side.
Later on the migration could be finished successfully in the test environment.

Cheers
Sebastian

#32

That was a nice catch :+1:

Mastodon