Listed on:

& more others...

© 2002-2008
BluWaySoft
All rights reserved

If you don't found answer to your trouble, please contact us by e-mail to:

IMPORTANT:
1) Check that "Basic Authentication" is disabled and "Allow Anonymous" is enabled for site that you want to protect, into IIS4/5/6 Management console.
2) Directories and files that you protect must be available to IIS anonymous account.
If you have trouble, try first to browse files disabling IISGate protection.

Learn all about IISGate with tutorials

More info:
   >Database VS INI-stile file
   >Administration directory selection 
   >Administer IISGate remotely on your LAN
   >How works the "concurrent login" feature
   >IISGate authentication by cookie
   >ODBC database connection
   >Load-balanced (cluster) web servers
   >Using HTTPS for basic and cookie authentications
   >Disabling IISGate without un-install it
   >Protect directory property:
        >>Redirection directory examples
        >>Access denied HTML control
        >>Access denied URL control

Database VS INI-stile file:
You can select to store the users on external database with ODBC connection or on INI-stile text file. According to your application, the table below will help you to choose.

Administration directory selection:
Open the administration program and follow the menu "File>Admin directory…" to select IISGate administration directory to viewing or editing settings.
The directory can be located on the same computer or a computer on LAN.
In both cases you must own the read/write privileges (NT security) for the target directory.
The IISGate admin directory is a directory that contains the 4 files:
   iisgate_dir.adm
   iisgate_global.adm
   iisgate_user.adm
   iisgate_group.adm

Administer IISGate remotely on your LAN:
You can install IISGate on computers on your LAN in order to administer IISGate remotly. When install the software, select to install only the administration program. You can install the program on Windows® NT (SP6) / 2000 / XP / 2003 operative systems.
Once complete the installation, run the program and follow the menu "File>Admin directory…" and select IISGate admin directory to viewing or editing settings.
The admin directory is the installation folder where IISGate is installed on server.
You must share this directory on your LAN and grant read/write privileges (NT security) to users needed.
Please, check that you login with these privileges before to administer.
The IISGate admin directory is a directory that contains the 4 files:
   iisgate_dir.adm
   iisgate_global.adm
   iisgate_user.adm
   iisgate_group.adm

How works the "concurrent login" feature:
If a user account is used by more that one computer at the same time, event "concurrent login" occur. IISGate trigger this event watching HTTP traffic request into 1 minute range. In this way, IISGate don't blocks the concurrent user to logon, but it waits for its initial HTTP traffic. This is for not trigger false "concurrent login" events.

IISGate authentication by cookie:
To protect a directory by cookie, follow these simples steps:
1) Copy the file "login.asp" (located in "cookie_auth" subdir of the installation directory) on previous dir that you want to protect.
2) Open "login.asp" and edit "PROTECTED_SUBDIRECTORY" variable. Delete comment character " ' " (see comments into file) if you want that cookie authentication will be persistent (don't lost with browser session).
3) Run admin program and add the directory to the protected directories list.
4) In the directory property, select "Cookie" authentication control and input the virtual path (format = http://[INTERNET_DOMAIN_OR_IP_ADR]/.../login.asp) of "login.asp" file.
5) Add users granted to protected directory.

NOTE:
The directory shared on IIS where reside login.asp must be outside IISGate protection.
View example below if you want apply redirection feature over cookie authentication.
Cookie credentials are supply from browser for all wide site where they was validated.
For example, if I have successfully provide my credentials to URL "http://www.iisgate.com/auth/",
then the browser supplies login credentials for all wide site "http://www.iisgate.com/...".
The same for Basic authentications, if the protected directories in the same site, have the same "realm" description.

ODBC database connection:
The database connection settings (ODBC source name and the advanced settings) are shared from IISGate admin program and the IISGate ISAPI filter (loaded with IIS WWW publishing service). The only setting that isn't shared, but is only used from the IIS WWW publishing service, is the "Impersonate NT user..." into advanced settings. If you have troubles connecting to database using the admin program, try to login into Windows with an NT account that has granted privileges to database file.

