Is there any way that a milter under postfix can be told that a given client connection attempt failed specifically because of an authentication error?
Sometimes, my email server gets blasted with repeated SMTP authentication attempts from the same client, presumably in order to try to break through my security. I'm running a milter, and these attempts show up as a CONNECT followed by a CLOSE, with an error message in my postfix log that contains info like this:
warning: unknown[aaa.bbb.ccc.ddd]: SASL LOGIN authentication failed: XGFqc3d97mQ6
I'd like to use my milter to track these authentication failures, but I don't know if it's possible for a milter to be notified by postfix that the connection failure is specifically due to an authentication failure.
I can scrape my postfix logs to look for these failures, but I'd prefer to track them via my milter, if at all possible.
Is there any way to do this with a postfix milter?
Thank you in advance.
Well, after a week, I've gotten no responses, and I haven't found any way to make this happen. I will now assume that the answer to my question is "no".
Related
i have a scenario running with an own CALDAV-server and CALDAV-clients like (iOS-calendar, mac-Calendar, Android sync adapter, Thunderbird/Lightning, Outlook Sync, ...)
The authentication so far works via basic auth (https and the "Authentication"-Header).
The CALDAV-clients store the user/password in their configuration.
So far so good, but the issue comes now once the password of the user/account either gets changed, reset, expired, etc.
The server has a restrictive password policy enforced, which locks the account after x failed attempts (e.g. 10).
What is happening now obviously is, that once the CALDAV-client configuration was not updated it continues to use an old password.
The server responds with an 401 not authorized - ok, thats fine apparently again.
But the Clients still continue to use the outdated password. It would be nicer to stop polling and present the user with a dialog that his credentials are not valid anymore. But the clients are out of my control so nothing can be directly done here.
The result: after 2-3 iterations (as most clients tries multiple request in one sync iteration) the account on the server of the user is locked due to too many failed login attempts.
That is not nice. The issue seems to be generic and known as "stale passwords".
A solution could only be a better client handling (out of scope here) or a oAuth-token handling. But i was not able to find anything that standard CALDAV-clients supports this. Only google calendar seems to enforce an oAuth2 authorization before allowing CALDAV communication.
So the question is, is there a good way to improve the bad experience of locked accounts?
Some special 401 response which tells the clients to forget the password or not using it again?
constructive feedback highly welcome.
Edit:
for macOS and ios calendar i found a strange behavior (bug) causing and/or enforcing the described situation.
A standard 401 response will cause the clients to bring up the password dialog as expected and described above. The clients stop polling until a new password is entered - as desired.
In my case the 401 response body contained an inline base 64 image (img src="data..."):
This doesnt lead to a password renewal dialog! Just a "something goes wrong" error state.
The clients are continuing to poll! Locking the accounts after some tries ;(
A solution for this problem than will be to remove the inline image but for me it sounds like a bug that an inline image in the 401 response provokes a different behavior on the client.
Some special 401 response which tells the clients to forget the password or not using it again?
Well, 401 is that response. If the client receives a 401 it knows the the login/password combination it provided doesn't work anymore, and shouldn't retry with the same. Obviously the clients don't do this, partially because:
On the other side your servers x-failed-attempts locking doesn't work with stateless protocols for obvious reasons. HTTP doesn't have that feature builtin. Locking the account is a side effect a client doesn't have to expect when running idempotent HTTP requests.
Assume the client is downloading 10 batches of items concurrently. If the credentials invalidate during this, the account would immediately be locked :-)
Summary: You can't use basic auth naively with backends that lock accounts after n-tries.
Google and iCloud both use token based auth schemes (Google OAuth, iCloud a proprietary one). You can't expect those to work in other clients. E.g. while the Apple clients support OAuth for Google, I don't think they support that for other account types.
So what can you do
I'm reading your question so that you own the account server and that the account locking is intentional and desired. (I.e. it is not a side effect of a different (e.g. SSO) backend system you reach out to.)
I think in this case it should be reasonable to rework your account system to allow unlimited login attempts with just the old password.
The lock-after-n-attempts measure is to protect against people trying different passwords. In your case it is always the same and as a bonus it also matches the old password.
There are a lot of different variations of this approach.
I'm trying to set up inbound mail with mailgun. I want to receive email at support#mydomain.com. (changed for privacy)
All Mailgun's DNS checks pass.
I have a route set up. The expression is match_recipient("support#mydomain.com") and the action is forward("me#gmail.com")
When I use the route testing tool it correctly matches my route.
But when I send email in real life to support#mydomain.com, I get a failure notice. The error message is:
Your message cannot be delivered to the following recipients:
Recipient address: support#mydomain.com
Reason: Remote SMTP server has rejected address
Diagnostic code: smtp;550 5.7.1 Relaying denied
Remote system: dns;mxb.mailgun.org (TCP|17.172.80.96|58312|52.5.239.85|25) (ak47 ESMTP ready)
What step am I missing here?
I know this is over a year old, but since I spent 4 hours trying to figure this out, I will share my solution:
My mailgun account wasn't verified. I saw someone suggest this but I figured they just meant that I had to verify the address I was forwarding to. Nope, when I logged it today I saw a banner at the top saying click here to resend your verification email. I did that, it went through a text message verification process, and all immediately started working!
My problem is as follows :
I have an application protected by a mobile security test involving a LDAP server. The corresponding realm is called LDAPrealm. I use the form-based authenticator + custom LDAP login module.
When the connection to the worklight server is lost and then re-established, I see that the current user is not authenticated in the LDAP realm anymore.
What I want is be able to re authenticate the user without having him enter credentials again.
However, since the user is still authenticated for other realms included by default in the mobile security test, the worklight server does not challenge the client again for credentials, which is causing j_security_check error when trying to submit credentials.
As a side note those credentials are stored in the encrypted json store for offline authentication and use of the app.
So my question is :
Is it possible to force the server to challenge the client again for this LDAPrealm and use submitLoginForm to re-log in?
More generally, is there a way to clear a user+device from all realms before trying to log in again?
Edit reasons : previous error was caused by a typo
In the case where the user first logs in online then loses connection then get connection again, calling
WL.Client.logout("LDAPRealm",{onSuccess:stealthed_relog});
and calling WL.Client.connect() later in stealthed_relog before sending credentials seems to wield the desired behaviour.
However, when the user logs in offline and then gets connection, when I try to use WL.Client.connect(), it says another instance of WL.Client.connect has already been called.
edit : for the log offline case, the application get challenged automatically shortly after that the connected event fires (cause of heartbeat? I do not really know), so you just have to use
login_clientside.submitLoginForm();
to successfully log in again.
If someone has a better way to implement auto-reconnecting in worklight with ldap server, feel free to post it and I'll unaccept my answer.
We have done a fair amount of work and have come pretty close to getting Jenkins to automatically kick off a build when a push is made into Github. However, Github is logging an error from Jenkins when attempting to post to the Github plugin webhook as follows:
Error 401 Either no such user 'CN=Github Account,OU=Jenkins,OU=Applications,DC=mydomain,DC=com' or incorrect password; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece?]
We have LDAP enabled in our environment to allow for active directory logins. An account called "github" has been created on our domain and authorized as a Jenkins user. We are able to manually login to Jenkins by punching in the username and password for this account and it works as expected. The "github" account has been authorized on the project for READ and BUILD directives on the job.
On Github, the push webhook has the url defined as follows:
http://github:password#jenkins.mydomain.com:8080/github-webhook/
We can confirm that the push event effectively triggers the post to the URL, but the response is a 401 with error details as described above. We know the account is valid and the password is correct, but we are stuck because we cannot understand why Jenkins suggests that it is invalid.
We have used the following link, among many others as a guide:
http://fourkitchens.com/blog/2011/09/20/trigger-jenkins-builds-pushing-github
As far as we can tell, the only difference between our configuration and those of others who have posted about their success on blogs and here on Stackoverflow is our use of LDAP authentication.
Does anyone have any guidance to help us overcome this hurdle? Currently, we can successfully run a build manually, so our communication TO Github FROM Jenkins is tip top. But Github back to Jenkins is a frustrating no-go.
This is now working. Here is what went wrong. When configuring the following string, pay careful attention to both the username and password:
http://github:password#jenkins.mydomain.com:8080/github-webhook/
In our case, the password contained special characters that Jenkins was tripping over. Usernames and passwords with special characters must be URL encoded or the authentication will fail. For example, the following password
!test+pw
must be URL encoded as follows:
%21test%2Bpw
We are receiving the following error message when people attempt to log in.
nHTTP: TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw== [173.164.83.101] authentication failure using internet password
Any ideas why this is happening and why it's preventing appropriate logins ?
Turns out it was a single sign-on setting problem. We fixed the setting and all is working.