Solved

Password Prompt for Exchange Connected Outlook 2007 client using Outlook Anywhere off the domain

Posted on 2007-11-14
9
37,809 Views
Last Modified: 2011-02-25
I've finished setting up Exchange 2007 and everthing works great with one exception.  I'm having a problem with Outlook 2007 clients specifically on computers that are not members of the domain.  It conistently prompts to enter the password everytime Outlook is opened.  I have Outlook 2003 clients that this is not a problem with once I do the registry hack to change "Incompatibilitylevel" to 3.  However, this doesn't help with Outlook '07.  I've tried every combination of security settings between Outlook and IIS and Exchange Management Console to no avail for both NTLM and Basic.  I've confirmed that settings were consistent across all applications but I can't shake this.  I do not have an ISA server and it isn't a firewall problem because my Outlook '03 clients work fine.
0
Comment
Question by:cdrichla
9 Comments
 
LVL 12

Accepted Solution

by:
bhnmi earned 250 total points
Comment Utility
On the advanced tab in user accounts in the control panel you can assign credentials for specific severs.
0
 
LVL 104

Expert Comment

by:Sembee
Comment Utility
Personally I don't see this as a problem. If the clients are not members of the domain then they need to authenticate. Outlook usually relies on the workstation to provide the security and access, but on a workgroup machine that isn't possible. If you are allowing your users to save the password then you are more trusting than I am!

Simon.
0
 
LVL 12

Expert Comment

by:bhnmi
Comment Utility
I woulnt save the password personally... But it is a fix if his users are not security minded. I am sure everyone here has had problems explaining security to people.. they want it but dont want to go through the motions.
0
 

Author Comment

by:cdrichla
Comment Utility
These users are are outside sales reps that are never connected to the domain except for access to Exchange.  Their Windows logins are secured with complex passwords and locked down pretty well.  Their Windows credentials match their Exchange "Domain" accounts, so they would essentially be logging in with the same credentials twice.  That raises a question though about hosted Exchange.  How do all these hosted Exchange SPs integrate with companies that have systems that are part of a different domain than the hosted Exchange AD domain?  Same situation right?

BTW... the first suggestion worked just fine.  Thanks...
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:cdrichla
Comment Utility
I actually found the solution.  You can add permanent login credentials to the user account in Windows within the XP or Vista user account maintenance.
0
 
LVL 1

Expert Comment

by:modus_operandi
Comment Utility
Force accepted.
modus_operandi
EE Moderator
0
 

Expert Comment

by:KKOS-KS
Comment Utility
Greetings, I hope my comment after-the-fact is of some use and helps a few folks 'not' re-invent the wheel, LOL...

The complete solution I found for the issue of 'continuous password prompt' was an assembly of each of the following steps in their entirety and in the sequence below. Like many others, I had dinked with IIS authentication settings with different combinations of Windows Authentication and Basic Authentication on the various Virtual Directories used by Exchange 2007 after enabling Outlook Anywhere on the server-side and began testing. This process was the only one that has worked successfully, with consistent/desired results. One desired result was the elimination of the periodic password prompt when launching Outlook 2007 configured with Outlook Anywhere, externally. The first attempt to address this was by changing authentication on only the RPC Virtual Directory, which resulted in locally connected (domain member) Outlook clients getting prompted for password. Growing weary of an evening, I made the error of changing too many authentication settings in IIS without notes in which to back-track on my changes. This resulted in a connectivity MESS.

The Outlook Anywhere 'enable' dialog in the Exchange Management Console offers only NTLM 'or' Basic Authentication (not both) and I believe it is this fact alone that was causing the seemingly mixed results I was getting with password prompting, both with local Outlook clients and external clients that were configured with Outlook Anywhere. I should not that the end-user 'not' being prompted for password on non-domain member machines is of little consequence in my judgement because this is also typical of a home user with a POP3 account configured with settings that are inherently saved in the first place. Is is this type of user that Outlook Anywhere/RPC over HTTP is aimed at anyway, right? When a computer is stolen, for example, it might be prudent to change passwords anyway, rendering the account in question inaccessible, etc etc...

A valid SSL UCC/SAN certificate with a common name of SMTP.INTERNETDOMAIN.COM is properly enabled on our Exchange server - for all services (IIS, SMTP, IMAP, POP3, UM) and includes SAN records for:

LOCALSERVER1
LOCALSERVER1.INTERNALDOMAIN.LOCAL
LOCALSERVER2.INTERNALDOMAIN.LOCAL
AUTODISCOVER.INTERNETDOMAIN.COM

LOCALSERVER1 is our solitary Exchange 2007 SP1 server running on Server 2008 x64 Standard Edition.

...it was recommended by GoDaddy support that one should have a SAN record for BOTH the Exchange server's machine-name AND its FQDN - onto which the certificate is being applied, to avoid documented issues with Unified Communications and more. Useful tidbit. Also note that you MUST use a SAN of AUTODISCOVER - as I found out the hard way when I had initially configured my domain A Host record of AUTODISCOVERY, instead. After editing the host record I had to obtain a re-keyed/re-issued certificate with the correct entries and go through the process of re-applying it.

The first step is to DISABLE the Outlook Anywhere feature in the Exchange Management Console, in Server Configuration/Client Access. Allow a few minutes for the changes to take place in IIS and possiblly - restart the IIS Admin service after a few minutes, too.

The second step needed is to begin straightening out IIS authentication and subsequently getting it all to work is to reset the default settings for ALL Exchange-related Virtual Directories in IIS back to their rock-stock default settings. The following document was key and should be followed to the letter. In my case, one machine serves as both the Client Access Server and Mailbox Server role.

This document was followed literally with close attention paid to the combination of authentication settings specified in the table, be it anonymous, basic, integrated - in the right combinations - They must all be set exactly as written:

http://msexchangeteam.com/archive/2008/02/01/447989.aspx

After restoring the proper authentication settings for each of the Exchange IIS Virtual Directories, re-enable the Outlook Anywhere feature, select your external FQDN when prompted by the wizard, and select NTLM authentication.

Next, open the Exchange Management Shell and execute the following CMDLet to note the ClientAuthenticationMethod and IISAuthenticationMethods values:

get-outlookanywhere | fl

IISAuthentication method can be observed set to NTLM authentication.

Next, execute the following command to set BOTH Basic and NTLM authentication for IIS:

get-outlookanywhere | set-outlookanywhere -IISauthentication basic,Ntlm

Now, execute the following command again to observe BOTH Basic and NTLM authentication enabled for IIS:

get-outlookanywhere | fl


Both locally connected Outlook clients and external clients configured with Outlook Anywhere should no longer prompt for authentication following their initial setup.

Note that both external and internal URL's must be configured properly for each element of Exchange in the first place, including the Public folder, OWA, OAB, etc.

Configuration settings that were generated with Outlook 2007 can be used to setup Outlook 2003 clients without Autodiscover (manual configuration of RPC over HTTP) by observing the account settings for your Outlook 2007 mail profile in the control panel and using them for your Outlook 2003 clients to avoid pitfalls with the older version.


0
 

Expert Comment

by:syediq
Comment Utility
I work as IT system consultant and have many Exhange using companies as my customers. A few of them had this problem. Seeing through all the suggestions here, some of them are correct for their problem. But i wanted to post here to explain something very important.

I solved this issue where i had checked everything stated here, pluss more. From the symptoms i always thought it was some autodiscover issue, and that it had to be related to authentication.

Here is a worklist of what you need to check if you have this issue. See abowe post for more details on each step.

1. Make sure that your SSL certificate is working. Test Outlook Web Mail. If SSL is working as intended go to step 2.

2. Check all internal and external URL. Also the SCP (Get-ClientAccessServer | fl)

3. Verify if you get a result from https://mail.domain.com/autodiscover/autodiscover.xml  (swap mail.domain.com with your AutoDiscoverServiceInternalUri - see step 2.).

4. Dobbel check that you got Windows authentication = enabled, on the Autodiscover site in IIS. Also the main fix for my issue was to ensure that under advanced settings of Windows Authentication you have kernel mode authentication enabled!!! On my customers server it was off. And it was standard install with no modifications in IIS.

Hope this helps those that still struggle with this issue.

0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Disabling the Directory Sync Service Account in Office 365 will stop directory synchronization from working.
Exchange server is not supported in any cloud-hosted platform (other than Azure with Azure Premium Storage).
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now