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!