Bug 47683 - [4.3] use separate unprivileged LDAP account on each backup
[4.3] use separate unprivileged LDAP account on each backup
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: HTTP-API (Kelvin)
UCS@school 4.3
Other Linux
: P5 normal (vote)
: UCS@school 4.3 v5
Assigned To: Daniel Tröder
Ole Schwiegert
:
Depends on: 46829
Blocks:
  Show dependency treegraph
 
Reported: 2018-08-28 10:56 CEST by Daniel Tröder
Modified: 2018-09-11 11:34 CEST (History)
3 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:56:02 CEST
+++ This bug was initially created as a clone of Bug #46829 +++

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 11:24:11 CEST
To detect the situation run:

# 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

Response will be either:
dn: uid=Administrator,cn=users,$BASE
or
ldap_bind: Invalid credentials (49)
Comment 2 Daniel Tröder univentionstaff 2018-08-28 12:11:22 CEST
Each DC backup now uses its own user.

[4.3 f6281d380] Bug #47683: create different user on each DC backup
[4.3 38313ec32] Bug #47683: changelog
[4.3 a42dc98ed] Bug #47683: advisory

ucs-school-import (16.0.2-39)

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 3 Daniel Tröder univentionstaff 2018-08-28 12:19:54 CEST
gunicorn will be restarted (if installed) by ucs-school-import-http-api.postinst.
Comment 4 Ole Schwiegert univentionstaff 2018-09-04 08:20:57 CEST
Tested with 16.0.2-41A~4.3.0.201808311701

Advisory&Changelog: OK
New user for backup: OK
Tests from Comment2 works
Import still works: OK
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2018-09-11 11:34:17 CEST
UCS@school 4.3 v5 has been released.

https://docs.software-univention.de/changelog-ucsschool-4.3v5-de.html

If this error occurs again, please clone this bug.