Closed pniederlag closed 3 years ago
resetting $domain=null before the call to Authentication::ldapAuthenticate does "fix" our SSO-Setup
--- AuthenticationService-dist.php 2020-12-16 08:32:44.039998930 +0100
+++ AuthenticationService.php 2020-12-21 11:40:29.546583037 +0100
@@ -144,6 +144,12 @@
}
}
+ /**
+ * HOTFIX/PATCH
+ * peter.niederlag@datenbetrieb.de
+ * https://github.com/xperseguers/t3ext-ig_ldap_sso_auth/issues/119
+ */
+ $domain=null;
$userRecordOrIsValid = Authentication::ldapAuthenticate($remoteUser, null, $domain);
if (is_array($userRecordOrIsValid)) {
// Useful for debugging purpose
Would be nice if the use case, where the SSO-Domain (@FOO.INT) does not match the ldap base dn (DC=foo,DC=local) would be supported again.
Thx for your support
After discussing, check this:
diff --git a/Classes/Library/Authentication.php b/Classes/Library/Authentication.php
index 2319796..fe160df 100755
--- a/Classes/Library/Authentication.php
+++ b/Classes/Library/Authentication.php
@@ -14,6 +14,7 @@
namespace Causal\IgLdapSsoAuth\Library;
+use Causal\IgLdapSsoAuth\Domain\Repository\ConfigurationRepository;
use TYPO3\CMS\Core\Utility\GeneralUtility;
use Causal\IgLdapSsoAuth\Domain\Repository\Typo3GroupRepository;
use Causal\IgLdapSsoAuth\Domain\Repository\Typo3UserRepository;
@@ -96,7 +97,11 @@ class Authentication
// Set extension configuration from TYPO3 mode (BE/FE).
static::initializeConfiguration();
- if (!empty($domain)) {
+ $numberOfConfigurationRecords = count(
+ GeneralUtility::makeInstance(ConfigurationRepository::class)
+ ->findAll()
+ );
+ if (!empty($domain) && $numberOfConfigurationRecords > 1) {
// Domain is set, so check it
if (strpos($domain, '.') !== false) {
$domain = 'DC=' . implode(',DC=', explode('.', $domain));
Problem is actually related to https://github.com/xperseguers/t3ext-ig_ldap_sso_auth/commit/135f1a3f4dbf259c95eae3db5ae182d99c7a5b26
With the implementation of #87 our SSO-Setup is now broken.
Our kerberos/SSO yields the users as '@FOO.INT'. This was working fine as only the user-portion (anything before the @) was used in the lookup to ldap. So the user was found in ldap (where the Base DN had ,DC=foo,DC=local).
Currently investigating and looking for a possible solution.
And, BIG THX for your kind support and efforts to maintain this extension!