Univention Bugzilla – Bug 50833
univentionBirthday can't be set initially via Self Service without write access to objectClass
Last modified: 2024-03-11 17:32:06 CET
If "univentionBirthday" is specified as an editable LDAP attribute in self-service/ldap_attributes it triggers a permissionDenied error because changing the birthday also adds the objectClass "univentionPerson". So admins would have to allow the users to change their own objectClasses to make it work or set it to a default value for all users. That gets even more difficult because "univentionBirthday" can't be added to user templates for some reason. If there's no technical reason we need "univentionPerson" as an objectClass for "univentionBirthday", I propose the removal of "univentionBirthday" from the objectClass definition. If there's a technical reason why "univentionBirthday" needs "univentionPerson" or vice versa, there should still be a way to allow changing "univentionBirthday" via the Self Service without giving users write access to their objectClasses.
(In reply to Valentin Heidelberger from comment #0) > If "univentionBirthday" is specified as an editable LDAP attribute in > self-service/ldap_attributes it triggers a permissionDenied error because > changing the birthday also adds the objectClass "univentionPerson". So > admins would have to allow the users to change their own objectClasses to > make it work or set it to a default value for all users. That gets even more > difficult because "univentionBirthday" can't be added to user templates for > some reason. can you file a separate Bug for the user template issue? > If there's no technical reason we need "univentionPerson" as an objectClass > for "univentionBirthday", I propose the removal of "univentionBirthday" from > the objectClass definition. I assume that univentionBirthday is only availble in univentionPerson and based on that assumption I don't see a way to solve it differently. > If there's a technical reason why "univentionBirthday" needs > "univentionPerson" or vice versa, there should still be a way to allow > changing "univentionBirthday" via the Self Service without giving users > write access to their objectClasses. Potential workarounds: - consider to allow writing to the objectClass attribute in the self service (this should be possible with the existing UCR configuration) - identify an other attribute of univentionPerson and define a usefull default, so that new accounts will have this objectClass (currently attributes are quotablocksoft $ quotablockhard $ quotafilesoft $ quotafilehard $ temporary $ virtual $ univentionBirthday $ univentionUMCProperty )
We have an other customer, but using a different attribute to be added, getting access-denied error. The customer uses Self-Service, tab "Your Profile", to have the LDAP attribute "univentionPasswordSelfServiceMobile" filled in by the user. Saving shows access-denied. The reason for this is the objectClass "univentionPasswordSelfService", which is set for users who add either a self-service telephone number or a self-service e-mail address. If the e-mail address is stored, not via the "Your profile" tab but via "Protect account access", the objectClass can be added. Adding the "objectClass" to the UCR variable in "self-service/ldap_attributes" is not a good workaround and also a security vulnerability
We will "fix" this once the Self Service is migrated to use Guardian instead of LDAP ACLs to enforce access control. As Guardian is pure attribute based and is separated from the LDAP access, the problems here won't occure. Until then, I don't see additional options than the workarounds listed in comment 1. Unfortunately I can't give a timeline for the guardian integration yet.