I Really Can’t Rename My Hosts!

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:

  1. I want to be able access my Linux hosts with credentials stored in Active Directory.
  2. I want to be able to centrally manage access control to my Linux hosts for user accounts stored in Active Directory.
  3. I want to be able to centrally manage privilege escalation (sudo) for user accounts stored in Active Directory.
  4. I want to be able to control automount maps for my Linux systems centrally.
  5. I want to be able to jump between my Linux hosts without requiring to enter passwords all the time (SSO).
  6. 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.
  7. 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).

  1. Maybe this is just me, but without a way of mapping ssh key authentication to kerberos, it feels like you’re in an unhappy middle ground. Any fileshares I think end up as SSO via kerberos, whether that’s NFS or CIFS, and you end up with authentication to the machine sorted, but not authentication the fileshares, which may include your home directory, unless you’ve provided kerberos auth from the outset.

    That said, ssh keys can be useful for the remote user, as it avoids having to repeatedly provide credentials, especially if they’re using ssh aware IDEs. One option there is to simply require an initial kerberos login to the host, but also allow key based logins. Once the first login has happened, they’ve got a valid key (renewable up to a week) supporting their use of ssh keys for future logins. Paired with delegation via ssh, and the user’s pretty happy.

    1. Right the problem is SSO from outside of IdM managed environment into IdM managed hosts that are not renamed. If you can avoid it by SSHing into a jump host with a password credential you avoided the problem altogether.

  2. Another option would be to give the Linux hosts some additional DNS names in the IDM domain, without changing their hostname.

    host1.example.com could also respond to host1.idm.example.com, so users could ssh to host1.idm.example.com and enjoy SSO thanks to the cross domain trust with FreeIPA.

    The “main” hostname would not be changed to avoid problems in the Big Proprietary App.

    1. If you need to login into such host from another system that is a Windows system that Windows system would ask for a ticket from AD. AD DNS will have this host but not Kerberos principal. Since AD thinks that DNS domain = Kerberos realm it will stop there.
      So the proposal will work for the case when you SSO between IdM managed hosts but not when you need to get to managed hosts from Windows desktop which is the usual case in this situation.

      1. Thank you for the comment. When you say “better solution is really needed” do you mean a better solution to what is covered in the article or you mean that the solutions offered in the article are good solutions to use and already address the challenge?

      2. The solution addressed here is good deserved to be implemented, I was talking just about the renaming hostname part in a Linux environment. But so far, the problem covered here is really important.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s