This topic describes how to set up a traditional perimeter network to support Enterprise Portal. A traditional perimeter network enhances the security of the Enterprise Portal configuration by using two firewalls and two domain controllers to restrict access to Microsoft Dynamics AX data. This topic also describes how to configure ports on the firewall devices and establish the appropriate trust level between domain controllers.

Caution note Caution

If you do not have experience setting up and configuring network security, contact your Microsoft Certified Partner for assistance. If you do not set up the perimeter network correctly, your system might be vulnerable to security threats.


Although a traditional perimeter network is recommended, you also can set up a standard perimeter network using Microsoft ISA Server and a single firewall device. For more information, see Configure a standard perimeter network for Enterprise Portal.

About traditional perimeter networks

A traditional perimeter network contains two Microsoft Active Directory® directory service domain controllers separated by firewall devices in two distinct networks, as shown in Figure 1.

Figure 1: A traditional perimeter network

Enterprise Portal traditional perimeter network

The perimeter network contains the Enterprise Portal Web server that is running IIS, and an Active Directory domain controller. The perimeter domain controller hosts accounts for those users who are external to the organization and who require Enterprise Portal access. These user accounts are set up on the perimeter domain controller as follows:

  1. External users have no rights on the internal domain.

    1. External users cannot log on to the machine as a local user (log on locally)

    2. External uses cannot access the internal network

  2. The internal network contains a complete installation of Microsoft Dynamics AX. This includes the following components:

    1. An Active Directory domain controller that contains the accounts for all internal Microsoft Dynamics AX users

    2. A database that stores Microsoft Dynamics AX data and a list of both internal and external Microsoft Dynamics AX users

    3. A Microsoft Dynamics AX AOS

The internal domain controller has a one-way trust with the perimeter domain controller. This means that information that is sent by the internal domain controller is trusted, but information that is sent by the perimeter domain controller is not trusted. This enhances network security by ensuring that the perimeter domain controller is not able to communicate to the internal domain controller which users are internal to the domain or which users are administrators. If the information that is sent by the perimeter domain was trusted, a malicious user might compromise the internal domain controller, and thereby access data in the internal domain.

Setting up a traditional perimeter network

This section describes how to configure ports and a one-way trust for a traditional perimeter network that supports Enterprise Portal.

Install and configure Enterprise Portal on a perimeter network

If you have not already done so, install Enterprise Portal on the Web server in the perimeter network. For more information about installing Enterprise Portal, see "Install Enterprise Portal and Role Centers" in the Microsoft Dynamics AX Installation guide.

Configure ports

This section describes how to configure ports in the perimeter network and the internal network so users can access the appropriate Microsoft Dynamics AX information using Enterprise Portal. Table 1 at the end of this section provides a complete list of ports and the associated direction, connection, and connection type information.

Figure 2: A request for an Enterprise Portal page

A request for an Enterprise Portal page

A request is processed as follows:

  1. By default, the Enterprise Portal Web server receives the request from the firewall on TCP port 80 (or 443, if your Web server is configured for Secure Sockets Layer [SSL] encryption). The firewall therefore must have port 80 or 443 open for incoming Internet requests. All outbound traffic is permitted, which means that all ports are open for traffic going from the perimeter network to the Internet.

  2. After the Web server receives the request, it sends the request to the perimeter domain controller on UDP port 53 to verify whether the user is an external or internal user.

  3. The perimeter domain controller and the internal domain controller communicate by using various ports, as shown in Table 1 at the end of this section.

  4. The perimeter domain controller identifies the user and then returns the request to the Web server on UDP port 53.

  5. The Web server authenticates the user and then sends the request to the AOS on TCP port 2712. The Web server and the AOS communicate by using the Business Connector proxy account.

  6. The AOS communicates with the Microsoft Dynamics AX SQL Server database on port 1433.

  7. After the AOS retrieves the necessary data from the database, it returns the request to the Web server on the default TCP port, 2712.

  8. The Web server completes the request by sending the page to port 80 or 443.

Table 1: Ports for a traditional perimeter network to support Enterprise Portal

Port

Direction

Connection

Type

Notes

80 or 443 (by default)

Inbound/ Outbound

Perimeter firewall to the Enterprise Portal Web server

TCP

Verify which ports are used in your environment

2712 (by default)

Inbound/ Outbound

Enterprise Portal server to Microsoft Dynamics AX AOS

TCP

Verify which port is used in your environment

53

Inbound/ Outbound

DNS

UDP

None

135

Outbound

Internal domain controller to perimeter domain controller

TCP

None

135

Inbound

Perimeter domain controller to internal domain controller

TCP

None

445

Outbound

Internal domain controller to perimeter domain controller

TCP

None

445

Inbound

Perimeter domain controller to internal domain controller

TCP

