none
EDGE Server... without the edge? RRS feed

  • Question

  • Okay, let me preface this by saying....

    I know this isn't best practice, and it kills me. However, the politics behind this particular move are far beyond discussing in this forum. Suffice to say, this is how I need to do it. For now.

     

    Alright, on to the question. I have an OCS 2007 R2 Enterprise deployment, consolidated. I have a near-immediate need for outside Communicator access. What I mean by this is: I have users, in my domain (child domain, specifically, but that domain has been OCS-schema-prepared) that need to be able to sign into Communicator. They need to be able to this, over the WAN, from outside the domain. They also need to be able to do this (for the time being) WITHOUT an EDGE server being deployed. The reason I'm not deploying the EDGE server is, well, I don't have a physical host available to actually do this on, and I don't know the ins-and-outs of virtualizing a perimeter network using only one physical network card.

     

    *sigh* I hope someone can tell me a clearcut way to allow someone from the WAN to authenticate with the front-end server directly, and utilize the IM services.

    As forethought, I've created a cert that verifies all the various requirements (pool name, SIPinternal, SIP external, SIP) that I'm aware of, and installed the cert path on the external workstations. OCS has also been configured to only use NTLM for authentication, firewall has been opened to allow 5060 and 5061 (TLS or TCP, whichever works) and OCS has been configured to allow the same. Also, I read somewhere that HTTP 1.1 needed to be enabled in IE, so I did that too.

     

    Can anybody help me? I hate the glued-together feeling of this setup, but the pressure from the top leaves me with no choice.

     

    Sincerely,

    John.The.Frustrated

     

     

    Wednesday, July 21, 2010 4:35 PM

Answers

  • If use VPN, firstly, could you resolve FQDN of OCS pool?  Could you telnet OCS pool with port? For example: CMD -> Telnet sip.fabrikam.com 5061? 

    Are policies configured to "Any to any" for VPN connection in Firewall?

    Have you imported Certificates Chain from CA server?

    At last, if you configure above all properly then still no luck would you enable logs on MOC then put errors here for narrow down the issue?

    MOC logs are stored in "Communicator-uccapi-x.uccapilog" under path C:\Users\alias\tracing; please go to MOC -> Tools -> Options -> General -> Logging turn on logging in Communicator.

    "Snooper.exe" helps you read logs more efficient and clear, it resides in OCS Resource Kit, please download from here: http://www.microsoft.com/downloads/details.aspx?familyid=9E79A236-C0DF-4A72-ABA6-9A9602A93ED0&displaylang=en


    Best regards,
    • Marked as answer by Ben-Shun Zhu Thursday, July 29, 2010 9:00 AM
    Thursday, July 22, 2010 7:11 AM
  • A couple things, those DNS SRV records are for auto client login. If you cannot create external SRV records due to restrictions from your provider, you can manually configure clients.

     

    Tools->Options

    Where it says signin name, click advanced and specify your server FQDN

    You can actually specify these using group policy as well, so if you have a lot of users you must configure, you can use the OCS ADM file to configure the server settings.

     

    http://www.microsoft.com/downloads/details.aspx?familyid=5d6f4b90-6980-430b-9f97-ffadbc07b7a9&displaylang=en

     

    I have had lots of clients have issues with their VPN because of DNS.

     

    Can you verify that the DNS servers your VPN client gets when connecting have just internal DNS records for your OCS environment. Like _sipinternaltls and the poolname?

     


    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    • Marked as answer by Ben-Shun Zhu Thursday, July 29, 2010 9:00 AM
    Tuesday, July 27, 2010 2:24 PM

