#3856 Second Factor prompts are misleading, always (optional)
Opened a month ago by hicksaw. Modified a month ago

Request for enhancement

As a user logging in with ssh to a FreeIPA enrolled host that does not require 2FA authentication, I should not be prompted for a "Second Factor (optional)"

As a user when I ssh to a FreeIPA enrolled host that requires 2FA authentication, I should not be prompted for "Second Factor (optional)" when it is not optional.

Issue

We have set up per host 2FA authentication with FreeIPA by:
- Enabling Two factor authentication (password + OTP) in the IPA server configuration
- Ticking OTP authentication indicator on those hosts we want 2FA to be enabled
- NO OTP AUTHENTICATION INDICATORS ON USERS OR OTHER HOSTS

We are getting a log of user complaints that the login prompts for the second factor are misleading. Their complaints come in two forms:
- States that the second factor is optional when it is required
- Requests a second factor when it is not required

This is probably an issue that will require co-ordinated changes with FreeIPA https://pagure.io/freeipa/issue/7733

Steps to Reproduce

  1. Set up per host 2FA as above
  2. Create 2 test login hosts, and update sssd to 1.16.0 or later
  3. Enroll the test hosts
  4. Set the OTP auth indicator on one the test host. This is the 2FA test host
  5. Add an OTP token to the login user
  6. Log with 2FA to confirm 2FA works, see "Second Factor (optional)" when it is required
  7. Log into the other test host and see "Second Factor (optional)"

Actual behavior

The prompt "Second Factor (optional)" appears everywhere regardless of the actual per host login requirements.

Expected behavior

On hosts that do not require 2FA users should only get a "Password" or "First Factor" prompt.
On hosts that require 2FA users should not be misinformed that the second factor is 'optional'

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server sssd

on a login node:
[root@login01 ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server sssd
package freeipa-server is not installed
package freeipa-client is not installed
package ipa-server is not installed
ipa-client-4.5.4-10.el7.centos.4.4.x86_64
package 389-ds-base is not installed
package pki-ca is not installed
package krb5-server is not installed
sssd-1.16.1-7.el7.centos.x86_64

On freeipa server:

[root@hpchipa06 ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server sssd
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.5.4-10.el7.centos.3.x86_64
ipa-client-4.5.4-10.el7.centos.3.x86_64
389-ds-base-1.3.7.5-24.el7_5.x86_64
pki-ca-10.5.1-13.1.el7_5.noarch
krb5-server-1.15.1-19.el7.x86_64
sssd-1.16.0-19.el7_5.5.x86_64

Additional info:

Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.

Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html
Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting


Thank you for the report. I see this ticket as a duplicate of #3264 and I'm very sorry I didn't had a chance to work on this ticket yet.

About the prompting. I can follow your reasoning but I think the default behavior of the current prompting should not be changed (that's why I think it is a duplicate of #3264 and should be solve with configuration options). The main reason is that authentication and authorization are two separate steps.

First, the user authenticates itself with whatever credentials he has and are considered suitable for the given service.

Second, the service, e.g. the service which offers access to the host, decides if a user is allowed to log in. The check here might include checks if the user account (not the password) is still valid, if HBAC rules allow access and if the given credentials used for authentication are strong enough. Additionally each service, e.g. ssh, GDM, /bin/login, might have different rules and requirements.

You prefer that 'On hosts that do not require 2FA users should only get a "Password" or "First Factor" prompt.'. But there are use-cases for this behavior. The type of authentication is recorded in the Kerberos TGT you get a fter authentication. So, e.g. even if 2FA is not required on the workstation the user logs in he might still want to use 2FA to have this recorded in his TGT so the he can log into other systems which require 2FA without requesting a new TGT manually or authenticating to the other system again.

I see your point for most of your response, however I disagree where (optional) is included in second factor prompt when it is required. In this case the prompt is misleading, if not actually lying to, the user, and introduces uncertainty in the required response.

I've been thinking about your response more and it doesn't actually address the issue we have described. We are finding that the prompts are not sufficiently clear about what its or is not required by the user to enter their credentials leading to confusion. This means that they are not in a sufficiently informed state to be able to respond as you claim in your first point:

First, the user authenticates itself with whatever credentials he has and are considered suitable for the given service.

As for the second point, we are asking that services prompt users in a meaningful way so that the end user is guided to the correct responses to allow login, rather than seeing exactly the same prompts for different services (or the same service on different hosts) with different requirements and having the user know or guess which host requires which responses. A host or service should prompt correctly for it's own authentication needs.

As for your last paragraph, can you please link the sssd/sshd documentation or configuration guide that explains how to set this up. The workflow we wanted was 2FA and password is required to ssh to our external lander/jump hosts exposed to the internet, but all internal hosts only use password authentication. We'd consider all hosts use 2FA if once challenged users could then freely move about within our environment (according to HBAC rules) until their Kerberos ticket expires.

Ooops, need to keep my account straight :P

Login to comment on this ticket.

Metadata