Platform: Windows 7, Apache 2.2.22, PHP 5.4.12, mod_auth_sspi 1.0.4, Drupal 7.20

SSO worked fine on 7.x-2.0-beta3 but don't work after some modifications of 7.x-2.0-dev at the end of December, 2012.

Now i've installed 7.x-2.0-beta4 and SSO still don't work.

Symptoms:

1. Login via user/login page works fine.

2. Login via user/login/sso says "You have been successfully authenticated" but it's not true.

3. Last message in log is:

Type: ldap_authentication
User: Anonymous (not verified)
Message: JSmith : Authentication result id=0 auth_result=6 (unknown error: 6)

(JSmith is my name :-) )

4. I've made some stuff - applied patch /node/1415270#comment-7175836. After it behaviour of SSO login looks same but appended to log 2 new (after all the same with previosly generated) messages:

Type: ldap_authentication
User: JSmith
Message: ldap_sso_user_login_sso.remote_user: uid of user=12766
Type: ldap_authentication
User: JSmith
Message: ldap_sso_user_login_sso.remote_user.user_success.drupal_goto front

New is the name of the user in 2 new messages but SSO still don't work.

Comments

trumanru’s picture

Issue summary: View changes

applied exact products versions

johnbarclay’s picture

Title: SSO with AD doesn't work » LDAP SSO: SSO with AD doesn't work
Version: 7.x-2.0-beta4 » 7.x-2.x-dev
Priority: Major » Normal
MichaelWeder’s picture

Version: 7.x-2.x-dev » 7.x-2.0-beta5
Priority: Normal » Major

We got the same problem (also with beta5):

SSO worked fine on 7.x-2.0-beta3 but don't work after some modifications of 7.x-2.0-dev at the end of December, 2012.

Now i've installed 7.x-2.0-beta5 and SSO still don't work.

johnbarclay’s picture

Title: LDAP SSO: SSO with AD doesn't work » LDAP SSO: with AD, mod_auth_sspi, not seemless authentication gives success but does not logon user

Thanks MichaelWeder. If you can narrow it down to particular build that last worked that would be helpful. Here is where you find the different builds http://drupalcode.org/project/ldap.git/shortlog?pg=1. Also confirm that you have the same setup as bigMuzzy along with your ldap_authentication settings.

I'd like to keep this thread for:

  • Active Directory
  • mod_auth_sspi
  • not seemless authentication (ldap sso that redirects user to user/login/sso)
  • message says "You have been successfully authenticated" but it's not true.

I'm suspect this has to do with the logon form validation changes.

MichaelWeder’s picture

Hy johnbarclay

We are still using the Version "7.x-2.0-beta3".
We first try to switch with the "7.x-2.0-beta3+24-dev" (26.2.2013) and the Problem is still happend with Beta5
In the time between, we tried several Versions.

Our configuration:
Platform: Ubuntu, Apache 2.2.22, PHP 5.3.10-lubuntu3.4, mod_auth_kerb, Drupal 7.22, Ldap AD-Connection

I am agree with "I'm suspect this has to do with the logon form validation changes", because we use Kerberos not SSPI.

johnbarclay’s picture

See recent commit #1415270: LDAP Authentication SSO redirect loop on automatic sign in patch in comment #2 and commit in #6. That patch may also fix this issue and is committed to 7.x-2.0-dev.

MichaelWeder’s picture

Perfect. The Patch works!

trumanru’s picture

Yes! Patch is works for me to!

But it doesn't work via "user/login/sso" URL, it works only if I switch on "Turn on automated/seamless single sign-on" option.

Is it correct?

johnbarclay’s picture

Version: 7.x-2.0-beta5 » 7.x-2.x-dev

@#7. Looks that way. Shouldn't the user_login_finalize() call be outside of the if ($auth_conf->seamlessLogin == 1) block? That block is just cleaning up some state variables that are particular to seemless. The outer block is for any sso logon success and is user_login_finalize();

Can someone test this?

http://drupalcode.org/project/ldap.git/blob/53c32b49ec6f93e90f19b61fdf1d...

