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.
저자 소개
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.