Gallardo, Lisa wrote: [...]a) Potentially could be up to everyone who has an account - up to 1000 + - although not all at once - maybe 10-50 at a time b) This site is available to staff both inside and outside the network, so they could access at the library, at their home, etc. Just need internet connection. c) The information is primarily documents and news used internally, no finance or confidential info. It is for staff only and may in the future store this type of info.
d) Users may use Firefox, IE, etc. and their own computersWell, that pretty much eliminates NTLM ( = Windows Integrated Authentication) for the people outside.
In any case, this is not going to be a simple setup where someone can just tell you to change this or that setting in sspi to make it work.
Let me give you a few pointers :Normally in Apache, it should be possible to configure authentication so that one method is tried first, and if it does not succeed, another is tried afterward. The question is that this depends a bit on the modules used (if they are flexible and clean or not in that respect). It should be possible to configure sspi to try first, and if it does not obtain a user-id (in this case, if the user is outside), let another method take over. At the sspi level, that would be done (probably) by the following parameter :
SSPIAuthoritative - set to 'off' to allow access control to be passed
along to lower modules if the UserID is not known to
this module
(but don't do this until you actually have another authentication module
behind sspi)
Then you would also need to configure another Apache authentication module, which would take over when sspi gives up.
How to configure this, I am not quite sure. 2) One issue is *what* this second module should be.Your users can be out on the Internet, with their own computers, and their own browser. That's about the worst-case scenario in terms of authentication.
Browsers, in general and by themselves, support 2 types of authentication : Basic and Digest. - Basic authentication is not secure at all, because the user-id and password (entered by the user in a login dialog), are then sent by the browser to the server in clear (actually encoded Base64, but that is not an encryption, it's just an encoding). That means that anyone that can capture a packet can get the user's user-id and password. This is particularly bad in your case, because users being humans, they will want to use the same user-id and password as in the internal network, so a hacker that gets the "outside" user-id and pw also gets the one for the inside Domain. - Digest is a bit more secure, because the user-id and password do not circulate directly on the network. What circulates is a hash composed on the base of user-id, password and other things. If someone captures the conversation, they would be able to use this hash to gain access to your server, but at least they can not use the user-id and password for something else. - IE and Firefox (with an add-on) also support NTLM, but this will not work outside with IE, because IE will not do that if the workstation is not already logged-in in the Domain. - another way, is to run all outside accesses over HTTPS, and have e.g. a login page and a method behind that sets a cookie, and re-uses that cookie at each access to provide the "single-sign-on". That is supported by all browsers, is very secure and may be in the end be the best solution, but I am not competent with HTTPS and you would need someone else to help you.
So unless you want the HTTPS solution, the one that might be possible would be something like :
- sspi tries first
- if it works, ok (that basically means the user is inside)
- if it does not work, fall back to LDAP on the server side,
with a browser exchange using Digest authentication.
This might be possible using mod_auth_digest, with the
"AuthDigestProvider" directive to indicate an LDAP provider such as
mod_authnz_ldap.
But I am not quite sure how to do that, because the Apache documentation
does not seem to make a direct link between these two (as it does
between mod_auth_basic and mod_authnz_ldap).
And I am not quite sure if sspi really works well with another
authentication module behind it.
See, what you want to avoid is that, when sspi first sends a 401 header (authorization required, type = NTLM), the browser would automatically fall back and do a Basic authentication. Because that is what is happening now, and it would send the user-id and password in clear over the Internet. You do not want that to happen in your case.
There may be other solutions, such as this kind :a first filter module which determines (on the base of the remote IP) if the user is inside or outside, and depending on the case re-directs the browser to the appropriate section of the website (or Virtual Host), set up with the appropriate kind of authentication (sspi or digest/ldap).
I can think of a way to do this using mod_perl, but it represents some work. Maybe you could have a look at mod_rewrite for this also. Or maybe this :would it be acceptable for your users to use a different hostname depending on wether they are inside or outside ? If yes, then it would be a bit easier : you could set up two Virtual Hosts (one for inside and one for outside) and have a different authentication method on each (sspi inside, another outside). That would at least avoid the issue of having two authentication methods working together. Your Virtual Hosts could share the same document space (DocumentRoot directory).
Anyone else with a better idea ? --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|