CAS and LDAP backend not working anymore

[cyworks]

Hi, Since the beginning of the year the CAS and LDAP backend not working anymore. In the database when OCA\UserCAS\User\Backend is set for a user only CAS working not the client or Owncloud form. When OCA\User_LDAP\User_Proxy is set only client or Owncloud form working. We don't know where is the problem, we have this error on the log : User already provided by another backend(OCA\User_LDAP\User_Proxy !== OCA\UserCAS\User\Backend), skipping."} Returned account has different backend to the requested backend for sync

Thank you for your help

[felixrupp]

Hi @cyworks

this is a "problem" or more like a feature of owncloud, not user_cas. ownCloud now syncs the backends more strictly to the accounts, they were created of. If a user is created by the ldap-backend, there is no chance of authenticating him/her via other backends. This is the reason, why the ldap-backend support for user_cas was abandoned. The reason why ldap users are able to use the regular owncloud login form is, because the ldap provider in the user_ldap extension has knowledge of the user and his credentials. This is not the case with a CAS instance. CAS is a black box concept, so we can not use the owncloud login form for login, we have to redirect the user to the CAS server, where he provides his/her credentials.

Please setup your installation according to that and either use ldap OR your CAS instance for central authentication purposes (ldap is reachable by a CAS server, so this should not be an issue).

You can, if you want to, convert your ldap user accounts to user_cas users manually in your database by simply changing the column "backend" to "OCA\UserCAS\User\Backend". After this change, the accounts will not be able to authenticate via ldap anymore. Please be sure to make a full backup of your installation before manually changing the database!

After that, a logged in user can set a local password in his user panel, and the client app (desktop, mobile) login will work again. The other, preferred option, is to use the OAuth2 app in combination with user_cas to log in client apps (desktop, mobile), to completely remove authentication credentials (password) from the ownCloud instance.

Best Regards,

Felix

[JaredBoone]

Hi @felixrupp,

You wrote:

You can, if you want to, convert your ldap user accounts to user_cas users manually in your database by simply changing the column "backend" to "OCA\UserCAS\User\Backend".

Is it possible to migrate a Nextcloud database from LDAP to CAS? If so, could you please explain how (maybe by providing a simple SQL example)?

Thanks!

[jgribonvald]

Hi, Independently of the LDAP authentication it seems that we can't search the user inside the LDAP backend after a CAS authentication success (I mean chaining CAS auth with a LDAP search to obtain user attributes from a LDAP backend). So how to do in this case if we can't get all needed user attributes from a CAS ticket ?

[felixrupp]

Hi @jgribonvald,

there is currently no solution for this use case, because in a correct setup you would have your CAS instance decide which LDAP attributes should be visible for an application using the SSO.

I know that in many cases, you, as an application admin, have no specific rights to decide which attributes should be delivered in the CAS payload of your company (that’s exactly the case in my company).

I can only tell you, that I am currently working on a solution to sync AD/LDAP users with the user_cas backend in ownCloud/Nextcloud including all available ownCloud/Nextcloud attributes. So please stand by and wait for user_cas 1.7 ;) .

Regards, Felix

[jgribonvald]

Thanks @felixrupp,

For me a SSO solution is only an authentication service not a user's attribute provider, more when the application can have access directly to a user backend.

What is your timeline about the user_cas 1.7 ? is it before the end of this month ?

Regards, Julien

[felixrupp]

Hi @jgribonvald,

yes, 1.7 will be published before end of the month.

Regards, Felix

[JaredBoone]

Hi @felixrupp,

I'm still hoping to hear back from you regarding my question above about how I can migrate my Nextcloud instance from user_ldap to user_cas.

Thanks, Jared

[felixrupp]

Hi @JaredBoone,

sorry, I totally forgot your question was still open!

Actually you can convert accounts by using the following SQL-Statement on the oc_accounts table: eg. with selecting by ID: ownCloud: UPDATEoc_accountsSETbackend='OCA\UserCAS\User\Backend' WHEREid='1'; Nextcloud (>=14): UPDATEoc_accountsSETbackend='OCA\UserCAS\User\NextBackend' WHEREid='1';

or with selecting by the old backend-type (Database here): ownCloud: UPDATEoc_accountsSETbackend='OCA\UserCAS\User\Backend' WHEREbackend='OC\User\Database'; Nextcloud (>=14): UPDATEoc_accountsSETbackend='OCA\UserCAS\User\NextBackend' WHEREbackend='OC\User\Database';

or with selecting by the user’s id (login-name): ownCloud: UPDATEoc_accountsSETbackend='OCA\UserCAS\User\Backend' WHEREuser_id='felix'; Nextcloud (>=14): UPDATEoc_accountsSETbackend='OCA\UserCAS\User\NextBackend' WHEREuser_id='felix';

or or or …

Please backup your ownCloud/Nextcloud instance and your database before converting your user accounts!

Regards, Felix

[JaredBoone]

Hi @felixrupp,

Thanks for your reply. I'm a little confused. I'm running Nextcloud 15.0.5 (with a PostgreSQL database). My oc_accounts table looks like this:

# \d oc_accounts
                       Table "public.oc_accounts"
 Column |         Type          |               Modifiers
