Bug 26055 - objectSid direkt setzen
objectSid direkt setzen
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 3.0
Other Linux
: P5 enhancement (vote)
: UCS 3.0-2
Assigned To: Stefan Gohmann
Arvid Requate
: interim-2
Depends on:
Blocks: 27105 26971
  Show dependency treegraph
 
Reported: 2012-02-08 11:29 CET by Stefan Gohmann
Modified: 2012-07-20 15:24 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): UCS Performance
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2012-02-08 11:29:53 CET
Die sambaSID wird aktuell im post-modify gesetzt. Würde die SID direkt im Mapping gesetzt werden, könnte man sich ggf. einen erneuten Sync des Users sparen.

Siehe auch Bug #26005#c1.
Comment 1 Stefan Gohmann univentionstaff 2012-05-10 08:53:29 CEST
Das gesamte SID Mapping ist relativ kompliziert geworden, u.a. ist ein Problem in der Mapping Definition, dass es im UCS einen Unterschied zwischen dem LDAP Attribut (sambaSID) und dem UCS / UDM Attribut gibt (sambaRID).

Das andere Problem ist, dass für die Samba 4 Migration die SIS aus dem Samba 4 LDAP in das Attribut univentionSamba4SID, wenn connector/s4/mapping/sid auf false gesetzt wird.

Zusätzlich kann man beim SID Mapping definieren, ob die SID von UCS nach S4 oder von S4 nach UCS oder beides synchronisiert werden soll.

Es gibt die folgenden UCR Variablen:
 - connector/s4/mapping/sid
 - connector/s4/mapping/sid_to_s4
 - connector/s4/mapping/sid_to_ucs

Per Default ist es in UCS so, dass connector/s4/mapping/sid_to_ucs aktiviert ist und die SID somit von Samba 4 vorgegeben und verwendet wird. Wird ein Benutzer im UCS angelegt, so bekommt er eine temporäre SID im UCS, wird im S4 mit einer neuen von Samba 4 vergebenen SID angelegt und dieses SID wird wieder zurück synchronisiert.
Im UCS@school Setup wird die SID von UCS vorgegeben. In diesem Fall wird connector/s4/mapping/sid_to_s4 aktiviert und connector/s4/mapping/sid_to_ucs deaktiviert. Damit wird beim Anlegen eines Benutzers die SID immer von UCS generiert.

Das Mapping wurde aufgrund der Komplexität und der Problematik, dass univentionSamba4SID nicht im UDM definiert ist. Wenn univentionSamba4SID genutzt werden soll, dann werden die bisherigen post-modify-Funktionen verwendet. Wenn ein direktes Mapping erfolgen soll, dann wird das über ein attribute Mapping definiert.
Comment 2 Stefan Gohmann univentionstaff 2012-05-11 07:14:49 CEST
Wenn jetzt das Mapping so eingestellt ist, dass die SID von S4 nach UCS synchronisiert wird, dann wird angezeigt, dass die SID nicht geändert werden darf:

25.04.2012 21:29:24,893 LDAP        (PROCESS): sync to ucs:   [          user] [    modify] ui
d=test2,cn=users,dc=deadlock32,dc=local
25.04.2012 21:29:24,907 LDAP        (ERROR  ): Value may not change: key=sambaRID old=5026 new
=1127 (uid=test2,cn=users,dc=deadlock32,dc=local)

Mir fällt aktuell kein Grund ein, warum die RID nachträglich über den UDM nicht geändert werden sollte. Die Änderung sollte im UDM Modul erlaubt werden.
Comment 3 Stefan Gohmann univentionstaff 2012-05-11 23:17:58 CEST
(In reply to comment #2)
> Wenn jetzt das Mapping so eingestellt ist, dass die SID von S4 nach UCS
> synchronisiert wird, dann wird angezeigt, dass die SID nicht geändert werden
> darf:
> 
> 25.04.2012 21:29:24,893 LDAP        (PROCESS): sync to ucs:   [          user]
> [    modify] ui
> d=test2,cn=users,dc=deadlock32,dc=local
> 25.04.2012 21:29:24,907 LDAP        (ERROR  ): Value may not change:
> key=sambaRID old=5026 new
> =1127 (uid=test2,cn=users,dc=deadlock32,dc=local)
> 
> Mir fällt aktuell kein Grund ein, warum die RID nachträglich über den UDM nicht
> geändert werden sollte. Die Änderung sollte im UDM Modul erlaubt werden.

Das betrifft Benutzer, Gruppen und DCs. Bei den Gruppen müsste auch das Attribut sambaPrimaryGroupSID der Benutzer mit geändert werden.
Comment 4 Stefan Gohmann univentionstaff 2012-05-14 08:38:22 CEST
Wurde hinzugefügt.
Comment 5 Arvid Requate univentionstaff 2012-05-23 19:24:29 CEST
Ggf. könnten Bug 27264 und Bug 27265 noch berücksichtigt werden.
Comment 6 Stefan Gohmann univentionstaff 2012-06-27 08:40:46 CEST
(In reply to comment #5)
> Ggf. könnten Bug 27264 und Bug 27265 noch berücksichtigt werden.

Ich denke das reicht später, da die Performance auch bei 50.000 Benutzern im UCS@school Umfeld gut ist.
Comment 7 Arvid Requate univentionstaff 2012-07-03 17:07:46 CEST
Verified:
* Die Anpassungen aus Bug 26971 Comment 4 sind übernommen.
* sambaPrimaryGroupSID an Benutzern wurde über Bug 27157 umgesetzt.
* Changelog OK
Comment 8 Stefan Gohmann univentionstaff 2012-07-20 15:24:26 CEST
UCS 3.0-2 has been released: 
  http://forum.univention.de/viewtopic.php?f=54&t=1905

If this error occurs again, please use "Clone This Bug".