As a Microsoft Active Directory expert, your first instinct for managing access to your Linux endpoint is to domain join your Linux VMs to Active Directory. The idea behind this is that you will be able to centrally manage your Linux endpoints from a familiar centralized location and not have to deal with Linux specific issues. However, the Linux operating system was not designed to be managed by a central Active Directory. This forces you to run multiple highly privileged agents and services in your Linux machine to emulate the Windows behavior in an Active Directory environment. This added complexity adds the same possible issues as with a Windows domain joined machine, except the debugging now must be done from a Linux Machine that doesn’t have the same tooling as its Windows counterpart. Here’s a quick glance at some of the obstacles you’ll encounter.
It is Always DNS: As with any other domain joined machine, the Linux endpoint will have to keep track of the DNS locations to reach the domain controllers. If dynamic DNS is not properly set up or a DNS change occurs on the domain without mirroring the change in the Linux endpoint, the endpoint will lose the ability to authenticate users.
Highly Privileged Agents: To enable AD-like user management, you must install over 10 extra packages and set them up. This does not only increase the management tax by ensuring that all these packages are up to date and working properly, but it also opens the door to a misconfiguration that could lead to a successful attack.
No Multi-Factor Authentication: The basic Linux domain join is all based on the usage of passwords, from a password being required to domain join the machine, to password-based domain authentication. In today’s zero trust world, password-based authentication is unacceptable as well as uncompliant, meaning that an extra PAM module must be loaded to enable multi-factor authentication.
Poor User Experience: As a security professional, one of my biggest concerns is making sure that the user experience of the secure path is better or equal to that of the shortcut engineers might take to get their job done. If you set up AD authentication, but the engineer must manually login to each endpoint and follow multiple steps, they might opt to instead add a local account to the machine and share it among the team. Defeating the whole purpose of adding secure and auditable authentication.
With over 90% of cloud infrastructure being Linux based, the Linux community has come up with centralized access management system: SSH Certificates. SSH Certificates are a native OpenSSH standard meaning that they are supported by most Linux distros by default. SSH Certificates are cryptographic certificates that are signed by a centrally trusted certificate authority. [How do many of the World’s largest organizations do SSH] (https://www.keytos.io/blog/passwordless/how-the-worlds-biggest-organizations-do-ssh)? Well, take a look at some of the documentation from organizations such as Facebook and Netflix. If you’d care to learn more about how easy it is to set up your own SSH CA, check out this post on how to create an SSH certificate. Contrary to popular belief, this is an exceptionally straight forward process, and is the best ways to ensure that SSH isn’t the weakest point in your infrastructure.
As we mentioned earlier, Linux was not designed to work with Active Directory. While it has a centralized access management system, it is not linked to Active Directory. This is where EZSSH comes into play. EZSSH is the only agentless Linux access management tool in the world specifically designed for passwordless SSH authentication. Keytos’ EZSSH leverages your existing AAD groups and users to manage access and create short term SSH Certificates. This enables AD-based control while using Linux based authentication.
If you checked out the video above, you’ll have observed that the user flow for accessing the system is WAY easier than creating an SSH key and then having to add it to the endpoint. As long as the user is a member of the policy assigned to the endpoint, all the user has to do is run “ezssh ssh username@endpoint” or use our UI tool. In the background, EZSSH will use the user’s AAD account, authenticate our service, verify the user has access to the endpoint, and create a short term SSH certificate that will expire once the defined period passes. This removes the need to lifecycle accounts and since a new cryptographic based credential is created each time, it meets and exceeds security and compliance requirements for credential rotation.
At Keytos our main priority is making sure the tools are familiar and easy to use for everyone. This is why we abstract the complexities of running a secure and compliant SSH Certificate Authority and create an easy-to-use policy-based system that enables you manage user access by adding AD groups and users. To set up access in the Linux Machine, it is as simple as running the script created by your policy that adds the CA as a trusted entity for user authentication. No agents, extra PAM modules, or complex setup just native Linux Authentication. Make it this far? Thank you so much for reding! …and be sure to check out more of our suggested posts about SSH and modern authentication below!
