Hello All, I have having issues with a specific user who AD account is being locked out continually. After investigation I have found the source is the Exchange CAS server. The user in question has 2 activesync devices (fully working and in sync). I believe it may be a device which is causing the problem as bad password attempts and lockouts are happening during the night. However the user is unwilling to turn off the devices to determine the source. I would like to determine if the bad password attempts are from OWA, Activesync, Outlook Anywhere etc. Is there logging I can increase which will assist to determine the CAS service causing the problem? Many Thanks Mark

So the user would rather get locked out than help you troubleshoot? If you look in the security logs on the CAS, look for event 4625 which is a logon failure The ip address of the client should be listed in the event details.

Hi, There must be an Account lockout policy in the domain. To verify the source of bad password attempt, you can open IIS log and search the specific account. There is a detail record about the user logon information. To check the IIS log on the CAS server, please refer to the following steps. a. Click "start" -- "administrative tools" -- Internet Information Services b. Right-click "default web site" -- properties c. In "web site" tap, click "enable logging", select log format to "W3C" d. Please reproduce this issue. e. the log will be generated in \windows\system32\logfile\w3svc1\exyymmdd.log Thanks. NovakPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Wrote a job aid for our desktop support team since this happens occasionally. Prereq Confirm with user if password was changed. 1. Determine the number of devices that the user has: a. Laptops and desktops in the domain b. Personal laptops and desktops at home running VPN or Outlook Anywhere c. Mobile devices, iPhone, iPad, BlackBerry, Droids etc 2. Performed by Desktop Support Ensure that the user has updated all the passwords if the password was changed. Re-enter them again regardless of whether the user said they updated it already in case of typos as we've seen. a. Desktop\Laptop: Check for services.msc and see if any services are running under his account and re-enter the password. b. Desktop\Laptop: Check for any scheduled tasks running under his account and re-enter the password. c. Desktop\Laptop: Check for stale stored passwords, control panel, users accounts, credential manager. d. Mobile device: Check if wifi is connecting to the corporate wifi. If not re-enter the password. e. Mobile device: Re-enter the password for the Exchange email account. f. Check if wifi is connecting to the corporate wifi. If not re-enter the password. 3. Performed by Server team Parse the Domain Controller’s security event logs for failed authentication b. Run eventcombmt.exe from C:\Admin\tools\EventComb c. In the white pane under “Select to Search/Right Click to Add” right click in the white pane box and choose Get DCs in Domain. d. Choose Log Files to Search: Select only Security e. Event Types: Select only Success Audit, Failure Audit, Success f. In the Text: Box type the user name jchong g. Scan Back: 2 days h. Click Search, and Click Yes at the dialog prompt Error nothing selected. i. When completed, the results are written to the C:\temp with log files for each DC. Look through each DC and determine if you can find how many devices the user is authenticating from. Notes: Sometimes the user may have a stale terminal server session and if the user changed his password, the stale terminal server session will lock out his account due to Group Policy processing occurring with his stale session on the TS server. Notes: IP’s do not show up for mobile devices. Typically if you see failed authentication attempts with limited info and no IP, it’s usually a mobile device. If you cannot determine where the lockout is originating from. Have the user turn off one device at a time for 15 minutes or just disable his wifi and carrier connection. After the 15 mins re parse the DC logs and see if the authentication failure attempts occur. If they do, turn off the next device and repeat. For activesync failures they happen very frequently, they appear every 2-3 mins in the DC logs so the user doesn't need to disable the device for very long.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Wrote a job aid for our desktop support team since this happens occasionally. Prereq Confirm with user if password was changed. 1. Determine the number of devices that the user has: a. Laptops and desktops in the domain b. Personal laptops and desktops at home running VPN or Outlook Anywhere c. Mobile devices, iPhone, iPad, BlackBerry, Droids etc 2. Performed by Desktop Support Ensure that the user has updated all the passwords if the password was changed. Re-enter them again regardless of whether the user said they updated it already in case of typos as we've seen. a. Desktop\Laptop: Check for services.msc and see if any services are running under his account and re-enter the password. b. Desktop\Laptop: Check for any scheduled tasks running under his account and re-enter the password. c. Desktop\Laptop: Check for stale stored passwords, control panel, users accounts, credential manager. d. Mobile device: Check if wifi is connecting to the corporate wifi. If not re-enter the password. e. Mobile device: Re-enter the password for the Exchange email account. f. Check if wifi is connecting to the corporate wifi. If not re-enter the password. 3. Performed by Server team Parse the Domain Controller’s security event logs for failed authentication b. Run eventcombmt.exe from C:\Admin\tools\EventComb c. In the white pane under “Select to Search/Right Click to Add” right click in the white pane box and choose Get DCs in Domain. d. Choose Log Files to Search: Select only Security e. Event Types: Select only Success Audit, Failure Audit, Success f. In the Text: Box type the user name jchong g. Scan Back: 2 days h. Click Search, and Click Yes at the dialog prompt Error nothing selected. i. When completed, the results are written to the C:\temp with log files for each DC. Look through each DC and determine if you can find how many devices the user is authenticating from. Notes: Sometimes the user may have a stale terminal server session and if the user changed his password, the stale terminal server session will lock out his account due to Group Policy processing occurring with his stale session on the TS server. Notes: IP’s do not show up for mobile devices. Typically if you see failed authentication attempts with limited info and no IP, it’s usually a mobile device. If you cannot determine where the lockout is originating from. Have the user turn off one device at a time for 15 minutes or just disable his wifi and carrier connection. After the 15 mins re parse the DC logs and see if the authentication failure attempts occur. If they do, turn off the next device and repeat. For activesync failures they happen very frequently, they appear every 2-3 mins in the DC logs so the user doesn't need to disable the device for very long. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com Nice write up !