Q: I've installed filter in the IIS. I've used admin tool but nothing happens!
A: There are two important things you must note here:
1. CGI tool must initially access the system branch of the registry (HKEY_LOCAL_MACHINE) thus it needs administrative rights for the actions such as: setting configuration file and setting the serial number. To solve the problem you will need to configure IIS to ask for authentication when accessing the admin CGI and authenticate as an administrator when asked. This can be done from the Microsoft Management Console - click properties over the AUTHADMINCGI.EXE and on the File security tab leave checked only "Basic authentication". You can use another type of authentication - but if you are not experienced with the IIS and IE behavior this configuration will be the easiest way (see questions below for more information).
2. Doing the previous actions and having AUTHADMINCGI.EXE working perfectly you may encounter that the filter does not handle authentications still. After configuring or reconfiguring the configuration file and/or serial number you will need to restart the WEB server - type net stop w3svc net start w3svc on the command prompt to do so. This is needed because filter limits access to the registry in order too improve the performance and thus it accesses it only when starting - thus the changes in the registry will not take effect until filter reload.

Q: I can't access the AUTHADMINCGI.EXE with the administratice user account - filter stops me!
A: It is good idea to place this exe in a site not handled by the filter. It is an administration tool for the entire system thus it does not belong to any site. If you have some reason to refer AUTHADMINCGI.EXE in a site handled by the filter you will need to add the administrator account in the bundled to the site authority and uncheck "Map to" check box for him. This will pass this user directly to the NT authority and thus for this particular user filter willbe transparent. Of course you will need to unload or disable the filter temporary in order to do so. In such situations you may need to edit the configuration manualy and especially if you don't want to stop and restart the WEB server. Open the configuration file (usualy AUTH.CFG) and in the section MAIN set value of the Disable record to 1 - example:
(int)Disable=1
This will disable the filter. Then you can enter the CGI authenticating directly to the NT, then you can enable filter by setting this vlaue to 0 (or through the admin tool).

Q: Can I use the Integrated Windows Authentication (NT Challenge response) or Digest Authentication with the filter?
A: Not - these authentications act as like another (alternative) filter(s) thus they are directed to the NT authentication services. Something more - browsers like Netscape, Opera and old versions of the Internet Explorer do not support them thus you must enable clear text authentication on the sites where you are using the filter.

Q: Is it dangerous to use clear text authentication for the site(s) users?
A: This depends on the targets you have. If you are trying to use this filter for some bank account system we can not recommend it. But in the most popular WEB situations it is safe enough - because clear text passwords can be captched only by the routers in the path of the IP packets - thus this requires too much manual work and as a result will serve to the hackers only the web-user password - not the NT password. If this is not enough you can use SSL (Secure socket layer) on your site.
This leads again to suggestion made before: put the main admin tool - AUTHADMINCGI.EXE on the separate site for example Administration site automatically created by the IIS. Making this you can access it using more secure authentication. In difference to the other content on the server here you will use the administrative NT account thus care about the security over the main admin tool is a good idea.

Q: How to use NT Challenge Response authentication to access AUTHADMINCGI.EXE?
A: NT Challaenge Response authentication scheme much likes to the authentication mechanism used for the Windows Networking (file sharings). The behavior of the Internet Explorer is the real problem sometimes - it uses credentials of the currently logged on user (localy) and sends them automaticaly to the server. This happens in the local NT domain(s) only but the filter's admin tool is accessed mostly from the machines on the local network. Thus some problems are quite possible: If the admin CGI is accessible for the local user that you are using you will be logged on as the given user without any notice and if this user is not a member of the Administrators group tool will not be able to write to the system registry! You can resolve such problems in many ways - you can make the exe accessible only for the Administrators (using NTFS security) and thus force the IIS to ask for login or you can set "Clear text authentication" to be used for it. There is one better way - to configure Internet Explorer to always ask for username and password. This can be done in the security tab of the Internet Options dialog (IE 5 and later). Here for the zone where the server is (usualy local Intranet if you are on the local network) you can set "Prompt for user name and password" in the User Authentication tree displayed from the Custom settings button.
If you gonna administer the filter form the remote location without using virtual private networks or some other way to make the server part of the local intranet it will be good idea to add it to the "Trusted sites".

Q: I have problems in the environment with trusted domains.
A: It is always a good idea to specify the full name of the account where needed. For example NT accounts used for mapping can be specified in the full form - DOMAIN\Username. If you suppose that your server can be moved to another domain (one of the trusted) this will help you to keep the configuration/authorities the same.