Objective: Securing FortiGate Authentication with AWS Managed Microsoft AD
The primary goal of this integration is to enhance the security of FortiGate's LDAP authentication by migrating from plain text LDAP on port 389, tunneled via VPN, to LDAPS on port 636. This transition ensures end-to-end encryption using TLS, while leveraging the existing AWS Managed Microsoft AD directory service. The expected outcome is for the managed Active Directory Domain Controllers (DCs) to listen securely on port 636 with a valid certificate, which the FortiGate firewall will then validate against a trusted Certificate Authority (CA).
This move addresses a critical security vulnerability inherent in using unencrypted LDAP, especially over potentially untrusted network paths. By implementing LDAPS, sensitive authentication data, such as usernames and passwords, is protected from eavesdropping and man-in-the-middle attacks.
Understanding LDAPS: Server-Side vs. Client-Side
A common point of confusion arises from the terminology and configuration options related to LDAPS. It's crucial to distinguish between client-side and server-side LDAPS, particularly within the context of AWS Managed Microsoft AD.
Server-Side LDAPS is Key for This Scenario
The AWS Directory Service console offers an LDAPS tab with a "register certificate" option. However, this feature is primarily designed for scenarios where the AWS Managed Microsoft AD itself acts as the LDAP client connecting to another LDAP server, not for securing inbound connections to the AD DCs. For integrating with a firewall like FortiGate, we need the AWS Managed Microsoft AD's DCs to act as LDAPS servers, accepting secure connections from the FortiGate. This requires configuring the DCs to listen on port 636 and present a valid TLS certificate to the connecting client (the FortiGate).
Think of it like this: you're not asking your AD to *initiate* a secure chat with another service; you're setting up a secure phone line *into* your AD so that the FortiGate can make a secure call. The certificate registration in the AWS console is for the former, while our goal requires the latter.
Prerequisites for LDAPS Integration
Before proceeding with the integration, several prerequisites must be met to ensure a smooth and secure setup:
- AWS Managed Microsoft AD: You must have an existing AWS Managed Microsoft AD deployment. The directory should be healthy and accessible via standard LDAP (port 389) over the VPN tunnel.
- FortiGate Firewall: A FortiGate firewall configured to manage users and perform authentication against an external LDAP server. It must have a VPN tunnel established to the AWS VPC where the Managed Microsoft AD resides.
- Certificate Authority (CA): A trusted Certificate Authority (CA) is required. This can be an internal enterprise CA or a public CA. The FortiGate must trust this CA.
- TLS Certificate: A server certificate for your AD domain is needed. This certificate must:
- Be issued by the trusted CA that the FortiGate also trusts.
- Include the Fully Qualified Domain Name (FQDN) of the AD domain in its Subject Alternative Name (SAN) or Common Name (CN). For example, if your domain is `mycorp.local`, the certificate should be valid for `mycorp.local`.
- Be configured for server authentication.
- Network Connectivity: Ensure that TCP port 636 is open between the FortiGate firewall and the AWS Managed Microsoft AD Domain Controllers within the AWS VPC. This may involve configuring Security Groups in AWS and firewall policies on the FortiGate.
Configuring AWS Managed Microsoft AD for Server-Side LDAPS
The process involves obtaining a TLS certificate and configuring the AD DCs to use it for LDAPS. This typically requires administrative access to the AD DCs or the ability to manage certificates within the domain.
1. Obtain and Install a TLS Certificate
The most robust method is to obtain a certificate from your trusted CA. This certificate needs to be installed on the AD DCs. The exact steps depend on your CA and domain setup:
- Request a Certificate: Use the Certificate Manager (certmgr.msc) on a DC or a domain-joined machine to request a new certificate. Select a template that supports Server Authentication (e.g., "Active Directory Domain Services"). Ensure the FQDN of your domain is included in the request, ideally in the SAN.
- Issue and Export: Have your CA issue the certificate. Export the certificate along with its private key, in a format like PKCS#12 (.pfx), ensuring you set a strong password for the export.
- Import to DCs: Import the exported certificate (including the private key) into the Personal certificate store of the Local Computer on each AD DC that will handle LDAPS connections. Use `certmgr.msc` for the Local Computer store.
2. Configure AD DCs to Listen on Port 636
By default, AWS Managed Microsoft AD DCs may not listen on port 636. You need to configure the Active Directory Domain Services (AD DS) service to bind to this port. This is often achieved by modifying the registry or using PowerShell scripts that interact with the AD DS configuration.
A common approach involves using the `ADSI` interface or specific PowerShell cmdlets to update the LDAP service configuration. The key is to enable the LDAPS protocol and specify the port. It's critical to ensure this configuration is applied consistently across all DCs that will serve LDAPS requests.
Important Note: AWS Managed Microsoft AD abstracts much of the low-level DC configuration. While you can install certificates, directly modifying the AD DS service binding for LDAPS might require specific tooling or support from AWS if not exposed through standard interfaces. The documentation for AWS Managed Microsoft AD should be consulted for the officially supported method of enabling LDAPS on port 636.
Configuring FortiGate for LDAPS Authentication
With the AWS Managed Microsoft AD configured for LDAPS, the next step is to configure the FortiGate firewall to use this secure connection.
1. Import the Trusted CA Certificate
The FortiGate needs to trust the CA that issued the certificate installed on the AD DCs. Navigate to the certificate management section of your FortiGate and import the root CA certificate (and any intermediate certificates if applicable). Ensure these are marked as trusted.
2. Configure the LDAP Server Entry
In the FortiGate's user and authentication settings, create or modify an LDAP server entry:
- Server Name: A descriptive name (e.g., "AWS-Managed-AD-LDAPS").
- Server IP/Name: Use the FQDN of your AWS Managed Microsoft AD domain (e.g., `mycorp.aws`).
- Port: Set this to 636.
- Protocol: Select LDAPS or ensure the connection uses TLS.
- Common Name (CN): Typically the domain name (e.g., `mycorp.aws`).
- Bind DN: The Distinguished Name of a user account within your AD that has read permissions to query user and group information. Example: `CN=ldapbinduser,OU=ServiceAccounts,DC=mycorp,DC=aws`.
- Password: The password for the Bind DN user.
- User Search: Configure the base DN for user searches (e.g., `OU=Users,DC=mycorp,DC=aws`) and any relevant filters.
- Group Search: Configure the base DN for group searches (e.g., `OU=Groups,DC=mycorp,DC=aws`) and filters if needed.
3. Test the Connection
After configuring the LDAP server entry, use the FortiGate's built-in testing tool to verify the connection to the LDAPS server. This tool usually allows you to specify the LDAP server, port, bind DN, and test user credentials. A successful test confirms that the FortiGate can establish a secure TLS connection to the AD DCs and authenticate using the provided Bind DN credentials.
Troubleshooting Common Issues
If the connection fails, consider the following:
- Certificate Trust: Verify that the FortiGate explicitly trusts the CA that issued the AD's server certificate.
- Certificate Validity: Ensure the AD's server certificate is not expired, is valid for the FQDN being used, and has the correct Server Authentication EKU.
- Port 636 Accessibility: Confirm that AWS Security Groups and Network ACLs allow inbound TCP traffic on port 636 from the FortiGate's IP address to the AD DCs' IP addresses. Also, check FortiGate firewall policies.
- Bind DN Permissions: The Bind DN user must have sufficient read permissions in Active Directory.
- FQDN Resolution: Ensure the FortiGate can correctly resolve the FQDN of the AWS Managed Microsoft AD domain to the IP addresses of the DCs.
- TLS Version/Cipher Suites: In rare cases, compatibility issues with TLS versions or cipher suites might arise. Check FortiGate and AD DC logs for specific TLS negotiation errors.
Conclusion: Enhanced Security for Network Authentication
Implementing LDAPS between FortiGate and AWS Managed Microsoft AD significantly strengthens the security posture by encrypting authentication traffic. This configuration moves away from vulnerable plain-text protocols, providing a more secure and compliant solution for enterprise network access control.