The admin program uses ODBC connection settings for:
1) Test database connection during wizard.
2) Retrieve tables names during setting protected directory property.
3) When you want to view or edit granted users table.
4) When you want to test settings and tables content for every protected directory.

The IIS WWW publishing service uses ODBC connection settings for:
1) Retrieve granted users during authentication.

NOTE:
If you have Windows XP or Windows 2003 server and your database file is on another computer in your LAN, in your ODBC connection property, set the path of the database using UNC format (\\servername\...\file.xxx). Do not map a network drive. If you have a database Access file, open the registry to [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\name_of_your_ODBC_connection]
and into "DBQ" key, type the UNC path for reach your database file. The same for "DefaultDir" key.

Load-balanced (cluster) web servers:
IISGate supports load-balanced web servers.
You must install IISGate on all load-balanced web servers and use a database with ODBC connection for users.
A single point of administration is guaranted modifing IISGate settings only on the first cluster node and replicating the 2 files iisgate_dir.adm and iisgate_global.adm, into installation directory, to others cluster servers.

If you use the "concurrent login" or "FrontPage" or "attack protection" features, you need to modify the WLBS session support to direct all client requests from a TCP/IP Class C address range to a single cluster host. This feature ensures that clients which use multiple proxy servers to access the cluster will have their TCP connections directed to the same cluster host.

In the white paper for Microsoft Windows NT/2000 Load Balancing Service, the section on Affinity and Session Support provides the key information: 
"WLBS supports client sessions and Secure Sockets Layer (SSL). If a server application (such as a Web server) maintains state information about a client session that spans multiple TCP connections, it is important that all TCP connections for this client be directed to the same cluster host. Should a server or network failure occur during a "stateful" client session, a new logon may be required to re-authenticate the client and re-establish session state. ..... WLBS also allows modification of session support to direct all client requests from a TCP/IP Class C address range to a single cluster host. This feature ensures that clients which use multiple proxy servers to access the cluster will have their TCP connections directed to the same cluster host. The use of multiple proxy servers at the client's site causes requests from a single client to appear to originate from different systems. Assuming that all of the client's proxy servers are located within the same 256 host Class C address range, WLBS ensures that client sessions are properly handled with minimum impact on load distribution among the cluster hosts."

So long as the domain name (eg www.domain1.com) remains the same across requests, then the browser will continue to supply the cookie-based or Basic Authentication logon credentials in the http request. If you have IISGate installed on each machine in the cluster, then users will not have to login each time they are served by a different machine in the cluster.

Using HTTPS for basic and cookie authentications:
>Basic authentication uses Base64 encoding (not clear-text) to encode the username and password between the browser and the server. This is a public encoder method, so easily breakable.
>Better situation for cookie authentication, where the username and password are sent to server in encrypted way (from version 4.73) with a custom private key.

If you want to keep more secure the transitions from client and server you must to use SSL (HTTPS). In this way the username and password is encrypted like the rest of content. Using SSL (HTTPS) will add a level of encryption which is virtually unbreakable. Keep in mind to place all protected directory into HTTPS site because the browser sends credentials for every page requested into these directories.

Disabling IISGate without un-install it:
>You can temporarily shut down IISGate on IIS modifing the key registry "HKEY_LOCAL_MACHINE\SOFTWARE\IISGATE\IISGate disabled" to 1  and re-starting the "WWW publishing service". WARNING !!! all protected directories will be un-protected.

Redirection directory examples:
A "Redirection" directory is a special protected directory that you can use to create, into your site, a single point of authentication for all your users. A user, successfully authenticated into a redirection directory, is automatically redirected to its custom protected directory. This feature is disabled if you have enabled the ODBC database connection, in the global properties.

