Univention Bugzilla – Bug 52261
AD-Connector reject "valueRequired" attribute which is present
Last modified: 2020-12-09 13:11:53 CET
univention-app info UCS: 4.4-6 errata776 Installed: adconnector=12.0 itslearning=3.2 self-service=4.0 self-service-backend=4.0 ucs-to-school-transformer=1.3.2 ucsschool=4.4 v7 ucsschool-kelvin-rest-api=1.1.1 Upgradable: ucsschool-kelvin-rest-api AD-Connector is in sync mode We are facing following behaviour: - an attribute (extendedAttribute) of user is removed in AD, so its configured ignorefilter applies - the user is removed from UCS by hand afterwards; due to the ad-connector-ignorefilter the user will not be removed automatically - if the user regains the attribute, which was deleted before, the ad-connecter starts the sync of the user to ucs, but rejects the sync with error "valueRequired: The property Last name is required", but the attribute is present. Overall the AD-connector is working, i.e. when new users are created in AD, they are synced and processed to UCS correctly.
let me update my description by a more detailed one: * AD-Connector is in sync mode We are facing following behaviour: * an attribute (extendedAttribute (mvSchools) of user is removed in AD, so its configured ignorefilter applies and the user won't be updated after this action * the user is removed from UCS by hand afterwards (the (extendedAttribute (mvSchools) ist deleted prior to that), due to the ad-connector-ignorefilter mentioned before, the user will not be removed automatically * if the user regains the ext. attribute, which was deleted before, the ad-connecter starts the sync of the user to ucs, but it rejects the sync with error "valueRequired: The property Last name is required", but the attribute is and was present the whole time. Overall the AD-connector is working, i.e. when new users are created in AD, they are synced and processed to UCS correctly.
Two observations from the mapping attached to Comment 5: 1. The mapping between UDM:mvDst and AD:mvSchools is in the postAttibutes section. Since you mention the LDAP attribute univentionFreeAttribute16, I can only guess that the UDM property "mvDst" is defined as a custom attribute backed by that LDAP attribute. If that is true then it would be interesting, if that custom attribute es marked as required. If that is the case, then I guess it may need to go into the "attributes" section of the mapping to tell the AD-Connector to add the attribute directly during the LDAP add, instead of putting it into the "postAttributes", which AFAIR are handled in a following modify. 2. The mapping specifies the mapping between UDM:mvDst and AD:mvSchools twice. Once under the key "msDst" and once under the key "mvSchools". I guess the former is correct. Maybe it even doesn't matter which key you use. But specifying it twice doesn't seem right.
In this case, a modification on the ad object is done,the modification is synced to ucs, converted to an "add" because no corresponding ucs_object is found. The function "def __set_values()" only sets any attribute "if changed". Since in this case, username, lastname and other required attributes have not changed, it tries to create an ucs_object solely with the changed attribute set. In this case mvDst, which is then rejected by udm. A solution would be if all attributes, whether changed or not are set, if the modification type is "add". The branch jbremer/bug52261-ADConnector-reject-valueRequired contains a test which reproduces the issue and a fix. https://git.knut.univention.de/univention/ucs/-/tree/jbremer/bug52261-ADConnector-reject-valueRequired Jenkins test was successful (both failing tests test features that were not published yet): http://jenkins.knut.univention.de:8080/job/UCS%20Branch%20Test/528/testReport/55_adconnector/
Created attachment 10569 [details] generate strong password at creation The patch from comment 10 applied to the customers environment created rejects due to missing password complexity. This is actually another Bug similar to Bug #34478, just in the ad connector. The temporary password during creation in the ad connector only contains numbers, which doesn't satisfy the mspolicy. This patch adds the same password creation function to the adconnector we have in the s4connector. I updated my branch with the patch and an automated test case, the branch test is currently running
I created a new bug for the password complexity issue http://forge.univention.org/bugzilla/show_bug.cgi?id=52439
5c1fde05e2 Bug #52261: fix addition of previously ignored objects 367c1ad555 Bug #51804, Bug #52261, Bug #52439: yaml e1ddf0b64f Bug #52261: changelog Successful build Package: univention-ad-connector Version: 13.0.0-61A~4.4.0.202012011729 Branch: ucs_4.4-0 Scope: errata4.4-7 User: jbremer I applied the patch and made a test case. Waiting for test results
OK, looks good TODO - 5.0-0 MR OK - Jenkins Test OK - __set_values() OK - ucs-test OK - yaml
Created merge-request https://git.knut.univention.de/univention/ucs/-/merge_requests/46
OK
Question: Do we need a similar patch in the S4-Connector as well?
(In reply to Florian Best from comment #20) > Question: Do we need a similar patch in the S4-Connector as well? probably yes, @Julia what do you think
Just from looking at the code I'd say yes. But I'll check.
Surprisingly not, if an attribute is changed or not is determined correctly in the s4connector, the issue mentioned at this bug is not reproducible with S4.
<https://errata.software-univention.de/#/?erratum=4.4x833>