Sync vs. Trust: Red Hat Enterprise Linux Identify Management Integration with Active Directory

Identity Management in Red Hat Enterprise Linux (IdM) supports two different integration options with Active Directory: synchronization and trust.

I recently got a question about comparison of the two. I was surprised to find that I haven’t yet covered this topic in my blog. So let us close this gap!

The customer was interested in comparison of the two. Here is the question he asked:

To integrate IdM with AD 2016 I want to use winsync rather than trusts.

  • We would like to be able to manage the SUDO, SELinux, SSH key and other options that are not in AD.
  • I understand the advantages and disadvantages of each of the configurations and it seems to me that the synchronization is the best option to get the maximum of functionalities of IdM
  • But I would like to know the reason why Red Hat does not suggest the synchronisation.

Red Hat documentation states:

“In some integration scenarios, the user synchronization may be the only available option, but in general, use of the synchronization approach is discouraged in favor of the cross-realm trust-based integration.”

Is there any special reason why Red Hat recommends trusts (although more complected) vs. winsync?

Thank you for asking!

We in fact do not recommend synchronization for several reasons that I will lay down below but we also acknowledge some cases when synchronization might be the only option. So let us dive into the details…

When you have sync you really have two accounts: one in AD and one in IdM. These would be two different users. In this case you need to keep the passwords in sync too. Keeping password in sync requires putting a password intercepting plugin – passsync on every AD domain controller because it is never known which domain controller will be used for the password change operation. After you deploy the plugin to the domain controllers you need to reset the password for every account so that the plugin can intercept the password and store it in the IdM account. So in fact there is a lot of complexity that is related to synchronization. Let us add that this solution would work only for a single domain. If you have more than one domain in a forest or even several forests you can’t use sync. The synchronization also is done against one AD domain controller so if the connecting is down the synchronization is not going to work and there is no failover.

Another issue to keep in mind is that with synchronization you have two different places where the user authentication happens. For compliance purpose all your audit tools need to be pointed to yet another environment and they would have to collect and merge logs from IdM and AD. It is usually doable but yet another complexity to keep in mind. Another aspect is the account related policies, when you have two different accounts you need to make sure that policies are the same and not diverge.

Synchronization only works for user accounts not groups. Groups structure needs to be created on the IdM side.

Benefits of Trust

With trust there are no duplicate accounts. Users always authenticate against AD. All the audit trails are there in the single place. Since there is only one account for a user all the settings that apply to the account (password length, strength, expiration, etc.) are always consistent with the company wide policy and you do not need to check and enforce them in more than one place. This makes it easier to pass audits.

Trusts are established on the environment to environment level so there is really no single point of failure.

Trust allows users in all AD domains to access IdM managed environment, and since IdM can establish trusts with multiple AD forests if needed you really can cover all forests in your infrastructure.

With the trust setup POSIX attributes can be either managed in AD via schema extensions, if they are already there, dynamically created from AD SIDs on the fly by IdM and SSSD or set on the IdM side as explicit overrides. This capability also allows setting different POSIX attributes for different sets of clients. This is usually needed in the complicated environments where UID and GID namespace has duplicates due to NIS history or merges.

AD groups are transparently exposed by IdM to the clients without the need to recreate them. IdM groups can be created on top or in addition to AD groups.

The information above can be summarized in the following table:

So the promise of the trust setup is to provide a more flexible, reliable and feature rich solution. But this is the promise. This is why I put an asterisk in the table. The reality is more complex. In practice there are challenges with the trust setup too. It turns out the trust setup assumes a well configured and well behaved AD environment. In multiple deployments Red Hat consultants uncovered misconfiguration of AD, DNS, firewalls and other elements of the infrastructure that made deployments more painful than we would like them to be. Despite of the challenges some of which are covered in the article Discovery and Affinity published last year and some of which will be covered in my talk at Red Hat Summit in May most of the current deployments see a way to resolve the deficiencies of the existing infrastructure and get to a stable and reliable environment.

So synchronization might be attractive in the case of the small environment but even in such environment setting up a trust would not be a big complication.

The only case where I would call synchronization out is two factor authentication (2FA) using one time password (OTP) tokens. Customers usually want to have some subset of users to be able to use OTP tokens to login into Linux systems. Since AD does not support 2FA natively some other system needs to assign a token to AD user. It can be a 3rd party solution if customer has it or it can be IdM. In this case to provide centralized OTP based authentication for the Linux systems managed by IdM the accounts that would use OTP would need to be created in IdM. This can be done in different ways: by syncing them from AD using winsync, by syncing them from AD using ipa migrate-ds command, by a script that will load user data from some other source using IdM CLI or LDAP operation, just manually. Once the user is created a password and token can be assigned to him in IdM or the account can be configured to proxy authentication to an existing 2FA solution via RADIUS. IdM allows to enforce 2FA for selected set of systems and services. How to do it, please, read the Red Hat documentation about authentication indicators. This is the best approach. It allows for a general population of users to access systems with their AD password while a selected set of special users will be required to use 2FA on a specific subset of hosts. The only limitation is that this approach will work on Red Hat Enterprise Linux 7 systems. Older systems have limitations with OTP support.

If all the users need to have OTP tokens to log into the Linux systems then trust does not make sense and syncing accounts might be a more attractive option.

Thank you for reading! Comments and suggestions are welcome!

 

  1. Does this mean that if we have one domain with AD, idm can also be on same domain and there is no need to have/add new forest if we go with the Synchronization method?

    1. No. Please see https://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/
      The problem is really with clients of the servers that are joined to IdM. For example if you have a Windows client joined to AD and a Linux system that a user from the client needs to log into joined to IdM, this client would think that Linux system is a part of AD domain while it will be a part of the IdM domain. Kerberos would not work. You can work it around with some loss of capabilities. The article above covers the options you have.

      Hope it helps.
      Thank you,
      Dmitri

  2. How would you compare simply configuring sssd to use LDAP interface (with some AD related features like servers discovery based on DNS) to two approaches you discuss? For small linux environments in AD word I feel like it’s the best option.

    1. For a small environment the recommendation is to use SSSD and connect directly to AD with SSSD’s AD configuration (rather than a LDAP configuration). On RHEL7 you can use realmd to do the work of joining SSSD to AD and configuring sssd.conf for you . You do not need IdM until you see a value in centrally managing host-based-access-control, sudo, automount, netgroups, SELinux user mappings, SSH keys, certificates, etc for your Linux clients. Once your environment becomes big enough where managing these aspects become critical you can deploy IdM. We draw the line at about 30-50 systems. After that we recommend deploying IdM and using the Trust configuration.

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s