On Thu, 22 Jul 2004, Rick Whitley wrote: > >From the user perspective, the first thing they will see is the > disclaimer page. Clicking either the login or activation link will be > the same as accepting the conditions. Where would I modify the > authentication window?
Unfortunately, I was the "unix guy" on the projects and dealt, primarily, with the network infrastructure and perimeter security. Windows was treated as a shared application. The applications support group made the modifications. Basically, I can only tell you that it can be done but nothing about the how. Merton Campbell Crockett > > thanks > > rick... > Rom.5:8 > > >>> Merton Campbell Crockett <[EMAIL PROTECTED]> 7/22/2004 8:20:00 AM > >>> > Out of curiousity, why is the notification that computer and network > usage > will be monitored being deferred until this late in the game? > > The monitoring began the moment the individual logged into the > sorkstation > or laptop and requested to use the Windows NOS. The pop-up > authentication > window can be modified to display the notification message and inform > the > user that he is agreeing to be monitored by submitting his > credentials. > > At one site where I did some work, the login process was modified so > that > a separate pop-up window was used. If you clicked on the accept > button, > the authentication window was displayed. > > Merton Campbell Crockett > > > On Thu, 22 Jul 2004, Chris Perreault wrote: > > > Here at my work all employees sign a form stating that they realize > email, > > internet usage, file storage systems, etc are for work purposes and > that > > none of it is truly private. That email will not be directly read > except for > > troubleshooting/maintenance issues unless there are illegal or > non-condoned > > company activities taking place. > > > > All traffic encrypted? Encryption puts a burden on the servers and if > all > > the traffic is being encrypted, then what exactly *is* being > monitored? > > > > Thoughts? Set your PC's gateway to your Apache server, visit > www.google.com, > > get your disclaimer page to come up, sign in, and then have it make > you end > > up at google. If this works, insert Squid afterwards. (one piece at a > time, > > see what works, what doesn't) > > > > Chris Perreault > > > > > > -----Original Message----- > > From: Rick Whitley [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 21, 2004 5:37 PM > > To: [EMAIL PROTECTED]; Chris Perreault > > Subject: RE: [squid-users] Re: Implementation issues > > > > > > The disclaimer page gives us the opportunity to inform the users that > their > > traffic is being monitored. It's the law. I am open to suggestions as > to a > > better way to accomplish this. I agree its ugly. The disclaimer page > would > > have a login link that went to the 2nd proxy. On top of everything, > they > > want the traffic encrypted. I need to get a workable process working > first. > > What if the first stop was a web server? > > > > client -> Apache -> Proxy -> internet > > | > > signon > > > > Here apache would trap the traffic unless authenticated(session > variable?). > > We would have apache be the gateway. > > > > Thoughts? > > > > rick... > > Rom.5:8 > > > > >>> Chris Perreault <[EMAIL PROTECTED]> 7/21/2004 3:55:21 > PM > > >>> > > First attempt: > > > > client -> Proxy1 -> sign-on/disclaimer -> Proxy2 -> ldap -> Internet > > > > User clicks on a page, sending another request, which then will do > > this: > > > > client -> Proxy1 -> sign-on/disclaimer -> Proxy2 -> ldap -> Internet > > > > If proxy1 sends all traffic to the signon page, then all traffic > passes to > > it. All of it. Each request is coming from the browser, not the > signon > > server, so each request hits the proxy1 first and gets resent to the > logon > > page. Ok...so if a session variable knows the user logged in, then > the > > signon server can redirect the request for the website through > proxy2. All > > requests would pass through proxy1-->signon server-->proxy2. If > that's > > acceptable, it looks like it would work. You'd want to redo the > session > > variable on each hit, or else you could have the user relogging in > every 20 > > minutes or so. If they were doing anything on the web (filling in a > form or > > taking a test) and didn't submit another request for a while, their > session > > could time out and they sure wouldn't be happy. It looks doable, but > it > > looks ugly too. > > > > Once a user has signed up, you want them to get the disclaimer page > every > > time they fire up a web browser? > > > > It would be much easier to have them just sign an "internet use > policy" and > > in exchange tell them their username and password:) > > > > > > > > Chris Perreault > > Webmaster/MCSE > > The Wiremold Company > > West Hartford, CT 06010 > > 860-233-6251 ext 3426 > > > > > > -----Original Message----- > > From: Rick Whitley [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, July 21, 2004 3:44 PM > > To: [EMAIL PROTECTED]; Chris Perreault > > Subject: RE: [squid-users] Re: Implementation issues > > > > > > What we are thinking of doing is: > > > > client -> Proxy -> sign-on/disclaimer -> Proxy -> ldap -> Internet > > > > The 1st proxy will be open and require no auth and redirect all > traffic to > > the sign-on/disclaim site. User has option to Activate account or > visit > > Internet. The "Visit Internet" link will change go to the 2nd proxy > which > > will have proxy_auth enabled for ldap. The client will be prompted > with a > > userid and passwd dialog to be authenticated and sent to the > internet. > > > > Does this seem possible? I have the gateway for the segment set up to > be the > > 1st proxy so I may still have a loop issue. Is there an automated way > to > > modify the gateway on client systems? Like a forced dhcp without the > > request. If we could make this behave as two separate segments ( seg1 > = 1st > > proxy with no auth required, seg2 = 2nd proxy with auth > > required.) client would always start in seg1 and have to request > seg2. Any > > thoughts or suggestions are greatly appreciated!! > > > > thanks > > > > rick... > > Rom.5:8 > > > > >>> Chris Perreault <[EMAIL PROTECTED]> 7/21/2004 2:02:23 > > PM > > >>> > > Doh, there is a referer_regex ACL type, but I don't see that helping > here > > anyways. > > > > 1)Browser wants to visit website.com and hits the proxy. > > 2)Request gets redirected to the signup_disclaimer.htm website. > 3)User signs > > up and/or logs in. 4)The page that verifies the username/password > then > > redirects to the originally requested site with the login information > stored > > in the correct header. (via the proxy) > > 5) the proxy sees the refering site and proxies the request. > > > > A better 5) would be squid sees it has an already authenticated > request so > > passes it through. Otherwise the user would have to log in, on the > > disclaimer page, every time they clicked a link. Open a new > window/session > > though and then the user would have to log in again. > > > > Hopefully my ramblings help Rick out. I see a loop happening though. > If > > proxy_auth is required, the user gets the pop up window, even if they > don't > > have an account yet. Once they visit the login page, that page should > be > > able to write/create the http_proxy_authorization header. > > I don't see how to redirect the user if they are not auth'd yet > without > > redirecting them when they are auth'd later so it looks like they are > stuck > > with the logon prompt and only get to the disclaimer/login page when > they > > fail to authenticate. > > > > > > Chris Perreault > > > > > > -----Original Message----- > > From: Chris Perreault > > Sent: Wednesday, July 21, 2004 10:15 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [squid-users] Re: Implementation issues > > > > > > > > We may turn into such a sponser. In reverse proxy mode we are looking > for a > > solution where we need to authenticate users as far out in the DMZ > as > > possible. Using ldap via basic auth results in some difficulty in > reaching > > some of the content on various back end webservers which also uses > basic > > auth. Over the next few days we'll determine the best solution, which > may be > > having users redirected to a logon webpage, use a form based > authentication > > that saves the ip, then passes the username down in a header to the > back end > > webservers, thus allowing some of those servers to match the header > username > > with a username in a profile database for portal type content > delivery while > > still allowing basic auth type apps to do their own authentication. > > > > If squid knew the referring IP address (the webserver that has the > > authenticating form on it that after submital send the browser back > to > > Squid) then all users could be directed to the logon page, and after > hitting > > submit go back to the proxy which would allow that referring IP to > get > > proxied info from the web. Spoof the IP though and you get through > without > > authenticating. Figuring that IP out might be difficult for a end > user > > though. > > > > Chris Perreault > > > > -----Original Message----- > > From: Adam Aube [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, July 20, 2004 8:15 PM > > To: [EMAIL PROTECTED] > > Subject: [squid-users] Re: Implementation issues > > > > > > Henrik Nordstrom wrote: > > > > > On Wed, 14 Jul 2004, Rick Whitley wrote: > > > > > >> I was setting up a proxy server to do the authentication and > > >> cacheing, but have learned from the list that it is not going to > > >> behave the way I expected. Users should only see the initial page > > > >> once. I seem to be out in left field as to how to implement this. > > Any > > >> suggestions? > > > > > > In theory it is possible to implement very close to what you want > > with > > > Squid & authentication, but so far no one has been willing to > > actively > > > sponsor such development. > > > > > > It is also possible to use a small proxy.pac script implementing > the > > > > > "startup splash" screen. > > > > Something like this might be a good starting point: > > > > http://www.squid-cache.org/mail-archive/squid-users/200404/0793.html > > > > > Adam > > > > -- BEGIN: vcard VERSION: 3.0 FN: Merton Campbell Crockett ORG: General Dynamics Advanced Information Systems; Intelligence and Exploitation Systems N: Crockett;Merton;Campbell EMAIL;TYPE=internet: [EMAIL PROTECTED] TEL;TYPE=work,voice,msg,pref: +1(805)497-5045 TEL;TYPE=work,fax: +1(805)497-5050 TEL;TYPE=cell,voice,msg: +1(805)377-6762 END: vcard
