> On 27 Nov 2023, at 17:47, Rob Crittenden <[email protected]> wrote: > > Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: >> >> >>> On 23 Nov 2023, at 09:19, Alexander Bokovoy via FreeIPA-users >>> <[email protected]> wrote: >>> >>> On Чцв, 23 ліс 2023, Francis Augusto Medeiros-Logeay wrote: >>>>> No. This cannot be done -- a client cannot tell the LDAP (or KDC) server >>>>> that it is a 'trusted one'. When authentication comes, it is all about >>>>> user login, not where that login is coming from. >>>> >>>> Thanks Alexander. >>>> >>>> I don’t think this will change your answer, but the feature I asked >>>> about was not about “ the client telling that it is a trusted one” , >>>> but being able to set password policies based on which IP the request >>>> comes from. >>> >>> That's exactly what you asked for: a client-driven choice of a policy. >>> IP address of the connected client is not under control of the server >>> and may be spoofed. This is also a reason why we removed more than a >>> decade ago ability to differentiate HBAC rules by the connecting >>> client's address. >> >> I hear what you’re saying, but the premise is different. The possibility of >> ip spoofing can be mitigated by other means, I’d think. >> >>>> When mail server authenticates towards FreeIPA, it gets pretty chaotic >>>> if the user changes the password and have the phone, iPad, work and >>>> home computers trying to authenticate with the older password. >>> >>> An ideal way is to move away from a direct password-based >>> authentication. For example, by relying on a OAuth2 bearer token or >>> GSSAPI. In those cases a valid token would continue to work until it >>> expires which decouples your 'password expired and needs to be changed' >>> and 'email client needs to continue its access' situations. In the >>> latter case if token becomes invalid, the client on the phone, iPad, >>> etc. would automatically spawn a browser view to re-authenticate. >>> >>> FreeIPA doesn't have OAuth2 IdP integrated right now but there are >>> plenty of instructions to integrate with several open source projects >>> around >> >> I did that, and used Keycloak for that matter. However, there’s the problem >> of compatibility with mail clients. > > Either way there is no mechanism to skip password policy by IP at all. > While it your specific use-case it could make sense (a static IP where > all auths originate) in the general case it'd likely be abused. It is > not something we would implement because of that.
I don’t want to be annoying about this, but it seems to me that this choice opens up for another type of abuse: if I want to block another user’s account, all I have to do is to attempt to login with her username and a dummy password. While I understand that an IP-based rule as complement to wrongly typed password can have its issues (especially when the wrong password is typed behind NAT), it still would be beneficial. Best, Francis -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
