Red Hat ブログ
Hello again! In this post I will be sharing some ideas about what you can do to solve a complex identity management challenge.
As the adoption of Identity Management (IdM) grows and especially in the case of heterogeneous environments where some systems are running Linux and user accounts are in the Active Directory (AD) - the question of renaming hosts becomes more and more relevant. Here is a set of requirements that we often hear from customers
- I want to be able access my Linux hosts with credentials stored in Active Directory.
- I want to be able to centrally manage access control to my Linux hosts for user accounts stored in Active Directory.
- I want to be able to centrally manage privilege escalation (sudo) for user accounts stored in Active Directory.
- I want to be able to control automount maps for my Linux systems centrally.
- I want to be able to jump between my Linux hosts without requiring to enter passwords all the time (SSO).
- I do not want to rename my Linux hosts; they are currently a part of Active Directory DNS domain. There are business critical applications running on them... and (thus) I really can’t rename them.
- I want the solution to be cost effective so that I do not have to pay extra for the integration of Linux systems into my Active Directory environment.
Before we move forward it is important to clarify terminology. When we talk about single-sign-on (SSO) we are talking about the ability for a user to authenticate once and to then access different systems and resources without being challenged for authentication again. This is not the same as having a single account. In fact, all solutions as discussed in this post assume that there is a single user account and that it is stored inside Active Directory. But this is not yet SSO. SSO would be achieved if the user is challenged to provide his password once, usually during the login into his workstation, and then was able to access other systems without being prompted to enter their password again. Also, when we talk about SSO inside the enterprise, the technology that provides such capability is called Kerberos. It is implemented both on the Windows and Linux sides.
Now that we’ve clarified the SSO terminology we can look at how the above listed requirements can be met.
The following diagram shows the current the state:
Let us drill down - exploring different options - to find out how these requirements can be met.
Option 1 - Use 3rd Party Software
This solution satisfies nearly all of the above listed requirements... the sole exception being cost effectiveness. It also puts everything - including the ability to manage Linux systems - into Active Directory. Sometimes this is desirable, sometimes it is not. For more information on the use of 3rd party software see one of my other articles. The costs associated with such a solution usually generate an interest in exploring additional options. Let's continue onward...
Option 2 - Use Direct Integration
I've written about direct integration in several of my previous blog posts. The main limitation with direct integration is that while access control can be centrally managed using the basic GPO support available in SSSD, policies like sudo or automount are unmanaged. This fails to meet requirements #3 and #4.
Option 3 - Use Indirect Integration with IdM
An IdM-based solution provides a lot of benefits as has been mentioned in other sections of my blog however, in this specific case, the problem arises with the hostnames due to the SSO requirement (i.e. requirement #5). To be able to leverage SSO between the hosts with Kerberos the hosts have to be put into a DNS domain managed by IdM rather than one controlled by Active Directory (i.e. they would need to be renamed).
If the hosts (really) can’t be renamed, the Kerberos-based SSO approach will not work because IdM hosts being in an AD domain will confuse clients. The clients will request Kerberos tickets for IdM hosts from AD instead of IdM. AD would fail to resolve Kerberos principals since these hosts are joined to IdM and have Kerberos principals from the IdM realm.
This problem is described in more detail in this document.
Deadlock? Not necessarily. There are couple options that can be explored here.
Option 3a - Use Indirect Integration with IdM and Exclude Hosts
Active Directory allows specifying external hosts. This means that if you have a small amount of hosts that can’t be renamed there is a way to explain to AD that these hosts are really from a different domain. With this setting Active Directory would know to rely on an external domain controller (in this case IdM) to resolve these names.
This, however, would only work when the number of such hosts is really small. Dozens of hosts would start to take a toll on Active Directory performance (according to specialists) and this is probably the last thing you want to accomplish.
Option 3b - Use Indirect Integration with IdM with SSH SSO
Another approach would be to complement the Kerberos-based authentication (or even completely replace it) with SSH-based SSO. The following two diagrams show how this can be accomplished.
Linux hosts will be joined to IdM but will not use Kerberos for SSO. This would allow them to preserve their names. To meet the requirement not to challenge users again with username and password after the initial authentication - SSH keys could be issued to AD users. Users coming from their Windows workstations would use Kerberos SSO to access a jump host and would then be able to SSH to other systems using SSH key authentication. IdM provides centralized user and host SSH public key management - making such a deployment quite simple.
Alternatively, Kerberos SSO can be abandoned for those hosts (it will still work fine for other hosts in the IdM domain and services running on those hosts) and SSH key based authentication can be implemented all the way through.
It is important to note that SSH key authentication is not formally "SSO". It is a key-based authentication tactic. It uses a key pair - a private key as generated by the SSH tools and stored on the user workstation and a public key that can be uploaded into IdM and IdM will make it available automatically to all managed hosts on an as needed basis. Though (again) it is not exactly "SSO", it does allow us to avoid prompting a user for their password when he or she accesses the host in question. With this in mind - many find that the SSO requirement can either be reformulated or perhaps removed entirely.
Nevertheless, here is an outline of the steps that would need to be taken to get to the situation where all of the requirements are met:
- Install IdM
- Establish trust with Active Directory
- Connect the hosts without renaming to IdM
- Optionally create a jump host in the IdM domain
- Configure access control, automount, and privilege escalation policies (as needed)
- Generate SSH keys (for workstation users) and share public keys with the IdM administrator so that he or she can upload them into IdM
- Make any / all workstations use SSH with keys directly or via the jump host
Then... success! All of the requirements have been met.
I do hope that you will find this article to be useful.
As always, we are interested in your feedback, questions, and stories - do reach out using the comments section (below).