Bug 27264 - objectSid von Gruppen wird wiederholt von UCS nach S4 geschrieben
objectSid von Gruppen wird wiederholt von UCS nach S4 geschrieben
Status: RESOLVED DUPLICATE of bug 32322
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 3.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: Connector maintainers
:
Depends on:
Blocks: 27265
  Show dependency treegraph
 
Reported: 2012-05-23 18:19 CEST by Arvid Requate
Modified: 2014-03-19 17:43 CET (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
connector-s4.log von UCS@School 3.0 Samba 4 DC Slave Join und anschliessendem Anlegen von Klasse 1A und testschueler1 (1.90 MB, text/plain)
2012-05-23 19:52 CEST, Arvid Requate
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2012-05-23 18:19:06 CEST
Wenn man connector/debug/level=4 vor dem Joinen in OU=SITE1 setzt, dann sieht man z.B. auf einem UCS@School 3.0 Slave:


1. Nach dem initialen Anlegen der Schul-OU per "create_ou SITE1 slave":
==============================================================================
16.04.2012 22:14:20,157 LDAP        (PROCESS): sync from ucs: [         group] [       add] cn=OUsite1-DC-Edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
16.04.2012 22:14:20,158 LDAP        (INFO   ): sync_from_ucs: add object: cn=OUsite1-DC-Edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
16.04.2012 22:14:20,159 LDAP        (INFO   ): addlist: [('objectClass', ['top', 'group']), ('objectSid', ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00{!,\x03>E\xd2\xb7\xa0\x15\xa6\xa2O+\x00\x00']), ('sAMAccountName', ['OUsite1-DC-Edukativnetz'])
==============================================================================

und ein wenig später:
==============================================================================
16.04.2012 22:14:40,839 LDAP        (PROCESS): sync from ucs: [         group] [       add] cn=ousite1-dc-edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
16.04.2012 22:14:40,843 LDAP        (INFO   ): get_object: got object: CN=OUsite1-DC-Edukativnetz,CN=ucsschool,CN=Groups,DC=arucs3s4x1,DC=qa
16.04.2012 22:14:40,843 LDAP        (INFO   ): encode_s4_object: attrib objectGUID ignored during encoding
16.04.2012 22:14:40,843 LDAP        (INFO   ): sync_from_ucs: modify object: cn=ousite1-dc-edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
16.04.2012 22:14:40,844 LDAP        (INFO   ): sync_from_ucs: modlist: [(2, 'objectSid', ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00{!,\x03>E\xd2\xb7\xa0\x15\xa6\xa2O+\x00\x00'])]
==============================================================================

Hier ist die objectSid eigentlich unverändert und ein modify nicht notwendig.



2. Dann folgt eine modify-Meldung, der anscheinend keine modlist-Operation folgt:
==============================================================================
16.04.2012 22:15:11,25 LDAP        (PROCESS): sync to ucs:   [         group] [    modify] cn=ousite1-dc-edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
==============================================================================


3. Dann wurde zum Test per UDM eine Klasse in OU=SITE1 angelegt und ein Schüler mit dieser Klasse angelegt. Daraufhin sieht man im connector-s4.log:
==============================================================================
17.04.2012 02:31:50,801 LDAP        (PROCESS): sync from ucs: [         group] [    modify] cn=ousite1-dc-edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
17.04.2012 02:31:50,802 LDAP        (INFO   ): get_object: got object: CN=OUsite1-DC-Edukativnetz,CN=ucsschool,CN=Groups,DC=arucs3s4x1,DC=qa
17.04.2012 02:31:50,802 LDAP        (INFO   ): encode_s4_object: attrib objectGUID ignored during encoding
17.04.2012 02:31:50,803 LDAP        (INFO   ): sync_from_ucs: modify object: cn=ousite1-dc-edukativnetz,cn=ucsschool,cn=groups,dc=arucs3s4x1,dc=qa
17.04.2012 02:31:50,803 LDAP        (INFO   ): sync_from_ucs: modlist: [(2, 'objectSid', ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00{!,\x03>E\xd2\xb7\xa0\x15\xa6\xa2O+\x00\x00'])]
==============================================================================

Auch hier ist die objectSid eigentlich unverändert und ein modify nicht notwendig.


+++ This bug was initially created as a clone of Bug #26971 +++
Comment 1 Arvid Requate univentionstaff 2012-05-23 19:19:35 CEST
Note: Die Verwendung des provision Controls wird im aktuellen Code deaktiviert, wenn zusätzlich zum Default connector/s4/mapping/sid == true
manuell connector/s4/mapping/sid_to_s4 = false gesetzt wird. Dann sieht man einen UNWILLING_TO_PERFORM Traceback pro modify, wohingegen die add-Operationen mit objectSid auch ohne das Control korrekt funktionieren.
Comment 2 Arvid Requate univentionstaff 2012-05-23 19:52:55 CEST
Created attachment 4388 [details]
connector-s4.log von UCS@School 3.0 Samba 4 DC Slave Join und anschliessendem Anlegen von Klasse 1A und testschueler1

Unter anderem sieht man nach dem initialen

sync_from_ucs: modify object: CN=SLAVE,ou=domain controllers,dc=arucs3s4x1,dc=qa

auch einen zweiten Modify auf objectSid für die lowercase-Variante:

sync_from_ucs: modify object: cn=slave,ou=domain controllers,dc=arucs3s4x1,dc=qa
Comment 3 Stefan Gohmann univentionstaff 2012-05-24 06:13:08 CEST
Das sollten wir mit einem normalen UCS Update beheben.
Comment 4 Stefan Gohmann univentionstaff 2014-03-19 17:43:16 CET

*** This bug has been marked as a duplicate of bug 32322 ***