I had this issue for some users and got it “fixed” in my 26.0.0 nextcloud instance. (this is a bug, but you can fix it with some workarounds)
In my situation we use LDAP as the only user backend. But actual logins use SAML SSO.
If a user has ever logged into nextcloud via ldap directly, using either the special direct login url ( https://nextcloud/index.php/login?direct=1 ), or via a direct WebDAV client connection (winscp in my test case), they will then begin to see the error above anytime they try to login via SAML from that point forward.
Something about the auth token that gets issued for the direct login is corrupt, and that user can then no longer login via SAML. They begin getting that error on all subsequent login attempts.
To fix:
Option 1 Fix a single user:
Delete ALL authtoken entries for the affected user: (note this logs them out of EVERYTHING, all desktop, browser, and mobile clients)
DELETE FROM oc_authtoken WHERE uid LIKE 'bob';
Option 2 - Fix for everyone in the nextcloud instance:
In my scenario, where saml is the only valid login type that should be allowed, i notice users that have the issue, their authtoken’s have a ‘password_hash’ value present, this seems to indicate the corruption is present, as the saml users shouldn’t have a password, nor password hash set since they don’t use passwords to login.
Here’s a full scale delete, that should only target the corrupt authtokens based on the presence of ‘password_hash’. Use with caution, you might log out a lot of client’s and sync clients with this. Make sure you then put in the ldap direct login uid block discussed down below to ensure the corruption doesn’t return. This logs out all direct login users too, like a local admin account.
Check the impact first with the select statement, shows the user and their devices name:
SELECT uid,login_name,name FROM oc_authtoken WHERE password_hash IS NOT NULL;
Delete the corrupt tokens for all users:
DELETE FROM oc_authtoken WHERE password_hash IS NOT NULL;
Prevent the bug from occurring again:
Workaround the issue while the bug exists by blocking direct login entirely for saml users. (Note: this will also fully disable webDAV access, as webdav does not support SAML login)
Blocking direct login is discussed in a few places currently, as direct login can also allow for 2FA bypass if the SAML idp enforces 2FA.
Allow native Nextcloud admins to still login · Issue #126 · nextcloud/user_saml · GitHub
and here:
[security] SSO with SAML: Locking down the direct login option - #10 by wwe
Seems like the current best option to disable direct login for LDAP backed users is to intentionally set the LDAP login UID to a non-existent LDAP attribute. @wwe suggests the below. This worked well for me:
(thisAttributeDoesNotExist=%uid)
To disable direct login for local nextcloud users that should only login using saml, that are not backed by ldap, just set all saml users that exist in the nextcloud database to random, long passwords that no one knows, this effectively blocks the user from using direct login and webdav; effectively enforces saml login only.
UPDATE: I’ve tested in a lab environment without LDAP backed users, just SAML mapping to an existing nextcloud user, the issue is the same. Any direct login corrupts all of that user’s auth tokens, which then prevents saml login.