Desktop client fails to login after password change

[Fernando-Sousa]

Expected behaviour

SSO using SAML (ADFS) on desktop client should complete as expected.

Actual behaviour

SSO using SAML (ADFS) does not complete and its stuck on a loop. Further notes: After use changes password on AD backend the desktop client password is revoked (as expected). After the user logs in again using the desktop client (and successfully completes the web flow for the desktop client/computer) he is granted access successfully . After that the user is prompted to login with the samAccountName and not the objectGUID that forms the nextcloud username. Example: User fernando.sousa changes password on AD backend. Desktop client password gets revoked and user need to sign in again. User is then sent to browser to login again and grant permission for the desktop client. Flow is completed successfully. (access is granted). User closes the browser and returns to desktop client. Desktop client states that he needs to login with fernando.sousa and not AAAA-AAAAA-AAAAA (example guid). From my investigation the error comes up in WebFlowCredentials::slotAskFromUserCredentialsProvided. As the SAML provider is sending the GUID as a user (nextcloud user) it fails the following QString::compare(_user, user, Qt::CaseInsensitive) == 0.

Steps to reproduce

1. User fernando.sousa changes password on AD backend.
2. Desktop client password gets revoked and user need to sign in again.
3. User is then sent to browser to login again and grant permission for the desktop client.
4. Flow is completed successfully. (access is granted).
5. User closes the browser and returns to desktop client.
6. Desktop client states that he needs to login with fernando.sousa and not AAAA-AAAAA-AAAAA (example guid).

Client configuration

Client version: 3.0.2 (tested with earlier 3.0.1 as well)

Operating system: Mac OS 10.15.7 (not sure if this affects windows clients as well)

OS language: English

Qt version used by client package (Linux only, see also Settings dialog): N/A

Client package (From Nextcloud or distro) (Linux only): N/A

Installation path of client: Standard Path: /applications/nextcloud.app

Server configuration

Nextcloud version:18.0.3

Storage backend (external storage): N/A

Plugins added: SSO & SAML Authentication: 3.0.1

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.

1. Client logfile:

   2020-09-23 10:06:19:427 [ info nextcloud.sync.credentials.flow2auth ]: setting remote poll timer interval to 30000 msec 2020-09-23 10:06:19:439 [ debug nextcloud.sync.networkjob ] [ OCC::AbstractNetworkJob::slotFinished ]: Network job OCC::SimpleNetworkJob finished for "" 2020-09-23 10:06:45:699 [ info nextcloud.sync.accessmanager ]: 4 "" "https://xxx.xxx.xxx/index.php/login/v2/poll" has X-Request-ID "423cbb2e-9d7b-4354-9884-5e1973a83a47" 2020-09-23 10:06:45:699 [ debug nextcloud.sync.cookiejar ] [ OCC::CookieJar::cookiesForUrl ]: QUrl("https://xxxxx.xxx.xxx/index.php/login/v2/poll") requests: (QNetworkCookie("xxxxxx; secure; HttpOnly; domain=xxx.xxxx.xxx; path=/"), QNetworkCookie("oc_sessionPassphrase=xxxxxxxxxx secure; HttpOnly; domain=xxx.xxxx.xxx; path=/"), QNetworkCookie("__Host-nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=XXX.XXXX.XXX; path=/"), QNetworkCookie("__Host-nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xx; path=/")) 2020-09-23 10:06:45:700 [ info nextcloud.sync.networkjob ]: OCC::SimpleNetworkJob created for "https://xxx.xxx.xxxx" + "" "OCC::Account" 2020-09-23 10:06:45:960 [ info nextcloud.sync.credentials.webflow ]: request finished 2020-09-23 10:06:45:961 [ info nextcloud.sync.credentials.flow2auth ]: Success getting the appPassword for user: "90F5F13D-AB14-4B07-ACA8-98FA8609E6F4" , server: "https://xxx.xxxx.xxx" 2020-09-23 10:06:45:961 [ debug nextcloud.sync.networkjob ] [ OCC::AbstractNetworkJob::slotFinished ]: Network job OCC::SimpleNetworkJob finished for "" 2020-09-23 10:06:45:962 [ info nextcloud.sync.credentials.webflow ]: Authed with the wrong user!

2. Web server error log: N/A

3. Server logfile: nextcloud log (data/nextcloud.log): N/A

[Fernando-Sousa]

Bump

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[Fernando-Sousa]

Bumping this one again Any feedback on this one?

[robertofabrizi]

Why is this bug closed?

[FlexW]

@blizzz are you in charge of SAML on the server? Could you tell us if this is a bug and the described workflow should work?

[blizzz]

If authentication goes via SAML, then there is no password ending up at the server. App token should continue to work regardless of the change. Therefore, I also cannot reproduce the issue.

When I do this against LDAP directly, the client stops syncing and is logged out. I need to trigger relogin manually (don't think this should be the case as the apptokens are updated after a successful login), but afterwards sync works normally.

(my client version: 3.1.3)

[Fernando-Sousa]

Hi, I don't think the problem is with the SAML workflow as it finishes successfully. The problem is on the return to the desktop client itself as you can see on the log (last line): info nextcloud.sync.credentials.webflow ]: Authed with the wrong user!. If you follow the last 5 lines of the log you will see the flow. User grants access, closes window, desktop client fetches the appPassword and the user is greeted with "please login with account fernando.sousa". This is caused by this particular line QString::compare(_user, user, Qt::CaseInsensitive) == 0 on the OS X client. SAML is working flawlessly here and I do think the problem is with the client and not with the SAML workflow, but rather the way the desktop client handles the return from a successful authentication. Can provide more logs if needed.

[blizzz]

@Fernando-Sousa what troubles me with your issue is still that the client should not stop working at all. The token is passwordless. Did you ensure that direct authentication through LDAP is disabled?

[Fernando-Sousa]

Hi @blizzz, do you mean in the SAML global settings? If so, yes its disabled.

[blizzz]

@Fernando-Sousa that's already good. Nevertheless, try to configure an unsatisfyable ldap login filter (e.g. "attributeDoesNotExsist=%uid").