none
Only connect to proxy servers that have this principal name in their certificate

    Question

  • Hi All ,

     

    I issued a certificate with 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 exchange restores the option ? or in alternative is there a way to let outlook

    work with that option selected ?

     

    Regards,

    Eric.

    Monday, November 26, 2007 8:18 AM

All replies

  • Did you ever resolve this?  We have the same issue.
    Thursday, December 6, 2007 7:56 PM
  • 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..

    Tuesday, December 18, 2007 5:00 AM
  • 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"msstdTongue Tiederver.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




    Tuesday, December 18, 2007 2:24 PM
  • 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 the netbios name?

     

    We want to deploy 4 more exchange servers but need this resolved first.

     


     

    Friday, February 29, 2008 5:28 AM
  • 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?

     

    Friday, February 29, 2008 5:32 AM
  • Any one see a way to keep autodiscover from checking the box that requires teh MSSTDTongue Tiedervename ?

     

    Friday, March 28, 2008 5:31 PM
  • .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.

     

    Thursday, April 10, 2008 12:39 AM
  • 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.fqdn
    Set-OutlookProvider WEB -Server $null -CertPrincipalName msstd:extern.fqdn

    see ma blog http://www.sch0.org/ for detailes
    Wednesday, April 16, 2008 10:49 AM
  • 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


    • Proposed as answer by Minammx Friday, March 13, 2015 9:38 PM
    Friday, May 23, 2008 3:56 PM
  • After running that command does autodiscover still populate the other rpc over https info?

    Friday, May 23, 2008 4:38 PM
  • 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.com

    Connect 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



    Friday, May 23, 2008 5:34 PM
  • I had a similar issue and was able to resolve it by the below command taken from http://forums.msexchange.org/m_1800486200/tm.htm

    set-outlookprovider -Identity EXPR -certprincipalname msstd:*.domain.com

    Instead of

    set-outlookprovider -Identity EXPR -certprincipalname *.domain.com

    Apparently the msstd: is important.


    Suhel Khan
    Friday, December 11, 2009 1:23 PM
  • 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

     

    Friday, April 9, 2010 3:18 AM
  • 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


    Tuesday, August 21, 2012 5:26 PM
  • this solve the problme
    Friday, March 13, 2015 9:38 PM