This is:

if ($auth_conf->seamlessLogin == 1) {
 276         if ($detailed_watchdog_log) {
 277           watchdog('ldap_authentication', 'ldap_sso_user_login_sso.remote_user.user_success.seamlessLogin', $watchdog_tokens, WATCHDOG_DEBUG);
 278         }
 279         setcookie("seamless_login", 'auto login', time() + $auth_conf->cookieExpire, base_path(), "");
 280         ldap_servers_set_globals('_SESSION', 'seamless_login', 'auto login');
 281         setcookie("seamless_login_attempted", '');
 282         ldap_servers_delete_globals('_SESSION', 'seamless_login_attempted');
 283         // Make sure we tell Drupal to create the session cookie for this authenticated user.
 284         user_login_finalize();
 285       }

should be:

if ($auth_conf->seamlessLogin == 1) {
 276         if ($detailed_watchdog_log) {
 277           watchdog('ldap_authentication', 'ldap_sso_user_login_sso.remote_user.user_success.seamlessLogin', $watchdog_tokens, WATCHDOG_DEBUG);
 278         }
 279         setcookie("seamless_login", 'auto login', time() + $auth_conf->cookieExpire, base_path(), "");
 280         ldap_servers_set_globals('_SESSION', 'seamless_login', 'auto login');
 281         setcookie("seamless_login_attempted", '');
 282         ldap_servers_delete_globals('_SESSION', 'seamless_login_attempted');
 283         // Make sure we tell Drupal to create the session cookie for this authenticated user.
 284       }  
 285       user_login_finalize();
c3rberus’s picture

I seem to be having the same issue, when we hit our Intranet (which runs Drupal on a Ubuntu server with LDAP module/SSO enabled via mod_auth_ntml_winbind) the users hit the site, get a "successfully authenticated" message.

However, looking closer at the site the user is not really authenticated, if you add /user to the URL, it shows a login page for a user/pass.

I found this out as I was updating my site's permissions to disable anonymous users from viewing published content, all my users were all of the sudden not able to see the site and were getting "access denied" message even when Drupal displayed the "successfully authenticated" message.

First I started fiddling with cookie session.. originally set to two hours, trying to change that to "session" breaks viewing the site at all, changing it to "immediately" takes awhile for the site to load, when it does there are about 30+ "succesfully authenticated" messages that Drupal throws back on the page. At this point, the user is again not authenticated.

Not sure when the bug was introduced under our setup, I was always under the impression that if Drupal was telling us the user was authenticated, we were good.. (we didn't make use of permissions much).

But now that I am starting to fiddle with it, I found that users are not getting SSO authenticated correctly. Thus, not able to implement roles/permissions until we get this fixed, as our users expect to be "automatically authenticated" and not wanting to type in a user/pass. (not my choice.. however, luckily we have LDAP module that allows for our end users to be simple minded).

Running ldap 7.x-2.0-beta5 release, running latest version of Drupal.

I assume the fixes above are for --dev release, I am running the "beta5 release", anyway I could help in testing this?

johnbarclay’s picture

Yes. You may help test. Please apply the change in #8 to the current 7.x-2.0-dev and test.

c3rberus’s picture

I have updated from 7.x-2.x-beta5 to 7.x-2.x-dev release, flushed the Drupal cache, logged out of the Drupal site and closed my IE which is also set to clear session/history on close.

Upon re-opening IE, my default site is set to our Intranet (Drupal with LDAP SSO for Active Directory) and got the.. "you have been authenticated" message, and also my administrative menus!

This to me indicates that the current -dev release fixed our issue.

I've also updated my "cookie" settings to be for the "session", then logged out of Drupal.. closed IE.. re-open and voila.. authenticated with admin menu.

Yay !! :)

Just to confirm, I basically did a "drush dl ldap --dev", which replaced my beta with --dev, since this was done after your commit in #8, it means that the suggested fix in #8 is included in my --dev or did I have to do additional steps?

johnbarclay’s picture

@#11. There are no addtional steps.

johnbarclay’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Some format changes