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:
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.
Sobre o autor
Mais como este
Navegue por canal
Automação
Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes
Inteligência artificial
Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente
Nuvem híbrida aberta
Veja como construímos um futuro mais flexível com a nuvem híbrida
Segurança
Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias
Edge computing
Saiba quais são as atualizações nas plataformas que simplificam as operações na borda
Infraestrutura
Saiba o que há de mais recente na plataforma Linux empresarial líder mundial
Aplicações
Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações
Programas originais
Veja as histórias divertidas de criadores e líderes em tecnologia empresarial
Produtos
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Red Hat Cloud Services
- Veja todos os produtos
Ferramentas
- Treinamento e certificação
- Minha conta
- Suporte ao cliente
- Recursos para desenvolvedores
- Encontre um parceiro
- Red Hat Ecosystem Catalog
- Calculadora de valor Red Hat
- Documentação
Experimente, compre, venda
Comunicação
- Contate o setor de vendas
- Fale com o Atendimento ao Cliente
- Contate o setor de treinamento
- Redes sociais
Sobre a Red Hat
A Red Hat é a líder mundial em soluções empresariais open source como Linux, nuvem, containers e Kubernetes. Fornecemos soluções robustas que facilitam o trabalho em diversas plataformas e ambientes, do datacenter principal até a borda da rede.
Selecione um idioma
Red Hat legal and privacy links
- Sobre a Red Hat
- Oportunidades de emprego
- Eventos
- Escritórios
- Fale com a Red Hat
- Blog da Red Hat
- Diversidade, equidade e inclusão
- Cool Stuff Store
- Red Hat Summit