Nextcloud bind password invalid

Apps & App Center
,
#1

Somehow, the nextcloud docker instance lost (or didn’t renew) the “maschinenkonto”-credentials.
(Didn’t check this regularly. Possible it happens sometimes between ucs or nextcloud upgrades)

root@nextc-40486529:/var/log# sudo -u www-data /var/www/html/occ ldap:test-config s01
The configuration is valid, but the Bind failed. Please check the server settings and credentials.

Whats the normal use case in that case?

  • re-execute the join script?
  • chance the password for the machine in ucs and nextcloud config?

Thx a lot,
best,
meg

#2

There shouldnt be any usage of an expring machine account for installations since mid 2017.
see


and

There was a discussion here about the password renewal (in german)

A long term solution would need more information, especially which bind-user is used and how its password got expired (if applicable).

Best Regards,
Dirk

#3

Hi ahrnke,

thanks for response…

Seems the problem isn’t fixed yet:

| ldapAgentName                 | cn=nextc-40486529,cn=memberserver,cn=computers,dc=xxx,dc=xxx |
| ldapAgentPassword             | ***

System is an UCC Appliance installed (deployed) in Feb '18.

#4

It might be a different one. The situation discussed in the mentioned threads was dealing with the fact that the machine account of the UCS-host was used. Now there is an account for the (docker-)guest. I dont see atm, where the guest would change the password which would be the case when the account of an UCS-machine is used.
Is there a chance that a password policy is in place which could also expire the password for the nextc-40486529 account?

#5

As far as I know, machine accounts change passwords every 30 days?
That’s why the linked issue recommends using a user account for this case.

But normally this change should be initiated by the client/machine.

#6

Almost true for UCS-based systems, see https://docs.software-univention.de/developer-reference-4.3.html#join:secret:change
The Nextcloud Docker image is based on Ubuntu which will most likely not change its password.

Thats why I asked for password policy which could include UCS-policies as well as Samba/Windows (e.g. shown by samba-tool domain passwordsettings show or specific GPOs)

#7

Nothing of this was changed:

samba-tool domain passwordsettings show
Minimum password age (days): 0
Maximum password age (days): 0

univention-config-registry get server/password/interval
21
#8

ok, this means that there is no global policy for Samba, but we still dont know if there is a password policy in UCS (see https://docs.software-univention.de/handbuch-4.3.html#central:policies) or some non-global rule in Samba.

It might be useful to check the general account status of the nextc-40486529 account, e.g. if it is locked.
You can also have a look at the sambaPwdLastSet-Attribute for this account. There are some “Epoch”/“Unix Timestamp” converters available which can translate the string to a readable date. This way you can at least figure out when the password was changed last time.

It might be also worth to check if the original password, which is stored in /etc/machine.secret inside the container (!) is still valid.

Forget about server/password/interval in this case, it does not apply.

1 Like
#9 
DN: cn=nextc-40486529,cn=memberserver,cn=computers,dc=xxx,dc=com

POLICY cn=nextc-40486529,cn=memberserver,cn=computers,dc=xxx,dc=com

Policy: cn=default-users,cn=admin-settings,cn=users,cn=policies,dc=xxx,dc=com
Attribute: univentionAdminMayOverrideSettings
Value: 0

Policy: cn=default-users,cn=admin-settings,cn=users,cn=policies,dc=xxx,dc=com
Attribute: univentionAdminListWebModules
Value: modself

Policy: cn=default-users,cn=admin-settings,cn=users,cn=policies,dc=xxx,dc=com
Attribute: univentionAdminListWizards
Value: None

Policy: cn=default-settings,cn=pwhistory,cn=users,cn=policies,dc=xxx,dc=com
Attribute: univentionPWLength
Value: 8

Policy: cn=default-settings,cn=pwhistory,cn=users,cn=policies,dc=xxx,dc=com
Attribute: univentionPWHistoryLen
Value: 3

Policy: cn=default-settings,cn=ldap,cn=policies,dc=xxx,dc=com
Attribute: univentionLDAPServer
Value: ucs.xxx.com

Policy: cn=selfservice-umc-servers,cn=UMC,cn=policies,dc=xxx,dc=com
Attribute: umcPolicyGrantedOperationSet
Value: cn=passwordreset-all,cn=operations,cn=UMC,cn=univention,dc=xxx,dc=com

Policy: cn=app-update-schedule,cn=policies,dc=xxx,dc=com
Attribute: univentionCronActive
Value: 1

Policy: cn=app-update-schedule,cn=policies,dc=xxx,dc=com
Attribute: univentionCron
Value: 5 1 * * * 

Policy: cn=app-release-update,cn=policies,dc=xxx,dc=com
Attribute: univentionUpdateActivate
Value: TRUE

131637976480000000 … what is that? picoseconds?

It is … strange.

So it seems the password on nextcloud setup was changed?

Have set the password manually like described here

#10

I can not say where this comes from.
From my demo system:

dn: cn=nextc-05083597,cn=memberserver,cn=computers,dc=...
sambaPwdLastSet: 1533890508

# date -d @1533890508
Fr 10. Aug 10:41:48 CEST 2018

In this case I see the date where Nextcloud was installed.

I dont know. What you can do:

  • read the password with univention-app shell nextcloud cat /etc/machine.secret
  • check if this password is valid, for example using kinit nextc-40486529$ (ldapsearch would be better but is more complicated)

If the password is valid you can change/set the ldapAgentPassword using occ.

Mastodon