URL: https://github.com/freeipa/freeipa/pull/5734
Author: rcritten
Title: #5734: Design doc to allow LDAP bind using the RADIUS auth type
Action: opened
PR body:
"""
The RADIUS auth type is only supported with Kerberos currently.
This design proposes a way to make it work with LDAP binds
as well without relying ok workarounds.
Signed-off-by: Rob Crittenden <rcrit...@redhat.com>
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/5734/head:pr5734
git checkout pr5734
From 2d465549a8821a56831aa3a289b10f6ae4eed3eb Mon Sep 17 00:00:00 2001
From: Rob Crittenden <rcrit...@redhat.com>
Date: Fri, 23 Apr 2021 16:46:40 -0400
Subject: [PATCH] Design doc to allow LDAP bind using the RADIUS auth type
The RADIUS auth type is only supported with Kerberos currently.
This design proposes a way to make it work with LDAP binds
as well without relying ok workarounds.
Signed-off-by: Rob Crittenden <rcrit...@redhat.com>
---
doc/designs/index.rst | 1 +
doc/designs/ldap_pam_passthrough.md | 180 ++++++++++++++++++++++++++++
2 files changed, 181 insertions(+)
create mode 100644 doc/designs/ldap_pam_passthrough.md
diff --git a/doc/designs/index.rst b/doc/designs/index.rst
index cbec1096c36..f353efa1cd4 100644
--- a/doc/designs/index.rst
+++ b/doc/designs/index.rst
@@ -13,6 +13,7 @@ FreeIPA design documentation
krb-ticket-policy.md
extdom-plugin-protocol.md
expiring-password-notification.md
+ ldap_pam_passthrough.md
libpwquality.md
membermanager.md
hidden-replicas.md
diff --git a/doc/designs/ldap_pam_passthrough.md b/doc/designs/ldap_pam_passthrough.md
new file mode 100644
index 00000000000..9eb473cf99f
--- /dev/null
+++ b/doc/designs/ldap_pam_passthrough.md
@@ -0,0 +1,180 @@
+# LDAP PAM Passthrough support
+
+## Overview
+
+Many organizations have authentication mechanisms already in place.
+They may not want to have the LDAP server be the central repository for
+authentication. In 2005 389-ds provided a plugin that does authentication
+using a PAM service, https://directory.fedoraproject.org/docs/389ds/howto/howto-pam-pass-through.html
+
+In current IPA (<= 4.9.3) there is no support for configuring this plugin
+in order to outsource some authentication. The use-case for this is
+a 3rd party RADIUS service.
+
+In particular cases (enable otp and radius authentication indicators) it
+can work but its use is unsupported and configuration is tricky and
+confusing.
+
+The basic workflow is:
+
+ - IPA is installed
+
+ - The PAM pass-through plugin is enabled 389-ds to a PAM service that
+ relies on pam_sss.so.
+
+ - A RADIUS proxy configuration in IPA
+
+ - A RADIUS proxy link is configured for some users
+
+ - set default authentication method in IPA to 'radius, otp'
+
+ - No password or principal key is set for the user
+
+ - The user has no tokens set
+
+When that is done, the following should happen (hats off to Alexander
+for the bulk of this):
+
+ - on LDAP BIND with uid=user,cn=users,cn=accounts,$SUFFIX, the BIND
+ request will get processed. Inside the IPA password plugin
+ preop if both radius and otp are set and there are no tokens
+ the plugin will return 0, allowing further authentication to happen
+
+ - If the user DN is in the allowed configuration for PAM pass-through
+ then the PAM stack is loaded and processed
+
+ - pam_sss.so is called and attempts to perform a
+ password-based authentication for 'user' account
+
+ - since 'user' account matches IPA domain, it will be Kerberos
+ authentication against IPA KDC (running on the same host, as we are
+ authenticating on IPA master)
+
+ - IPA KDB driver in KDC will notice that the 'user@IPA' principal has
+ 'radius' pre-authentication method configured with TL data
+ "otp\0[{\"indicators\": [\"radius\"]}]" meaning it should advertise
+ OTP pre-auth mechanism to the Kerberos client
+
+ - the client (SSSD) would notice availability of OTP pre-auth mechanism
+ and would use host principal's TGT as its FAST channel wrapper to
+ proceed with OTP pre-auth
+
+ - OTP pre-auth mechanism will talk between KDC and the client to ask
+ for additional details (OTP value) via prompting mechanism it has
+
+ - Kerberos client (SSSD) will return the OTP value and KDC then will
+ issue a RADIUS request "Accept-Request" to a RADIUS server configured
+ in the KDC configuration. The OTP value in this case is the
+ credentials the user provided.
+
+ - We don't have explicit configuration for KDC and a compiled-in
+ default is to talk to UNIX domain socket /run/krb5kdc/DEFAULT.socket
+
+ - systemd listens to this socket as configured by ipa-otpd.socket
+ definition and on any access to it would launch ipa-otpd daemon
+
+ - ipa-otpd will connect to LDAP (LDAP URI is passed as part of
+ ipa-otpd@.service definition from /etc/ipa/default.conf, so it'll be
+ LDAPI access). It will parse RADIUS packet and look up requested user
+ principal entry from LDAP.
+
+ - if user principal entry has 'radius' authentication indicator
+ configured (or it is default for IPA deployment) and there is a
+ RADIUS proxy link in the user entry (there is no default so it must
+ be set per user), it will send the same RADIUS packet to the RADIUS
+ server configured as a proxy link with the credentials provided by
+ KDC
+
+ - If the RADIUS server answers with 'Accept-Response' message with
+ 'Access-Accept' code, ipa-otpd will respond to KDC with
+ 'Accept-Response' message with 'Access-Accept' code. If not, it will
+ respond with 'Access-Reject' code in 'Accept-Response' message.
+
+ - For native OTP setup where user has 'otp' authentication indicator a
+ process is about the same: instead of sending a RADIUS proxy request,
+ ipa-otpd will bind to LDAP with a user DN and pass the credentials
+ provided by KDC
+
+So yes, this is a complicated path.
+
+And unsuppported.
+
+## It would be confusing to users
+
+Strictly speaking, a user can have this configuration and still have
+a userPassword and krbPrincipalKey set. But it doesn't do much in LDAP.
+Regardless of whether the provided password is valid or not authentication
+will proceed to the RADIUS server for the final word.
+
+This is similar behavior if a user tries a raw kinit without armor:
+there may be a password/key but it isn't used.
+
+This could lead to "I can't log in" calls and an admin resetting their
+password in IPA with no real effect.
+
+## Why is otp required?
+
+This scheme works because RADIUS isn't considered at all in the
+password plugin.
+
+In prepost.c::ipapwd_pre_bind_otp() the user is checked to see if
+they have OTP auth enabled. If they do then the tokens are examined
+and if there aren't any, the function exits in a way that allows
+subsequent authentication. This will then fall out and return a 0
+to 389-ds to allow PAM Passthrough to execute.
+
+If the user does not have OTP auth enabled then that code will be
+skipped and return a 1 because the auth_type is not
+OTP_CONFIG_AUTH_TYPE_PASSWORD.
+
+## Proposal on how it should work
+
+So passthrough authentication basically works by accident and by
+working around the lack of direct handling of RADIUS in the password
+plugin.
+
+This proposal may break existing installations.
+
+The flow:
+
+RADIUS will be evaluated first.
+
+If RADIUS authtype is set:
+ - require no userPassword and krbPrincipalKey
+ - require radius proxy setting
+
+If auth request comes in and these conditions are not set then
+LOG_FATAL() and end the authentication attempt.
+
+The logging is because the authentication is so opaque users won't
+know why it failed.
+
+It would be nice to check that PAM passthrough is enabled but there
+is is no way to validate the configuration so skip it.
+
+OTP is evaluated next
+
+Is OTP enabled? If yes then do existing token evaluation.
+
+If No then fall through.
+
+OTP checking is done in ipapwd_pre_bind_otp() which is called unless
+there is a sync request. Authenticaiton type handling needs to be
+better centralized here. There are two paths that can return different
+results as outlined before (assuming otpreq = False).
+
+1. User has otp auth type and has no tokens it will return 0.
+2. User does not have otp auth type it will only return 0 if the
+ user has OTP_CONFIG_AUTH_TYPE_PASSWORD.
+
+This loophole needs to be closed. Perhaps change to return false if
+auth type is OTP_CONFIG_AUTH_TYPE_NONE. This would likely be more
+future-proof.
+
+If OTP doesn't return an error then the password will be authenticted,
+if there is one.
+
+If the password plugin returns 0 then subsequent authentication
+will happen. For the case of RADIUS we need to enforce the requirements
+because with PAM passthrough enable it becomes a defacto default
+method.
_______________________________________________
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
