As SSSD (the System Security Services Daemon) is gaining ground as a
bridge between applications running on a machine and central
authentication sources such as Active Directory and FreeIPA, questions
about support for other authentication protocols start to come up. One
such protocol is RADIUS (Remote Authentication Dial In User Service).
RADIUS is a popular authentication protocol for enterprise deployments,
notably for VPN (virtual private network) and WPA (WiFI Protected
Access) access.

Some enterprise deployments today also rely on RADIUS for the
authentication of system users. This is most often accomplished through
the use of the pam_radius_auth[1] module for PAM (Pluggable
Authentication Modules).

>From a design standpoint, a RADIUS authentication module would be a
simple fit. SSSD would acquire user identities from an LDAP directory
server, but would perform authentication against a RADIUS server, rather
than via LDAP simple-bind or Kerberos TGT acquisition. From a
completeness perspective, it seems sensible for SSSD to implement a
RADIUS authentication provider.

The question we need to ask is whether support of RADIUS in SSSD adds any
additional benefits. For this, we need to reach out to our community for
their experience and advice. Do you have (or know of) any specific
use-cases where the availability of a RADIUS authentication provider
would be beneficial? Similarly, do you feel that implementation of such
a provider would be best served by SSSD (and by extension, with offline
cached-credentials capability), or should we recommend continued use of
pam_radius_auth and simply ensure that SSSD gets out of its way?

Please provide as much justification and reasoning to back your
recommendations, so we can use this information to best identify our
path forward on this.

[1] http://freeradius.org/pam_radius_auth/

Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to