--------+-----------------------+----------------------------------------
 uid    | character varying(64) | not null default ''::character varying
 data   | text                  | not null default ''::text
Indexes:
    "oc_accounts_pkey" PRIMARY KEY, btree (uid)

# select * from oc_accounts where uid='3e5def9a-9167-102c-9fea-5d2a32e26af1';
                 uid                  |
                                                                             data

--------------------------------------+---------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
 3e5def9a-9167-102c-9fea-5d2a32e26af1 | {"avatar":{"scope":"contacts"},"displayname":{"value":"Jared Boone (jboone)","sc
ope":"contacts"},"email":{"value":"jared.boone@xxxx.com","scope":"contacts"},"website":{"value":"","scope":"private"},"a
ddress":{"value":"","scope":"private"},"phone":{"value":"","scope":"private"},"twitter":{"value":"","scope":"private"}}
(1 row)

That doesn't seem to match the SQL you provided. Not sure how to explain the difference. Any ideas?

Viele Grüße, Jared

[felixrupp]

@JaredBoone sorry, my bad! Nextcloud has changed the accounts table to use a JSON-string for the account information. Please give me some time to build a working sql-statement for Nextcloud! I’ll report back if it works!

Regards, Felix

[JaredBoone]

@felixrupp Have you had any success building a SQL statement? I have been trying to do it myself but I haven't discovered where the user backend is specified in Nextcloud 15. Regards, Jared

[felixrupp]

@JaredBoone I reviewed my Nextcloud 15 dev system and noticed, that on Nextcloud the backends do not have to be updated, because Nextcloud did not change anything here since the fork of ownCloud. So basically it should work to just use one account (doesn’t matter if local or LDAP user) to also log in via CAS (if the uid/username is exactly the same).

[landryb]

Fwiw, using 1.6.2 with nc 15.0.7, there's no user_id field in oc_accounts, and even with the code in https://github.com/felixrupp/user_cas/blob/master/lib/Hooks/UserHooks.php#L188 the codepath is used, which triggers a php error in the logs:

{index} {"Exception":"Doctrine\\DBAL\\Exception\\InvalidFieldNameException","Message":"An exception occurred while executing 'UPDATE \"oc_accounts\" SET \"backend\" = ? WHERE LOWER(\"user_id\") = LOWER(?)' with params [\"OCA\\\\UserCAS\\\\User\\\\Backend\", \"celine.tixier\"]:\n\nSQLSTATE[42703]: Undefined column: 7 ERROR:  column \"user_id\" does not exist\nLINE 1: ...DATE \"oc_accounts\" SET \"backend\" = $1 WHERE LOWER(\"user_id\")...\n

is the test for get_name() wrong ?

[felixrupp]

Hi @landryb

I am going to investigate that!

Probably the same problem as with #58

[felixrupp]

@landryb Is the problem still there with Release 1.7.2?

[landryb]

I'll have to upgrade to test .. hopefully before the end of the year :(

[qw3672939]

HI @felixrupp I am updating cas to version 1.7.3, but cas and ldap still can't work at the same time. Why? In addition, after the form configuration parameters in the function module of the import CLI in the CAS, what is the reason for not refreshing the parameter records?

[felixrupp]

@qw3672939 Because the code architecture of both apps has been changed several times, so they are not working together anylonger. At the moment I do not have time to re-implement the user_ldap API into user_cas. I am looking forward to find a company/an organization to fund this feature, because it seems to be needed by many.

Until then both apps can coexist beneath each other but user_cas is not able to bind CAS users to LDAP-users from user_ldap.

[felixrupp]

Good news, I am planning to implement an LDAP update feature in Release 2.0! Please stand by, information will be released next year.

Regards and happy christmas,

Felix

[jgribonvald]

Hi, Sorry but did you began something on this feature announced ? We would need this feature in the next days / week, the only thing is that we don't know how we can chain with the ldap but we can provide some developing help if you tell us how to do. Also if you began something could you share it ?

Thanks

[felixrupp]

Hi @jgribonvald

I didn’t start yet, due to scheduling problems. If you setup your CAS correctly you don’t need any LDAP integration. If you need quick help though, please contact me via e-mail, to get a quote for commercial support (http://www.felixrupp.com/).

Best Regards, Felix

[jgribonvald]

hi @felixrupp, our problem is not on configuring CAS, we need to get user information from an LDAP, our CAS is used only as an authentification system and not as a user information provider system. So for that we need to chain with a LDAP request. So we would be ready to contribute on your plugin to offer this possibility without to fork it. The only thing is on which best way we should develop that ?

Thanks

[felixrupp]

Hi @jgribonvald

I see. You are encouraged to develop such feature and provide corresponding pull requests. That is, in my eyes, the most practical way of contributing to the project.

My plan was to abstract the existing ldap configuration in user_cas, which is currently only used for the AD import cli, and male use of it for the cli and the new ldap sync feature. The best place to integrate such sync feature would be the postLogin hook, where the user details get updated after a CAS based login.

Best Regards, Felix

[jgribonvald]

Thanks @felixrupp we will see that on this way so ! And we will keep you informed when it will be done to have your overview before the Pull Request.

[felixrupp]

@dingzhixue Please be so kind to write in english, as we do not understand chinese.