SRV records on external DNS -_sipfederationtls._tcp.domain ???

جميع الردود

• 12/ربيع الأول/1429 06:03 م

  المشرف

   

   
  

  0

  All SRV records (internal and external) need to be located in the domain that matches the SIP URI of the user.  If you have been assigning SIP URIs like user@domain.local and want autologon to work from the internet, you'll need to change the URIs to user@domain.com and publish the appropriate internal and external SRV records.

   
• 13/ربيع الأول/1429 08:20 ص

   

   
  

  0
  Mike, thank you, very much for the reply. I will try this in a day or two and will post the results. I have no doubt that it will work
  
  
  Again, thanks
  
  Andrija
  
   
• 13/ربيع الأول/1429 10:30 ص

   

   
  

  0

  Mike, I would have another question.
  
  Regarding changing SIP URI of the user…

  I would like to ask you for basic steps I need to take. So far I tried the following:

   

  I have created the _sipinternaltls._tcp.domain.local (in domain.local zone)
  

  
  

  and
  

  
  

  _sipinternaltls._tcp.domain.com(in domain.com zone ),

  
  

  both resolve to pool.domain.local

  
  

  I have configured new SIP URI of the user so they use the user@domain.com login scheme.

  
  

  I WILL (still have not) change the certificate for pool.domain.local so that it includes the domain.com as an alternate subject name?

   

  Should this be OK for internal login to work using user@domain.com scheme?

   

   

  Best regards,

   

  Andrija

   
• 29/ربيع الثاني/1429 05:09 م

   

   
  

  0

  Hi,
  
  I have one question regarding SRV records on public DNS server.
  
  Our internal domain is:  ABC.local
  Our external domain is:  XYZ.com
  
  Our clients inside our domain.local network are using Communicator 2007 with autologon without any problems.
  
  
  For the EDGE server, I should create SRV records on public DNS so the external client can login:
  
  Which one SRV record should I create
  :
  _sipfederationtls._tcp.ABC.local
  
  or
  
  _sipfederationtls._tcp.XYZ.com
  
  This is very confusing, because the OCS edge server deployment guides states:
  _sipfederationtls._tcp.<domain>, over port 5061 (where <domain> is the name of the SIP domain of your organization
  
  Is this our internal ABC.local or external XYZ.com ???????????

   

   

   

  RGDS

  SANJAY

   

   
• 29/ربيع الثاني/1429 08:42 م

  المشرف

   

   
  

  0

  Yes, that is typically the intended deployment scenario when using a split-DNS configuration.  Since your users probably already have a primary SMTP address matching your external domain and possibly a UPN in the same domain, they are already accustomed to that format.  Using SIP URI's that match the same format make it easy on the user to adapt to OCS authentication as well.  Just make sure you add the new SIP domain to the OCS configuration correctly, as well as certificate SANs.

   

   
• 01/جمادى الأولى/1429 12:43 ص

   

   
  

  0
  You've already gotten the DNS info you need however it's important to note that you'll need a trusted cert (with appropriate SANs) with the external FQDN on the edge server as well

   

   
• 01/جمادى الأولى/1429 03:36 م

   

   
  

  0

   

  Sorry for hijacking your thread but I'm having the same problem, and rather than fork over the money for a new certificate and potentially break other stuff, I'd prefer to work with what we have.  Can't this security feature be bypassed or could we convince the servers to trust the email domain as well as the AD domain?

   

  Just as above users state, we have email domain users@blah.com, and AD domain blah.local.  The SRV record in blah.com points to the server ocs.blah.local.  Of course this generates a trust error:

  • "Communicator was unable to locate the login server.  The DNS SRV record that exist for domain blah.com point to an invalid server ocs.blah.local which is not trusted to provide support for the domain because the server's domain is not an exact match."

  Changing the SRV record to a new FQDN within blah.com would require us to get a new certificate (from verisign, not our internal CA), and so we see the error:

  • Communicator could not connect securely to server ocs.blah.com because the certificate presented by the server did not match the expected hostname (ocs.blah.com)."

  So to reiterate my question: Any way we can work around the cross-domain issue without changing the domains we're using, without getting a new certificate, and still using TLS? 

   

  Thanks!
  Joe

   
• 01/جمادى الأولى/1429 05:26 م

   

   
  

  0

  ***Found the answer to my question***

   

  You said this above and I just didn't get the terminology, but for others who google their way over here I'll spell it out:  When you create the self signed certificate for your OCS server, there are fields for SANs (Subject Alternate Names), where you put in as many FQDNs as you require (in my case ocs.blah.com and ocs.blah.local), and once that's installed (and you have SRV and DNS records in place) the TLS error goes away. 

   

  Here's a site that illustrates it further:

  http://fawzi.wordpress.com/2008/02/16/configuring-ocs-2007-for-dns-splitting/

   

  Joe

  • تم الاقتراح كإجابة بواسطة M FawziMVP 10/جمادى الأولى/1430 10:26 ص
  •