Verification of SSH using SSSD with migration to Amazon Linux 2023
#SRG(Service Reliability Group) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
This article isCyberAgent Group SRE Advent Calendar 2025This article is the first of a series of articles. It introduces the details of the technical verification to achieve secure LDAPS authentication using SSSD and AWS services in conjunction with the migration to AL2023, as well as the network configuration challenges and solutions that were faced during the process.
Introduction
openssh-ldapAimed architecture
One of the goals of this OS upgrade was not just migration; one of the goals was to strengthen security.
For that reason, we assumed that connections to the LDAP server would use encrypted LDAPS (LDAP over SSL/TLS).
The outline of the architecture we ultimately adopted is as follows:
Configuration points
The LDAP server is placed in a dedicated VPC, and the VPCs running each application connect to the LDAP server via AWS PrivateLink. All LDAP access from application VPCs is aggregated via a Network Load Balancer (NLB), clarifying the communication path and control point.
TLS communication via LDAPS is terminated on the NLB side, not on the LDAP server itself. Specifically, the client (SSSD on EC2) connects to the NLB in the format ldaps://{domain}:636, and the NLB decrypts the TLS communication before forwarding it to the backend LDAP server as plaintext LDAP (TCP/389).
There are three main reasons for adopting this configuration:
- Reduced operational burden:You want to avoid managing certificates yourself
- Limiting the scope of impact:It is sufficient if the communication path from EC2 in the VPC to the NLB is protected by TLS.
- Consideration for the existing environment:We wanted to avoid changing the settings on the existing LDAP server as much as possible.
Certificate Management
We decided to use AWS Certificate Manager (ACM) to manage our certificates.
If we used self-signed certificates, we were concerned that operational costs would be high, such as distributing them to each client and rotating them when the certificates expire.
ACM allows you to use three certificates: a public certificate issued by Amazon, a private certificate using AWS Private CA, or a certificate imported from an external CA.
In this case, we prioritized cost and ease of implementation and chose to set up a public certificate on the NLB.
This allows us to leave certificate acquisition and renewal management to AWS.
Network configuration challenges and solutions
The most time-consuming part of this testing was the network-related settings.
In particular, the configuration used AWS PrivateLink (VPC Endpoint and Endpoint Service), which meant that communication needed to be allowed in security groups in multiple locations, making the settings more complex.
Initially, we thought that we could connect by simply configuring security groups between the client EC2 and NLB, but communication was not established with that alone.
Ultimately, we needed to configure appropriate inbound and outbound settings in all of the following locations:
In particular, I spent a lot of time trying to identify the cause of the connection error because I overlooked the inbound settings on the Interface VPC Endpoint side.
When using AWS PrivateLink, it's important to keep in mind that security group settings are required for all components along the communication path.
summary
Through this verification, we were able to achieve LDAPS authentication in an Amazon Linux 2023 environment by consolidating TLS termination on the NLB and managing certificates with ACM, reducing operational load and minimizing configuration changes to the existing LDAP server.
In addition, I gained a deeper understanding of network components such as VPC peering and AWS PrivateLink, and it was a good opportunity to reaffirm the importance of security group design in environments involving multiple VPCs and multiple services.
SRG is looking for people to work with us.
If you are interested, please contact us here.