feature: Domain Join use SSSD instead of winbindd

[jbouse]

I've been evaluating using the seamless domain join with Linux EC2 instances and noticed that it currently relies on winbindd and Samba rather than using SSSD. I would rather use SSSD but haven't seen anyway of doing so short of giving up on the existing seamless domain join functionality and handling it manually.

Any thoughts on making this a supported feature? Both can be done via the realm command just changing the --client-software option passed to realm when joining the domain. I believe most modern available Linux distributions all have SSSD available,

[smhmhmd]

We had to use winbindd because SSSD did not support AD Trusts

[jbouse]

We had to use winbindd because SSSD did not support AD Trusts

I don't think that's been the case for several years now, and SSSD provides much more integration at this point, I believe, including GPO, along with sudo & SSH authorized_keys support if the schema is extended.

[smhmhmd]

SSSD supports FreeIPA a lot better. If you have tested SSSD with AD Trust with Microsoft Active Directory, please let me know.

[jbouse]

SSSD supports FreeIPA a lot better. If you have tested SSSD with AD Trust with Microsoft Active Directory, please let me know.

I don't have an AD forest with trusts currently available to test against and was basing my previous comment on a ticket that was opened seven years ago and closed five years ago when SSSD 1.15.2 was released fixing the issue. Given the current version is 2.7.4 and I hadn't found a more recent bug report I based my belief.

At this point I opened this I was currently evaluating using the AWS Directory Service Managed AD to test the Linux seamless domain join and found it using winbindd rather than SSSD so I've started to write a custom solution as I do no want to use winbindd but there doesn't currently seem to be any other option available and the aws_domainjoin.sh script is compiled into the agent/plugin/domainjoin Go code

[smhmhmd]

Was there a fix for your ticket ? I could add an opt-in option to use sssd as a field in the Secrets Manager secret, but, we will continue to use passwords for domain-join. Would this work for you ?

[jbouse]

The documentation page that led me to that ticket was which seems to indicate expansion of the domain options to provide configuration options to trusted domains. I also found a RedHat solutions doc that requires RedHat credentials to access that talks about SSSD and AD trusts.

I understand needing to maintain the current state to avoid breaking anyone using the existing behavior. I also know it is a pretty good assumption that modern distributions that would have winbindd available will also have SSSD so defaulting to winbindd and having a means to opt-in to use SSSD would be the route I would have suggested. I use the realm command to join using SSSD if I configure it manually and the command structure for that in the script inside agent/plugins/domainjoin/domainjoin_unix_script.go is the same save changing --client-software=winbind to --client-software=sssd after ensuring that the sssd package is installed.

In some testing I found if you install only have the Winbind packages installed with Realm and run the realm discover without the --client-software option at all it will return showing client-software=sssd which indicates that Realm is defaulting to SSSD over Winbind. So it would seem Realm isn't detecting the client-software to use and will install SSSD unless Winbind is explicitly selected. I had also noted that it appeared SSSD was already installed through the install_components() function for SUSE only but from the rest of the script logic appears it is never used.

[ec2-user@ip-172-31-23-170 ~]$ rpm -qa realmd samba-winbind sssd
realmd-0.16.1-9.amzn2.0.1.x86_64
samba-winbind-4.10.16-18.amzn2.0.1.x86_64

[ec2-user@ip-172-31-23-170 ~]$ realm discover example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools

[ec2-user@ip-172-31-23-170 ~]$ realm discover --client-software=winbind example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: winbind
  required-package: oddjob-mkhomedir
  required-package: oddjob
  required-package: samba-winbind-clients
  required-package: samba-winbind
  required-package: samba-common-tools

[ec2-user@ip-172-31-23-170 ~]$ realm discover --all example.com 
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: winbind
  required-package: oddjob-mkhomedir
  required-package: oddjob
  required-package: samba-winbind-clients
  required-package: samba-winbind
  required-package: samba-common-tools
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no

What might be debatable is whether to put the option in the Secrets Manager or the SSM doc. The Secrets Manager really does only need to maintain the username and password to use for the bind credentials. The aws:DomainJoin plugin action already has support for the optional directoryOU to change the OU that hosts are joined under that requires creation of a custom SSM document (awsconfig_Domain_d-0d3adb33f0_example.com for example) if needed. A strong argument could be made to use a similar pattern to opt-in to using SSSD instead of default behavior. Calls to the configure_samba() and reconfigure_samba() functions would not need to be called if using SSSD, and configure_nsswitch() would require a conditional operation to use sss instead of winbind along with potentially adding sudoers to the list. Some of those are automatically added, I believe, when realm adds the domain.

[jbouse]

Additionally found this RedHat RHEL7 doc talking about AD cross-forest trusts.

[smhmhmd]

I also found a RedHat solutions doc that requires RedHat credentials to access that talks about SSSD and AD trusts.

I have Redhat access, I will go through the docs, thanks for posting.

[smhmhmd]

From the RedHat solutions doc, it does not seem like it can be automated. If you would like to get on a call, I can show you contents of the doc and discuss. Realm does default to SSSD, but winbind works fine as well.

[jbouse]

Yeah reading more and even checking out the RHEL8 docs it looks like SSSD only supports domains in a single AD forest. So seems like I'll continue down my path of just writing Ansible to handle the domain join and SSSD configuration and modify the SSM doc to execute that on Linux systems and leave Windows to execute aws:domainJoin like normal.

If still would like to have a call and discuss I could find time to do so still.

[smhmhmd]

ok, if you would like to discuss the changes you plan to make, we can have a call.

[forward-observations]

Hi all, I'm a complete neophyte when it comes to the differences between winbind and sssd, but I noticed that some things like securing SSH access to the Linux EC2 instance, mounting shared folders from our FSx for Windows File Server required some slight tweaks to the commands being used to get things up and running. Will there be any effort to change the SSM document over from using winbind to sssd? I noticed that it hasn't been updated since 2020 and if it makes more sense to use sssd, can it be made to do so? It would also be hugely beneficial to prompt for the automatic addition of the AWS Delegated Administrators group into sudoers.

I still need to wrap my head around a lot of this since I edited some other files to allow root access to the machine instead of the /etc/sudoers.d location. As I've come to find, there are many ways to skin a cat in Linux.

[smhmhmd]

Will there be any effort to change the SSM document over from using winbind to sssd?

Ack, I will try to reach out to RedHat, since AD Trusts are important for Directory Service.

[jbouse]

Hi all, I'm a complete neophyte when it comes to the differences between winbind and sssd, but I noticed that some things like securing SSH access to the Linux EC2 instance, mounting shared folders from our FSx for Windows File Server required some slight tweaks to the commands being used to get things up and running. Will there be any effort to change the SSM document over from using winbind to sssd? I noticed that it hasn't been updated since 2020 and if it makes more sense to use sssd, can it be made to do so? It would also be hugely beneficial to prompt for the automatic addition of the AWS Delegated Administrators group into sudoers.

I still need to wrap my head around a lot of this since I edited some other files to allow root access to the machine instead of the /etc/sudoers.d location. As I've come to find, there are many ways to skin a cat in Linux.

I've not mounted any FSx for Windows File Server volumes on to a Linux EC2 instance before so I'm not sure on the process and what tweaks were needed.

SSSD is the more modern method and it does involve actually joining the domain as a member and using Kerberos authentication. Adding SSH authentication is fairly easy AD schema update and then all public SSH keys are able to be stored and looked up from AD directly without having to install them. SSSD also is able to use the SID to automatically handle consistent UID/GID values on the Linux host. Sudo access is also able to be managed from within AD records.