James, Works like a champ! Thanks - the only thing I am noticing is that it can sure slow the initial page load while it makes sure that you are who you say you are.
I built a test site with the directives in the htaccess file for mod_auth_sspi. When my initial index.pl loads it grabs the user login from the environment variable and builds a cookie for the user. Once the user has a cookie, then the rest of the cgi's use the cookie. What would be ideal is to have a way to bypass the htaccess file if a cookie was present. That would really speed things up. Any ideas? -----Original Message----- From: Tillman, James [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 10:02 AM To: 'Norris, Joseph'; 'Mark G. Franz'; Perl Web (E-mail); Perl Admin (E-mail); Perl Win32 Users (E-mail) Subject: RE: Question about IIs You might check out the mod_auth_sspi module. It is supposed to allow this kind of authentication to happen through Apache. It looks promising, but all my Apaches are on Linux and the module requires windows, so I haven't had time yet to try it out. http://www.syneapps.com/software/mod_auth_sspi/ In the worst case, you might try using the mod_auth_any module and rolling your own NTLM authentication mechanism that uses some perl code. That might be a bit time-consuming, though. jpt > -----Original Message----- > From: Norris, Joseph [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 11:54 AM > To: Tillman, James; 'Mark G. Franz'; Perl Web (E-mail); Perl Admin > (E-mail); Perl Win32 Users (E-mail) > Subject: RE: Question about IIs > > > Thank you James. With this type of information never fear > "long-winded-ness" ;) > > I am not as brave as you in using IIS and suffering with it. I loaded > apache > almost immediately. However I am now finding that the powers > that be want > this type of authentication from windows. > > Is what you mention below exclusively windows/IIS or can > Apache be tinkered > with > to find out who the log on user is. At present when I look > at the %ENV > variables > I only see the user that apache is using to sign on with - > not the actual > user > using the web page. We are using only IE - is there any way that I can > exploit this > for my purposes on our intranet? > > Thanks again for any and all information. > > > -----Original Message----- > From: Tillman, James [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 4:44 AM > To: 'Mark G. Franz'; Perl Web (E-mail); Perl Admin (E-mail); > Perl Win32 > Users (E-mail) > Subject: RE: Question about IIs > > > Perhaps I can clarify this issue a little further, having had the > displeasure of working very closely with IIS for the last 5 > years or so ;-) > > First, Internet Explorer is the only Web client that can use > with what is > called "Integrated Windows Authentication". This is a > setting that can > applied to a web site (or sub folder or sub page on a site) > which will allow > users to authenticate using their Windows domain usercode and > password. If > you enable "Basic Authentication" on a site, folder, or page, then > Netscape/Mozilla/others can allow users to send their Windows domain > usercode and password *in cleartext across the network* to perform > authentication against the domain. > > With that in mind, there is one more quirk of IE that is > worth explaining > regarding automatic logons using network credentials. IE has > a special > security mechanism that splits web sites into various > groupings (called > "Zones") based on certain settings in the browser. These zones are > "Internet," "Intranet," "Trusted Sites," and "Restricted > Sites." The 2 I'm > usually most interested in are the Internet and Intranet sites. > > A site ends up in the Internet zone based on whether the > server name has a > dot in it. I'm not kidding here. That seems like a very > arbitrary measure > to use, but it does handle IP addresses as well as domain > names. Internet > sites rightfully receive the most restricted security > settings. One of > these restrictions is that your Windows network > authentication credentials > will not be sent automatically. > > A site ends up in the Intranet zone by default if its name > does NOT have a > dot in it. This means that sites you access using WINS or > hostname aliases > or by default domain name appending (configured in the > network settings of > the computer), will be placed in the Intranet zone. As you might have > guessed, IE will automatically log you in to Intranet sites > without forcing > you to re-enter your user code and password. You can > actually add sites to > the Intranet zone by manually entering them. Since our > network uses neither > WINS or Dynamic DNS (please, don't ask), this is what the users in our > rather large network have to do in order to log on consistently to our > Intranet. > > The logged-in status, by the way, lasts as long as the > browser process does. > If you have all your IE browsers tied together (i.e., you > have unchecked the > "Start browsers in a new process" checkbox in IE's advanced > settings), then > you will remain logged in for as long as IE is in use > somewhere on your > machine. That's been my experience anyway. > > "Integrated Windows Authentication" is enabled for webs, > folders, or pages > in the Internet Service Manager (which is a Microsoft > Management Console > (MMC) tool). More information on that can be found in the > help files for > IIS. > > As for getting access to the logged-in user's name, MS at > least made that > simple: They set the standard environment variables LOGON_USER and > REMOTE_USER regardless of the logon method. These are usable > from perl > CGI's (via the %ENV hash) or from ASP as others have > mentioned. Someone > recently informed me on this list that REMOTE_USER is more > portable to other > web environments. I've always used LOGON_USER with no > troubles in IIS. The > choice is yours, I suppose. > > One final point to keep in mind: When your users > authenticate with their > network credentials (automatically or manually), they MUST > have "Log on > locally" rights on the server computer. Also, because IIS will be > impersonating them at that time, they will also need certain > access rights > to the web files they are attempting to access AND to > anything else those > files might depend on. In the case of ASP pages, they'll need execute > rights on the ASP.dll which usually appears in > c:\winnt\system32\inetsrv\ > (your installation may vary). Note that registry permissions > are also a > potential issue. > > You can spend days, even weeks, tracking down hard to > understand permissions > problems on an IIS server once you start fiddling with the permissions > (perhaps in an attempt to "lock the server down"). If you > find yourself in > this situation, I recommend learning how to use "Auditing" on > a Windows > Server, and also going to www.sysinternals.com and picking up > their FileMon > and RegMon tools. These will help you track down the > problems. Note that > IIS itself will be of absolutely NO help in most of these > situations. Its > error messages are useless about 90% of the time. > > Sorry to be so long-winded, but I felt you might benefit from > a bit of this > knowledge. It took a lot of sweat and tears for me to pick > all this up over > the years! > > jpt > > > -----Original Message----- > > From: Mark G. Franz [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 13, 2003 12:03 PM > > To: Perl Web (E-mail); Perl Admin (E-mail); Perl Win32 > Users (E-mail) > > Subject: Re: Question about IIs > > > > > > Yes and no, when a Windows user authenticates to a local > > domain, and the web > > server is the same server then there is no second dialog box > > for logging > > onto the site. Without going into a lot of details, when a user > > authenticates to a server it is stored in a system session > > variable that > > dies after the default timeout. > > > > However if the web server is on a different machine and the > > Users and Groups > > are not replicated across the network then yes, the user will > > have to login > > again. If the web server and the domain controller are one > > in the same then > > no, you will not have to log in twice, the same goes if the domain > > controller and the web server replicate ACL's > > > > Mark > > > > ----- Original Message ----- > > From: "Norris, Joseph" <[EMAIL PROTECTED]> > > To: "'Mark Bergeron'" <[EMAIL PROTECTED]>; "Norris, Joseph" > > <[EMAIL PROTECTED]>; "Perl Web (E-mail)" > > <[EMAIL PROTECTED]>; "Perl Admin (E-mail)" > > <[EMAIL PROTECTED]>; "Perl Win32 > > Users (E-mail)" > > <[EMAIL PROTECTED]> > > Sent: Thursday, February 13, 2003 8:46 AM > > Subject: RE: Question about IIs > > > > > > > I guess I should be clearer about where I am going with > > this and to where > > I > > > have come. First of all I have written a fair > > > amount of code based on Apache/mysql/Perl and I have used > > cookies and > > hidden > > > variables etc... > > > > > > My experience in the world of htaccess has been that if > > there is such a > > file > > > and the apache conf file is set to recognize it, > > > the user gets a pop-up for user/password combination. I > > have the notion > > > (please correct me if wrong) that on IIs the same > > > thing happens but the pop-up checks against the magic > > secrete windows > > stash > > > of users/passwords. So am I correct in thinking > > > that if a user uses his logon/password to get onto the > > windows network, > > that > > > he would have to enter this again if he logs on to a IIs > > web page that is > > > protected via the IIs user/password scenario? > > > > > > I have begun to code the apache http.conf file with PerLDAP > > so as to plug > > > into Active Directory and what I mention above I am experiencing. > > > > > > > > > I hope I have explained myself and again, thank you for > all of your > > > comments. They have been very helpful to my understanding > > of this process. > > > > > > > > > -----Original Message----- > > > From: Mark Bergeron [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 12, 2003 1:04 PM > > > To: Norris, Joseph; Perl Web (E-mail); Perl Admin (E-mail); > > Perl Win32 > > > Users (E-mail) > > > Subject: Re: Question about IIs > > > > > > > > > This is really more of an ASP question I guess. You can > > track the user > > > through IIS with the Session Object. Of course there are > > many, many ways > > of > > > doing the same with IIS and Perl. Session information is > > one of the easier > > > elements to track within an application. Go and check out > > Oreilly's site > > and > > > go to the Perl section. Download the examples for CGI > > Programming with > > Perl > > > 2nd edition. There is an application in there that uses > > session data and a > > > unique key to track a user within a shopping cart. > > > > > > Here's the URL: > > > http://www.oreilly.com/catalog/cgi2/ > > > > > > While you're at it, buy the book (-8 > > > > > > GL, Mark Bergeron > > > > > > > > > -----Original Message----- > > > From: "Norris, Joseph"<[EMAIL PROTECTED]> > > > To: "Perl Web > > (E-mail)"<[EMAIL PROTECTED]>, "Perl > > > Admin (E-mail)"<[EMAIL PROTECTED]>, > > "Perl Win32 > > > Users (E-mail)"<[EMAIL PROTECTED]> > > > Date: Tue Feb 11 08:20:33 PST 2003 > > > Subject: Question about IIs > > > > > > >Group, > > > > > > > >I am into apache but I have a question about Microsoft web > > server IIs. > > > Does > > > >it have enough hooks into the operating system > > > >that I can detect when a user has signed on using their > > profile and know > > > >what that user's login name is? > > > > > > > >Please provide your experience and a site that explains > > this. Thanks for > > > >your help. > > > > > > > > > > > >I have cross-posted on this one because you never know > > just what experts > > > are > > > >found where. Thanks again. > > > > > > > >_______________________________________________ > > > >Perl-Win32-Users mailing list > > > >[EMAIL PROTECTED] > > > >To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > > > > > > > > ___________________________________________________ > > > GO.com Mail > > > Get Your Free, Private E-mail at http://mail.go.com > > > > > > > > > _______________________________________________ > > > Perl-Win32-Web mailing list > > > [EMAIL PROTECTED] > > > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > > _______________________________________________ > > > Perl-Win32-Users mailing list > > > [EMAIL PROTECTED] > > > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > > > > > > _______________________________________________ > > Perl-Win32-Users mailing list > > [EMAIL PROTECTED] > > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > > > _______________________________________________ > Perl-Win32-Users mailing list > [EMAIL PROTECTED] > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs > _______________________________________________ Perl-Win32-Admin mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
