Iron Speed Designer and your generated application should run on any computer which is in your Active Directory and has proper access to Active Directory. Proper access means both that (a) you can log into your computer using the domain user name and also (b) Iron Speed Designer and your application can retrieve information from the Active Directory such as the root path, search the Active Directory and perform other standard operations.
The network access permissions and the operating system of the machine running your application affect the Active Directory functionality available to your application.
If you run your application on the Active Directory Domain Controller machine, the full Active Directory functionality is available to your application.
When your application is run on any Microsoft Windows 2003 Server which is not the Active Directory Domain Controller, the only limitation is your application will not be able to automatically retrieve user credentials from the session and use them to automatically sign in users. In other words, application users will be prompted for their user name and password via your application’s Sign In page. Of course, the application user can check the ‘remember me’ option on the Sign In Page to avoid signing into future sessions, unless explicitly signing out. I.e., the application user can close the browser window and when opening the application again will be automatically signed in with his stored credentials.
When your application is run on Microsoft Windows XP Workstation the only way to configure Microsoft IIS web server to allow the application to authenticate users via Active Directory is to provide the username and password in the Web.config file:
<identity impersonate="true" userName="username" password="password" />
Microsoft IIS will use these credentials to access the Active Directory. The downside of this approach is that automatic sign in option in Active Directory should be disabled because the application will use username and password values from the Web.config file to authenticate the user instead of the user’s actual credentials. If the automatic sign in option is disabled, users will be able to sign in with their username and password and they can use the ‘remember me’ option on the Sign In page to remember them in the future.
Check if other Active Directory utilities such as Administrative Tools, Active Directory Users and Computers; and Administrative Tools, Active Directory Sites and Services can start. If they can’t find the domain or connect to the domain controller, most likely:
Your computer is not in the Active Directory
Your Active Directory is improperly configured, or
You computer is improperly configured
Contact your IT administrator to properly configure your Active Directory.
Set IIS Authentication Methods to Integrated Windows Authentication. This is located in Directory Security, Anonymous access and authentication control section of the Microsoft IIS Properties menu.
The processModel property in machine.config file should be either:
<processModel
autoConfig="true" />
This is the default configuration. In
this case, Microsoft IIS assigns any process to the ASPNET built-in user with
a low permission level. Your
generated application will not be able to access the AzMan policy store
located in the Active Directory.
<processModel
enable="true" userName="username"
password="userpassword" />
Microsoft IIS assigns a process identity to userName.
Note: If you assign processModel to the built-in System account, most likely the Microsoft Authorization Manager (AzMan) API will not work.
The machine.config file is located in:
C:\<windows>\Microsoft.NET\Framework\<version>\config\machine.config
If you are running application on non-Windows 2003 computer and the Microsoft IIS web server while using an AzMan policy store located in the Active Directory, make these changes to allow your generated application to access the AzMan policy store:
Step 1: Add username account to the ‘Pre-Windows 2000 Compatible Access’ group in your Active Directory.
See http://support.microsoft.com/kb/331951 for details.
Step 2: Set the <processModel …/> property of the <system.web> section in your machine.config file to allow the Microsoft IIS web server to run the ASP.NET application worker process (aspnet_wp.exe) using the account you added to the ‘Pre-Windows 2000 Compatible Access’ group instead of the built-in ASPNET account with lesser permissions. The Authorization Store running on the Domain Controller machine and located in your Active Directory does not allow processes owned by the ASPNET account to access any information.
This property should have these attributes:
enable="true" userName="domain\username" password="validpassword"
See http://msdn2.microsoft.com/en-us/library/aa291339(VS.71).aspx for details.
Note: the Microsoft IIS web server will assign all processes it starts to this account.
If you change your machine.config file, reboot your computer to make these changes effective.
If you do not change your machine.config file, you can still use AzMan role management, with an XML file-based policy store, but in a less efficient mode. This mode only affects authorization of users different from the current user logged into Microsoft Windows. Namely instead of using the GetRolesForUser(username) method to retrieve the list of roles for a particular username, your application will create a new HttpContext with username as a current user, retrieve its roles via the GetRolesForUser() method and then roll back to the previous context.
Active Directory and Microsoft Authorization Manager Configuration