Using Red Hat Identity Management as a Domain Controller for systems in a DMZ

This post is a follow-on to Identity Management for Systems in a DMZ. Here we will drill down into the deployment of the IdM server as a domain controller for Linux systems residing in DMZ.

The architecture of the deployment will look like this.

The IdM server in the DMZ will play the role of the domain controller for Linux systems. To solve the problem of proxying Kerberos traffic make sure that the kdcproxy component is enabled on the IdM server that is inside the firewall. See corresponding documentation for more details.

Linux systems in the DMZ will be connected to the IdM server by using ipa-client-install or realmd.

The SSSD component will need to be configured on the clients. After the installation and enrollment the client systems would need to be reconfigured to start leveraging kdcproxy rather than a standard Kerberos protocol.  For more details on how to achieve this see Configuring a Kerberos Client section in the System-Level Authentication Guide.

This diagram assumes that there can be more AD and IdM domain controllers in the deployment. To plan an IdM deployment based on different factors please see the article Thinking Through an Identity Management Deployment.

The IdM server inside the firewall will play two main roles: acting as a kdcproxy server and acting as a trust controller. A trust controller is an IdM server that establishes trust operations with AD. The IdM servers in the DMZ should not be deployed as trust controllers but rather as trust agents (see reasoning below). For more information about trust controllers and trust agents see the following documentation. Trust agent will use CLDAP and LDAP protocols to connect to AD DC and fetch necessary information but no other ports for other Microsoft specific communication like SMB or DCERPC need to be open.

Firewall configuration

Now let us look at the firewall configuration. In this setup only two types of traffic will cross it: HTTPS traffic and LDAP/CLDAP traffic from IdM server(s) in DMZ to AD servers and IdM server(s) inside the firewall. HTTPS is usually allowed and the exposure of the LDAP/CLDAP ports is confined to a small set of IdM servers in the DMZ. This means that the firewall configuration can be simpler than in case of many open ports.

The only concern in such a setup is that IdM server is not a read-only server. The lack of read-only replica capability is a limitation of the current IdM implementation. It has not been addressed due to the complexity of the task and a lack of customer demand.  

If you are interested in expediting the development of read-only replicas you can either engage FreeIPA community directly via the corresponding mailing lists or reach out to Red Hat via your Technical Account Manager (TAM) or the sales team.

In the absence of read-only functionality the IdM server in DMZ would have to be a full server. Let us look at the potential attack vectors in such situation. Let us say that attacker managed to gain root access to the IdM server in the DMZ. In such case he will be able to log into any of the Linux systems residing in DMZ connected to it. However he would not be able to cause any damage to systems that are inside the firewall environment. For this statement to be true it is crucial to establish a policy that would prohibit connecting any internal hosts and services to this IdM realm. If you have internal systems that you want to connect to IdM and leverage trust deploy a different IdM realm not connected to the one serving DMZ hosts.

Using the hijacked IdM server in DMZ the attacker would be able to create LDAP entries, new users and even new host entries and this information will be replicated to the IdM servers inside the firewall. However if there are no clients or services connected to the IdM server inside the firewall, creating those LDAP objects is unlikely to harm the inside environment.

Not having a trust controller on the IdM server in DMZ will also reduce the attack surface. This is true because trust agent requires less open ports in the inner firewall thus limiting attacker’s ability to try to forge a rogue Kerberos trust.

To reduce the risk of hijacking IdM server in DMZ several techniques can be employed.

• Use unique strong passwords on the IdM server system in DMZ
• Do not install unnecessary services on the IdM system in DMZ; only run what is required to operate the IdM service
• Do not install additional IdM components that you do not need on the IdM server, for example Vault or Trust Controller.
• Use hardening recommendations for the IdM server (also see the following KB for Apache server hardening).
• Scan IdM system regularly to detect vulnerabilities and open ports. Update packages accordingly and close ports that do not need to be open.
• You should restrict which servers can open SSH connections to IdM server in DMZ via SSH configuration.
• Additionally you might consider limiting outbound traffic required by non IdM related services from the IdM host to other systems. For example, explicitly declare hosts from which IdM server would receive yum updates.
• Finally continuous monitoring of the suspicious activity via logs and audit feed collected from the IdM server in DMZ might be another tactics to detect and stop a potential attack in progress.

With such precautions the risk of attack can be reduced.

Tradeoffs

As you can see it is not a perfect solution and there are some limitations and risks. However the solutions has several benefits that other approaches do not. On the other side its security properties are comparable to other options covered in the previous blog.

Overall it is a viable solution with good capabilities, lower cost and security properties to help mitigate the risks. It can become even better with the introduction of the read-only replicas. How soon? It all depends on the demand and your involvement. The ball is in your court!