SSSD in container on Fedora Atomic Host
Table of Contents
- SSSD overview
- IPA-enrolling system
- IPA-enrolling via SSSD in container
- Testing the setup
- Complex options
- Uninstalling the container
- Note about DNS
- Versions used
SSSD can be run in a container and provide services to the programs on the host, without being even installed on the host. With the help of the SSSD container, it is possible to IPA-enroll the Atomic Host to FreeIPA / IdM server (IPA) or to join it to Active Directory, and have authentication and authorization for the Atomic Host working for users that are externally-managed in those identity management systems.
System Security Services Daemon (SSSD) is a daemon that provides identity, authentication, and authorization services to the operating system and applications. It provides modules and/or plugins for multiple subsystems of the operating system, including NSS, PAM, or sudo. It can cache multiple types of information to speed-up subsequent lookup or authentication operations, and it can use various remote backend types, including IPA, Active Directory, or LDAP.
SSSD can be configured by editing
directly but due to overlap to other subsystems, those
subsystems typically need to be configured as well to
make use of SSSD, like
pam_sss.so for PAM,
/etc/krb5.* for Kerberos operations.
For two use cases, setups against IPA and Active
Directory, setup tools can be used to configure
SSSD and other components of the operating system in automated
fashion. For IPA it's ipa-client-install,
or realm which can also configure the system
for remote Active Directory backend.
Configuring operating system and SSSD to use identity,
authentication, and authorization services of IPA is called
IPA-enrollment. While running the setup tools, credentials
typically need to be passed to
realm commands to authenticate the operation
on the remote system, as well as other options that specify
to which remote system we are IPA-enrolling the machine,
or which components should be configured.
The typical approach could include pre-creating the host record on the IPA server and generating one-time password for it:
That password can then be used to authenticate from the client during IPA-enrollment, instead of using credentials of admin or other power user.
ipa host-add --random host.example.com[...] Random password: 3dW742a5rYTX
When run on a typical Fedora non-Atomic machine, this command will retrieve the keytab file for the host principal (
ipa-client-install -w 3dW742a5rYTX[...] Client configuration complete.
/etc/krb5.keytab) and configure SSSD plus various identity, authentication, and authorization subsystems to use SSSD.
However, on Fedora Atomic Host, the command is not available
and neither is available
ipa-client-installbash: ipa-client-install: command not found
dnfto install package containing that program.
What we however have on Fedora Atomic Host is command
can download, configure, and run containers. SSSD container
is available and can be used to IPA-enroll (or join to Active
Directory) the Atomic Host in a very similar way you would do
it on non-Atomic machine.
IPA-enrolling via SSSD in container
Upgrading Atomic to get SSSD client bits
When SSSD is run in a container, programs running directly on the Atomic Host will talk to it via Unix sockets. Libraries that can do that and that will allow for example ssh daemon to use SSSD for authentication and authorization are available in Fedora Atomic 23.17 or newer.
If the sssd-client is not available on your Fedora Atomic Host, when for example using the Fedora 23 GA image Fedora-Cloud-Atomic-23-20151030.x86_64.raw.xz, please upgrade your host:
After the reboot, we should find the SSSD client packages installed and our Fedora Atomic Host ready to be IPA-enrolled:
rpm -q sssd-clientpackage sssd-client is not installed
atomic host upgradeUpdating from: fedora-atomic:fedora-atomic/f23/x86_64/docker-host [...] Upgrade prepared for next boot; run "systemctl reboot" to start a reboot
atomic# rpm -q sssd-client sssd-client-1.13.1-3.fc23.x86_64Note: The IPA-enrollment would pass even without sssd-client installed but we would not be able to test the results so we started with the upgrade to have our environment ready.
ipa-client-install in a container
The SSSD container is pulled and configured using
install fedora/sssd and it can take multiple parameters,
both on the command line and in configuration files. By default,
ipa-client-install is called in the container
and the parameters are passed to it.
Assuming we have our IPA server ready and we have precreated host record for our Fedora Atomic Host and let it generate one-time password via
we can use that password with the
kinit adminPassword for admin@EXAMPLE.COM:
ipa host-add --random atomic.example.com[...] Random password: kztxKgvR44qs
-wcommand-line parameter to the
atomic install fedora/sssd:
The fedora/sssd container will first copy various configuration and data directories into the container, then it will run
atomic install fedora/sssd -w kztxKgvR44qs[...] Client configuration complete.
ipa-client-installwith the command-line parameters that we passed to the
atomic install fedora/sssdcall, in this case
ipa-client-install -w kztxKgvR44qs, and upon successful IPA-enrollment copies the config and data files back to the host machine.
Starting the daemon in container
Unlike with directly calling
on the non-Atomic machine, the SSSD container and the daemon
inside of it does not stay running after
finishes. We need to start it with second step:
atomic run fedora/sssd
systemctl start sssd
Testing the setup
As root on the Atomic host, we can check that the SSSD container is running
and we can see what processes run in the container:
docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9088c7d529c6 fedora/sssd "/bin/run.sh" 27 minutes ago Up 26 minutes sssd
docker exec 9088c7d529c6 ps axuwwfUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 29 0.0 0.2 47960 3500 ? Rs 08:58 0:00 ps axuwwf root 1 0.0 0.1 11744 2596 ? Ss 08:31 0:00 /bin/bash /bin/run.sh root 7 0.0 0.0 4356 728 ? S 08:31 0:00 tail -f /var/log/sssd/systemctl.log root 12 0.0 0.4 155032 6352 ? Ss 08:31 0:00 /usr/sbin/sssd -D -f root 13 0.0 0.9 248556 14244 ? S 08:31 0:00 \_ /usr/libexec/sssd/sssd_be --domain example.com --uid 0 --gid 0 --debug-to-files root 14 0.0 2.1 161108 31448 ? S 08:31 0:00 \_ /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files root 15 0.0 0.3 133860 5568 ? S 08:31 0:00 \_ /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files root 16 0.0 0.4 138624 6888 ? S 08:31 0:00 \_ /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files root 17 0.0 0.3 133852 5480 ? S 08:31 0:00 \_ /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files root 18 0.0 0.4 159184 6840 ? S 08:31 0:00 \_ /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files root 28 0.0 0.0 4316 632 ? S 08:47 0:00 sleep 1000
From different machine (or the IPA server), we can test that GSS-API (Kerberos) authentication to the Fedora Atomic Host now works and that the user gets authenticated and the Atomic host knows user's identity:
We don't have home directories mounted but we see that authentication and user and group identity lookups work.
kinit bobPassword for bob@EXAMPLE.COM:
ssh firstname.lastname@example.orgCould not chdir to home directory /home/bob: No such file or directory
iduid=1215800001(bob) gid=1215800001(bob) groups=1215800001(bob) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
The PAM stack gets configured to use SSSD as well so for example when you disable the allow_all host-based access control (HBAC) rule in IPA, you can use custom rules to for example allow ssh access to the Fedora Atomic Host to members of admin user group.
Starting with Fedora Atomic 23.53, the sss_sudo is included which makes it possible to manage access to sudo for IPA-managed users in IPA server.
We've seen that we can pass the one-time password generated
by the IPA server when the host record was created to
atomic install fedora/sssd command and
it will be passed to the
in the container. In fact, if the first parameter to
atomic install fedora/sssd starts with a dash
-), all parameters will be passed to the
It is also possible to pass parameters to
ipa-client-install by storing them to
on the host before running
For example, it can contain
--server=ipa.example.com --domain=example.com --password=kztxKgvR44qsand these strings will be used as parameters. This approach can be useful for example for automatic enrollments upon provisioning when parameters for the provisioning are stored in some file or passed to the (virtual) machine in a form of configuration file anyway.
One difference to running
on non-Atomic machine is the interactivity. The
atomic install fedora/sssd runs
ipa-client-install in non-interactive mode
-U parameter) so it's not
possible to enter the password on a prompt. That further
increases the importance of scenarios using one-time
passwords for hosts.
Besides IPA-enrolling the Atomic Host, the SSSD container
can also join the Atomic Host to Active Directory using
realm command. There are two ways to trigger
this scenario instead of the default
If the first parameter to the
atomic install fedora/sssd
realm is called with the
remaining parameters. Alternatively, when file
realm will be called with its content as
In both cases, since the SSSD container is noninteractive and
realm does not allow the password for joining
the machine to Active Directory to be passed on the command line,
to contain the password, for the operation to succeed.
So for example,
will join the Fedora Atomic Host to Active Directory domain example.com, provided Administrator's password is stored in
atomic install fedora/sssd realm join example.com
Manual SSSD configuration
Since the configuration and data that the SSSD container uses
are stored in the exact locations where standard sssd service
stores them, it is possible to configure SSSD manually on the
/etc/sssd and other locations,
realm join in the container.
To instruct the container that is shouldn't attempt any additional
configuration besides configuring self to be run when sssd
systemd service is invoked (in
You can for example manually configure LDAP identity and authentication providers and special PAM handling and then just start the SSSD container.
atomic install fedora/sssd --migrate
Uninstalling the container
The SSSD container also supports uninstalling / leaving
the external identity provider, either via
ipa-client-install --uninstall or using
For IPA-enrolled machine, use
For machine joined to Active Directory, the same command should also work when the container can figure out that
atomic uninstall fedora/sssd
realmwas use to join but you can be explicit and use
atomic uninstall fedora/sssd realm leave
To disable the sssd.service on the host from attempting to start the container when it was unconfigured and possibly removed, use
atomic uninstall fedora/sssd
Note about DNS
In the examples above, we assume that the machines can find the IPA server because they are configured with correct DNS settings.
If you are trying the examples in testing setup, you can use
and set the hostname on those machines with domain matching the domain handled by the IPA server:
- Source code: https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/sssd
- Docker image: https://hub.docker.com/r/fedora/sssd/
- Fedora 23.53 Atomic Host (ostree)
- SSSD container docker.io/fedora/sssd: 5e464ff2c527 (use