Univention Bugzilla – Bug 51676
Serverpasswordchange fails if ppolicy is enabled
Last modified: 2020-10-05 09:05:31 CEST
Serverpasswordchange fails on memberserver: Starting server password change (Tue Jul 7 01:08:52 CEST 2020) Proceeding with regular server password change scheduled for today ... run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd prechange Permission denied. run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server nochange univention-nscd prechange is last script in directory. File permissions and ownership is correct. Colleague DirkA has the same problem in different environment. He discovered that the following udm command in /usr/lib/univention-server/server_password_change throws the error.
Under what circumstances does this happen: always, after installing certain components, ...?
I have opened ticket for another customer where the same symptoms are visible. There is at least a correlation to the the time where ppolicy was enabled, the problem started afterwards.
(In reply to Dirk Ahrnke from comment #2) > I have opened ticket for another customer where the same symptoms are > visible. > > There is at least a correlation to the the time where ppolicy was enabled, > the problem started afterwards. can you give more details about "ppolicy"?
> can you give more details about "ppolicy"? the feature is documented in https://docs.software-univention.de/handbuch-4.4.html#users:faillog-openldap
I am at least for the case I have reported quite sure that the problem ist related to the ppolicy overlay. When having ppolicy active, changing the machine password with udm-cli by using vaild machine credential always fails with "Permission denied". Changing the password with udm-cli as root without specifying other credentials is still possible. After disabling ppolicy by setting the corresponding UCRVs to "no" I tried to set the machine password with udm-cli and the machine credentials, I got "LDAP Error: Undefined attribute type: entry update failed" instead. I would expect that this is rather caused by remnants of the ppolicy overlay that had to be removed.
(In reply to Dirk Ahrnke from comment #5) > I am at least for the case I have reported quite sure that the problem ist > related to the ppolicy overlay. OK, I made the subject more specific. "Workaround" to avoid this error could be to deactivate the automatic password rotation on memberserver instances.
In my case it was an update. UCS 4.4.4-624 worked. The problem occurred with univention-errata-level_4.4.4-648, but could be caused by all updates since errata 624. Customer is not using ppolicy: user@ucs:~$ sudo ucr search ldap/ppolicy user@ucs:~$
I changed back the topic as it is not ppolicy in my case! No real workaround. Customer can keep password by touch secret file or set UCR to a higher value, but server_password_change is and stays broken.
See also Bug #37915 if it has something to do with ppolicy overlay module.
Let's collect facts instead of speculating. Ticket#2020071021000427 even has slpad logs, they should be given here: ============================================================================== Jul 10 01:06:23 kepler slapd[2442]: conn=364193 op=17 MOD dn="cn=foo,cn=memberserver,cn=computers,dc=corp,dc=net" Jul 10 01:06:23 kepler slapd[2442]: conn=364193 op=17 MOD attr=krb5Key krb5KeyVersionNumber userPassword sambaNTPassword sambaPwdLastSet Jul 10 01:06:23 kepler slapd[2442]: conn=364193 op=17 RESULT tag=103 err=50 text=User alteration of password is not allowed ============================================================================== Unless the other ticket shows the same, they should not be lumped together.
(In reply to Arvid Requate from comment #10) > Unless the other ticket shows the same, they should not be lumped together. In addition: we have an automated test which ensures that password changes work for server instances. We need to identify the differences between a "plain UCS" and the customer environments which create the problem. @Dirk & Dirk - can you split this into two Bugs and describe the priorities?
Before we split I would suggest to check if updates are also meet in DirkA scenario...UCS 4.4.4-624 or before worked On my customers environment it was the only (found) change between the two passwordchanges.
Cannot reproduce w/o ppolicy: root@member13:~# univention-app info UCS: 4.4-4 errata652 Installed: samba-memberserver=4. Upgradable: root@member13:~# /usr/lib/univention-server/server_password_change root@member13:~# univention-ldapsearch -LLLs base 1.1 dn: dc=ar41i1,dc=qa No errors in /var/log/univention/server_password_change.log
Created attachment 10435 [details] server_password_change.log OK memberserver 4.4-4 errata652
I get the same error message on two slave-servers which are connected via openVPN to master/backup-servers. I started getting the cron-error message 03.07.2020 - it could be related to some the mentioned update at the time. There is also another user in the forum reporting the error. https://help.univention.com/t/error-change-server-password-via-cron/15058 They persist in 4.4-5 errata652
My fault. Ppolicy is enabled. I checked the member and not the master. root@master:/home/user# ucr get ldap/ppolicy yes root@master:/home/user# ucr get ldap/ppolicy/enabled yes One of the two bugs are duplicate now.
This is reproducible. Regarding Comment 5: > After disabling ppolicy by setting the corresponding UCRVs to "no" I tried to set the machine password with udm-cli and the machine credentials, I got "LDAP Error: Undefined attribute type: entry update failed" instead. I would expect that this is rather caused by remnants of the ppolicy overlay that had to be removed. Yes, in my test I had to temporarily re-activate ppolicy to be able to to remove the operational attributes: bash -c 'eval "$(ucr shell)"; while read -r; do [ -n "$REPLY" ] && echo -e "$REPLY\nchangetype: modify\ndelete: pwdChangedTime" | ldapmodify -D "cn=admin,$ldap_base" -y /etc/ldap.secret -e relax; done < <(univention-ldapsearch -LLL pwdChangedTime=* 1.1)' Leftover attributes that are not defined in the OpenLDAP schema any longer show up as fully uppercase in ldapsearch output and the operational attributes can be shown by appending '+' to the search.
*** Bug 51684 has been marked as a duplicate of this bug. ***
Same for normal users if ucr set ldap/acl/user/password/change='yes' is enabled too. Also applies to Administrator account if it tries to modify its own password. But Administrator can successfully change other user passwords.
The patch from Bug 37915 Comment 8 doesn't seem to fix this.
(In reply to Arvid Requate from comment #19) > Same for normal users if > > ucr set ldap/acl/user/password/change='yes' > > is enabled too. > > Also applies to Administrator account if it tries to modify its own password. > But Administrator can successfully change other user passwords. -> increase "Who" and "How"
This issue is caused by an explicit default setting in cn=default,cn=ppolicy,cn=univention,$ldap_base : ===================================================================================== root@master10:~# univention-ldapsearch -LLL objectclass=pwdPolicy pwdAllowUserChange dn: cn=default,cn=ppolicy,cn=univention,dc=ar41i1,dc=qa pwdAllowUserChange: FALSE ===================================================================================== Workaround: eval "$(ucr shell)"; echo -e "dn: cn=default,cn=ppolicy,cn=univention,$ldap_base\nchangetype: modify\nreplace: pwdAllowUserChange\npwdAllowUserChange: TRUE" \ | ldapmodify -D "cn=admin,$ldap_base" -y /etc/ldap.secret
Created attachment 10436 [details] patch proposal To fix this on updates we probably need to increment the joinscript version. Maybe this would be good for UCS 5.0.
(In reply to Arvid Requate from comment #22) > This issue is caused by an explicit default setting in > cn=default,cn=ppolicy,cn=univention,$ldap_base : > > ============================================================================= > ======== > root@master10:~# univention-ldapsearch -LLL objectclass=pwdPolicy > pwdAllowUserChange > dn: cn=default,cn=ppolicy,cn=univention,dc=ar41i1,dc=qa > pwdAllowUserChange: FALSE > ============================================================================= > ======== > > Workaround: > > eval "$(ucr shell)"; echo -e "dn: > cn=default,cn=ppolicy,cn=univention,$ldap_base\nchangetype: modify\nreplace: > pwdAllowUserChange\npwdAllowUserChange: TRUE" \ > | ldapmodify -D "cn=admin,$ldap_base" -y /etc/ldap.secret The workaround works for me.
b43365fe64 | make ppolicy allow users to change their own password d609b5d28a | UCS-5 changelog entry Package: univention-ldap Version: 16.0.0-7A~5.0.0.202008041052 Branch: ucs_5.0-0
OK: upgrade OK: changelog entry
Instead of UCS 5.0 the change has been implemented to UCS 4.4-6 in: changelog-4.4-6.xml c140d92e3c9e | Bug #51676: add changelog entry univention-ldap (15.0.0-41) 51e8246a0462 | Bug #51676: make ppolicy allow users to change their own password
*** Bug 52059 has been marked as a duplicate of this bug. ***
The postinst script shut down the ldap server to call ldap_setup_index and afterwards without starting it again executes the joinscripts. This then causes that every ldap interaction failed there. The slapd is now started again after calling ldap_setup_index. univention-ldap (15.0.1-1) 8318c9a87975 | Bug #51676: start slapd after ldap_setup_index
OK - univention-ldap-server # before -> udm computers/memberserver modify --dn "cn=member,cn=memberserver,cn=computers,dc=four,dc=four" --binddn "cn=member,cn=memberserver,cn=computers,dc=four,dc=four" --bindpwd univention --set password=univention1 Permission denied. # after -> udm computers/memberserver modify --dn "cn=member,cn=memberserver,cn=computers,dc=four,dc=four" --binddn "cn=member,cn=memberserver,cn=computers,dc=four,dc=four" --bindpwd univention --set password=univention1 Object modified: cn=member,cn=memberserver,cn=computers,dc=four,dc=four OK - changelog entry OK - update
UCS 4.4-6 has been released: https://docs.software-univention.de/release-notes-4.4-6-en.html https://docs.software-univention.de/release-notes-4.4-6-de.html If this error occurs again, please use the "Clone This Bug" option.