None

1638

Outbound

Internal domain controller to perimeter domain controller

TCP

None

1638

Inbound

Perimeter domain controller to internal domain controller

TCP

None

389

Outbound

Internal domain controller to perimeter domain controller

UDP

None

389

Inbound

Perimeter domain controller to internal domain controller

UDP

None

None

Outbound

Internal domain controller to perimeter domain controller

UDP equals domain

None

None

Inbound

Perimeter domain controller to internal domain controller

UDP equals domain

None

If necessary, use Telnet or Netmon to verify these ports. For more information about configuring firewall ports, see How to configure a firewall for domains and trusts.

Configure DNS

The following procedures describe how to configure your Domain Name System (DNS) to create a one-way trust between the domain controllers in your network. For Enterprise Portal, the perimeter network domain controller should trust the internal domain controller, but the internal domain controller should not trust the perimeter domain controller.

To create the one-way trust, complete the following procedures:

  • Configure zone transfers on both domain controllers

  • Create a secondary zone on both domain controllers

  • Create trust from the internal domain controller to the perimeter domain controller

Configure zone transfers on both domain controllers

Complete this procedure to ensure that the domain controllers can communicate with each other.

  1. Log on to the internal domain controller by using an account that is a member of the domain administrators group.

  2. Open DNS ( Start> Programs> Administrative Tools).

  3. In the DNS console, expand the local name server.

  4. Expand Forward Lookup Zones, right-click the domain name, and then click Properties.

  5. Click the Zone Transferstab.

  6. Select Allow Zone Transfers, and then select Only to the Following Servers.

  7. Enter the IP address for the perimeter network domain controller, and then click Add.

  8. Click OK, and then restart the DNS server.

  9. Repeat this procedure for the perimeter domain controller.

Create a secondary zone on both domain controllers

Complete this procedure to ensure that the domain controllers know each other's fully qualified domain names.

  1. Log on to the internal domain controller by using an account that is a member of the Domain Administrators group.

  2. Open DNS( Start> Programs> Administrative Tools).

  3. In the DNS console, expand the local name server.

  4. Right-click Forward Lookup Zones, click New Zone, and then click Next.

  5. On the Zone typepage, select Secondary zone, and then click Next.

  6. On the Zone Namepage, enter the fully qualified domain name of the perimeter network, and then click Next.

  7. Enter the IP address for the perimeter domain controller, and then click Next.

  8. Click Finishto complete the wizard, and then restart the DNS server.

  9. Repeat this procedure for the perimeter domain controller.

Create a one-way trust between the domain controllers

Complete this procedure to set up the one-way trust between the internal domain controller and the perimeter domain controller.

  1. Log on to the perimeter domain controller by using an account that is a member of the Domain Administrators group.

  2. Open Active Directory Domains and Trusts ( Start> Programs> Administrative Tools).

  3. In the console tree, right-click the domain name for the domain that you want to administer, and then click Properties.

  4. Click the Trusttab.

  5. Click New Trust, and then click Next.

  6. On the Trust Namepage, enter the fully qualified domain name for the internal domain, and then click Next.

  7. Select One Way: Outgoing, and then click Next.

  8. Select Both this domain and the specified domain, and then click Next.

  9. Enter the domain administrator credentials for the internal domain, select Domain Wide Authentication, and then click Next.

  10. Click Nexttwice, and then click Yesto confirm outgoing trust.

  11. Click Finish.

Important Important

The IIS server and the AOS cannot communicate unless the IIS server can resolve the AOS IP address and name by using an LMHosts file. You must create an LMHosts file to resolve NetBIOS names as described in the following section.


Resolve computer names

Microsoft Dynamics AX uses the Remote Procedure Call (RPC) to communicate with the AOS. NetBIOS is a requirement of RPC. The IIS server and the AOS cannot communicate unless the IIS server can resolve the AOS IP address and name by using an LMHosts file.

Follow these steps to resolve the computer names.

  1. Create an LMHosts file on the IIS server in the perimeter network. For information about how to create this file, see How to Write an LMHosts File for Domain Validation and Other Name Resolution Issues.

  2. Add the AOS IP address and the AOS name in the LMHosts file on the IIS server.

Verify security and access

To verify the security of your traditional perimeter network, create a user account on the perimeter domain controller, and then configure the user as an external user in Microsoft Dynamics AX. After you create the external user account, open a page on an external Enterprise Portal site (for example, a page such as a questionnaire that has been set up for external access). The external user should be able to access this site.

Next, attempt to access an internal Enterprise Portal site. Verify that the external user receives an access denied message or is redirected to the external site (depending on how you configured Enterprise Portal and IIS).

Finally, verify that you can access the internal site using your internal credentials. If any of these access attempts fail, verify the procedures in this document.

See Also