• Direct SIP: Cisco Unified Communications Manager 6.1

    Posted over 5 years ago
    by DrRez_}

    If you're looking for an introduction about how to configure Cisco Unified Communications Manager (CUCM) version 6.1.2 with Office Communications Server 2007 R2, this article will help you. The proper way to connect and interoperate the two products is to set up a Direct SIP connection in Office Communications Server. On the Cisco side, this is referred to as a SIP trunk. This article covers how to configure a SIP trunk in CUCM.

    Authors: Jerome Berniere, Rui Maximo

    Original publication date: December 2009

    Product version: Office Communications Server 2007 R2

     Interoperating Office Communications Server and CUCM

    If you're looking for an introduction about how to configure Cisco Unified Communications Manager (CUCM) version 6.1.2 with Office Communications Server 2007 R2, this article will help you. The proper way to connect and interoperate the two products is to set up a Direct SIP connection in Office Communications Server's parlance. In Cisco's parlance, this is referred to as a SIP trunk. So, when discussing the configuration of CUCM, we'll refer to this interop connectivity as SIP trunk. When explaining the configuration of the Office Communications Server, we'll refer to this interop connectivity as a Direct SIP.

    If you're trying to operate CUCM with Office Communications Server 2007 R2, you probably already have CUCM deployed in your environment for all your IP phones and your CUCM configured to route all external calls to the PSTN through a PSTN trunk. In this case, you'll likely want to configure Office Communications Server 2007 R2 Enterprise Voice to route external calls to the PSTN through the CUCM PSTN trunk. Calls between Communicator users and Cisco IP phone users should be possible using each user's unique extension number, and users are accessible via externally routable direct inward dialing (DID).  This is illustrated in Figure 1.

    Figure 1. Routing of calls between Communicator users and Cisco IP phone users

    There are two parts to interoperating the two products: configuring CUCM, and configuring Office Communications Server. The high level steps for configuring CUCM are as follows:

    1. Create partition
    2. Create calling search space
    3. Define translation patterns
    4. Provision SIP trunk
    5. Set up route pattern

    The following sections describe the CUCM configuration steps in more detail. For details about how to configure Direct SIP on Office Communications Server 2007 R2 Mediation Server, see Direct SIP: Configuring Mediation Server.

     Configuring Cisco Unified Communications Manager 6.1.2

    Let's dive into the configuration steps for CUCM. The connectivity between CUCM and the Mediation Server is referred to as SIP trunk to conform to Cisco's terminology.

    To read the rest of the article, go to Direct SIP: Cisco Unified Communications Manager 6.1 in the TechNet Library.

  • Microsoft Lync Server 2010 Resource Kit: Technical Overview

    Posted over 4 years ago
    by DrRez_}

    The Technical Overview chapter of the upcoming Microsoft Lync Server 2010 Resource Kit book provides a technical overview of the product. This chapter is being developed. It describes the overall architecture, new enhancements to the different server roles, and what services comprise each server role. Ports and protocols used by each server role are also covered. You can download this chapter from here.

    Author: Rui Maximo

    Publication date: December 2010

    Product version: Microsoft Lync Server 2010

    The upcoming Microsoft Lync Server 2010 Resource Kit book will provide in-depth technical content about Microsoft Lync Server 2010 communications software. The book will focus on professionals who want to understand more about how the product works internally. Product planning and deployment guidance is provided in the Lync Server documentation library in the Technical Library.

    The Technical Overview chapter details the workloads that Lync Server supports. You can download this chapter from here. Based on the Lync Server 2010 Protocol Workloads Poster, this chapter explains how the different server roles in Lync Server are configured to enable the following workloads:

    • IM and Presence
    • Audio and video conferencing
    • Web conferencing
    • Enterprise Voice

    These workloads are the foundations for Microsoft Unified Communications. Each server role serves has a specific purpose. Each purpose is described to help provide context for when and why you should deploy a server role in your topology. This chapter describes which services each server role runs, and what ports and protocols it uses.

    Summary

    Lync Server is a comprehensive solution for presence, IM, web conferencing, and telephony that provides a unified communications user experience that is integrated with Active Directory Domain Services, Microsoft Exchange Server, Microsoft Office SharePoint Server, and Microsoft Office.

    Lync Server Resources

    We Want to Hear from You

  • Protecting the Edge Server Against DoS and Password Brute Force Attacks in Office Communications Server

    Posted over 4 years ago
    by DrRez_}

    Companies that allow employees to sign in to Office Communications Server remotely from the Internet can be susceptible to denial-of-service (DoS) and brute-force attacks. These kinds of attacks involve guessing users' passwords or locking users out of their accounts when too many incorrect password attempts are made to a valid Active Directory user account when password policy is enforced. Although internal security is not compromised, these types of attacks are disruptive to users and use up internal server resources. To prevent such attacks at the edge, you can install a security filter on the Edge Server that monitors sign-in attempts and enforces account lockout at the network perimeter.

    Author: Rui Maximo

    Publication date: May 2010

    Product version: Microsoft Office Communications Server 2007 R2

    When exposing services, and therefore servers, to the Internet to allow employees more flexibility and mobility in working remotely, there's always the concern of attacks. In Office Communications Server, the Edge Server provides protection against unauthorized access by using industry-standard security measures. All communications are encrypted and authenticated. However, some customers might be concerned about DoS and password brute force attacks, and these are legitimate types of attacks. Although brute force attacks on user passwords can be prevented by using Active Directory's lockout security policy, and corporate information is not compromised under such attacks, it does pose a nuisance to legitimate employees trying to connect to the corporate service when their Active Directory accounts have been locked out. It also consumes internal server resources as the external user's sign-in request to Communications Server must be performed by an internal server such as a Director or pool. The Edge Server cannot authenticate the user because it's not connected to the corporate's Active Directory. Such an attack can easily be mounted by knowing the victim's Active Directory username and domain name. What measures can organization use to defend against such attacks?

    Overview

    DoS attacks are indistinguishable from legitimate sign-in requests. The only differentiation is in the frequency of sign-in attempts and origin. A large number of sign-in attempts in rapid succession can be indicative of a DoS attack. DoS attacks attempt to guess the user's password to gain unauthorized access, and often result in locking out the user account if security policy is enabled in Active Directory.

    The Edge Server doesn't protect against such DoS attacks. However, because Office Communications Server provides a flexible programming platform, you can use the Microsoft SIP Processing Language (MSPL) to create server applications that intercept SIP messages on the server and perform specialized logic. This is exactly what the security filter does. It's a server application that inspects all incoming sign-in requests. Because the user is not authenticated at the Edge Server, the sign-in request is passed on to the Director or directly to the internal pool, which then performs the authentication process. The response is passed back to the Edge Server. The security filter inspects the response. If the sign-in failed, the security filter tracks the number of failed attempts for each user account. The next time a client attempts to sign in to the same user account, and the number of failed attempts exceeds the maximum number of sign-ins allowed, the security filter immediately rejects the request without passing the request to the Director or internal pool for authentication. By enforcing account lockout at the Edge Server, the security filter prevents DoS attacks at the edge of the network perimeter, and as a result, protects internal Office Communications Server resources.

    Design

    The security filter is comprised of two parts: an MSPL script and a .NET application. The MSPL script must be registered with the Edge Server. The MSPL script intercepts SIP messages of interest from the Edge Server and passes those messages to the .NET application that inspects the messages and enforces the account lockout logic.

    To prevent such attacks, there were several options that I, with the help of the Communications Server Masters community (thanks Adrian Maclean), investigated to determine how to uniquely identify the user. We could have used source IP address, sign-in name (meaning, the SIP URI), or account name. When we investigated each of these options, and we determined that rogue clients mounting a DoS attack could spoof the source IP address eliminating this choice as a way to uniquely identify the user being authenticated. The sign-in name, although necessary to successfully sign in to Office Communications Server, is not used to authenticate the user. The sign-in name can be changed in sign-in requests and still lock out the same user account. Therefore, neither the source IP address nor the sign-in name were good sources to identify the user. Only the account name uniquely identifies the user account.

    The account name, which consists of the user name and domain name, can be extracted only from the authentication protocol. Users trying to sign in from the Internet use the NTLM v.2 authentication protocol, not Kerberos. The NTLM protocol uses a three-stage handshake authentication process. The client passes the user's credentials in the third stage of the NTLM handshake. Because the security filter runs as a trusted server application on the Edge Server, it's allowed to intercept the sign-in request. The security filter decodes the username and domain name from the NTLM authentication message. Because the account name is not available in the response, the security filter maps the response to the request by the message ID.

    When the internal pool or Director sends the authentication response to the Edge Server, the security filter can view the register response. If the sign-in failed, the security filter increments the count of failed attempts. If the sign-in succeeds, the security filter resets the count of failed attempts to zero.

    Every time the Edge Server receives a sign-in request, the request is passed to the security filter. The security filter checks whether the sign-in request has exceeded the maximum allowed number for the particular user account. If the request has not exceeded the maximum lockout count permitted, the security filter allows the request to continue its course to the Director or internal pool. If the request exceeds the maximum lockout count permitted, the security filter blocks the request and returns a 403 response rejecting the request. Any further sign-in attempts are rejected for the duration of the lockout period. After the lockout period expires, it is reset to allow new sign-in requests to be authenticated.

    Run the Security Filter

    To run the security_filter application, open a command prompt window as a local administrator, and then go to where you downloaded the application. Enter "security_filter". The application will indicate that two input parameters are missing.

    Two configuration settings must be passed to the security filter. The first parameter is the account lockout count. This is the number of failed sign-in attempts allowed before an account lockout is triggered. The second parameter is the account lockout period. After an account is locked out, this lockout period specifies how long the account remains locked before another sign-in attempt is allowed. Any sign-in attempts during this lockout period are immediately rejected without verification.

    If there's enough interest in this application, I can build an installer (MSI) for it to simplify the installation process. Hope you enjoy it!

    You can download the security filter application from the Microsoft Download Center. More sophisticated logic can be built into this application. If you need further customizations, contact me.

    Summary

    DoS attacks can easily be mounted against valid Active Directory user accounts from the Internet by targeting the Edge Server. By leveraging the programmable extensibility available in the Office Communications Server platform, I was able to create a security filter application that runs on the Edge Server. This server application inspects SIP requests and responses of interest, and enforces logic similar to the account lockout policy in Active Directory to prevent DoS attacks on user accounts.

    Additional Information

    To learn more, check out the following articles:

     Communications Server Resources

     We Want to Hear from You

  • Remote Conferencing with Lync Web App with Forefront Threat Management Gateway 2010 Reverse Proxy: Part 1

    Posted over 3 years ago
    by DrRez_}

    Microsoft Lync Web App is the new Microsoft browser-based client solution for the Microsoft Lync Server 2010 communication software instant messaging and conferencing features. The Lync Web App client can provide remote user access to internally hosted Lync Server 2010 conferences. This is done by using a reverse proxy configuration that many web proxy server solutions offer. Microsoft Forefront Threat Management Gateway 2010 supports a reverse proxy configuration that can host the remote Lync Web App conferencing client.

    This article is the first part of a two-part series that provides you with a step-by-step solution for configuring Microsoft Forefront Threat Management Gateway 2010 as a reverse proxy that provisions remote access for Lync Web App conferencing users. Part two explains the type of network connectivity that is required to adequately use all the conferencing features of the remote Lync Web App client.

    This article is being reviewed and updated. We will repost the article when revisions are complete.

    Author: Mike Adkins

    Publication date: February 2011

    Product version: Microsoft Lync Web App, Microsoft Forefront Treat Management Gateway 2010, Microsoft Lync Server 2010


     

  • How to Create Additional Lync Server 2010 Call Details Reports: Part 1

    Posted over 3 years ago
    by DrRez_}

    Microsoft Lync Server 2010 Monitoring Server Reports provide a collection of system usage and call diagnostic reports. This collection of reports meets the needs of most Lync Server 2010 audio/visual (A/V) call scenarios. However, administrators that want to add to the extensibility of the Lync Server 2010 Monitoring Server Reports can easily do so by using tools that are provided with Microsoft SQL Server and the Monitoring Server Reports to add user-defined call details reports that are based on user-defined data sources. This article, in two parts, describes how to create these additional call details reports.

    Author: Mike Adkins

    Publication date: January 9, 2012

    Product version: Lync Server 2010

    Introduction

    The Lync Server 2010 Monitoring Server Reports provide customers with a set of predesigned reports that provide the diagnostic and the summary details for audio/visual (A/V) calls that are managed in the Lync Server 2010 environment. Installing the Lync Server 2010 Monitoring Service adds the LcsLog (archiving) and the LcsCDR (call details) databases to the SQL Server instance that manages data for the Lync Server 2010 Monitoring Service. The predesigned Monitoring Server Reports may not provide all the information that is needed by an organization to completely assess the use of their networks Voice over Internet Protocol (VoIP)-enabled clients. Any need for additional A/V call detail reporting could require the design and implementation of new database objects for the LcsCDR database, a data source connection, and the reports that will display the additional A/V call detail information.

    This article is divided into two parts that explain the steps needed to create a Lync Server 2010 call details report based on specific information that is stored in the LcsCDR database. Part 2 of this article will provide the step-by-step information for using the Microsoft SQL Server Report Builder to create the data connection to the new SQL Server stored procedure and the new Lync Server 2010 call details report that will display that stored procedures information.

    Designing and creating the database objects

    Whether you create a new Lync Server 2010 call details report is dependent on the availability of the data that the report will present. You can use Microsoft SQL Server Management Studio to display all of the LcsCDR database’s tables and their contents so you can inspect the information that may be used for a new report. Just expand Tables node under the LcsCDR database (see Figure 1).

    Important SQL Server requires the delegation of its security model to the user account that will access the SQL Server, perform SQL Server configuration updates, read and write information that is stored in its databases and perform design updates to databases. For detailed information on managing SQL Server permissions, see the “Additional Information” section of this article.

    Figure 1. Using SQL Server Management Studio to analyze information in the LcsCDR database

    To view additional information stored in the Lync Server 2010 Monitoring Service LcsCDR database, you need to create the SQL Select queries that will be used as the basis for the report’s SQL Server stored procedure. The SQL Select query will allow the extraction of information from the tables in the LcsCDR database that contain information needed for the report. A SQL Select statement allows the use of SQL Join syntax to extract related information from multiple tables in a database. The simple SQL Select query example that is provided (see Figure 2) will use a SQL Select statement with a simple SQL Inner Join and SQL Where clause. The purpose of the Inner Join is to display the number of rows of information in a secondary table that contains a key value that matches the key value for one row in the primary table. In practice the secondary table will contain many matches for the key value that is listed only once in the primary table. This determines the range of data and the overall number of rows returned by the SQL Select query. The SQL Where clause is used to determine the type and amount of information that is returned by the SQL Select query based in the criteria defined by it.

    Note: This article will not go into detail on the many uses of SQL syntax. For details about using basic SQL Select statements, see the SQL Server Search option from the Help menu of SQL Server Management Studio.

    Creating a SQL query

    The SQL Select query created in this example provides information that can be used to determine which Microsoft Lync 2010 users have used the enabled call forwarding feature to forward their incoming calls to the public switched telephone network (PSTN). This information will be displayed in a Lync Server 2010 Call Details Report that can be used to track the cost of this type of call to the PSTN (see Figure 2). The Select query will extract information from two tables that are part of the LcsCdr database. The primary table for the SQL Select query is named Users. The Users table contains a record for each Lync 2010 user that initiates an A/V call. The secondary table is named SessionDetails. The SessionDetails table contains a record of each A/V call that is managed by the Lync Server 2010 Voice over IP (VoIP) environment. The key fields in each table that will host the Inner Join are Users.UserId and SessionDetails.ReferredById. Each of these fields contains an integer value that represents the Lync A/V caller’s UserId. With the Inner Join defined in this manner, the SQL query will display the user’s SIP Uniform Resource Identifier (URI) that referred or forwarded the incoming A/V call from another local Lync 2010 user to the PSTN.

    The following procedure shows how to create the SQL Select query statement for analyzing A/V calls that have been forwarded by a specific Lync 2010 user to the PSTN.

    To create the SQL Select query statement

    1. Open the SQL Server Management Studio console.

    2. On the SQL Server Management Studio’s toolbar, click New Query to open a SQL Server query window.

    3. Use the SQL Server query window to design and test the query that will be used as the data source for the new A/V call detail report.

    4. To test and view the results of the new query, click Execute, as shown in Figure 2.

    5. Save the contents of the SQL Server query window as a file with a .sql extension.

    Figure 2. Creating and testing a SQL Select query

    Create a SQL Server Stored Procedure

    A SQL Server stored procedure is a database object that contains procedural instructions that are defined in SQL syntax. It’s useful because of its portability. In this example the SQL Server stored procedure is designed to contain the SQL Select query statement that we defined in the “Creating a SQL Query” section of this article. This SQL Server stored procedure allows the entry of the BeginDate and EndDate parameters to be passed to the SQL Query’s Where clause.

    Creating a SQL Server stored procedure requires three steps:

    • Create the SQL Server stored procedure template
    • Add the SQL Select query’s code to the SQL Server stored procedure template
    • Test the SQL Server stored procedure

    To create the SQL Server stored procedure template

    1. Use the SQL Server Management Studio object browser to locate the LcsCDR database that is listed under the user database objects.

    2. Expand the LcsCDR database, and then expand the Programmability node.

    3. Right-click the Stored Procedures node, and then click New Stored Procedure.

    4. The SQL Server query window will now display the SQL Server Create Stored procedure template, as shown in Figure 3.

    Figure 3. The SQL Server Create Stored procedure template

    The next step in the stored procedure creation process is to add the SQL Select query’s code (see Figure 2) to the SQL Server stored procedure template.

    To add the SQL Select query’s code

    1. Add the name for the stored procedure to the right of the Create Procedure clause of the SQL Server stored procedure template, as shown in Figure 3.

    2. Copy and paste the SQL query @BeginDate and @EndDate parameters from the SQL query that is described in the “Creating a SQL Query” section of this article into the parameters section of the SQL Server stored procedure template, as shown in Figure 3.

    3. Copy and paste the SQL query Select statement from the SQL query that is described in the “Creating a SQL Query” section of this article into the “Insert statements for procedure here” section of the SQL Server stored procedure template, as shown in Figure 3.

    4. To create the new SQL Server stored procedure, click Execute, as shown in Figure 4.

    Figure 4. Adding the SQL Select query syntax for the new SQL Server stored procedure

    The last step in the creating database objects procedure is to test the new SQL Server stored procedure to make sure that it works as expected.

    To test the SQL Server stored procedure

    1. Open the SQL Server Management Studio console.

    2. From the toolbar, click New Query to open a SQL Server query window.

    3. Select the LcsCDR database from the database selector on the toolbar.

    4. Use the SQL Server query windows to type the following (as shown in Figure 5):

    Execute <name of stored procedure> <paramerter1>, <parameter2>…

    5. To test and view the results of the new query, click Execute.

    Figure 5. Running the new SQL Server stored procedure

    Summary

    You need only a limited amount of knowledge of SQL Server Management Studio tools to use the A/V conferencing information that is stored in the LcsCDR database to create custom call details reports. Using SQL Select queries to analyze A/V call detail information provides insight into how specific information can be extracted from the LcsCDR database as presentation material for a call details report. The use of the SQL Server stored procedure database object provides a convenient way to manage access to the data that will be presented by the call details report. The second part of this article will provide a step-by-step process on how to access the output of SQL Server stored procedures from a SQL Server Report Builder report.

    Additional Information

    For more details about creating additional Lync Server 2010 Monitoring Server Reports, see chapter 2 of the Lync Server 2010 Resource Kit:

    For more details on managing SQL Server permissions: