Active Directory Integration
An overview of active directory authentication and authorization with the Alpha Anywhere IIS Application Server.
Active Directory authentication and authorization can be used in 2 different ways in Alpha Anywhere:
Use an Active Directory rather than a custom database to validate credentials that a user enters into a login page.
"Windows Integrated Authentication" whereby a user and the server are in the same Active Directory domain and an automatic negotiation can be done to identify the user*.
*Windows Integrated Authentication is only implemented in Alpha Anywhere Application Server for IIS as of build 2358.
The Active Directory store is treated as read only by Alpha Anywhere. Management of Active Directory users and groups is outside the scope of Alpha Anywhere and is left to the Active Directory administrator's usual tools.
A web application that uses a form to collect user credentials should run over HTTPS so that the credentials are encrypted when transmitted from the browser to the server.
Edit the Web Security Configuration for your web project.
Select the "Use Active Directory" option. The prompt below this option will change to read "Security Table Type for Development and Testing". A DBF file or SQL database will still be used for developing and testing of the application. This means you can develop and test the application without having or needing to have access to the production Active Directory domain. The group names used during development and testing do need to be the same as in the Active Directory. The "Web User and Groups" dialog "Groups" tab allows group names to be imported from an Active Directory or a text file. Create or edit the publish profile settings for the production web server to configure the Active Directory server used in production. Publish profile setting for development and test servers should use the custom DBF file or SQL database.
Set the remaining security settings needed, such as the redirect pages.
While users and groups are now used through Active Directory, developing and testing the web application against a production Active Directory server can be impractical because you may not have access to the Active Directory server. For this reason, you will want to create users and groups to be stored in a DBF file or SQL database. These users and groups will be used during development and testing.
In order to work in this way, the name of the groups you want to secure against must be spelled the same way as they are stored in the Active Directory. If you only have a few, you can manually enter the groups and add some users as members of the groups. Otherwise, you can import groups directly from Active Directory or from a file.
Importing groups gives you the option to merge into existing groups (add group names not already in the list), overwrite existing groups (delete all groups before adding groups being imported), and include a test user in each group.
When you select "Add test user to each group", the generated test user's name will be the group name prepended with "TestUser-", and the test user's password is set to the string "password".
Example: A group name of "Engineering" will get a test user with the name "TestUser-Engineering".
To import groups from a file, change the Group name source to "File". Then specify a file that has the name of each group on a separate line. A test user name can be include for the groups too. The test user name follows the group name on the same line. Two tab characters are included between the group name and the test user name. The format of the test user name is the test user's name followed by a | character and then the SAM-Account-Name for the test user. Example: John Doe|jdoe
A command line tool named A5ActiveDirectoryExport.exe is included in the Alpha Anywhere Developer Edition installation for generating a file from an Active Directory that can be imported into the Alpha Anywhere Developer Edition. This stand alone exe file can be sent to anyone who has access to Active Directory to create a file for import. The command line options are:
Show the command line options.
Specify a domain name.
Username that has permission to access Active Directory.
password of the Username that has permission to access Active Directory.
Include a group's users.
Restrict groups that are output to a specific organizational unit.
A5ActiveDirectoryExport -iu > ad.txt
This will create a file named ad.txt that will contain groups and test users for current user's domain and will access Active Directory with the current user's identity. The test user names and SAM-Account-Name that are generated are the same. Example: TestUser-Engineering|TestUser-Engineering
A5ActiveDirectoryExport -iu -ou "East Coast"> adEastCoast.txt
This will create a file named adEastCoast.txt that will contain groups and test users for current user's domain in the organizational unit of "East Coast" and will access Active Directory with the current user's identity. The test user names and SAM-Account-Name that are generated are the same. Example: TestUser-Engineering|TestUser-Engineering
In order to use Active Directory in a web application, the publishing profile must define an Active Directory configuration. The create publish profile genie adds a security store type for the Active Directory configuration if the security settings has the "Use Active Directory" option set. This will be the last page of the genie.
When the "Configure Active Directory" button is selected, the Active Directory Configuration dialog is shown. If an Active Directory server is detected, the fields will default to use that Active Directory server.
Select an Active Directory configuration mode to be used.
The user will need to enter their Windows credentials (username and password) in a login page, and the server will validate the credentials against an Active Directory server. This mode can be used for an internet or intranet web application and should only be used with HTTPS to protect the confidentiality of the user's credentials.The user id and password in this dialog are the credentials used to access Active Directory at runtime in order to validate the user id and password entered in the application's login page. If the user id and password in this dialog are left blank, the account the server process is running as is used to access Active Directory. Under IIS, this account defaults to a local machine virtual account which will most likely not have access to Active Directory. If the account does not have access to Active Directory, the application's login page will not be able to verify the application user credentials. In this case, a user should be added to Active Directory to be used for the user id and password in this dialog for access to Active Directory at runtime.
This mode of authentication is also known as single sign on and does not require a user to enter credentials. When using this mode, the machine the user is logged into and the server the web application is on are both in the same Windows domain. An automatic negotiation is done between the browser and the server in order to identify the user. This mode is typically used in a corporate intranet supporting internal web applications.This mode is only available in the Alpha Anywhere Application Server for IIS at this time.
There is an additional option to "Impersonate user" when Integrated authentication is selected. Choose this option when server resources need to be accessed as the logged in user. Examples of server resources are files and/or folders on the server or a SQL database.
The Windows Authentication server role must be installed in order to use integrated Windows authentication. Use the "Add Roles and Features Wizard" on a Windows server operating system (Windows Server 2008 R2 or later) to verify or add the Windows Authentication feature. Use "Turn Windows features on or off" on a Windows client operating system (Windows 7 or later).
Windows Authentication is site specific. If you publish a web application to a site sub-folder and the web application uses integrated Windows authentication, Windows Authentication must be enabled in the site's root web application.
Example: This publish profile publishes a web application to a folder named TestActiveDirectory in the Default Web Site.
In this case, make sure the Default Web Site authentication setting has Windows Authentication enabled.
To change a publish profile's Active Directory configuration, locate the Active Directory settings in the publish profile's Miscellaneous section of the property sheet. Change the security store type to indicate whether an Active Directory configuration is published and/or change the Active Directory configuration by clicking on the smart field button for the "Configure Active Directory" option.
When testing and developing a web application, it is necessary to validate user authorization to parts of the application. For instance, the web application may have a back office component that should only be available to users in the "web app administrator" group. This is why users can still be defined in the web project's security settings. When publishing to a test environment, instead of defining an Active Directory configuration, publish the Alpha Anywhere security tables so that they will be used for authentication and authorization instead of Active Directory. This gives the ability to accurately test authorization.