locked
Cannot login to OCS remotely RRS feed

  • Question

  •  

    I have setup an EE server and consolidated Access Edge Server.  Clients can login from the internal network but not remotely.  I can telnet to port 5061 externally to the AES fqdn.

     

    When I enable logging on the OC07 client, here is what event viewer shows.  The cert checks out with the correct FQDN.  LCSerror does not come back with a match for the validation error below. 

     

    Any help would be greatly appreciated.

     

    Event Type:    Error
    Event Source:    Communicator
    Event Category:    None
    Event ID:    5
    Date:        2/21/2008
    Time:        6:07:46 PM
    User:        N/A
    Computer:    D50WC891
    Description:
    Communicator could not connect securely to server
    im.corp.company.com because the certificate presented by the server was not trusted due to validation error 0x80ee0065.  The issuing certificate authority (CA) for the server's certificate may not be locally trusted by the client, the certificate may be revoked, or the certificate may have expired.
     
     Resolution:
     A tool like winerror.exe from the Windows Resource Kit or lcserror.exe from the Office Communications Server Resource Kit can be used in order to interpret the error code listed above.  If you trust the server certificate, the issuing certificate authority (CA) certificate can be placed in the local trusted root certificate authorities certificate store.  If you have logged into the server before without issues the network administrator should carefully examine the certificate if no known configuration changes have been made.

    For more information, see Help and Support Center at
    http://go.microsoft.com/fwlink/events.asp.


    Event Type:    Error
    Event Source:    Communicator
    Event Category:    None
    Event ID:    3
    Date:        2/21/2008
    Time:        6:07:46 PM
    User:        N/A
    Computer:    D50WC891
    Description:
    Communicator was unable to resolve the DNS hostname of the login server ocspool01.corp.dom.
     
     Resolution:
     If you are using manual configuration for Communicator, please check that the server name is typed correctly and in full.  If you are using automatic configuration, the network administrator will need to double-check the DNS A record configuration for ocspool.corp.dom because it could not be resolved.

    For more information, see Help and Support Center at
    http://go.microsoft.com/fwlink/events.asp.

    Friday, February 22, 2008 3:09 PM

Answers

  • Yes, this has been resolved.  The problem was the external cert not having the Certificate Distribution Point attribute.  Basically what it boiled down to is us not purchasing the correct SSL cert.  We had purchased an SSL123 cert and we needed a Web Server Cert.
    Wednesday, March 5, 2008 8:00 PM

