By forgette on

Has anyone attempted to login to a drupal based intranet that is housed behind a sonicwall ssl-vpn 200 device?

I have drupal up and running fine. Also on the same server I have a mediawiki install. I recently installed a Sonicwall ssl-vpn 200. If I'm remote and authenticate through the device (active directory based), I get passed through to the intranet properly. I also can get passed to the wiki fine. Once on the intranet, I'm not able to log in to drupal. I can however log into the wiki fine.

I click login, put in my username/password, I get:

Access denied
You are not authorized to access this page.

If I go directly to the page, without going through the device, it works fine.

thoughts?

⋅ Categories: Drupal 5.x

Comments

forgette’s picture

forgette commented

oops

version 5.2

cog.rusty’s picture

cog.rusty commented

Any change in the URL's domain name when going through the device?
Any cookie blocking by the device?

forgette’s picture

forgette commented

Does not block cookies, but the url, going through the device appears like this:

https://foo/cgi-bin/nph-httprp/http://intranet%2Efoo%2Elocal

https://foo/cgi-bin/nph-httprp/http://intranet.foo.local/index.php?q=user

cog.rusty’s picture

cog.rusty commented

Does it help if you set $base_url = 'http://intranet.foo.local'; in your settings.php file? (to force Drupal use this one for its internal links)

Perhaps also $cookie_domain = 'intranet.foo.local'; (not so sure about the latter, because cookies generally don't work across different domains)

If none of these works, next you could try another method, borrowed form drupal multisites.

forgette’s picture

forgette commented

I've tried both suggestions above, and unfortunately neither worked. Would you be able to point me to that other method you mention?

Thanks!

cog.rusty’s picture

cog.rusty commented

Hmm... The idea was to treat them as two different Drupal sites for access, which however use the same database, so they become the same again.

This is usually done by creating additional settings directories for the domains, instead of using sites/default:

sites/default/settings.php (not used)
sites/domain1.com/settings.php (one site)
sites/subdomain.domain1.com/settings.php (another site)
sites/domain1.com.subdirectory/settings.php (another site)

Accessed as different sites, but it is possible to put the same $db_url in them, so that they are essentially the same no matter which one you access.

What I was thinking was something similar to the last example, using the same $bd_url.

sites/domain1.com/settings.php
sites/domain2.com.domain1.com/settings.php

But now that I am looking at your https://foo/cgi-bin/nph-httprp/http://intranet.foo.local URL I am not so sure that it can be used in a directory name. And it does look wrong.

You said that your wiki worked. Did its URL change in the same way? Or in some different way?

forgette’s picture

forgette commented

Wiki worked, the same way with the url change. Today though, I noticed that when I tried to install wsus on this same server that other things were not working properly. I think that after tomorrow I will uninstall IIS and reinstall it considering that I inherited this setup from a person who no longer works here.

After I reinstall, I will post a followup on the status of authentication.

Thanks!

forgette’s picture

forgette commented

Well, I can safely rule out that it is not an iis issue. I had forgotten that my test drupal internet was set up on a lamp box, so I tried that real quick. Same issue happens to that install as well when attempting to login through the ssl-vpn device. So something is happening that drupal doesn't like.

cog.rusty’s picture

cog.rusty commented

I forgot to mention that one purpose of the above was to be able to set a different $cookie_domain in each settings.php file, because now it has to stay commented out (a cookie_domain doesn't work across different domains).

youlikeicecream’s picture

youlikeicecream commented

I am running a lamp server and drupal 5.x I can happily view the site but login does not seem to work. I get no error message when I enter a correct username and password, the site simply does not log me in.

anyone found a fix to this ?

Mike :)

youlikeicecream’s picture

youlikeicecream commented

setting the $cookie_domain variable in sites/default/settings.php has solved this problem for me.

Mike :)