In this post we will be talking about managing Linux systems that are located in a demilitarized zone (DMZ) also referred to as a perimeter network. From the identity management and authentication perspective, DMZ installations create a particular challenge: How can we provide identity and authentication services without jeopardizing the integrity of our perimeter security?

There are multiple options. For easier reading I placed my perspective on their relative advantages and disadvantages in the following table:

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.




The workarounds mentioned in the table related to opening Kerberos ports in the firewall are the following:

  • MIT Kerberos includes services that implement the IAKERB protocol. This service acts as a proxy for Kerberos traffic. Deploying a Kerberos proxy  solves the problem of allowing all clients to talk over the Kerberos port but still requires an extra port to be open for the GSSAPI protocol.
  • Later Microsoft came up with an alternative to the IAKERB solution. Usually the HTTP traffic is enabled through the firewall. Instead of creating a proxy that uses Kerberos protocol as MIT did Microsoft created a new protocol that allows proxying Kerberos traffic over HTTP and HTTPS. It is called “Kerberos Key Distribution Center (KDC) Proxy Protocol” [MS-KKDCP]. This protocol allows Kerberos clients to talk to KDC over HTTP/HTTPS. MIT together with Red Hat implemented the same protocol so that Linux and Windows clients and proxy servers can interoperate. The details of that project can be found here. The open source variant of proxy server that implements MS-KKDCP protocol is called kdcproxy. It is included into IdM server and can be enabled on demand if needed.

It is worth mentioning that in either case Linux clients would need to be specially configured post installation to take advantage of the kdcproxy.

As you can see there are multiple options. In the next post I will drill down into the specifics of the IdM based solution and give some recommendations.