Hi All ,

In my environment frequently i am getting account lockouts for the pop based email accounts (both internal and external user from internet).

So i just tried to find the caller computer name for the account lockouts.Finally i found that exchange CAS server is making those account lockouts.

I have enabled the protocol logging on the CAS server and i found the below mentioned error message.

"R=""-ERR Logon failure: unknown user name or bad password."";Msg=LogonFailed:LogonDenied"

Environment Details :

Exchange 2013 SP1

Client Windows Live mail.

Please all you tell me how to overcome this issue for my pop Email cli

They probably have hard-coded invalid passwords that trigger your account lockout policy.  Maybe you should consider revisiting your account lockout policy and raise the number of unsuccessful attempts.

Hi ,

Thanks for your reply .

But here the problem is i am getting frequent account lockouts only for the pop accounts and that is done by the CAS server.All the outlook anywhere connections are all going via that same server (i.e casserver1) but those accounts are not getting locked.

Below is the logs which is have take it from the netlogon.log on the domain controllers.

05/13 09:47:54 [LOGON] [15780] SFL: SamLogon: Transitive Interactive logon of (null)\nithya from Casserver1 (via casserver1) Entered

05/13 09:47:54 [LOGON] [15780] SFL: SamLogon: Transitive Interactive logon of (null)\nithya from Casserver1 (via Casserver1) Returns 0xC0000234

As an additional info ,most of the account locked out pop users were connecting to exchange server from internet and at the same time we have kept those user's password as never expires in AD .

Pop Email-client Details : Windows Live mail .

Okay so block POP on those mailboxes if you don't want them to be locked out.

Hi ED ,

Again thanks for your reply.

Really sorry that is not possible because most of the users from internet are accessing their emails by using POP protocol through windows live mail .Since we cannot use outlook anywhere for all the user accounts through outlook software because it is an paid one.

Any other suggestions ?

Okay, change or remove your password lockout policy.  It sounds like someone is hacking those accounts or your users have misconfigured clients that are repeatedly trying to log on and locking out the accounts.

POP is a really ancient featureless protocol.  You really ought to be considering something better.

Hi ,

Thanks ED for your reply.

i have checked the affected pop client authentication settings (user name and password) and it is correctly set on the client machine.

please have a look in to the below mentioned article especially the reply which is given by  "David Whitehead"  .Why i am mentioning is we are also facing the same issue as stated on David's reply. 

http://community.spiceworks.com/topic/81359-accounts-lockout-but-password-never-expires-is-enabled

While connecting to exchange through pop ,If the client is using the wrong credentials or user name then please tell where i can find those details and i don't want to check it on Email client end because the user name and credential settings are correct ? In protocol logs i can found only the user name and not password utilized by the client during the pop connectivity ?

Once the account is locked out ,on the client end we are getting the below mentioned error message.

Hi All,

Any help on this case .Got stuck up .

I'm going to say it one more time:  Disable POP for this user's mailbox until he figures out what's wrong with his client.

Please note that opening POP to the Internet just invites a denial of service attack or password hacking attempts.

hi Nithya, I hope there is no issue due to credential manager, may be the cached password causing this issue, have you checked it before?

Hi ,

We have checked that too .

If the pop is enabled for a account then it is getting locked in active directory.At the same time we have checked the user name and the password and it is mentioned correctly on the client end.

Below is the error message which we have took it from the pop protocol logs.

Error Message : 

R="-ERR Logon failure: unknown user name or bad password."";Msg=LogonFailed:LogonDenied"

Hi Magudeeswaran ,

Thanks for your reply.

None of the passwords was stored on the credential manager.

Hi ,

Any help on this case ?

Hi,

The key of this question is who or which attempted wrong username and password to login AD then trigger account lockout policy.
As you mentioned, it happened in CAS server. Then we need to analyze the IIS log to find who did it.

Heres an similar blog about The case of the mysterious account lockout coming from Exchange, through analyze IIS log and find the root of the problem. For your reference:
http://blogs.technet.com/b/instan/archive/2009/09/08/the-case-of-the-mysterious-account-lockout-coming-from-exchange.aspx
 
Thanks

Hi Allen ,

Thanks for your reply .Definitely i will have a look in to the iis logs.

My question is why the pop accounts from internet is making the bad password attempts via cas server even though the pop clients are mentioned with the correct user name and password  ?

POP doesn't go through IIS.  You'll need to enable protocol logging for POP and look at those logs.

https://technet.microsoft.com/en-us/library/aa997154%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396

You won't want to leave logging on for long unless you have an enormous drive.

Hi.

You may want to run the following steps to isolate the issue whether it is FE-facing, FE-BE or is it BE-AD interactions?

Assuming involving POP3 and not POP3s (if with POP3s, test accordingly using something like openssl s_client -connect server:port)

1. Do a POP3 connection to the FE server using telnet (using valid username/password) and verify that the POP3 session is in order. Do this test from the FE's LAN network as well as from the Internet (just in case there's some sort of POP3 Proxy mid-way) and compare the Banner/Return values displayed.

- If possible, test using the account that was commonly locked out.

######## !!! PRIVACY ALERT !!!! ########

2. Run (for a while) a packet sniffer (using tcpdump , wireshark etc) on the FE and verify if the client's sent username/password is in fact correct. (if using POP3s you will need the FE's certificate Private Key to decrypt the SSL session) - this is only relevant if you're using Basic authentication of course. You will probably have to wait accrding to the clien't POP3 sync schedule :)

- You would probably want to exclude and filter-out all other non-POP traffic from the sniff.

################################

3. While sniffing you may want to confirm the source IP addresses of POP3 connections are actually coming from your clients and not from unknown sources. Based on your previous logs, you may want to set up the sniffing at the most often time the issue happened.