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 might not have the same tooling as its Windows counterpart.
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. Enabling large companies such as Facebook, Netflix and many other large companies to manage access to their Linux endpoints through a centralized authority.
If you are interested in how to set up and run your own SSH Certificate Authority, read this blog where we walk you through step by step on how to create an SSH certificate authority.
As mentioned in the first paragraph, 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 in. EZSSH is the only agentless Linux access management tool in the world. EZSSH leverages your existing AAD groups and users to manage access and create short term SSH Certificates. Giving you Active Directory based control, while using Linux based authentication.
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.
As shown in the video below, the user flow for accessing the system is quicker and easier than creating an SSH key and adding it to the endpoint. As long as the user is a member of the policy assigned to the endpoint, all the user must 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.
Get started with EZSSH with a free one-month trial. Still have questions? Talk to one of our Identity experts and get a free Identity assessment.