What is the support status for Samba file server running on IdM clients or directly enrolled AD clients where SSSD is used as the client daemon

Updated -


The System Security Services Daemon (SSSD) and Winbind are two complementing tools shipped in Red Hat Enterprise Linux for system integration with Microsoft Active Directory. Both tools provide ability to retrieve identity information about users and groups from Microsoft Active Directory forests, transform it for use in POSIX environment and present as system user and group identities for other applications.

A regular computer enrolled into Microsoft Active Directory is called a domain member. In a traditional domain member configuration, the member machine has no possession of a particular user credentials. Instead, it relies on its own connection to its own domain controller to identify a user and to proxy user’s authentication to the domain controller of the domain a user belongs to. In case a user is performing a remote authentication using Kerberos, a remote system has to present a Kerberos ticket to the domain member’s SMB service, like with any other Kerberos services.

A file server capabilities can be enabled on a domain member running under Red Hat Enterprise Linux with the help of Samba suite. Samba suite, when running as a domain member, starts two daemons:

  • smbd, the main process which handles network connections, file system operations, and remote procedure calls like LSA and NETLOGON. Each connection is handled by a separate smbd child;

  • winbindd, a process to perform identity resolution for all configured and known domains. Active connection to a domain is handled by a separate winbindd child. winbindd processes connect to domain controllers and perform required LSA and NETLOGON operations against them. Normally, authentication of a user from a trusted domain is delegated to the domain member`s own domain controller which then forwards it further.

Winbind uses a set of identity mapping modules collectively called idmap modules in Samba terminology. Each idmap module represents a strategy to map security identifiers (SIDs) from Active Directory to corresponding POSIX IDs. Since SID namespace in Active Directory is common for all kinds of objects and POSIX ID name space is separate for users and groups, with both POSIX ID name spaces being smaller than a common SID name space, there exist multiple approaches to perform the translation. A choice of a translation method is tightly connected with a specific deployment configuration.

It is possible to configure Red Hat Enterprise Linux system to use winbindd for both system level POSIX IDs retrieval and file server operations in Samba suite. Thanks to winbindd idmap modules support, it is also possible to configure it to look up system identities via SSSD. In the latter case winbindd daemon would still be running but will not provide NSS and PAM services.

In many deployments SSSD has already been configured for system-level authentication and authorization purposes. The sssd-winbind-idmap package provides a winbind idmap module, called idmap_sss which can be used by winbindd as an identity mapping module to leverage SSSD capabilities.

Since both winbindd and SSSD need to know domain member credentials when communicating with Microsoft Active Directory domain controller, they need to coordinate their operations on more than a configuration level.

Support status

There are a few limitations, though, when the idmap_sss module is used with Red Hat Enterprise Linux 7. Please see Red Hat System Administrator Guide for more details. Therefore Red Hat currently does not recommend using the idmap_sss module for Samba file server enrolled into an IdM or AD domain.

There are a few exceptions though:

  • In cases where Red Hat Enterprise Linux 7.x or 8.0 is used and where Samba/Winbind has already been configured to use the idmap_sss module and where the setup works as expected, Red Hat would still provide support for a single domain (e.g, Samba file server machine is enrolled in AD.COM and all users who want to access the Samba share are managed in this domain).
  • In cases where Red Hat Enterprise Linux 7 or 8.0 is used and the same setup, as described above, doesn’t work anymore after an upgrade, Red Hat would still provide support to work on the regression.
  • With the release of Red Hat Enterprise Linux 8.1, a technology preview for a Samba server to be set up on an IdM domain member. Further detail is available in section A Samba server, available to IdM and AD users logged into IdM hosts, can now be set up on an IdM domain member as a Technology Preview in RHEL-8.1 Release Notes.
  • In a later release, Red Hat will also provide support for Samba file server on directly enrolled Active Directory member systems.

It is recommended to open a support case with Red Hat Global Support Services to provide your Samba use case details to allow improving overall coverage of supported Samba file server configurations. Please make sure to provide relevant debug data for the SSSD and Samba service to speed up the overall resolution time of your support request.


The article does not answer the question in the title. I am trying to find out what kind of integration between IDM and Samba is currently possible. The article only talks about Active Directory integration, but not IDM.

We currently do not recommend the use of winbindd idmap_sss module for clients enrolled into IdM or AD domain. We will provide support for Samba running on IdM clients starting with Red Hat Enterprise Linux 8.1. Support for Samba running on directly enrolled AD clients is scheduled for a later release of Red Hat Enterprise Linux 8. There are a few exceptions we would also support on existing releases, those are outlined in the text.

Thanks for that detail Thorsten.

We're currently keeping our fileservers back on RHEL 7 until the support for directly enrolled AD clients is released. If I raise a support ticket can I add any weight to the priority on that work for Engineering?

How about





for a RHEL server joined to AD using SSSD ?

BTW, all those links contain the same information / instructions

Hello Daniel,

Thank you for the feedback! Let us know if you need help with anything specific so that we can assist you in a better way. You can even raise a support ticket with us.

  • Akshay S | Technical Support

Were you able to get SMB properly setup using either winbind or SSS to retrive the POSIX attributes from the AD side? if so what aritcle from the above have you used?

We have been having no luck.

We are having multiple issues with the SMB since the new version release.

Using winbind we are unable to get winbind to read the POSIX attributes directly from AD. We have had a support case opened for this, over two months now and still no luck. It has been escalated and still on a fresh Redhat 7 system the tech can not get it to work.
In another test env we are using SSS method, however we are expereincign a few issues here as well.

One, on some RedHat 7 systems we are not able to access the system, even though it is configured as per RedHat instructions, in short it states that it does not have the privliages to access the system. We have a ticket opened for this as well, no luck so far. Some users are not showing up when doing a getent -s sss password and some are. In both cases we are finding that behavious of both SSS and Winbind methods are unstable and not working as it should.

Marino, thank you for reporting this. With winbind, to get POSIX attributes from AD, you need to use idamp ad in smb.conmf file:

idmap config EXAMPLE:backend = ad
idmap config EXAMPLE:schema_mode = rfc2307
idmap config EXAMPLE:range = 10000-999999
idmap config EXAMPLE:unix_nss_info = yes

& idmap config EXAMPLE:unix_primary_group = yes <---- If you want primary group should be set to the one which points to gidNumber set (and not 'domain users' group)

On SSSD system, what issues are you facing? Could you please shed more light?

If possible I will check the cases you have opened with us and update you.

  • Akshay S | Technical Support

I have another case open that I have escalated to which we are trying to get winbind setup to use POSIX atttributes from AD, so far no luck with that.

SSSD it is all in the case updates as to what is going on there:

In short: 1. When attempting to connect to the machine via smb from any windows systems we are getting "Not acessible Error. Full Error message was attached to the case.

  1. Some users were not able to query using getent -s sss passwd <domain\user>. Only after redoing the entire Domain join process following https://access.redhat.com/solutions/3802321 did it work. This to is updated in the case notes.

Hello Marino,

I am already checking the case you're referring to, let's take this further over the case.

  • Akshay S | Technical Support