What about resent NTLM request after logout?

header('WWW-Authenticate: Negotiate');
header('WWW-Authenticate: NTLM', false);
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

could you please be more explicit? i don't know if you are posting a problem and a solution or just a problem

maca’s picture

It is not a patch. It is only concept. There is 'log out' link if I am using Webserver Auth module but without effect. I do not know how to glue sending "logout" http header with click on 'log out' :-( Sorry if I missed discussion thread.

adonix’s picture

Version: master » 6.x-1.0

This feature is very important imho.
At the moment, there is (afaik) no possibility to change the user.
After logout, the user is logged in again immediately as the same user.
I'm searching how to check if the user is logging out (for send these headers and purge ).
Any idea?

adonix’s picture

Status: Active » Needs work
FileSize
5.44 KB

I did some work, but there are still some troubles:

  • incompatibility to ldapauth:
    I had to change the select to get the expected uid: (only for existing ldap users)
    SELECT uid FROM {authmap} WHERE authname = '%s' AND module = 'ldapauth' OR module = 'webserver_auth'", $authname);
    For new users, there is no need for this, but they are also not synchronized from ldap... :-(
  • $expected['uid'] seems to trouble with the admin account (gives no number).
  • $userchanged and $relogin is a try prohibit drupal to not logout every login after the first logout.This still doesn't work and $relogin has to be switched by hand ;-) (switch to TRUE for login and vice versa)
    I tried to find out by HTTP_REFERRER (if $q stays 'webserver_logout', but referrer is allways the last called site before logout, header(location) does nothing change), by track 'expected' id with 'user-uid', but no solution yet.
    In fact, the problem is that webserver_auth.module never knows, if the user still is logged in, or if he tries to login again.
    The only way I could get this to work is: never login as the same user again. *)
  • the session_destroy() stuff from user_logout() does recall index.php twice. This is no problem but performance...
    Consider: while logging out/in, the webserver_auth.module script is invoked respective two or tree times.

Since there are lot of troubles (incompatibility) between ldapauth and webserver_auth, I don't continue to solve this. But perhaps someone can 'recycle' this my approach...

*) To get this to work:

