I have succeeded in configuring
DAF5 on our new IIS6 web server. DAF is the linchpin of our web intranet, as it permits our web site to authenticate parents without creating network accounts for them. It also provides a standard HTML login form instead of the default Windows popup dialog.
DAF permits a web site to authenticate users against two databases. We authenticate our network users against Active Directory and our parents and guest users against an Access database. DAF checks the Access database first and then forwards unknown users to IIS for Active Directory authentication. I don't know of another product that does this function, so I was thrilled to be able to configure it correctly. Since DAF5 is in perpetual beta, documentation is scarce.
I found the correct configuration through educated trial-and-error. Here are the key steps.
IIS Manager --> [your web site] --> Properties --> Directory Security --> Authentication and Access Control --> Enable Anonymous Access
You must allow IIS to enable anonymous access in order for DAF to take over authentication for this web site.
Security Handler --> Always use a SSL connection
This is essential to prevent the plain text transmission of user passwords. Windows is no help in this regard, since Windows basic authentication is required in order to authenticate non-Internet Explorer users. Instead, I have purchased a SSL certificate for this web site, which in conjunction with DAF will make login encrypted for all users.
Security Handler --> Login Form Type --> HTML Login form
This points DAF to a HTML form instead of using a standard popup dialog. The form is located in /session in your web site. You can modify the HTML there, as long as you leave the form mechanics and includes intact. Check out our
modified login form.
By default, login failure brings up a different web page. I pointed our failure page back to the same login form page, on which the error message appears. Later, it would be preferable to either make the error messages more verbose or to redirect to a different failure page with more information about what the user can do to correct the problem.
Security Handler --> User ID & Session --> HTML Login Form (using Cookies)
I used the defaults for HTML form.
Security Handler --> Advanced --> Default DAFAUTH.INI file
This step is critical to protect all of the directories in your web site at once. By default, a dafauth.ini file must be present in each directory in your web site. Since this is impractical, it is easier and more secure to choose an appropriate ini file here. Mine has the following simple settings:
[PreAuthentication]
Anonymous = disable
Authenticated = enable
Then I set NT folder security as appropriate for the access permissions I want.
Security Handler --> Count as ONE Registered Protected Site
If you don't register with DAF, then only ten users can connect to your site.
Security Handler --> Logs
Enable Write to log file. DAF keeps different sets of error logs for different purposes. The most useful logs for debugging configuration are site-specific and found in /dafdata just outside the web site directory that you specified during installation. Note that /dafdata has the web site resource id appended to its directory name.
User DB --> Data Store --> Primary Data Store --> ODBC Data Source --> Settings
User your server's Administrative Tools --> Data Sources (ODBC) to set up an ODBC link to your external database containing non-network user information. I wrote a separate PERL script to populate this database with registered parent login information.
Source & Connection tab: Select the ODBC source for your database and provide login information if necessary.
Table & Columns tab: Match the columns in your ODBC database to DAF standards.
Advanced tab: Use defaults
User DB --> Data Store --> Secondary Data Store --> NT User DB --> Settings
Default NT Domain: Select NT Domain User Database and specify the default NT domain. This step seemed helped in order to successfully authenticate network users without requiring them to specify their domain.
NT Account Mapping: Select Forward credentials to NT/IIS. This step permits IIS to authenticate network users, e.g., those who aren't in the DAF database.
User DB --> Session
Enable session state. This is required for this approach, but I don't recall why.
Other settings keep their defaults.
User DB --> NT Accounts
Default mapped NT account: This is an easy way to control privileges for the parent users on our network. As it happens, my parent registration script creates a static mapping in the DAF database, so I leave this setting empty.
Data source Login NT account: A server user that has privileges to read and write the DAF database. If this is improperly set, you will see corresponding error messages in the site error log.
User DB --> Encryption
I would like to use encryption, but it is easier to set this up for a clean install than to migrate existing, unencrypted passwords to this system. I will work on this soon.
User DB --> Logs
Write to log file
Exchange server default home page!
Richard Kassissieh is Director of Information Services at 
RSS 2.0 