Identity Management for Systems in a DMZ

Type of the solution

Configuration

Advantages

Disadvantages

Local authentication

Configure local accounts on the DMZ systems without integration with any central identity server.

It is a quite simple solution.

Accounts and policies are managed per system. In some cases it can be viewed as advantage as it might make it easier to address some of the compliance requirements. But it also makes it harder to meet other requirements like:

• Password history
• Same password on all systems
• Lockout on failures
• Making sure the credentials are mapped to a single account
• Multi factor authentication

Also maintaining a set of the local accounts across a farm of the systems creates a bit of operational complexity and overhead that could lead to inconsistencies in configuration or in your security policies. Ansible can come to the rescue to alleviate some pain but it will still be a pretty custom solution that the organisation would have to own.

Connect systems to the core Active Directory domain

You can use System Security Services Daemon (SSSD) or third party software to connect systems to AD. For more details see the overview of the direct integration options earlier in my blog.

Authentication happens centrally leveraging the same accounts and related policies in the DMZ in the same way as it is done inside the inner firewall. Allows for consistent application of security policies and configurations. AD is commonly found in Enterprises and can easily be leveraged for centralized identity services.

To allow authentication you would need to poke holes in the inner firewall. You would need to at least open the Kerberos port for access from all the DMZ systems. This is usually a non starter for many Enterprise Security and Network teams. To be fair and complete I added a couple of workarounds that are described below the table.

In addition you would need to open the LDAP port for the systems in DMZ to be able to access identity information. On top of this some other Microsoft related protocols (like DCE RPC) might be needed if you choose to use a non SSSD based solution.

Policies like host based access control, sudo and SELinux use mappings for Linux systems in DMZ are not centrally managed.

Expose read only AD replicas in DMZ

Put a read only replica of the core AD domain into DMZ.

Connect clients to it.

You can use SSSD or third party software to connect systems to AD. For more details see the overview of the direct integration options earlier in my blog.

Authentication happens centrally leveraging the same accounts and related policies in DMZ in the same way as it is done inside the inner firewall.

Enrolling SSSD with a read only AD server would require several manual steps (one would need to create the computer object on a RWDC and copy the keytab to the client).

See third party documentation for other other solutions.

You would need to make sure that clients do not try to talk to the DCs that are unreachable and inside the firewall.

Active Directory domain, though in the read only form, is exposed outside of the firewall.

You will need to open all the ports required for two domain controllers to talk to each other. More information about the ports that need to be open can be found here.

Policies like host based access control, sudo and SELinux user mappings for Linux systems in DMZ are not centrally managed.

Create a separate AD domain for the DMZ systems

Create an AD domain for DMZ systems. Establish trust with the main domain inside the firewall.

You can leverage centrally managed accounts and policies for authentication.

The same Kerberos proxy issue applies here. See workarounds after the table.

Also you would need to open all the ports required for two domains to talk to each other.

Policies like host based access control, sudo and SELinux user mappings for Linux systems in DMZ are not centrally managed.

In addition this might be costly as you might have to buy another AD license to deploy this domain.

Create a separate IdM domain for the DMZ systems

Create an IdM domain for DMZ systems. Establish trust with the main domain inside the firewall.

You can leverage centrally managed accounts and policies for the authentication.

Minimal set of ports needs to be open.

Policies like host based access control, sudo and SELinux user mappings for Linux systems in DMZ are centrally managed.

You do not need to deploy a separate proxy server, IdM includes it out of box.

Costs might be lower.

Still some ports need to be open.