Hi,
I recently started to use FreeIPA for ldap login for my mail server (dovecot).
I wonder if it is possible to disable user locking when fail requests come from dovecot. That’s because it already has fail2ban enabled there, and I feel that it should block logins from a particular ip, not user login per se.
At the same time, I’d like to keep user lock for the other logins.
Is this doable?
Best,
Francis
On Аўт, 21 ліс 2023, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
Hi,
I recently started to use FreeIPA for ldap login for my mail server (dovecot).
I wonder if it is possible to disable user locking when fail requests come from dovecot. That’s because it already has fail2ban enabled there, and I feel that it should block logins from a particular ip, not user login per se.
At the same time, I’d like to keep user lock for the other logins.
Is this doable?
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.
On 22 Nov 2023, at 14:49, Alexander Bokovoy abokovoy@redhat.com wrote:
On Аўт, 21 ліс 2023, Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: Hi,
I recently started to use FreeIPA for ldap login for my mail server (dovecot).
I wonder if it is possible to disable user locking when fail requests come from dovecot. That’s because it already has fail2ban enabled there, and I feel that it should block logins from a particular ip, not user login per se.
At the same time, I’d like to keep user lock for the other logins.
Is this doable?
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.
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.
Best, Francis
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.
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.
On 23 Nov 2023, at 09:19, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org 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.
Best,
Francis
Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
On 23 Nov 2023, at 09:19, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org 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.
rob
On 27 Nov 2023, at 17:47, Rob Crittenden rcritten@redhat.com wrote:
Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
On 23 Nov 2023, at 09:19, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org 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@lists.fedorahosted.org
-
Alexander Bokovoy -
Francis Augusto Medeiros-Logeay -
Rob Crittenden