Active Directory Integration

Alpha Anywhere Application Server Active Directory Authentication and Authorization

Overview

Active Directory authentication and authorization can be used in 2 different ways in Alpha Anywhere:

1. Use an Active Directory rather than a custom database to validate credentials that a user enters into a login page.

2. "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.

Assumptions

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.

Using Active Directory Authentication and Authorization

Set Web Security Configuration

Edit the Web Security Configuration for your web project.

Web security configuration icon in the web security dialog.

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. In fact, your application can be developed with groups names that make sense for your application. Then Active Directory group names can be mapped to your application defined groups names in the publish profile. 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.

Security settings dialog.

Set the remaining security settings needed, such as the redirect pages.

• Users and Groups

  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.

  

  Web users and groups dialog with the groups tab selected and the import groups link highlighted.

• 

  Import Active Directory groups dialog.

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.

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:

-h

Show the command line options.

-d

Specify a domain name.

-u

Username that has permission to access Active Directory.

-p

password of the Username that has permission to access Active Directory.

-iu

Include a group's users.

-ou

Restrict groups that are output to a specific organizational unit.

Example usage:

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

• Mapping Active Directory group names to application group names

  There may be times when an application will need to be published in more than one Active Directory domain where group names are not the same. This would require a big change to the application for updating the security settings for the new group names of the new Active Directory domain. Additionally this becomes a maintenance problem as features are added to an application and the updated application needs to be republished.

  In this case, use group names that make sense for the application. A map of Active Directory group names to application groups names can then be defined in the publish profile Active Directory Configuration dialog.

  

  Map Active Directory group names to application group names

Publishing an Application

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.

Create publishing profile Active Directory genie page.

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.

• Form Based Authentication

  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.

  

  Create publishing profile Active Directory genie page.
  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.

• Integrated Authentication

  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.

  

  Create publishing profile Active Directory genie page.
  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.

• Installing Windows Authentication server role in IIS

  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 to verify or add the Windows Authentication feature. Use "Turn Windows features on or off" on a Windows client operating system.

  

  Windows Authentication server role.

• Site Specific Authentication

  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.

  

  Publish profile to Test Active Directory folder in the Default Web Site.

• In this case, make sure the Default Web Site authentication setting has Windows Authentication enabled.

  

  Get to site authentication setting for Windows Authentication.
• 

  Site authentication setting for Windows Authentication.

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.

Active Directory options in the publish profile dialog.

Testing an Application

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.