search

xperseguers / t3ext-ig_ldap_sso_auth

TYPO3 Extension ig_ldap_sso_auth. This extension provides LDAP and SSO support for TYPO3.
https://extensions.typo3.org/extension/ig_ldap_sso_auth
27 stars 62 forks source link

Local users locked out of backend when unable to connect to LDAP server, despite extension configuration being set to enable local backend users #128

Closed Prospero256 closed 2 years ago

Prospero256 commented 2 years ago

I experimented with the LDAP / SSO extension 3.6.0 on two different TYPO3 10.4.20 installations. On one it worked perfectly fine, on the other one -due to a very capsuled setting- it couldn't connect to the LDAP server, resulting in a 502 gateway timeout. The connection failure was to be expected in that setting and has nothing to do with the extension, but albeit Enable local Backend users / backend.BEfailsafe (boolean) being set to true in the extension configuration, I couldn't log back in with my local admin account after logging out. The only way to fix being locked out, was deleting the configuration record from the database.

Whilst local users are enabled, local login should always be possible, even if the connection to the LDAP server fails completely.

xperseguers commented 2 years ago

Well, the LDAP connection is happening before the local one, to ensure it has a higher priority. This means that if it times out, then ... well... the other one may logically not happen.

Trying to do it the other way around, would imply changing the built-in authentication so that TYPO3 does not allow a "local" account actually associated to LDAP to be taken into account, and this could happen since TYPO3 does not know about the additional field we use to relate those records to LDAP.

Prospero256 commented 2 years ago

That's unfortunate. I had hoped we could have admin accounts working independently from LDAP authentifikation, that would allow us to access and fix problems if need be, no matter if the LDAP connection is available or not. Doesn't that mean, that the failsafe is basically useless?

xperseguers commented 2 years ago

I must admit that I never thought of the fallback to be used as a failsafe mechanism in case your AD connection is not stable enough to be accessible anytime.

It was built-in exactly for allowing disconnected AD account to be usable once we ensured that those accounts were not supposed to be used exclusively over an AD connection.

Possibly this may be “enhanced” but security will need to be checked carefully. Feel free to suggest a PR.

However I’d suggest to try to fix your 502 error in the first place because it doesn’t sound good…

xperseguers commented 2 years ago

Coming again to that topic. Admin (or even non-admin) accounts as fallback work properly from my point of view, but those accounts must not be related to LDAP. The whole point of LDAP is trusting it to let someone in or not, if you disable the person in LDAP you don't want any "fallback", the person must be blocked. However if you have a local (ie not related to LDAP at all), you can configure the extension to allow those accounts to log in, which may be useful in case your LDAP doesn't work or if you need some account disconnected from LDAP for some reason.