FAQ: The removal of Identity Management for Unix (IDMU) in Active Directory and how it affects the authentication of RHEL clients

Updated -

In more recent versions of Active Directory, Identity Management for Unix (or IDMU), has been removed. This article will outline how the lack of IDMU in Active Directory affects the ability for RHEL to authenticate to it.

Q: What is needed for a user to authenticate into RHEL?

In order for a user to authenticate to RHEL, the system requires that a user have the following defined: username, UID, GID, home directory, shell and a password.

Q: Which of the above are not defined in an AD system that lacks IDMU?

One of the things that IDMU in AD does is it gives the System Administrator the ability to easily administer the following user attributes through the GUI: uidNumber, gidNumber, unixHomeDirectory, loginShell. These are defined in the RFC 2307 schema, from which the ability to administer has been disabled in later versions of Active Directory without requiring additional steps.

Q: If the above attributes are missing from AD, how can AD users still authenticate to RHEL?

The answer is that the authentication module in RHEL will take advantage of overrides and id mapping to fill in the blanks. One of the main authentication modules that RHEL uses in order to do this is SSSD.

Q: How can SSSD be configured to authenticate AD users into RHEL when AD lacks required user attributes that RHEL requires?

SSSD has many advantages that allow it to work with certain directory servers that have been modified in certain ways. At minimum, in order to authenticate your AD user into RHEL using SSSD, the user object needs to have the following attributes: one that contains a username for the user (this attribute can be called anything) and an objectSID.

In Active Directory, all users will have a unique SID assigned to their object. SSSD uses the SID from an object to algorithmically generate a local ID number on the RHEL system. This is called ID Mapping. The way SSSD does this is similar to how Winbind's autorid mapping works. This allows you to configure your RHEL systems with SSSD so that any AD user who logs into any of the RHEL systems will have the same UIDs and GIDs across those systems.

Here is an article that describes how to authenticate RHEL to AD using ID Mapping:

Authenticate RHEL manually to Active Directory with SSSD using AD backend

Q: How does SSSD know to use ID Mapping in the above setup described by the article?

In the above article, the [domain] section of /etc/sssd/sssd.conf is configured with the below options:

id_provider = ad
access_provider = ad

By default, SSSD will use ID Mapping when specifying 'ad' as an id provider, unless you specifically define 'ldap_id_mapping = false'.

Q: But I am also missing a home directory attribute among the others needed by RHEL.

SSSD also has the options to specify overrides and fallbacks for things that may need to be defined as such. An example SSSD configuration that supports user objects that have only a SID and username can be seen below:

id_provider = ad
access_provider = ad
fallback_homedir = /home/%u
default_shell = /bin/bash

The use of 'fallback_homedir' and 'default_shell' tells SSSD that if it does not receive information from the directory server for those options, it will fall back to what is defined by these options. You may also tell SSSD to simply override anything it receives from the directory server for all users:

id_provider = ad
access_provider = ad
override_homedir = /home/%u
override_shell = /bin/bash

Q: What if we still want to use RFC 2307 user attributes in AD and have RHEL reference those?

You may still enable the ability to administrate the referenced user attributes in Active Directory by following this blog on the Microsoft website:

See: "How do I continue to edit the GID/UID RFC 2307 attributes now that the Unix Attributes Plug-in is no longer available for the Active Directory Users and Computers MMC snap-in?"

On the RHEL side, you simply configure /etc/sssd/sssd.conf with the following options:

id_provider = ad
access_provider = ad
ldap_id_mapping = false

Additional Information

The lack of IDMU in Active Directory in no way impairs the ability for AD users to authenticate to RHEL. ID Mapping in SSSD and Winbind autorid algorithmically generate UID and GID numbers from the static, unique SID property of an object, which is always present. For further explanation or assistance with any of the above questions or examples, please reach out to us:

Call us at:
1 (888) 467-3342

Open a case at:

Table of Contents

Automatically generate a table of contents


This link is deprecated: https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/