Blogs

LCS Server, SIP and ISA Server 2004

  • Comments 3
  • Likes

Mixing these technologies together has a mixed story behind them and can lead you into all kind of quagmires.  Let’s briefly discuss where we are at today, what some additional things are to consider, why many challenges are faced and then I will discuss some new options.  This article will in no way be a complete analysis into all possible scenarios and technical references (that would require a book!).  Instead I hope to overview some of the items and point people in the right direction to learn more.

 

First of all there are documents that discuss how to publish LCS services through ISA 2004 (http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/tls-isa.mspx).  They are straightforward and easy to configure.  LCS documentation also outlines how they recommend you secure external access to your LCS infrastructure and it includes leveraging the LCS Access Proxy.  So what is lacking from this story?

 

The LCS AP is an important part of securing your LCS infrastructure when External Access and/or Federation are required.  When you place ISA 2004 in front of LCS for external access you are not able to leverage the full potential of the application layer inspection infrastructure ISA provides.  There is no ‘intelligence’ that SHIPS with ISA 2004 around the SIP protocol.  To learn more about what that means check out my recent article on ALF’s (http://blogs.technet.com/accessdenied/articles/419068.aspx).   Does that mean that ISA can’t add value?  Before that, let me share a couple of key gripes I do have regarding the LCS Access Proxy. 

 

First, customers shouldn’t have to deploy multiple proxy server solutions developed by separate product teams at Microsoft (believe it or not, there are others!).  We have made such wonderful progress working towards standardizing on a management platform (MOM with Management Packs), a reporting platform (SQL reporting services), a database platform (SQL technologies), interface standards (MMC), etc.  This has allowed for better integration, easier deployment for customers and for product teams to focus on their products and not having to re-produce what others have already done.  Leveraging ISA’s secure Application Layer Firewall infrastructure would seem like a logical next step!

 

Second, the LCS team recommends that the LCS proxy servers be deployed in a workgroup.  More and more products, services and appliances either deploy in a workgroup or are not domain aware (the second being more non-windows based devices).  These are typically ‘Front End’ or ‘Gateway’ based components as part of a solution.  It is a concern to see individual product teams introducing services they recommend you deploy in a workgroup (and don’t necessarily support on the same system as other services you might deploy in a workgroup).  At this rate customers risk having a farm of workgroup based servers. 

 

Placing machines in a workgroup limits manageability, policy application, auditing, monitoring, access control and authorization options.  These limitations have a DIRECT impact on security.  The risks of workgroup based machines increases with the more machines you have.  ISA Server has the OPTION to be installed in a workgroup.  I don’t always endorse that option (due to the above outlined benefits of domain membership).  If ISA and LCS are being deployed in a workgroup it is that many more machines you must manage.

 

ISA still has a ton of benefits to help manage access to the LCS Server and make sure that you are properly securing/blocking protocols and connections that you want to limit to the AP.  It is also disappointing that the public documentation providing details as to what level of security the AP provides when ‘inspecting’ SIP traffic is very high level and lacking in details.  More information here would help users make more informed decisions as to the level of risk being mitigated by these services.

 

As we finalize our discussion around where we are at today there is one more area to address regarding external access to LCS.  It is in regards to P2P services such as application sharing, file transfers, audio and video.  The scenarios I am outlining are specific to when SIP is used with LCS from SIP enabled clients (Windows Messenger and Office Communicator).  Public IM clients (like MSN messenger) have some similar challenges but handle the communication differently (they do not use SIP).

 

One example of these challenges would be when a client on the inside network (Client A on a private IP scheme) asks (via SIP) a client on the Internet (client B) to connect to Client A and grab a file.  The private IP address of Client A is encapsulated in the (encrypted) SIP traffic sent to Client B.  Client B then cannot connect to Client A (the IP address of Client A is useless over the Internet).  Yeah, I know…I need a diagram.

 

Lets assume that we could magically ‘fix’ the IP address problem – as the SIP traffic (with the private IP address) is exiting the corporate network the private IP is replaced with a public IP that resolves back to the company.  Now Client B would know how to connect back to a public IP, but would the perimeter device know what to do with that secondary connection (and would you want to open up all the ports required for these services)?

 

Well guess what!  Now you can.  One of the great things about ISA is how it can be extended with filters to provide for more advanced scenarios.  A 3rd party Microsoft Partner, www.collectivesoftware.com, has a SIP Filter for ISA 2004 in beta called LCS-Bridge.  First it can decrypt the TLS SIP communication (and re-encrypt).  That is the first step to being able to inspect the SIP traffic and try to ‘fix up’ scenarios where there are private IP references.  Then, when the secondary connection comes to request a file (in this example) the filter can dynamically open the necessary port and map it to the appropriate internal client for THAT client/connection only!  This means you can support P2P services for far more NAT based scenarios (there are many more complex scenarios than I have detailed and they have taken steps to improve them all as much as possible) and without having to turn your ISA firewall into Swiss Cheese!

 

Collective Software has this filter in beta now and are actively recruiting Beta customers.  I have tested all the features and gotten them to work in my ISA environment.

 

The most secure way to provide, manage and monitor usage of the public IM cloud is to use a single stack LCS client (Office Communicator) and to federate your LCS infrastructure into those clouds (where then some of the above scenarios would then apply).  If you insist on allowing public IM clients (like MSN messenger) from working in your environment we have another great ISA 2004 partner (www.akonix.com) that can provide capabilities to help manage and monitor this traffic in a much more granular fashion that ISA 2004 can alone.

 

Do not consider ISA partner add-ins a bad thing.  Although I would like to see more product teams leveraging the powerful infrastructure ISA provides, ISA was designed to provide for this extensibility.  You can leverage one great product that fits so well into a ton of scenarios and then extend it to meet other unique and specific needs without having to purchase other expensive appliances and solutions!

Comments
  • Here I summarize my thoughts on providing secure and feature rich external access to LCS utilizing...

  • Hi Tom -- you made a major typo:
    "Placing machines in a domain limits manageability, policy application, auditing, monitoring, access control and authorization options"
    You should have said that placing machines in a WORKGROUP limits your options and reduces your overall security posture.

  • You are correct - that was a major Typo.  I re-worded that section a couple times and that slipped up.  I have corrected it, thank you!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment