Only connect to proxy servers that have this principal name in their certificate
Hi All , I issued a certificatewith my local Authority using the following command : New-ExchangeCertificate -GenerateRequest -domainname exchange2007,exchange2007.mydomain1.com,webmail.mydomain2.com,autodiscover.mydomain1.com -privatekeyexportabletrue -path c:\cert_exchange2007.txt Everything went ok. Outlook has been set as follows : Use this URL to connect to my proxy server for exchange : https:\\webmail.mydomain2.com Connect using SLL Only (selected) Auth Method : Basic Now....If i select "Only connect to proxy servers that have this principal name in their certificate" msstd:webmail.mydomain2.com ...Outlook will request the password infinite times even if you enter the correct one. Instead, if i untick the option outlook works correctly. Unticking that option could be a good solution in the end , but sometimes Exchange (Outlook?) restores the option to the original state (Selected + msstd:webmail.mydomain2.com) I gave a look into the console and i didnt find anything about any policy applied to the client. Now,the question is : Is there a way to avoid that exchangerestores the option ? or in alternative is there a way to let outlook work with that option selected ? Regards, Eric.
November 26th, 2007 3:18am

Did you ever resolve this? We have the same issue.
Free Windows Admin Tool Kit Click here and download it now
December 6th, 2007 2:56pm

I am also having this exact issue.. periodically Outlook changes the settings back.. originally we had a wildcard certificate and replaced that with a UC certificate, but the only paramter that works is when using the common name of the certificate as the msstd:commonname.domain.com. Unfortunately, something changes this, autodiscover is my only guess? I can't find any options to change this..
December 18th, 2007 12:00am

We were able to resolve it with Microsoft. Here is what they said... As I understand based on your problem description, the issue you're experiencing is If "Only connect to proxy servers that have this principal name in their certificate" is checked and configured with Code Block"msstderver.domain.com" , Outlook Anywhere users will be prompted for credentials repeatedly. We will work towards solving this specific issue through the course of this service request.If I have misunderstood your concern, please let me know. Once we get it resolved, I'd appreciate your verification. This will allow us to make absolutely sure we have completed the agreed upon incident. I'd explain that this issue may occur when the CertPrincipalName parameter for OutlookProvider is not configured. Therefore, Outlook uses the ExternalHostname parameter for Outlook Anywhere to populate the server name listed after msstd: in the Only connect to proxy servers that have this principal name in their certificate profile setting, so it will be taken as msstd:<internal FQDN of CAS>, which does not match the Issued To Name on the certificate, and users will be promoted for credential repeatedly. To fix this issue, please try the folowing steps. 1. Please run the CMDLet below Code Block Get-OutlookProvider | fl Take a look at the field CertPricipalName. <!--[if !supportLineBreakNewLine]-->2. If the CertPrincipalName is not configured, please run the CMDLet below on CAS server to set it Code Block Code Block Code Block set-OutlookProvider -id EXPR -server "<your CAS FQDN>" -CertPrincipalName "msstd:server.domain.com" -------------------------------- To configure it, please try the following steps 1. Run the CMDLet below Code Block get-OutlookAnywhere | fl Please take a note of the Identity field, for example, "2k7Server\RPC (Default Web Site)"2. Run the CMDLet below Code Block Set-OutlookAnywhere -ExternalAuthenticationMethod:NTLM identity <identity of #1> For example, Code Block Set-OutlookAnywhere -ExternalAuthenticationMethod:NTLM identity "2k7Server\RPC (Default Web Site)" 3. Run the CMDLet below Code Block set-OutlookProvider -id EXPR -server $null After running the three steps above, clients should be configured correctly now.<!--[if !supportLineBreakNewLine]--><!--[endif]-->---------------------------------------------------- Please try the following CMDLet if SP1 has been applied. Code Block Set-OutlookAnywhere -ClientAuthenticationMethod:NTLM -identity "SERVER\Rpc (Default Web Site)" Then run the CMDLet below Code Block set-OutlookProvider -id EXPR -server $null
Free Windows Admin Tool Kit Click here and download it now
December 18th, 2007 9:24am

I posted a similar issue over here http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2925740&SiteID=17&mode=1 and followed the info up above. But my setting are already correct. The question this raises is if the CertPrincipalName "msstd:server.domain.com" needs to match thenetbios name? We want to deploy 4 more exchange servers but need this resolved first.
February 29th, 2008 12:28am

