Univention Bugzilla – Bug 33677
Samba doesn't generate proper SIDs on Memberservers in Single-Master setup
Last modified: 2014-10-06 16:05:01 CEST
I joined an additional Memberserver into an existing Single-Master domain. The Membersever doesn't belong to any of school specific groups, e.g. OUxxx-Memberserver-Edukativnetz but is positioned in cn=computers,$(ucr get ldap/base). No problems occurred at the point of joining the machine and operating it.
One big issue I ran into was the creation of LDAP objects on the Memberserver. These objects receive a SID that doesn't belong to the domain, i.e. S-1-4-5128, instead of S-1-5-*. Creating the same object on the Master doesn't cause any issues.
The problem is caused by the UCR variable directory/manager/samba3/legacy which is set to "yes" on the Master and is <empty> on the Memberserver. Setting it to "yes" on the Memberserver solves the problem.
Either we create a meta-package also for UCS@school member servers or we should set an UCR policy.
Could we simple copy the UCR variable from the master while joining the memberserver? I think it would work for most scenarios.
ucs-school-master and ucs-school-singlemaster now set a UCR policy "ucsschool-samba4" and reference it at the ldap/base. This is a more generic extension of the local UCR config already implemented via the ucs-school-metapackage postinst scripts (see Bug 26034).
During joins the policy is evaluated by 20univention-directory-policy.inst, no accounts are created locally
I've added two test cases: r50333
Waiting for jenkins results.
You are adding a new UCR policy to the base. This does not work if there is already a UCR policy at the base. I think you have to modify the UCR policy if exists.
Ok, fixed, The scripts now first check for UCR policies assigned to the ldap/base. If several are found, a warning is issued. If one of the existing registered UCR policies already sets the UCR variable, then that one is modified to set the value as desired. Otherwise the first registered UCR policy is ammended. If no UCR policy is found registered at ldap/base, then a new one is created and assigned.
OK, it works like expected. An existing policy is updated or a new policy is created.
Jenkins result for the memberserver scenario:
UCS@school 3.2 R2 has been released:
If this error occurs again, please use "Clone This Bug".