This example demonstrates how you can build a redirection directory with cookie authentication:
1> I have a site "http://www.iisgate.com/", virtual dir of the real directory "d:\site\".
2> I make a new dir "d:\site\auth\" (reaching with "http://www.iisgate.com/auth").
3> I copy  in this new dir the login.asp file.
4> I edit into login.asp file the "PROTECTED_SUBDIRECTORY" variable to "protected".
5> I make a new dir "d:\site\auth\protected\".
6> In the global properties, add the new cookie redirection directory "d:\site\auth\protected\" and I type "http://www.iisgate.com/auth/login.asp" in the URL control.
7> I make a new dir "d:\site\users\" (reaching with "http://www.iisgate.com/users")
8> I create a new user named "user1" and type "http://www.iisgate.com/users/user1/default.htm" in the URL redirection control.
9> I make a new dir "d:\site\users\user1\", I place an empty file named default.htm into its and I protect this dir with IISGate.
10> In the property of protected directory, I select Cookie authentication, and type "http://www.iisgate.com/auth/login.asp" in the URL control.
11> I grant access to this protected directory only to "user1" above created.
12> I repeat from point 8 for every user insertion.

NOTE:
The directory shared on IIS where reside login.asp must be outside IISGate protection.
The "d:\site\auth\protected\" folder is used for redirecting users to their protected directory (it's empty but necessary).
Login.asp file must exist only in "d:\site\auth\" folder (this is the authentication directory for all users).
If a user try to go to its protected dir directly without pass through authentication, it will be redirect to common authentication point.
The link "http://www.iisgate.com/auth/protected/" will be the common authentication point for all users of your site.

This example demonstrates how you can build a redirection directory with cookie authentication WITH LOGIN.ASP PAGE INTEGRATED INTO ASP HOME PAGE:
1> You have a site "http://www.sitename.com/", virtual dir of the real directory "d:\site\".
2> Copy the login.asp code into your home page (ex. default.asp, MUSTE BE AN ASP PAGE).
3> Edit into copied code the "PROTECTED_SUBDIRECTORY" variable to "protected".
4> Make a new dir "d:\site\protected\".
5> In the global properties, add the new cookie redirection directory "d:\site\protected\" and I type "http://www. sitename.com/default.asp" (home page) in the URL control.
6> Make a new dir "d:\site\users\" (reaching with "http://www.sitename.com/users")
7> Create a new user named "user1" and type "http://www.sitename.com/users/user1/default.htm" in the URL redirection control.
8> Make a new dir "d:\site\users\user1\", place an empty file named default.htm into its and I protect this dir with IISGate.
9> In the property of protected directory, select Cookie authentication, and type "http://www.sitename.com/default.asp" (home page) in the URL control.
10> Grant access to this protected directory only to "user1" above created.
11> Repeat from  point 7 for every user insertion.

This example demonstrates how you can build a redirection directory with basic authentication:
1> I have a site "http://www.iisgate.com/", virtual dir of the real directory "d:\site\".
2> I make a new dir "d:\site\auth\" (reaching with "http://www.iisgate.com/auth").
3> In the global properties, I add a new basic redirection directory "d:\site\auth\" and type the "Realm" = "IISGate".
4> I make a new dir "d:\site\users\" (reaching with "http://www.iisgate.com/users")
5> I create a new user named "user1" and type "http://www.iisgate.com/users/user1/default.htm" in the URL redirection control.
6> I make a new dir "d:\site\users\user1\", I place an empty file named default.htm into its and I protect this dir with IISGate (type the same "Realm" of the redirection directory above!!!).
7> In the property of protected directory, I select Basic authentication and I grant access to this only to "user1" above created.
8> Than I repeat from point 5 for every user insertion.

NOTE:
The "d:\site\auth\" folder is used for redirect users to their protected directory (it's empty but necessary).
The link "http://www.iisgate.com/auth/" will be the common authentication point for all users of your site.

Access denied HTML control in "Protect directory property":
You can customize the HTML page displayed for bad logins during basic authentications.
In this control insert the HTML tags of your custom "access denied" page (insert only HTML code that appear between <body> </body> tags in a normal HTML document, moreover every link or path to files must be an absolute URL "http://...")

Access denied URL control in "Protect directory property":
You can set the HTML/ASP/PHP page displayed for bad logins during basic authentications.
This link must be a URL to a file that resides on a web server in Internet or on the same web server where IISGate is installed. Every link or path inside to linked file must be an absolute URL ("http://...").

Copyright © 2002-2008 BluWaySoft. All rights reserved