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
