For purchasing SSL Certificates please visit: http://www.exchangecertificates.com
There have been a lot of questions recently regarding Outlook prompting for a username and password whilst using Exchange 2007. There are a few reasons why this would happen and I will try to cover the most common ones here.
Exchange 2007 Service Pack
There was an issue with repeated password prompts that was resolved by installing Rollup 9 for Exchange 2007 SP1, however I would recommend that you should now be using Exchange 2007 SP2 since it has been around since August 2009: http://www.microsoft.com/downloads/details.aspx?FamilyID=4C4BD2A3-5E50-42B0-8BBB-2CC9AFE3216A&displaylang=en
If you are in an Small Business Server 2008 environment and not yet using Exchange 2007 Rollup 9 you can also install SP2 for Exchange 2007 with the aid of the Installation Tool, available here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;974271
Autodiscover
If that doesn’t fix the repeated prompt for password then it could be down to the autodiscover if your using Outlook 2007 then you must configure autodiscover correctly. There are many articles out there that cover the correct way to configure autodiscover, one of the better ones I have found is this one: http://www.exchange-genie.com/2007/07/exchange-2007-autodiscover-service-part-1/
However the part that most people are missing is the autodiscover.domainname.com (where domainname.com) is the part after the @ in your e-mail address. Newer versions of outlook will look for this for OAB download, free/busy information, Out of Office etc etc. If it’s not there then outlook will continually give user prompts. To accompany this you must have an SSL Certificate that contains the autodiscover.domainname.com URL (whilst you can configure ways around this, it really isn’t worth all the hastle). So purchasing an SAN/UCC Certificate with the following names in is a must for Exchange 2007 and Exchange 2010:
-
autodiscover.domainname.com
-
owa.domainname.com (the URL used for Outlook Web Access)
-
servername.domainname.local (the internal FQDN of your Exchange Server)
-
SERVERNAME (NETBIOS Name of your Server)
If you have not yet purchased an SSL Certificate I can recommend http://www.exchangecertificates.com/ as a cost effective product that is fully supported.
You must also have the coresponding autodiscover.domainname.com and owa.domainname.com A records configured in your external DNS
Kernel authentication Mode
If you have all the above configured and you are still experiencing problems then the following procedure will more than likely fix it for you. It has been working a lot for me lately and also for people asking questions on Experts Exchange.
In Internet Information Services (IIS) Manager locate the Exchange virtual directories, if you are using Small Business Server 2008 these will be under the SBS Web Applications website, if your not using SBS then they will be under the Default Website.
The virtual Directories you are looking for are:
- Autodiscover
- EWS
- RPC
- OAB
In turn highlight each of these virtual directories and double click the Authentication icon on the right hand side. Right click on Windows Authentication and select Advanced Settings. Place a check box in the box for Enable kernel-mode authentication. Do this for each virtual directory listed above.
Demazter's Blog 
Thank-You Very Much, I found out by following the steps to do with the Kernal Authentication mode, that my remote virtual directory, windows authentication was turned off. So I did enable Kernel-mode authentication for the ones listed, but also enabled windows authentication for the remote directory and voila, fixed it!!!
I’ve spent almost a month on this thing,
Thanks again…
Glad it helped you out.
Thank you for the feedback.
Glen
What a super post, I have been trying to sort this out all week, and the kernal sorted it. thanks again
Glad it sort it out for you, make sure you subscribe to my blog so that you receive future postings 🙂
As my problem started after running updates on the server I was reluctant to update again to SP2. I followed your instructions for changing the Kernel authentication Mode. This worked perfectly. I’ll probably never understand why running the initial updates changed the security as the default should have been ON.
Is it the same for Exchange 2010? I tried to set the Kernel Authentication Mode as described above but no luck. I think Autodiscover is working fine because I was able to set up a user’s Outlook by entering their email address and password. Thanks for any help provided.
Unfortunately this is not the same for 2010. The most common cause of password prompts in Exchange 2010 is invalid SSL Certificate Configuration.
In your SSL Certificate you should have at least the following names:
autodiscover.domainname.com (where domainname.com is the part after the @ in your email address)
owa.domainname.com (your Outlook Web App URL)
servername.domainname.local (The internal Fully Qualified Domain Name of your server)
SERVERNAME (The NETBIOS name of your server)
You need to use the wizard in the Exchange Managent Console to generate the certificate request. And then purchase a UCC/SAN certificate. I can recommend http://www.exchangecertificates.com
Ok, I think I didn’t create the Certificate correctly then. I have:
autodiscover.domainname.com
servername.domainname.com (it’s the same for internal FQDN and OWA)
SERVERNAME (I don’t have this one! :P)
I will check this and update the post.
Thank you!
I think I figured this out. There were some permissions missing on the OAB Web distribution folder. The person before me had attempted to create a segregated environment to host email for multiple companies and he left in the middle of doing so; thus, he never completed the white paper he was going through.
Thanks for your help.
Where do I go to find the SSL Certifcate to see that list
In what way? What are you trying to do?
Good job! You saved me a lot of time. The last part worked for me. Thank you!
[…] Outlook continually prompting for username and password February 201010 comments 3 […]
Thanks for the article. I’d like to share some information regarding a case we’ve just run into and resolved related to credential prompts in Outlook 2010. It appears that if a user has a secondary mailbox configured in their mail profile that no longer exists in Exchange, Outloko 2010 will continue to try to get autodiscover information about that mailbox and enter a really horrible loop of trying to find the CAS server with the autodiscover.xml that it wants, ultimately failing over to the autodiscover.domain.com host, which doesn’t exist when, like us, you are supporting internal Outlook users only. On top of this, if you use a proxy.pac file, Outlook will try to hit the server hosting the pac file every time it fails over presumably because the autodiscover.domain.com host doesn’t exist in DNS. Thought I’d share just in case anyone else runs into this scenario.
Outlook 2007 and 2010 still continually prompt for password. We have migrated all users to exchange 2010 sp1. It is so annoying….Outlook 2010 prompts for password, OCS 2007 R2 also prompts for password.
my certificate (godaddy) doesn’t have the domain.local and netbios name. We have 9 exchange servers.
You must have the local FQDN of your exchange server in the certificate.
It contradicts wtih this:
http://technet.microsoft.com/en-us/library/dd351044.aspx
“Best Practice: Use As Few Host Names as Possible”
The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate’s subject alternative names.
The host names you must include in your Exchange certificates are the host names used by client applications to connect to Exchange. The following is a list of typical host names that would be required for a company named Contoso:
Mail.contoso.com This host name covers most connections to Exchange, including Microsoft Office Outlook, Outlook Web App, Outlook Anywhere, the Offline Address Book, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Control Panel, and ActiveSync.
Autodiscover.contoso.com This host name is used by clients that support Autodiscover, including Microsoft Office Outlook 2007 and later versions, Exchange ActiveSync, and Exchange Web Services clients.
Legacy.contoso.com This host name is required in a coexistence scenario with Exchange Server 2003 or Exchange 2007. If you’ll have clients with mailboxes on both a legacy version of Exchange and Exchange 2010, configuring a legacy host name prevents your users from having to learn a second URL during the upgrade process. For more information about upgrade and coexistence, see Upgrade from Exchange 2003 Client Access and Upgrade from Exchange 2007 Client Access.
Which part are you suggesting is contradictory? As far as I can tell it just confirms what I have posted.
You need to include host names that are used by your clients.
I’ts about individual host names.
You said:
1.
In your SSL Certificate you should have at least the following names:
autodiscover.domainname.com (where domainname.com is the part after the @ in your email address)
owa.domainname.com (your Outlook Web App URL)
servername.domainname.local (The internal Fully Qualified Domain Name of your server)
SERVERNAME (The NETBIOS name of your server)
2.
You must have the local FQDN of your exchange server in the certificate.
Article says:
The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate’s subject alternative names.
Surely if your internal users use internalname.domain.local to access OWA then you need to include this in the certificate?
You may also want to use EWS to access from a 3rd party product, which will also need the internal host name in the certificate.
If its an Internet only CAS server then you don’t need it. If it isn’t, then with the default configuration you do.
Sent from my iPhone
The idea (and best practice) behind this, is to use less names, use split DNS, and use only two (or three)names internally and externally:
1. mail.hostname.com
2. autodiscover.hostname.com
3. Optional if migrating from previuos versions and need some coexistance – legacy.hostname.com
No FQDN, no NetBIOS names in cert’s SAN list. I remember it was recommended for Exchange 2007, but for Exchange 2010. You said it must include FQDN. I refered to Microsoft KB, it is not mandatory and even not recommended.
I said as a default configuration. Split brain DNS is not default configuration.
If you use the wizard in the Exchange Management Console to create a certificate and select for internal use by default it will use the internal FQDN.
I use what I know works, so do literally thousands of others that have found my blogs useful.
Your only purpose seems to cause an argument, I suggest you go somewhere else and do that.
Sent from my iPhone
Sorry for insulting you, my single argument was that your sudgestions contradicts with Microsoft best practices (Best Practice: Use As Few Host Names as Possible
), just that. I am just showing this, it’s relevant to the subject. Split DNS is common practice.
Have I nice day.
Also, what the Microsoft article fails to mention is that the servers internal name must be included in the certificate what setting up UM & CAS Array to name just 2 services that require it.
There are many articles by many Exchange Experts that confirm the content of this blog. I am afraid just because it appears in a Technet article doesn’t make it gospel!
Sent from my iPhone
hi, glad i found your site. i hit a wall when i reached the RPC as when i double-click on the “windows authentication” it is marked as disable. that’s the only one that is disabled so i enabled it and clicked on the kernel mode authentication.
crossing my fingers! =)
[…] Other potential issues can be found on this nice post: https://demazter.wordpress.com/2010/02/09/outlook-continually-prompting-for-username-and-password-2/ […]
awsome info, bookmarking this for sure!
Brilliant thanks, even the geeks at my place didn’t know how to fix this.
Glad to be of assistance 🙂
Hi Demazter,
I checked my SSL config its correct still my outlook 2007 is asking my users username and password.(my exchange is 2010)…
Thanks
Can you post a screenshot of the password prompt box you receive?
So my question is why are these disabled when it says right in the control that they should be ENABLED!!! I’ve only had a few users with this problem but I’ll give it a try. I’m running Exchange 2010 SP1 on 2008R2 SP1. Getting ready to apply Exchange SP2 soon. On the fourth Virtual Dir (OAB) the option to enable kernel auth mode is greyed out. Should that concern me? I sure wish I had found your post when I was first deploying Exchange 2010.
The article is actually related to Exchange 2007. I have not seen this problem with Exchange 2010 and if it’s happening I would suggest it was something else.
Funkin’ Legend!
Enbling Kernel Mode Auth on SBS 08 with Exch 07 SP1 resolves the issue on W7 Pro 64 w/ Office 2010.
Again, you’re a freakin’ legend!
Thanks for posting this info!!!!
Can you tell me if you have to restart Exchange services after enabling kernal authentication?
I don’t believe you do but, to be honest, it will only take a few minutes so if you have made the changes and applied the latest service pack level and you are still experiencing problems restart them.
If you still have problems after the restart then it is likely a completely different issue.
Hello and THANK YOU for taking the time to read this.
Clients run Outlook 2007 and server is Exchange 2007. All users connect via VPN. Any users trying to get email outside the domain use OWA…outside users not having any problems.
Initial issue was that a user would get an error message stating that the server was not available when trying to access Out Of Office or free/busy.
I added autodiscover.domain.com with the exchange server’s internal IP to the user’s hosts file. Now when he tries to access Out of Office or free/busy info, he is prompted to enter his domain credentials. After successfully entering his credentials, Out Of Office and free/busy both work successfully. I almost did the happy dance at this point, but…
New problem is that the user is prompted again if/when they close and reopen Outlook and try to access Out of Office or Free/Busy info.
Does anyone have advice how I could keep the uesrs from getting prompted for credentials each time?