[RFE] Support OTP logins for AD trust users

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2908

• Created at 2016-01-04 10:52:51 by jhrozek
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1292363

---

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1292363

Description of problem:
Allow defining OTP token for AD user logging in Linux machine. This is not for
GSSAPI use case, this is for log-in with user password. Alexander already did a
prototype at DevConf 2015.

At the moment it should be possible to assign a token already and do an
ldapsearch with password+token. However, we need to figure out the prompting
part and whether we need to only do an ldapsearch or also kinit (provided we
know the long-term password part)

Version-Release number of selected component (if applicable):
sssd-1.14

How reproducible:

Steps to Reproduce:
1. set up IPA-AD trust
2. log in with AD user ID and password+pin combo
3.

Actual results:

Expected results:

Additional info:

Comments

---

Comment from jhrozek at 2016-02-16 12:22:01

This work requires improvements in libkrb5 that are not available yet, moving out of 1.14

blockedby: => blocking: => changelog: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => mark: no => 0 milestone: SSSD 1.14 alpha => SSSD 1.15 beta review: True => 0 selected: => testsupdated: => 0

---

Comment from jhrozek at 2017-02-24 15:07:20

Metadata Update from @jhrozek:

• Issue set to the milestone: SSSD Future releases (no date set yet)

---

Comment from thalman at 2020-03-13 11:58:08

Metadata Update from @thalman:

• Custom field design_review reset (from 0)
• Custom field mark reset (from 0)
• Custom field patch reset (from 0)
• Custom field review reset (from 0)
• Custom field sensitive reset (from 0)
• Custom field testsupdated reset (from 0)
• Issue close_status updated to: None
• Issue tagged with: bugzilla

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards, André Boscatto

CC: @tscherf