Account Blog

So last week at MEC I held 2 sessions on Authentication prompts. I was actually amazed that the room was a full as it was. And most people indicated they have had some sort of problems with prompts. So I decided I needed to follow-up with a blog post about the possibilities of fixing this and how to trouble shoot the problems. Let me start by saying there are 2 key elements to this that must be in place before trouble shooting any of the prompt issues. You must have Kerberos implemented fully for exchange. Do not assume that it is make sure it is. Kerberos does not work in a Load balanced Exchange environment without specific configurations. Ross Smith has a great article explaining why this is important. It is located here http://blogs.technet.com/b/exchange/archive/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients.aspx

Second piece is you must have NTLM setup for your outlook anywhere deployment. If you have not set this up then all bets are off. Understand the only way to setup NTLM for outlook anywhere is to used Kerberos Constrained Delegation (KCD) which means your TMG has to be a member of the Domain. If you have not configured these 2 then there is no guarantee (actually there are never any guarantee’s because all environments are different) that we can setup an environment that will not have some prompts. But I will try to show you the area’s to check to see if you have everything else setup in a way that will limit the number of prompts. So all I can really say is that we can decrease the number you are having.

So lets look at what can cause and authentication prompt and when it might occur. It is important to find out when it happens because that generally will give you some indication of the possible problems. I will also suggest you become very familiar with the following tools.

· Connection status

· Test Email autoconfiguration

· NSLOOKUP

· www.digicert.com/help

· http://testexchangeconnectivity.com

· Web browser

Back to what can cause an authentication prompt.

• RPC Connections
• IIS
• Autodiscover
• EWS
• Active sync
• OAB
• Outlook Anywhere
• ECP
• OWA
• Puplic folders
• Improperly configured certificates

I question putting in ECP and OWA because you will only receive a prompt from them when you specifically go to the URL and the client will not use OWA or ECP but yes they can cause a prompt. So we have to start with Autodiscover since that is the first thing outlook or Lync does when it starts. At least for the most part.

Autodiscover is handled by the following methods

Service connection Point (SCP) this is only for Domain Joined Computers and they have to have access to a Domain controller for this to work. To find out what your SCP points are set to simply open Exchange Management Shell and type get-clientaccessserver |fl Name,*uri*,*scope* as you can see below. All of the ones in this test environment are not uniform. And they all have the server name listed. So in this environment if I follow best practices and do not put the Server name in the cert, I will receive a certificate prompt. Best practice would be for me to change all the AutodiscoverServiceInternalURi to be the same url https://email.contoso.com/autodiscover/autodiscover.xml. NOTE: this is not my Client Access Array name.

[PS] C:\Windows\system32>Get-ClientAccessServer |fl Name,*uri*,*scope*

Name : EXCH200701

AutoDiscoverServiceInternalUri : https://exch200701.contoso.com/Autodiscover/Autodiscover.xml

AutoDiscoverSiteScope : {Default-First-Site-Name}

Name : EXCH200702

AutoDiscoverServiceInternalUri : https://exch200702.contoso.com/Autodiscover/Autodiscover.xml

AutoDiscoverSiteScope : {Default-First-Site-Name}

Name : EXCH10M01

AutoDiscoverServiceInternalUri : https://exch10m01.contoso.com/Autodiscover/Autodiscover.xml

AutoDiscoverSiteScope : {KC}

Name : EXCH2010M02

AutoDiscoverServiceInternalUri : https://exch2010m02.contoso.com/Autodiscover/Autodiscover.xml

AutoDiscoverSiteScope : {KC}

Name : EXCH2010M03

AutoDiscoverServiceInternalUri : https://exch2010m03.contoso.com/Autodiscover/Autodiscover.xml

AutoDiscoverSiteScope : {Florida}

NON Domain Joined computers or external connections

If the client can’t reach the SCP record on the DC then the client will look for the following in the following order:

· Local xml

· Https://smtpdomain.com/autodiscover/autodiscover.xml

· https://autodiscover.smtpdomain.com/autodiscover.autodiscover.xml

· HTTP Redirect method

· SRV Record Query

Why does the order matter to me? Well that is a good question. If by chance I have a company that has a web site and they have configured that web site to use a certificate so it now accepts HTTPS requests my client will hit there first. If by chance the certificate does not have smtpdomain.com in the SAN list then my outlook client will pop a cert error. But my Lync client will pop an Authentication prompt. So in every environment I always test to see what https://smtpdomainname.com/autodiscover/autodiscover.xml actually brings up. If it is not a 404 page not found then I can garuntee your client will have some issues it may be intermittent because autod information is cached. However I am betting you would have a problem creating a profile while off the network or not joined to the domain if that URL is responding to requests. Remember if you are on a domain joined machine it should not prompt and it should not show a certificate error.

Many companies have started this advertising thing where when you do not find a page for the company web site they apologize to you and show some cool picture and then help redirect you back to the real home page. This can cause all kinds of problems and it should not respond for autodiscover/autodiscover.xml. This affects the Lync client often. More often than most realize.

I will start on the next blog post shortly there is just too much information to put in a single post. More to come over the next 2 weeks. My intent is to provide more information about these specific challenges. I plan on putting in more information about Load balancing as well.