All replies

  • If you are using a local CA to issue your certicates, make sure that your external client has your local CA certificate chain trusted.  Also double check that your internal interface on the edge server has a valid certificate and that the FQDN on the cert matches what you have configured on the Front end server.


    Friday, February 22, 2008 4:28 PM
  • The CA for the public facing interface on the Edge server has a Public CA cert.

    Why would the internal interface on the Edge Server have the FQDN of the FE server?
    Friday, February 22, 2008 4:32 PM
  • sorry, guess that was kind of vauge.  I meant make sure that your cert name fqdn on the internal edge interface is the same as what you have configured in the edge servers tab of the forest level OCS properties configuration.


    Friday, February 22, 2008 4:50 PM
  • It is configured the same in the cert and the OCS properties.
    Friday, February 22, 2008 4:57 PM
  • Also, on the SIPSTACK tracing I'm doing on the Edge Server I'm getting the following:

    The connection from a remote user client is refused because remote user access is disabled

    I've checked and remote user access is enabled on the Edge Server and on the User.

    Thanks for your help!
    Friday, February 22, 2008 5:07 PM
  • I was getting this error at one point too during my battle with my first edge server deployment, have you created the _sip._tls.<domain.com> service record and the sipexternal.<domain.com> A records in DNS?  As a test you could manually point the client to your edge server over port 443, ie ocsedge.domain.com:443





    Friday, February 22, 2008 6:38 PM
  • My sipexternal.domain.com is a CNAME record pointing to the A record for external FQDN of my edge server.
    _sip._tls.domain.com is a SRV records pointing to port 443 of the external FQDN of my edge server.
    Friday, February 22, 2008 7:08 PM
  • Have you checked the tracing logs from the OCS client?  That will have a lot more information in it than what is put into the event viewer.

    Something else to check - open the properties of the server from within the OCS admin console and look at the general tab.  On the lower half there is a Connections section - it should have All Addresses and port 5061 selected using MTLS.  As a test you can also try adding All addresses listening on port 5060 using TCP, but I wouldn't recommend using that configuration as it is not secure.

    Also, I know I asked about the certificates but I had a bear of time getting them just right - I would go through and double and triple check all your edge server configurations with the issued certificates to make sure they all line up. 

    Good luck, it can be a PITA

    -Joe
    Friday, February 22, 2008 7:29 PM
  • I'm using the 05 Client for testing this, as it's suppose to work before enhanced presence is enabled...and indeed I have the client logging on, but there are no errors in the client log.

    I checked the General tab setting and that is what it reads, ALL 5061 MTLS.  I've checked the certs over and over again and they are matched.

    Thanks for your help!
    Friday, February 22, 2008 7:51 PM
  • Well this is the only "error" that I'm getting now....this is from the OCS Logging Tool SIPSTACK tracing.

    TL_INFO(TF_CONNECTION) [1]08C4.08C8::02/22/2008-21:14:25.937.00000e2f (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(161))$$begin_record
    LogType: connection
    Severity: information
    Text: TLS negotiation started
    Local-IP: IP1:5061
    Peer-IP: IP2:1337
    Connection-ID: 0x5500
    Transport: TLS
    $$end_record


    TL_ERROR(TF_SECURITY) [1]08C4.08C8::02/22/2008-21:14:26.046.00000e3c (SIPStack,SIPAdminLog::WriteSecurityEvent:1224.idx(431))$$begin_record
    LogType: security
    Text: The connection from a remote user client is refused because remote user access is disabled
    Result-Code: 0xc3e93d6d SIPPROXY_E_CONNECTION_EXTERNAL_INTERNET_ACCESS_DISABLED
    Peer-IP: IP2:1337
    Peer: IP2:1337
    $$end_record

    Friday, February 22, 2008 8:53 PM
  • Are you using a GoDaddy UC Cert?

     

    Friday, February 22, 2008 8:57 PM
  • We are using a Thawte SSL123 Cert on the external edge, an internal cert on the internal edge and an internal cert on the internal interface on the FES.

    The edge server has the certification path to the internal CA.
    Friday, February 22, 2008 9:05 PM
  •  

    Did you ever try manually pointing your client to ocsedge.domain.com:443?  Also do you have a valid A record for ocspool01.domain.com?  I see above in the client log that it was having issues resolving that.
    Monday, February 25, 2008 1:32 PM
  •  Josef Hanning wrote:

     

    Did you ever try manually pointing your client to ocsedge.domain.com:443?  Also do you have a valid A record for ocspool01.domain.com?  I see above in the client log that it was having issues resolving that.


    I attempted to point the client to port 443, nothing changed.  Also, yes there is a valid a record for the pool internally that the edge server does resolve via it's internal interface.
    Monday, February 25, 2008 3:17 PM
  •  

    This is really a bugger of a problem.  Sorry if i'm asking obvious questions, just trying to rule everything out Smile

     

    For your certificate, are you using 1 certificate for all external and internal interfaces, or are you using separate certificates?  The only other thing I can think of to look at is verifying that your public interface certificate(s) has all the correct SANs associated with it.  Can you pull the SAN list out of the certificate details and post it?

     

     

    Monday, February 25, 2008 3:38 PM
  •  Josef Hanning wrote:

     

    This is really a bugger of a problem.  Sorry if i'm asking obvious questions, just trying to rule everything out

     

    For your certificate, are you using 1 certificate for all external and internal interfaces, or are you using separate certificates?  The only other thing I can think of to look at is verifying that your public interface certificate(s) has all the correct SANs associated with it.  Can you pull the SAN list out of the certificate details and post it?

     

     



    I don't mind the questions!

    The certs are as follows:

    External Edge Interface - Thawte cert
    Internal Edge Interface - Internal CA cert
    EE Pool - Internal cert

    No SAN's are being used.
    Monday, February 25, 2008 6:52 PM
  • Ok, I think that's your problem.  Your external edge interface needs to have the following SANs associated with it:

     

    sip.domain.com

    sipexternal.domain.com

    ^These have to be as they are above

     

    webconf.domain.com

    audiovideo.domain.com

    edge.domain.com

    localserver.domain.com

    ^These names have to be whatever you have assigned in the edge server configuration wizard. 

     

    I found that it was easiest to just tack on the role of each SAN to the end of ocsedge, so my entries were:

     

    ocsedgewc.domain.com

    ocsedgeav.domain.com

    ocsedge.domain.com

     

    Localserver is the local server's actual name.

     

    You will have to request a new certificate with these SANs for it to work properly. 

     

    Cheers,

     

    Joe

    Monday, February 25, 2008 7:25 PM
  •  Josef Hanning wrote:

    Ok, I think that's your problem.  Your external edge interface needs to have the following SANs associated with it:

     

    sip.domain.com

    sipexternal.domain.com

    ^These have to be as they are above

     

    webconf.domain.com

    audiovideo.domain.com

    edge.domain.com

    localserver.domain.com

    ^These names have to be whatever you have assigned in the edge server configuration wizard. 

     

    I found that it was easiest to just tack on the role of each SAN to the end of ocsedge, so my entries were:

     

    ocsedgewc.domain.com

    ocsedgeav.domain.com

    ocsedge.domain.com

     

    Localserver is the local server's actual name.

     

    You will have to request a new certificate with these SANs for it to work properly. 

     

    Cheers,

     

    Joe



    That's what I thought as well, however, the same can be accomplished with CNAME records that point to the FQDN of the external edge server interface.  That's the reason I didn't go with a SAN cert.   I could be wrong here, but the OCS Edge Server Documentation Guide says the following:

    Table 5 DNS records for the single-site edge topology

    Interface

    Server

    DNS Settings

    External

    Collocated Access Edge Server and Web Conferencing Edge Server

    An external SRV record for all Access Edge Servers for _sipfederationtls._tcp.<domain>, over port 5061 (where <domain> is the name of the SIP domain of your organization). This SRV should point to an A record with the external FQDN of the Access Edge Server. If you have multiple SIP domains, you need a DNS SRV record for each domain. This SRV record supports federation and public IM connectivity.

    A DNS SRV (service location) record for _sip._tls.<domain>, over port 443 where <domain> is the name of your organization’s SIP domain. This SRV record must point to the A record of the Access Edge Server. If you have multiple SIP domains, you need a DNS SRV record for each domain. This SRV record supports external user access through Office Communicator and the Live Meeting client.

    Note: Configuring multiple SRV records for the same SIP domain is not supported. If multiple DNS records are returned to a DNS SRV query, the Access Edge Server will always pick the DNS SRV record with the lowest numerical priority and highest numerical weight.

    For each supported SIP domain in your organization, an external DNS A record for sip. <domain> that points to the external interface of the Access Edge Server and resolves to the external IP address on the firewall. If you have multiple SIP domains, you need a DNS A  record for each. If a client cannot perform an SRV record lookup to connect to the Access Edge server it will use this A record as a fallback.

    An external DNS A record that resolves the external FQDN of the Web Conferencing Edge Server to its external IP address.

    A/V Edge Server

    An external DNS A record that points the external FQDN of the A/V Edge Server to its external IP address. This IP address must be a publicly routable IP address.

    Reverse proxy

    An external DNS A record that resolves the external Web farm FQDN to the external IP address of the reverse proxy. The client uses this record to connect to the reverse proxy.

    Internal

    Collocated Access Edge Server and Web Conferencing Edge Server

    An internal DNS A record that resolves the internal FQDN of the collocated Access Edge Server and Web Conferencing Edge Server to its internal IP address.

    A/V Edge Server

    An internal DNS A record that resolves the internal FQDN of the A/V Edge Server to its internal IP address.


    Monday, February 25, 2008 10:49 PM
  • All that is correct as far as DNS is concerned, but your certificates still need to have the DNS names as SANs for the MTLS authentication.  If the referring DNS name in the TLS packet is not listed on the certificate, then the server will think it is a bogus packet and will not allow the traffic.  I went through this with MS when setting up my edge server.  If you don't have the proper SANs for your external interface certificate, the server will not accept any connections. 

     

    OCS 2007 is very finicky with certificates, if you have any one piece mis aligned, it will all go to c rap. 

    Monday, February 25, 2008 11:59 PM
  •  Josef Hanning wrote:

    All that is correct as far as DNS is concerned, but your certificates still need to have the DNS names as SANs for the MTLS authentication.  If the referring DNS name in the TLS packet is not listed on the certificate, then the server will think it is a bogus packet and will not allow the traffic.  I went through this with MS when setting up my edge server.  If you don't have the proper SANs for your external interface certificate, the server will not accept any connections. 

     

    OCS 2007 is very finicky with certificates, if you have any one piece mis aligned, it will all go to ***. 



    Please tell me your kidding....(I know your not!)

    Anyway, is this documented ANYWHERE in the OCS Deployment Guides?

    Thanks again for your assistance with this.  Anyone know of a vendor providing trial SAN certs?

    -Art
    Tuesday, February 26, 2008 12:03 AM
  • Art,

     

    For your sake I wish I was kidding but unfortunately I'm not.  I'm actually having issues getting a public DoD cert now too with all my required SANs because they normally do not to that (we are currently just supplying the CA Cert Chain for our internal CA to external clients)

     

    I would think that any major certificate authority would provide you with SANs on your certificate, it's not a new thing after all.  If you cannot get Thwat to issue you a cert with multiple, look into Verisign.

     

    Good luck!

     

    -Joe

     

    ps - I'm at home now and all my OCS docs are at work, I'll look through tomorrow for the references, but i had the luxury of some very smart MS personel helping me when i setup my Edge server.

    Tuesday, February 26, 2008 12:11 AM
  •  

    Before you re-issue any certs or do anything make sure that the Thawte root cert that you are using have "All Purposes" enabled on its properties. The two Thawte root certs do NOT have this enabled by default and will create a major headache. Give this a try. Good luck

     

    Mark

    Wednesday, February 27, 2008 12:13 AM
  •  

    Any updates on your issue?
    Wednesday, March 5, 2008 7:45 PM
  • Yes, this has been resolved.  The problem was the external cert not having the Certificate Distribution Point attribute.  Basically what it boiled down to is us not purchasing the correct SSL cert.  We had purchased an SSL123 cert and we needed a Web Server Cert.
    Wednesday, March 5, 2008 8:00 PM