Description of problem: ldap searches are broken when running ipa version 4.12 and users configured to use OTP tokens. Version-Release number of selected component (if applicable): 4.12.2-1 How reproducible: easy reproducible running different versions Steps to Reproduce: 1. install ipa-server version 4.10, create user, add token, enable password+otp for this user -> ldapsearch using authenticated bind works using password+token as password 2. upgrade to ipa-server version 4.12, run ldapsearch using authenticated bind, you can login to ldap server without token (just enter password) Actual results: when upgraded (or newly installed) ipa version 4.12 you can bypass OTP authentication using ldapsearch and password authentication even if OTP is activated for this user. Expected results: keep behavior as it's currently on 4.10: if authentication type password+OTP is activated for user -> enforce authentication using pwd+OTP Additional info:
'Enable password+otp for this user' -- does it mean you have enabled *both* 'password' and 'otp' authentication types? If you have enabled both password and otp methods, then LDAP will be accepting password-only as well. The change in FreeIPA 4.12 is documented in RHEL 9.4.z release notes: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/9.4_release_notes/index#new-features-identity-management --------- Enforcing OTP usage for all LDAP clients With the release of the RHBA-2024:2558 advisory, in RHEL IdM, you can now set the default behavior for LDAP server authentication of user accounts with two-factor (OTP) authentication configured. If OTP is enforced, LDAP clients cannot authenticate against an LDAP server using single factor authentication (a password) for users that have associated OTP tokens. This method is already enforced through the Kerberos backend by using a special LDAP control with OID 2.16.840.1.113730.3.8.10.7 without any data. To enforce OTP usage for all LDAP clients, administrators can use the following command: $ ipa config-mod --addattr ipaconfigstring=EnforceLDAPOTP To change back to the previous OTP behavior for all LDAP clients, use the following command: $ ipa config-mod --delattr ipaconfigstring=EnforceLDAPOTP --------- Can you check if adding EnforceLDAPTOP configuration is doing what you need?
The behavior changes when using EnforceLDAPOTP: If user is configured to use pwd+OTP: login works as expected If user is configured to use only pwd: login fails But this does not solve the issue as not all users are configured to use pwd+OTP (like application users).
Sorry for misleading information: Enable password+otp for this user' -> means checkbox at user level is set only to menu item "two factor authentication (password+token)"
Ok, so I'd need some logs to debug for the non-enforced use case. Suppose you don't use EnforceLDAPOTP, in order to allow non-OTP users to bind to LDAP. Can you please provide: - output of 'ipa user-show non-enforced-user' - directory server logs when LDAP bind is done with non-enforced-user Ideally, for the directory server, if you could activate plugin debugging -- see https://www.port389.org/docs/389ds/FAQ/faq#troubleshooting, then we'd see internal searches IPA plugins do during the bind.
Created attachment 2053404 [details] directory server debug output
output of ipa user-show: # ipa user-show otpuser User login: otpuser First name: otp Last name: user Home directory: /home/otpuser Login shell: /bin/sh Principal name: otpuser Principal alias: otpuser Email address: otpuser UID: 736400003 GID: 736400003 User authentication types: otp Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: True
just verified on latest available version on Fedora (freeipa-server-4.12.2-5) that the error also exists on this version
I am a bit confused. You have provided the debugging output for authentication of the user that actually has OTP token and does not have password-authentication allowed. Can you please provide the same for the user who has password authentication allowed (and do this in the mode where EnforceLDAPOTP is not enabled)?
What I see from the debug log: 1. An attempt to authenticate as otp user starts: if (!syncreq && !ipapwd_pre_bind_otp(dn, entry, credentials, otpreq, ¬okens)) { /* We got here because ipapwd_pre_bind_otp() returned false, * it means that either token verification failed or * a rule for empty tokens failed current policy. */ if (!(notokens || (otpreq == OTP_IS_NOT_REQUIRED))) goto invalid_creds; } 2. In ipapwd_pre_bind_otp() we get into token verification because we see this debug message: Oct 24 09:42:51 idmtest.domain.lcl ns-slapd[14797]: [24/Oct/2024:09:42:51.879140460 +0200] - DEBUG - ipa-pwd-extop - Attempting OTP authentication for 'uid=otpuser,cn=users,cn=accounts,dc=domain,dc=lcl'. 3. ipa-pwd-extop plugin searches for OTP tokens for this user and finds one: Oct 24 09:42:52 idmtest.domain.lcl ns-slapd[14797]: [24/Oct/2024:09:42:52.306549078 +0200] - DEBUG - ldbm_back_next_search_entry - filter test value 0 ipatokenuniqueid=e0187bde-e6c9-4fd6-b56c-e67431475535,cn=otp,dc=domain,dc=lcl 4. At this point we are go to validate the token by the call to otp_token_validate_berval(). If token verification succeeded, we return true. We'll keep notokens set to 'false'. 5. As ipapwd_pre_bind_otp() returned true, we go to authenticate the password by calling ipapwd_authenticate() 6. In the logs we see this debug message from ipapwd_write_krb_keys(): Oct 24 09:42:52 idmtest.domain.lcl ns-slapd[14797]: [24/Oct/2024:09:42:52.463071722 +0200] - DEBUG - ipa-pwd-extop - kerberos key already present in user entry: uid=otpuser,cn=users,cn=accounts,dc=domain,dc=lcl this means a call to ipapwd_authenticate() was successful, so we get to next step which detects that Kerberos key is already in the entry and we don't need to perform a migration process. It is not important here, we'd just exist ipapwd_write_krb_keys(). So we definitely authenticated both OTP value and the password in this debug trace.
otp_token_validate_berval() looks into each allowed token definition and uses last X characters of the password credential passed as X digits of the code to try. If it cannot get those digits converted into the code to try, we'll return 'false'. In case only password is passed and no token value, the conversion of last X characters as digits will fail. Of course, there is a possibility that a password ends with X characters that are actually digits and then are the same as a next token values expected by this token, but that already is a stretch given this bug report. Since we passed through the validation, it was successful.
Created attachment 2054205 [details] pwduser directory server debug output I created new user "pwduser" and did ldapsearch using it's credentials. # ipa user-show pwduser User login: pwduser First name: pwd Last name: user Home directory: /home/pwduser Login shell: /bin/sh Principal name: pwduser Principal alias: pwduser Email address: pwduser UID: 736400004 GID: 736400004 Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: True Please find log attached.
Thanks. I reproduced the issue.
Did you identify the issue?
Sadly, not yet.
I submitted https://github.com/freeipa/freeipa/pull/7618 upstream.
FEDORA-2024-860c80c29c (freeipa-4.12.2-7.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-860c80c29c
FEDORA-2024-860c80c29c (freeipa-4.12.2-7.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-f033eb5f2b (freeipa-4.12.2-6.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f033eb5f2b
FEDORA-2024-aaa7dc08df (freeipa-4.12.2-2.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-aaa7dc08df
FEDORA-2024-f033eb5f2b has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f033eb5f2b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f033eb5f2b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-aaa7dc08df has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-aaa7dc08df` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-aaa7dc08df See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-aaa7dc08df (freeipa-4.12.2-2.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-f033eb5f2b (freeipa-4.12.2-6.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.