Planning Active Directory for Forefront UAG DirectAccess SP1

Applies To: Unified Access Gateway

This topic provides information about planning Active Directory requirements in your Forefront Unified Access Gateway (UAG) DirectAccess deployment.

• Overview

• Requirements

• Limitations

• Planning steps

Overview

Forefront UAG DirectAccess uses Active Directory and Active Directory group policy objects, as follows:

• Authentication—Active Directory is used for authentication. The infrastructure tunnel uses NTLMv2 authentication for the computer account connecting to the Forefront UAG DirectAccess server, and the account must be in an Active Directory domain. The intranet tunnel uses Kerberos authentication for the user to create the second tunnel.

• Group policy objects−Forefront UAG DirectAccess gathers configuration settings into group policy objects that are applied to Forefront UAG DirectAccess servers, clients, and internal management servers.

• Security groups and OUs—Forefront UAG DirectAccess uses global or universal security groups, and organizational units (OUs), to gather together and identify DirectAccess client computers, and DirectAccess servers. The group policies are applied to the required security group or OU.

• Extended IPsec policies—By default Forefront UAG DirectAccess uses IPsec authentication and encryption between clients and the Forefront UAG DirectAccess server. You can extend IPsec authentication and encryption through to specified internal application servers. To do this, you gather the required application servers into a security group.

Requirements

When planning Active Directory for Forefront UAG DirectAccess deployment, the following is required:

• At least one domain controller running Windows Server 2003 or later is required.

• The Forefront UAG DirectAccess server must be a domain member.

• DirectAccess clients must be domain members. Clients can belong to:

  • Any domain in the same forest as the Forefront UAG DirectAccess server.

  • Any domain that has a two-way trust with the Forefront UAG DirectAccess server domain.

  • Any domain in a forest that has a two-way trust with the forest to which the Forefront UAG DirectAccess domain belongs.

Limitations

Note the following limitations:

• The Forefront UAG DirectAccess server cannot be a domain controller.

• The Active Directory domain controller used for Forefront UAG DirectAccess must not be reachable from the external Internet adapter of the Forefront UAG DirectAccess server (the adapter must not be in the domain profile of Windows Firewall). If either of these is true, the Forefront UAG DirectAccess Configuration Wizard cannot run.

• If you want to extend IPsec authentication and encryption through to specific internal application servers, the application servers must reside in the same forest as that in which the DirectAccess server is located.

Planning steps

Planning steps include the following:

Planning stage	Planning steps
Planning for domain controllers	Plan for at least one domain controller running Windows Server 2003 or later. If you must deploy an Active Directory domain controller on a perimeter network (and therefore reachable from the Internet-facing interface of Forefront UAG DirectAccess server) prevent the Forefront UAG DirectAccess server from reaching by adding packet filters on the domain controller, to prevent connectivity to the IP address of the Internet adapter.
Planning for client security groups and OUs	For a client computer to receive the DirectAccess client group policy and thus be configured as DirectAccess clients, it must be included in an OU or security group, and belong to one of the client domains specified during Forefront UAG DirectAccess deployment. Note the following: To use an OU, ensure that the OU exists in the domain containing the client computer. OUS can only contain client computers from the OU domain. Security groups can contain client computers from any domain. To deploy with security groups, ensure that DirectAccess clients belong to the required security group, and to at least one of the client domains that will be specified during deployment.
Planning for DirectAccess server security groups or OUs	DirectAccess servers can be grouped used security groups or OUs. Ensure that servers belong to the required OUs or security group before beginning deployment.
Planning for extended authentication and encryption	If you want to extend IPsec policies through to specific internal application servers, add the required servers to a security group.
Planning for GPOs	During deployment you can choose to let Forefront UAG DirectAccess automatically create GPOs for clients and the DirectAccess server, and internal infrastructure servers. As an alternative, you can specify preexisting GPOs that Forefront UAG DirectAccess should use. This is useful if the Forefront UAG administrator does not have GPO permissions, or if your organization uses a specific naming policy for GPOs. If you want to use predefined GPOs, do the following before beginning deployment: Create a GPO for the DirectAccess server settings in the domain to which the Forefront UAG DirectAccess server belongs. Then set the security filtering and link to all the required OU or to the server domain root (when using security groups). Create a GPO for the DirectAccess client settings with the same name in each of the client domains. Configure security filtering and create links as required. Note that cross-domain links should not be created. If you want to extend IPsec policy from clients to specific internal application servers, create a GPO for the server settings with the same name in each domain containing the servers. . Configure security filtering and create links as required. Note that domains containing these servers must reside in the same forest as the Forefront UAG server. Ensure that the administrator configuring Forefront UAG DirectAccess has GPO Create permissions for each domain, and link permissions to all the selected client domain roots (for security groups), or to all the selected OUs (when using OUs).Alternately the administrator can send the script (containing the group policy settings) that is generated at the end of the Forefront UAG DirectAccess deployment process to a domain administrator with the correct permissions, to run on their domain. Ensure that the user account running the script to populate the predefined GPOs during DirectAccess deploy has Write permissions on each GPOs. Otherwise a warning will be issued. We also recommend that you configure Read permissions for the Forefront UAG DirectAccess administrator on the predefined GPOs. If you do not, automatic validation of the GPOs, during DirectAccess configuration and deployment, might fail. The configuration script generated during Forefront UAG DirectAccess deployment is applied to predefined GPOs as follows: The script searches for the predefined DirectAccess server GPO in the forest to which the Forefront UAG DirectAccess server belongs, and applies the policy settings to the GPO. The script searches for the predefined client GPO name in all client domains, and copies the policy settings to the each GPO that is located. If IPsec policy is extended to specific internal application server, the script searches for the predefined application server GPO in all application server domains, and copies policy settings to each GPO that is located. If you want to use GPOs generated by Forefront UAG DirectAccess, do the following: The export script generated must be applied by a domain administrator. If the Forefront UAG administrator does not have the required permissions, the script must be exported and sent to an authorized administrator.
Planning for multiple domains	Management servers should include domain controllers from all domain containing security groups that include DirectAccess client computers. Management servers should contain all domains that contain user account that might use computers configured as DirectAccess clients. This ensures that users who are not located in the same domain as the client computer they are using are authenticated with a domain controller in the user domain. Where possible, common domain name suffixes should be added to the NRPT during DirectAccess deployment. For example, if you have two domains, domain1.corp.contoso.com and domain2.corp.contoso.com, instead of adding two entries into the NRPT, you can add a common DNS suffix entry, where the domain name suffix is corp.contoso.com. To apply the export script generated during DirectAccess deployment domain admin permissions are required. If there are domains on which the domain admin does not have permissions (for example additional client domains) then the domain admin must be granted link permission on those domains. For more information, see Linking to the Group Policy objects (GPOs). If WINS is deployed in a multiple domain environment, you must deploy a WINS forward lookup zone in DNS. For more information, see Unqualified, single-label names and DNS search suffixes.
Planning for authentication domains	Domains required for authentication are those containing domain controller required to authenticate user accounts over the infrastructure tunnel. During deployment, client domains are automatically added as authentication domains. Plan to add additional authentication domains as follows: Add domains that contain user accounts are not members of a client domain. This enables a user from another domain using a client computer enabled for Forefront UAG DirectAccess, to be authenticated with a domain controller in the user domain. Add domains that contain management servers that require Kerberos authentication with the DirectAccess client, and that are not included in any of the client domains. Add the domain of the Forefront UAG DirectAccess server, if it was not included as one of the client domains.