Ok I did a Outlook-provider |fl and saw the only one that has the CertPrincipalName is the EXPR, not EXCH or WEB. Does this matter?
Free Windows Admin Tool Kit Click here and download it now
February 29th, 2008 12:32am

Any one see a way to keep autodiscover from checking the box that requires teh MSSTDervename ?
March 28th, 2008 1:31pm

.We have exactly the same issue where in MS Outlook 2003 the Autodiscover settings mysteriously place a tick in the "Mutually authenticate the session when connecting SSL" checkbox. The Principal name also populates mysteriously with msstd:myserver.domain.com. Our OutlookProvider shows all 3 providers EXCH, EXPR, WEB. However none of them have a server and certprincipalname configured. The autodiscover.xml file was completely empty except for a line where it says ...place holder. We are using Basic authentication. My questions are: do we need to configure server and certprincipalname for all of the 3 providers? How do we do these? Any help will be greatly appreciated.
Free Windows Admin Tool Kit Click here and download it now
April 9th, 2008 8:39pm

I think i got the answer.You have to look at your certificate for the issued to name and put it at the CertPrincipalName.Set-OutlookProvider EXPR -Server $null -CertPrincipalName msstd:extern.fqdnSet-OutlookProvider WEB -Server $null -CertPrincipalName msstd:extern.fqdnsee ma blog http://www.sch0.org/ for detailes
April 16th, 2008 6:49am

I believe I've figured out how to keep Exchange from checking the stupid "Only connect to Proxy Servers that have this Principal Name in their certificate" box.If you set the CertPrincipalName to 'none' it will prevent it from enabling Mutual Authentication. For example:>Set-OutlookProvider EXPR -Server 'site1cas01.company.com' -CertPrincipalName none >Set-OutlookProvider EXPR -Server $null
Free Windows Admin Tool Kit Click here and download it now
May 23rd, 2008 11:56am

After running that command does autodiscover still populate the other rpc over https info?
May 23rd, 2008 12:38pm

It does in my case. A brand new Outlook profile/MAPI profile using Autodiscovered settings now gives me:Connect to Microsoft Exchange using HTTP (checked)Use this URL to connect to my proxy server : site1cas01.company.comConnect Using SSL only (checked)Only Connect to proxy servers that have this principal name in their certificate: (unchecked)On fast networks (unchecked)On slow networks (checked)AUthentication : NTLM
Free Windows Admin Tool Kit Click here and download it now
May 23rd, 2008 1:34pm

I had a similar issue and was able to resolve it by the below command taken from http://forums.msexchange.org/m_1800486200/tm.htmset-outlookprovider -Identity EXPR -certprincipalname msstd:*.domain.com Instead of set-outlookprovider -Identity EXPR -certprincipalname *.domain.com Apparently the msstd: is important. Suhel Khan
December 11th, 2009 8:23am

I had a similar issue and resolved it by forcing the value of the Outlook client setting "Only Connect to proxy servers that have this principal name in their certificate" to the "Issued to" value from the CAS certificate, as described here: http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/a9bfb3d1-892a-4a3c-9884-b87658a4b889 To force the value I used the following Group Policy Administrative template to manage the RPC/HTTP settings for Outlook 2007 clients: Article 961112 Policy Settings Alexei
Free Windows Admin Tool Kit Click here and download it now
April 8th, 2010 11:18pm

I had similar problem: OA was intended to be used from the internet without VPN. VPN is still useful by us to access more critical data. Without VPN everything is ok, it connects to a reverse proxy /ssl offload where the valid certificate (Wildcard) is installed. Once connected internally, if it happens it tries http connection (for instance, a VPN connection with slow link detection if enabled), it will get into a loop of proxy certificate error and authentication attempt. In this case it points directly to the internal exchange server which does not host the wildcard certificate for its IIS services. Solutions: 1. Manage to get a certificate that could be use internally and externally ==> that could not be the wildcard (external domain name does not match internal domain name) ==> not easy if we want a valid one, cert management becomes more difficult 2. Disable certification validation as you describe ==> security guys not happy 3. Force RPC o/ TCP/IP attempt before HTTP even on slow links so in any case it will not use Outlook Anywhere when internal exchange server is available <=> OA is only used from the Internet w/o VPN, thus not going into the certificate mess. You have GPO template that works great for this, also for 2. http://download.microsoft.com/download/F/B/C/FBC43645-89EA-4FB4-828C-DFE27C360233/article-961112.adm http://download.microsoft.com/download/D/B/0/DB080999-71D6-4498-AD42-34873F8DD04B/2426686_template.adm
August 21st, 2012 1:33pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics