Bug 46377 – s4 connector does not sync users with flag functional

Bug 46377 - s4 connector does not sync users with flag functional


Summary:	s4 connector does not sync users with flag functional

Status:	CLOSED INVALID

Product:	UCS
Classification:	Unclassified
Component:	S4 Connector
Version:	UCS 4.3
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	Erik Damrose
QA Contact:	Florian Best

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2018-02-23 09:54 CET by Erik Damrose
Modified:	2019-10-30 10:32 CET (History)
CC List:	1 user (show)

See Also:
What kind of report is it?:	Development Internal
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):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Erik Damrose

2018-02-23 09:54:55 CET

The S4 connector does not sync OpenLDAP users with univentionObjectFlag: functional. These users do not count against the ucs licence. At Bug #33214 an additional functional user is created on all UCS systems, which is required to be synced to S4

Comment 1 Florian Best

2019-03-01 21:02:20 CET

These objects aren't even users/user objects. There is already a bug to change this.

Comment 2 Florian Best

2019-10-29 11:19:42 CET

Nowerdays the user is a "users/ldap" account. They don't get syncronized as well. Why is the syncronisation necessary, Erik?

dn: uid=sys-idp-user,cn=users,l=school,l=dev
uid: sys-idp-user
objectClass: person
objectClass: univentionPWHistory
objectClass: simpleSecurityObject
objectClass: top
objectClass: uidObject
objectClass: univentionObject
userPassword:: e2NyeXB0fSQ2JDRiSGFqMjd0RDJyWmkvMXEkNGN1dFdBNE1uVmhGVW5oSm16TGZKSGlIN0l6anFmZ1FtQVJlNWhxWXhaZk1ZN1VnVWtNZDRoSVczSURZbi5yc2dqaXNVcUt3NTJUWE1nR3dsektsdTA=
pwhistory: $6$BEwCS4k5NL63V1qD$MPJ6wHOgbrGuayxXa00..THAI6yfKDKc8HOTKgqses8tC.8PydXjjAJ84CLMeveUtWKcOde/m4zZGWgGWyBi11
sn: idp-user
univentionObjectType: users/ldap
cn: idp-user
univentionObjectFlag: functional
univentionObjectFlag: hidden

Comment 3 Erik Damrose

2019-10-29 11:40:03 CET

If i remember correctly the idea was to use this account not only for the SAML IdP ldap access but also as the kerberos service principal. We implemented another solution so there is currently no requirement anymore. I am resolving this as invalid.

Comment 4 Florian Best

2019-10-30 10:32:59 CET

OK