All replies

  • John,

     

    Sounds like you know why this is a bad idea and want to not go this route but are being forced.  I'd caution against this as it is a security risk (as you know) but you should be able to make this work.

    Here's what you can do:

    Create an A record for SIP.COMPANY.COM and point it to a public IP that is going to OCS (NAT'd by your firewall)

    Create an SRV Record for _sip._tls.comapny.com pointing to SIP.COMPANY.COM on port 5061. 

    Make sure SIP.COMPANY.COM is one of the SAN fields in your cert and that the clients trust the cert.

    Make sure the clients can resolve the SRV record and MOC connects.

    That should do the trick, again this is a security risk, but you already know that.

    Hope this helps!

    -kp


    Kevin Peters blog: www.ocsguy.com MCITP: Enterprise Administration | MCTS:OCS | MCSE | MCSA | CCNA
    Wednesday, July 21, 2010 6:29 PM
  • Kevin,

     

    A couple questions about the DNS configuration:

    I have the A record pointed to the publicly facing IP. It resolves. I've created an SRV record, just as you described. I noticed, however, that for my internal domain (.local) that the SRV record is "_sipinternaltls._tcp.(domain)"

    Should it be setup the same way for the other record? Or will _sip._tls.(domain) function fine?

    Thanks again!

    Wednesday, July 21, 2010 7:50 PM
  • Hi John,

     

    For the public record you will want to use _sip._tls.domain.com.  This should be the sip domain as well, not the internal domain (unless they match).

     

    For example your AD domain would be acme.local and your sip domain would be acme.com.  In that case the records would be:

    A = sip.acme.com

    SRV= _sip._tls.acme.com pointing to sip.acme.com on port 443.

     

    Hope this helps!

    -kp


    Kevin Peters blog: www.ocsguy.com MCITP: Enterprise Administration | MCTS:OCS | MCSE | MCSA | CCNA
    Wednesday, July 21, 2010 8:27 PM
  • Kevin,

    Alright. Well. Suffice to say that due to DNS thing is not going to work.... there are several limitations (that I was unaware of) that will prevent me from pulling that off.

    So be it. It's insecure anyways. So I've decided to pursue another, slightly more obvious option, that's served me well so far. That's right, VPN. So, now I'm on the corp network at home now... doing my thing, pinging my servers, RDP, etc etc.

    MY COMMUNICATOR WILL STILL NOT LOGIN.... what am I missing? This is making me lose what little hair I have left...

    Thanks in advance,

    John.Still.Frustrated

    Thursday, July 22, 2010 4:08 AM
  • If use VPN, firstly, could you resolve FQDN of OCS pool?  Could you telnet OCS pool with port? For example: CMD -> Telnet sip.fabrikam.com 5061? 

    Are policies configured to "Any to any" for VPN connection in Firewall?

    Have you imported Certificates Chain from CA server?

    At last, if you configure above all properly then still no luck would you enable logs on MOC then put errors here for narrow down the issue?

    MOC logs are stored in "Communicator-uccapi-x.uccapilog" under path C:\Users\alias\tracing; please go to MOC -> Tools -> Options -> General -> Logging turn on logging in Communicator.

    "Snooper.exe" helps you read logs more efficient and clear, it resides in OCS Resource Kit, please download from here: http://www.microsoft.com/downloads/details.aspx?familyid=9E79A236-C0DF-4A72-ABA6-9A9602A93ED0&displaylang=en


    Best regards,
    • Marked as answer by Ben-Shun Zhu Thursday, July 29, 2010 9:00 AM
    Thursday, July 22, 2010 7:11 AM
  • Hi, John ,any updates?
    Best regards,
    Tuesday, July 27, 2010 8:57 AM
  • A couple things, those DNS SRV records are for auto client login. If you cannot create external SRV records due to restrictions from your provider, you can manually configure clients.

     

    Tools->Options

    Where it says signin name, click advanced and specify your server FQDN

    You can actually specify these using group policy as well, so if you have a lot of users you must configure, you can use the OCS ADM file to configure the server settings.

     

    http://www.microsoft.com/downloads/details.aspx?familyid=5d6f4b90-6980-430b-9f97-ffadbc07b7a9&displaylang=en

     

    I have had lots of clients have issues with their VPN because of DNS.

     

    Can you verify that the DNS servers your VPN client gets when connecting have just internal DNS records for your OCS environment. Like _sipinternaltls and the poolname?

     


    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    • Marked as answer by Ben-Shun Zhu Thursday, July 29, 2010 9:00 AM
    Tuesday, July 27, 2010 2:24 PM