Bug 47682 - [4.2] use separate unprivileged LDAP account on each backup
[4.2] use separate unprivileged LDAP account on each backup
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: HTTP-API (Kelvin)
UCS@school 4.2
Other Linux
: P5 normal (vote)
: UCS@school 4.2 v11
Assigned To: Daniel Tröder
Ole Schwiegert
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-28 10:55 CEST by Daniel Tröder
Modified: 2018-11-22 15:35 CET (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 4: A User would return the product
User Pain: 0.229
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2018082321000432
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Tröder univentionstaff 2018-08-28 10:55:58 CEST
+++ This bug was initially created as a clone of Bug #46829 +++
+++ This bug was initially created as a clone of Bug #45164 +++

The package "ucs-school-import" is installed on the DC master and all DC backups.
The join script creates an LDAP user "uid=importhttpapi,cn=users,$ldap_base" and stores its password in /etc/ucsschool-import/ldap_unprivileged.secret.
(It actually stores "$LDAP_USER_DN:$ldap_base:$LDAP_SECRET_PW".)
The password is generated on each system - and thus different on each system
When the join script runs, it always sets the password from an existing file or creates a new one.

With subsequent runs of the join script on the different DC backups, the LDAP users password is changed. When the import code wants to use it on the DC master it then uses the password from its file and fails.

1) Create a separate non-privileged LDAP user on each DC backup: "uid=importhttpapi-$hostname".
2) Don't change the user on the DC master ("uid=importhttpapi"), but change its password. That will fix all customer systems. Restart gunicorn afterwards.
Comment 1 Daniel Tröder univentionstaff 2018-08-28 12:11:15 CEST
Each DC backup now uses its own user.

[4.2 c5516f475] Bug #47682: create different user on each DC backup
[4.2 474666e05] Bug #47682: changelog
[4.2 415c51026] Bug #47682: advisory
[4.2 61223b860] Bug #47682: fix merge error: JS version is lower in 4.2
[4.2 b27449e52] Bug #47682: advisory update

ucs-school-import (15.0.3-67)

Test by running on both DC master and DC backup:

# FILE_DN="$(cut -f 1 -d : /etc/ucsschool-import/ldap_unprivileged.secret)"
# PYTHON_DN="$(python -c 'from ucsschool.importer.utils.ldap_connection import get_unprivileged_connection; lo, po = get_unprivileged_connection(); print lo.lo.binddn')"
# [ $FILE_DN = $PYTHON_DN ] && echo OK

# DN="$(cut -f 1 -d : /etc/ucsschool-import/ldap_unprivileged.secret)" BASE="$(cut -f 2 -d : /etc/ucsschool-import/ldap_unprivileged.secret)" PW="$(cut -f 3 -d : /etc/ucsschool-import/ldap_unprivileged.secret)"
# ldapsearch -LLL -x -D $DN -b $BASE -w $PW uid=Administrator dn
Comment 2 Daniel Tröder univentionstaff 2018-08-28 12:19:50 CEST
gunicorn will be restarted (if installed) by ucs-school-import-http-api.postinst.
Comment 3 Ole Schwiegert univentionstaff 2018-09-04 09:41:41 CEST
Tested with ucs-school-import 15.0.3-67A~4.2.0.201808281206

Changelog&Advisory: OK
Package installed: OK
separate user created: OK
Tests proposed in Comment1 work: OK
Import still works: OK
Comment 4 Sönke Schwardt-Krummrich univentionstaff 2018-09-11 11:33:37 CEST
UCS@school 4.2 v11 has been released.

https://docs.software-univention.de/changelog-ucsschool-4.2v11-de.html

If this error occurs again, please clone this bug.
Comment 5 Daniel Tröder univentionstaff 2018-11-22 12:41:54 CET
This has lead to usernames with length > 20, which produces a traceback and thus rejects in the ad-connector.
Comment 6 Daniel Tröder univentionstaff 2018-11-22 15:35:37 CET
(In reply to Daniel Tröder from comment #5)
> This has lead to usernames with length > 20, which produces a traceback and
> thus rejects in the ad-connector.
Turns out, that at the customers system the migration from 4.2 to 4.3 od a users/user object with option "ldap_pwd" to users/ldap didn't succeed.
So the user was now a full users/user object in 4.3, which the s4/ad-connectors syncs.
Solution was to simply delete the account and run the join script again, which will create a users/ldap object, which is ignored by s4/ad-connectors.