- if (variable_get('webserver_auth_allow_logout',FALSE) == 1 && $relogin === FALSE) {
+ if (variable_get('webserver_auth_allow_logout',FALSE) == 1 && trim($_GET['q']) == "logout" && ! $userchanged) {

and then delete all from
if (trim($_GET['q']) == "logout" && ! $userchanged) {
to and with
else if (trim($_GET['q']) == "webserver_logout" && $userchanged) {
and the } which belongs to this if.

kswan’s picture

Status: Needs work » Needs review
FileSize
5.14 KB

I had the same problems as others with the webserver_auth module. The first is that it is impossible to login as user 1. Also, the Log out link is still on the menu, but it is useless (because the user is automatically logged back in).

Please see the attached patch. It does a few things to fix these issues.
1. The automatic login code (most of webserver_auth_init) is disabled on the logout and user (login) pages.
2. The automatic login code is disabled if the current uid is 1.
3. After logout, the redirect goes to the user(login) page.
4. I added a check box on the webserver_auth settings page to hide the Log out menu item and added a menu rebuild after saving the settings.
5. A menu_alter function is added to hide/show the Log out menu item.

This is working very well for me. Please test and post any issues.

I haven't looked at how this works with LDAP Integration. That is my next step (only to pull email addresses and maybe some profile info). Also, I haven't looked at adonix's patch yet, but it sounds rough based on his/her comments.

FYI, I am using this with the SSPI module installed on apache.

erikkramer’s picture

How do I apply the patch? I tried eclipse with http://drupal.org/patch/apply#comment-946478 but when I press finish nothing happens.

erikkramer’s picture

Managed to patch with http://drupal.org/node/32875.

I'm using iis6 with Windows Authentication and the webserver_auth module.
After applying the patch I can press the logout button and get a new webbased login screen. Which is good. However, when I try to login it says "Incorrect Username or Password. Did you forget your password?"

Recent Logs shows:

Type user 
Date Monday, September 8, 2008 - 19:22 
User Anonymous 
Location http://win2k3/Drupal/index.php?q=user 
Referrer http://win2k3/Drupal/index.php?q=user 
Message Login attempt failed for Erik. 
Severity notice 
Hostname 192.168.1.30 
Operations 
Type user 
Date Monday, September 8, 2008 - 19:22 
User Administrator 
Location http://win2k3/Drupal/index.php?q=logout 
Referrer http://win2k3/Drupal/ 
Message Session closed for Administrator. 
Severity notice 
Hostname 192.168.1.30 
Operations 
erikkramer’s picture

This is my workaround:

- I created a new virtual directory in IIS pointing to the same physical directory of Drupal.
- Only difference being that here Basic Authentication is enabled.
- External users are redirected to this virtual directory while for internal users drupal is still available with Windows Authentication.

This way external users are always prompted with the login box.
The logout button still does not function, but is now redundant.

This method also solves another issue that I was having, where external users have to login with DOMAINNAME\USERNAME. With basic authentication a default domain name can be set.
Drawback is a loss in security since passwords are now sent in clear text. Therefore I'm going to try and figure out how to enable ssl on the server.

kswan’s picture

The web-based login screen that you saw after logging out is only going to work to authenticate to the drupal user table, not the Activedirectory server (or whatever IIS is authenticating to). I am guessing that the user "Erik" is setup on the Activedirectory server, not the drupal user table.

The primary benefit of this patch is to allow access to user 1 (the super admin account). For my application, my normal users won't need to logout. That is the reason that the patch adds an option to disable the logout link on the menu.

I don't competely follow your needs and current setup, but it sounds like the virtual directory setup might work well for you.

erikkramer’s picture

I need internal users inside my domain to authenticate with Windwos authentication, without being able to log out. And I need external users to be able to logout, since multiple users might be using the same computer.

With the described workaround http://drupal.org/node/22981#comment-1001067 this works because when a logged in users closes his browser window, the next user will be prompted for credentials again.

And your comment about the AD users makes sense, maybe I'll try it with the ldap_auth module. But for now I don't need users to be able to switch to user 1.

btw, is there a method to just hide the logout button?

kswan’s picture

Category: feature » bug

I think adonix explained this issue well in comment #3. To me this problem should be considered a bug instead of a feature request since it is impossible to login as uid 1 without disabling the module. The patch I posted above http://drupal.org/comment/reply/22981/1001802#comment-985701 makes it possible to login as uid 1 or any local drupal account. If anyone else has experience with this patch, please post your thoughts.

@erikkramer: I think we need to keep this issue focused on the stated topic. Your challenge of using Windows authentication for internal users and login form authentication for external users is an interesting and beneficial discussion for a forum post. BTW, the patch I posted does provide the option of hiding the Logout link.

Paul Natsuo Kishimoto’s picture

Hi all—I was just made maintainer of webserver_auth, so I'm trying to catch up with what's going on here. kswan, your patch in #5 looks good, but I haven't had a chance to apply and test it yet. I will do that as quickly as possible.

My only gripe is that $q is obtained from raw POST or GET variables. Drupal provides an $args global that I seem to recall is preprocessed in some way, possibly to provide security. Could you please look into this and perhaps alter the patch to use the global variable?

As an aside: I am also looking at #284515: Initial login when first turning module on and wondering how that patch and this one will coexist. What if UID#1 is mapped to by an external auth source? Then different results would occur if the user logged through webserver_auth or using the default Drupal behaviour...right? I suspect kswan's approach should override the one from the other issue, since UID#1 should always be accessible, even if webserver_auth is disabled/the webserver is misconfigured. Thoughts?

kswan’s picture

Paul,

Thank you for taking over as maintainer of this module. I will definitely look at the $args variable and probably post another patch.

I just took a quick look at #284515: Initial login when first turning module on. I think this issue is already resolved in the D6 version of webserver_auth.

Is it possible for uid 1 to be mapped to an external auth? I thought uid 1 had to be in the local drupal user table.

kswan’s picture

I looked for the $args global variable that you mentioned. I didn't find a global variable, but I found the arg() function that is similar. Also, I thought the logic would be a little more clear if we just returned when we didn't want to use the webserver authentication.

  $q = arg(0);
  // Bypass webserver_auth in the appropriate cases
  if (($q == 'logout') || ($q == 'user') || ($user->uid == 1))
    return;

I rerolled the patch.

dcoe’s picture

This patch worked very well. Used cygwin , reloaded and it is a perfect solution.

kswan’s picture

Status: Needs review » Reviewed & tested by the community

Thank you for the feedback. Hopefully Paul will have a chance to commit this so everyone can benefit.

ipman’s picture

Unfortunately in order to log out, you'll have to close the browser. There currently exists no way to "flush" the password cache in the major browsers (although Lynx allows you to do this via the underscore (_) key command). However that patch about does work great if you would like to just switch users.. however if you leave your session at the login screen the next user can just surf to the root www.example.com and be logged in as your account.

kswan’s picture

@ipman: The basic purpose of this issue and the attached patch is to enable logout and login as the superuser (uid: 1).

If you want to enable anonymous access, you would need to modify the permissions in httpd.conf or IIS and apply something like http://drupal.org/node/318878 or http://drupal.org/node/295783.

If your webserver is using NTLM and your browser supports NTLM (not sure if Lynx supports NTLM) then the normal behavior is that any page load (except /logout and /user) will trigger an automatic logon using the credentials of the current Windows user.

brandon.dixon’s picture

So your patch does NOT allow a user to hit the logout and actually have them logout? If it doesn't, is there an easy way to implement that in the current module?

kswan’s picture

Brandon,

With my patch, a user can hit logout and the user will be logged out of drupal and redirected to the logon page allowing the user to login as another user. Depending on the webserver configuration, the user might be logged back in if they visit any other page on the site. See the links in #18 for more details on that setup.

As the site administrator you can decide whether you want the users to be anonymous until they explicitly log in or you want every user to be automatically logged in when they visit any page.

DRScales’s picture

As an alternative, for the 5.x version we added a http://mydrupalintranet-admin url that did not present the authentication variable and bypassed the module - the alt URL is simply added to the settings form (we also added a role in order to incrementally release the test version). This is pretty useful for running admin tasks whilst monitoring changes as a regular user in the same browser. I'm patching this for 6 this week - will post shortly

dvesh’s picture

The patch works like a charm. Thank you.

gaards’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Closed (outdated)

Closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.