We experienced some significant problems with Live ID earlier this week that was eventually traced to a bad Live ID logon in the CRM email router. The Live ID team has recently added some additional security logic to their service that will block all authentication from an IP address that exceeds a high threshold of failed logon attempts. Most corporations use a firewall that proxies all outbound web requests over a single IP address. This means that if you reach those thresholds, no user in your organization will be able to authenticate using Live ID, effectively locking you out of all Live ID-based applications such as CRM Online, Windows Azure Management Console, CustomerSource and PartnerSource websites, the MPN website, and Hotmail. The root of my problem is that the CRM Email router does not have an internal authentication failure threshold and will continuously try to reauthenticate until you change the credentials that it uses. The Live ID team showed me a report where I had 150,000 bad logon attempts from my IP address in a single day.
The symptom that the end user will see is that when they try to log onto Live ID, they will be presented with an additional Captcha challenge. They will attempt to use the captcha screen to authenticate probably about 3 or four times, with the first three wondering if they got the extremely cryptic captcha answered correctly or if they are perhaps not really humans. When that Live ID threshold is reached, you don't get a message stating that the threshold is reached - you keep getting prompted for captchas until you just give up.
The resolution is to track down which application in your network is causing the issues. To do that, start by using nslookup and look up all IP addresses for the doman name login.live.com. Since this traffic is SSL, you have to use the IP addresses and just look for outbound https sessions to any of the addresses. You should be able to spot the activity pretty quickly. From there you can locate the internal machine that is responsible for that activity then use netstat to identify the process. If it has the CRM Email Router installed, I would start by validating all of the Live ID logons in use.
The moral of the story is that Live ID is really not good for business authentication. I was unable to get support through standard channels and had to resort to some gracious people who picked up an email of mine on the Azure MVP alias and forwarded it to the Live ID team on my behalf. Those guys were super and helped me identify the problem quickly. I was unable to open a ticket with partner support nor have a case escalated because it is Live ID not CRM or Azure that was failing. I had one heated argument with a support person who stated that the problem was a misconfiguraiton of my network because Live ID works from another location for me - I was not able to get him to accept that the problem was probably a security block in Live ID. If you are using CRM Online, I highly recommend that you use the version of CRM Online that is associated to an Office 365 subscription. At least with that you can federate with your own domain and have full control of user authentication.
If you are running the CRM Email Router in your network and routing CRM Online emails, I would highly recommend that you put that on a machine that is using a separate IP address than your standard outbound proxy so that any blockages from that device will not affect the rest of your network from using Live ID services. I also highly recommend that you disable password changes on any Live ID account that you use with the CRM Email router until such a time as Microsoft fixes the authentication bug that can trigger the Live ID block.
