One of the interesting features in this Forefront UAG release is our integration with SSTP (Secure Socket Tunneling Protocol) – a firewall-friendly VPN technology introduced into Windows in Vista SP2. SSTP is another RRAS (Routing and Remote Access) tunneling protocol, which relies on standard SSL technology for implementing a ‘layer 3 VPN’.

Supporting layer 3 VPN to enable remote users full access into the corporate network is not new in UAG – it’s supported in IAG via the Network Connector component that resides on both the user’s endpoint machine and the IAG server. However, Network Connector is a proprietary technology which is being replaced by the SSL-based in-box technology. That replacement brings several benefits:

• Saves installation of a driver on endpoint machines
• Scalability gains (requires a single HTTPS connection to the UAG server)
• Supports DHCP for VPN client IP provisioning

Network Connector is still supported in UAG, primarily for down-level clients (more on that a bit later in this blog), but the direction is clear: rely on standard platform technologies where possible.

“Sounds great – show me how!” – configuring UAG\SSTP has 3 steps:

Step 1 - Enablement

The first step is enabling SSTP, and it’s performed by launching the “SSL Tunneling Configuration” dialog via Admin->Remote Network Access->SSL Network Tunneling (SSTP):

• In the “General” tab you specify the max number of client connections and choose a trunk to rely on. That trunk must already exist, and SSTP would pull several elements from that trunk, like its public hostname (for the clients to dial to), port and server certificate (which must be valid).
• The Protocols tab is pretty straightforward – you just make sure the SSTP protocol is checked (which it is by default) and the rest (PPTP and L2TP/IPSEC) are not as these two are not supported in this beta.
• The IP Address Assignment is more interesting, as here is where you configure the policy of assigning IP addresses to VPN clients. We support two modes: static and dynamic via DHCP. In the case of static, you will notice that you’ll need to exclude the IP range from the definition of your internal network - you’ll get an error message if you don’t.
• Access Control is preserved for dial-up scenarios which are not supported in beta – please leave it blank.

Step 2 - Publishing

The second step is publishing the Remote Network Access app. You use the standard “Add Application Wizard” for that- you’ll find the Remote Network Access app, alongside Network Connector,  in the “Client/Server and legacy” dropdown list.

This is a good opportunity to elaborate about why Network Connector is still relevant and supported in this release: as mentioned above, SSTP is only supported on Vista SP2 clients and above. When an end-user launches the Remote Network Access app from the trunk, a client-side logic determines if the client OS version is Win 7 or a previous version. In the former case SSTP will be used to establish a connection; in the latter – NC (assuming NC is also enabled on UAG). You might be wondering why we’re using NC on a Visa SP2 client machine; the reason is to provide a single sign-on experience. Let me elaborate a bit: typically when a user dials-into RRAS\SSTP she needs to undergo some kind of authentication. But in the scenario where the user has already logged into the UAG trunk, and launched Remote Network Access from there, we don’t want her to need to provide log-in credentials to RRAS again; that’s why we’ve implemented an RRAS admin plug-in that delegates authentication and authorization decisions to UAG. Now comes the tricky part: that plug-in is only supported on Win 7 clients, not on Vista SP2 clients. Hence, we’ve made a decision to treat Vista SP2 as ‘legacy’ for this case, and use NC.

Step 3 - End-user Testing

The last step is, well – just try it out. Log in to the trunk and launch the Remote Network Access app (or whatever name you gave to that app during the publishing phase). You will see a dialog showing the connection attempt, and if successful – a “connection started” bubble:

That’s pretty much it – you’re connected and can ping and browse internal resources. You can end the connection from the Portal Activity window or by just logging off from the portal.

Happy networking,

Asaf Kariv | Lead Program Manager | Microsoft Unified Access Gateway

One of the major new features in this UAG release is ‘array’. An UAG array is a set of machines that share the same configuration (trunks, applications, etc.) and is managed as a unit. It maps to our ‘Enterprise Readiness’ pillar, and provides the following benefits:

• Increased Availability
• Increased Scale
• Management as a unit

Increased availability and scale are achieved by load-balancing incoming traffic among several UAG machines – that increases both the overall capacity of the deployed system, and in case one UAG machine is down – the backend app is still available via other UAG machines. Before this release that was only possible with an external SSL load-balancer. In this release, we’ve integrated with Windows NLB (Network Load Balancing) to provide an out-of-box solution at no extra cost.

Obviously, when working with multiple machines for publishing the same applications and in the same manner, it would be a huge burden for the administrator to configure each machine separately. Fortunately, UAG abstracts that in a nice way: the admin would only need to make the configuration change from one of the machines, and the change would be automatically propagated to all array members. This is accomplished by having one of the array members (usually the first one) defined as the “manager”, which holds the authoritative copy of the configuration; changes to the configuration (from any machine) are updated there first, then propagated to other members. BTW, the array manager does not need to be a dedicated machine. There’s no extra load on the array manager.

Example Array

How does one get started with an array? It’s simple: you install UAG on one machine (that would be your Array Manager), then install UAG on another UAG machine and ‘join’ that machine to the Array Manager machine via the Array Management wizard. Before you join the machine to the array, you need to open connectivity from the member to the manager machine – you do that by launching the TMG console on the array manager machine and adding the second machine to the “Managed Server Computers” computer set:

Opening Connectivity to the Array Manager

Array Management Wizard

After joining the second machine to the array and performing activation you have a 2-nodes array up and running. You can start creating trunks and publishing applications; you can also join a node after you create trunks and publish applications – that node would inherit the configuration from the array manager. You should note that when joining a node to an array, the local configuration of the node will be wiped…

In order to enable NLB on your array you would need to create a Virtual IP Address, also known as a “VIP”, first. The VIP is an IP address that is shared by each node of the array. Traffic destined for a trunk that is associated with that IP address arrives at each of the nodes, but is picked by only one of them (this filtering is performed by NLB itself, way low at the network stack), thus effectively load-balancing the traffic between the nodes. You define a VIP from the Network Load Balancing dialog:

Network Load Balancing UI

Once you have a VIP defined, you can associate a trunk with that VIP.

UAG also has an interface for showing status of and performing operations on array members. For example, before taking a machine down for maintenance you can “drain” that machine, which means that new sessions are not going to be routed to that machine. When the current sessions on that machine terminate, you can safely take the machine down without disrupting active users. Those operations can be performed from the NLB section of the Web Monitor.

We have a lot more planned for the array. We see it as an important feature for our enterprise customers and we’re planning on investing much more in it. We’d love to hear your feedback on it!

Cheers,

Asaf Kariv | Lead Program Manager | Microsoft Unified Access Gateway

As the PM lead responsible for the UAG DirectAccess, I’m proud to present our solution based on the new and exciting technology introduced by Windows 7 Direct Access. If you want to learn more about this technology click here.

Microsoft Forefront Unified Access Gateway (UAG) utilizes DirectAccess technology built into Windows 7 and Windows Server 2008 R2 to create an enterprise level solution. UAG offers an all in one, end-to-end solution that lets the enterprise open its resources to managed clients in a seamless, painless manner.

UAG DirectAccess extends access to IPv4 servers

In order to support all backend servers, UAG DirectAccess adds a necessary transition technology (NAT64 and DNS64 also known as NAT-PT and DNS-ALG) to also allow clients access to IPv4 only servers – in addition to IPv6 based servers (natively or via ISATAP).

UAG DirectAccess enhances scalability, high-availability and management

Our solution adds the ability to scale and have multiple Direct Access Servers (DAS) in a cluster for providing high-availability of the service as well as scale-up. As part of ‘all in the box’ paradigm, UAG integrates Windows Network Load Balancing (NLB) support that could be seamlessly activated for the cluster.

UAG DirectAccess simplifies deployment and administration

We incorporated and augmented the DirectAccess configuration into its Unified Access Gateway management console allowing an easier deployment of the cluster. The console will help you setup, configure, activate and manage the cluster and each node in it from a central location. This console can be used to enforce policies (such as NAP and Smartcard), set IPs, etc.

UAG also provides access, from within the same cluster, for down level and non Windows clients

As its name suggests, Unified Access Gateway provides multiple access scenarios for managed remote clients (via UAG DirectAccess) as well as unmanaged, or even ‘foreign’ remote access clients in a secure way. By utilizing various remote access technologies, UAG can publish business server applications to unmanaged clients enforcing various authentication methods.

Nitzan Daube

Principal Program Manager Lead, UAG product group.

When the design of UAG began a few years ago we noticed that our customers had multiple boxes on their network edge providing remote access. They had IP VPNs, SSL VPNs, E-Mail relays, mobile gateways, terminal services gateways - but there was no remote access solution. This is exactly what we set out to solve with the Unified Access Gateway: provide one, unified solution to all the remote access needs of the organization, regardless of the technology.

For years, vendors created and sold remote access technologies, claiming that they were the remote access panacea, the single remote access technology that would solve all of the organization’s remote access needs. Today it is clear that there is no magic solution. Modern organizations need a variety of technologies for a variety of audiences, applications and user scenarios. The technology that fits the needs of the CEO reading her e-mail on her laptop will not be useful to a sub-contractor who works with the organization but also with its competitors, a sales person working from his home PC or even the same CEO when reading her mail from an Internet kiosk or mobile device. The technology that is ideal for SharePoint access is the wrong tool when using CAD or call center applications.

In UAG Beta we introduce four types of remote access technologies:

1. Web Application Publishing / SSL-VPN – Application aware publishing of HTTP/HTTPS applications.
2. Layer 3 VPN / Tunneling – Various networking protocols and tunnels to provide full networking connectivity. On top of the IAG technologies we added SSTP, L2TP and PP2P.
3. Terminal Services – Incorporating Terminal Services / Remote Desktop Gateway into UAG to provide application level publishing of remote applications.
4. DirectAccess – Integrating Windows DirectAccess technology for always-on connectivity.

UAG brings these technologies together while adhering to two major principles:

Show Me the Money

Saying “in today’s tough economy” is a cliché, but when we talk to any of our customers we hear that they are under enormous pressure to cut budgets and to show how their infrastructure is more efficient. We must enable our customers to dramatically cut their costs, and in UAG we are doing this by:

Unified Management

Every system that is introduced to the organization has its cost even before the first user logs on. Looking at our customers’ TCO we see that they spend lots of money on educating their IT staff, integratingeach system into the NOC, creating backup and restore procedures, etc. UAG reduces most of this spending by providing unified management for all the remote access technologies. This includes:

• Single management console
• Consolidated setup that installs and configures all the components
• Unified SCOM Management Pack
• Out of the box cluster and load balancing integration

Hardware consolidation

We see remote access vendors marketing an appliance for remote access technology X, an appliance for technology Y, another appliance for load balancing and another appliance for managing the rest of the appliances. UAG not only have all remote access technologies on the same box but also allows to choose how to deploy it:

• Hardware appliance – UAG is offered as HW appliance by our OEM partners. Some use standard hardware, others offer specialized hardware.
• Virtualization – Plugging UAG into the organization virtualization infrastructure.
• Software installation – Gives IT full control of the deployment.

Good, Better, Best

Unifying remote access technologies doesn’t mean giving the same experience to everyone but rather providing multiple experiences, each with its own tradeoffs between user experience, possible risk to corporate resources and availability. Here are some examples:

Full network connectivity:

• Good: SSL based layer 3 network tunneling – the good old SSL tunneling technology originating from IAG that works on almost any version of Windows.
• Better: Secure Socket Tunneling Protocol (SSTP) – SSL Tunneling technology that is part of Windows Vista and above.
• Best: Windows 7 DirectAccess provides a seamless, always connected experience exclusively for domain joined managed Windows 7 clients.

SharePoint publishing:

• Good: SharePoint browsing from mobile devices – always available but limited by the mobile devices’ screen size and input.
• Better: Publish SharePoint on the remote access portal.
• Best: User accessing SharePoint via DirectAccess.

Meir Mendelovich

Senior Program Manager, UAG Product Group

Hi!

In the last blog post Oleg wrote about the UAG Beta becoming available in a couple of weeks. I've been working with the team for the past nine years and I'm now excited to give you an overview of what we actually did in the new Forefront Unified Access Gateway (UAG). If we were to describe where it is we want to take UAG, the following sentence would sum it up:

Provide employees, partners and customers with seamless, secure access to any application or resource, from any device on any network

The great thing about UAG is that it is a comprehensive solution for corporate resource access. UAG adds seamless network connectivity with DirectAccess and greatly improves the publishing experience for Exchange, SharePoint, TSG and Dynamics CRM, coupled with new authentication combinations and enhanced scalability options. Whew! That was a long sentence :-)
Let me break what we've done into three main themes: Unified remote access, Business productivity and Enterprise readiness. In the following paragraphs I will list the main features. This is just to whet your appetite. The actual drilldown will happen in the following posts, so come back later to read the details!

Unified Remote Access

• New and optimized ways to easily configure secure publishing of SharePoint, Exchange (including integrated Outlook Anywhere) and Dynamics CRM
• DirectAccess - seamless, always-on, secure connectivity to on-premise and remote users alike. Just turn on your machine, log into windows and you are connected to the corporate network!
• Comprehensive combination of connectivity options: traditional IP VPN, SSL VPN, SSTP, Remote Desktop Services including TSG integration and RemoteApp publishing, and mobile access. Whatever your users need to get their work done remotely you can manage on just one server!

Business Productivity

• Optimized for employee remote access with a revamped portal catering to Internet Explorer as well as other leading browsers and mobile devices.
• Secure partner access to line-of-business applications - using ADFS integration
• Granular identity and health-based policy for improved risk management and compliance based on endpoint health detection.

Enterprise Ready

• Scalable solution through performance enhancements, as well as gateway and backend load balancing - supporting NLB and web farm load balancing (WFLB).
• Centralized management, reporting and logging - with Array Management, SCOM support and SQL logging.
• Support for multiple strong authentication methods in combination with Kerberos Constrained Delegation, Integrated Windows Authentication, NTLM and more!
• Virtualization ready.
• Heavy investments in Secure Development Cycle (SDL) to produce secure design and secure code.

That’s it for the overview. Starting from the next blog post you will be getting all the juicy details straight from the source, beginning with Meir’s “Remote Access Technologies of the World - Unite!”.

Noam Ben-Yochanan,
PM Architect, UAG Team

More than a year ago, we have announced the successor of IAG - Forefront Unified Access Gateway (UAG). For this entire period, our team was heads down in making this happen (and to have an excuse for not blogging extensively about IAG :-) ). It’s been a long journey and we are very proud to present the result to you, our customers and community. In just a couple of weeks you will be able to join our excitement and dig in deep into the new UAG, when it reaches its public beta.

We can’t wait to show you all the new features and capabilities! Meanwhile, over the coming weeks we will use this blog to share with you the story of UAG: new features, behind the scenes and in-deep discussions. To start the celebrations, we are changing the name and look of this blog.

Stay tuned…

Oleg Ananiev,

Group Program Manager, UAG Team

Good news, everyone! The new IAG/UAG public forum on TechNet is now live at: http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/. I will be moderating that forum, and we hope to draw a big crowd of IAG customers and potential future customers of UAG.

This forum will offer help on any topic related to IAG and UAG, and anyone is welcome to post questions or answers, and actively participate in open discussions. Any suggestions or ideas will be more than welcome as well!

I'd like to thank you in advance for any help and participation, and wish you the best possible experience with the forum!

Ben Ari,

IAG Support Team

By default client browsers (or at least, any reasonably up to date client browser) will connect to IAG using 128 Bit encryption. This can be seen by right clicking in the browser pane and choosing ‘Properties’ after you have accessed your IAG portal. For example:

Internet Explorer 7 on Windows XP:

Internet Explorer 8 on Windows Vista:

To view the encryption in use on Firefox the process is similar. Right click in the browser pane and choose ‘View Page Info’, then click the ‘Security’ padlock icon. Here is a screenshot of Firefox 3.0 on Windows XP:

128 bit encryption is pretty strong and is adequate for most use. But what if you have a requirement for stronger encryption? Can IAG support 256 bit encryption? This blog entry would be rather pointless if the answer was ‘No’ so clearly it can. Let’s see how we can configure this – it’s pretty easy.

Step 1: Add support for AES 128 and AES 256 to the OS.

When Windows Server 2003 was released it supported up to 128 bit symmetric encryption algorithms for SSL. Whilst Windows Server 2003 supported AES It did not have any support for the AES cipher suites in schannel.dll. An update has subsequently been released that adds AES128 and AES 256 cipher suite support into schannel.dll for Windows Server 2003. So our first step is to install this update on the IAG server. The update can be downloaded from here.

Install it on IAG and restart your IAG server for the new cipher suites to become available for use.

If you test from your browser clients you will see some differences now:

• Windows XP with IE7 still uses 128bit RC4
• Windows Vista with IE8 now uses 128 bit AES. As does Firefox 3.

So we’re getting closer, but still no 256 bit encryption. It appears that even though AES 256 is an option, it is not offered as the preferred cipher, presumably for performance reasons (256 bit encryption will take a bit more effort to encrypt/decrypt than 128 bit encryption).

Step 2: Forcing AES 256

On the IAG server open regedit.exe and browse down to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers

Here you will find details of the all ciphers available to Schannel (which is responsible for SSL/TLS)

To stop Schannel from offering AES 128 open the ‘AES 128/128’ key and create a REG_DWORD value ’Enabled’ with the hexadecimal value ‘0’. Then open the ‘AES 256/256’ key and create a REG_DWORD value ’Enabled’ with the hexadecimal value ‘C0’. This value enables AES 256 for TLS1 (the AES algorithms will not work with SSL3).

If you want to block everything apart from AES 256 then set ‘Enabled= 0’ for each of the other ciphers. You can achieve the same thing by opening the IAG configuration UI, then from the toolbar choosing ‘Admin/SSL Configuration’ and unchecking all the Symmetric Ciphers. Activate the IAG to update the registry. Whichever way you use, a reboot is required to make the new settings take effect.

Restart the IAG again and you are done

Now let’s try again with our browsers

Windows XP with IE7 still uses 128bit RC4 (or will fail to connect if you disabled everything except AES 256)

Windows Vista with IE8 and Windows XP with FF3 both now use AES 256

So what Browser/OS combinations can you use to get AES 256 support?

• IE7 upwards on Windows Vista (or Windows 7).
• Firefox on XP or Vista (I’ve not tested on Windows 7)

I’ve not tested Chrome, Safari, Opera or other browsers (or other non-Windows operating systems) so support may vary. But once you have configured IAG to offer AES256 it should be straightforward to test for any other browsers that you need to support.

Just remember that switching to 256 bit AES encryption is likely to take more processing power to handle than 128 bit RC4 encryption, (though it may actually be a better choice than 168bit 3DES) and being an SSL VPN, obviously IAG uses SSL extensively. Before choosing to use 256 bit encryption remember that you are gaining security at the expense of performance. Make sure you have the balance right for your organization and test to make sure performance and throughput are acceptable.

Author

Phil Bevan

Support Engineer – IAG Team

Microsoft - UK

Tech Reviewer

Noam Ben-Yochanan

Senior Program Manager – IAG Product Team

Accessing corporate emails via Active Synch trunk though IAG is a pretty cool feature. Being in Customer Service and Support Security we come across very diverse and interesting scenarios. A few days ago there was a support call about Active Synch trunk where users were not able to send out pretty heavy emails using their cell phones through IAG. It turned out to be a problem with emails having attachments size of 200K or greater - anything smaller works fine. On further scoping it turned out to be a very specific incident where users are using non-Windows mobile phones only.

Interestingly, some tweaking of an underlying component could make things work as expected so to understand where to look I had to investigate a bit. The OEM Partner who was working with me confirmed the following cell phones models (Nokia E66,E70,E71 Sony-Ericsson P1,P990i, Z770, C902, iPhone) seem to be reporting this behavior.

I started working towards identifying the component responsible for this behavior. To start with I had to see what’s happening inside the filter engine so I enabled the verbose logging to reproduce the scenario and then dumped the communication. Enabling tracing of the component involved actually gives quite a lot of detail about IAG activity to better understand how the request is being handled and parsed. It does show lots of function calls and if you do not have source code in front of you then it doesn’t make much sense but if you ignore the function calls and stick to HTTP communication straight away its pretty easy to understand and could make sense out of it.

In this scenario I am interested in looking inside the URLFilter so here are steps required to enable verbose tracing for the URL filter:

1. Browse to C:\Whale-Com\e-Gap\von\InternalSite\inc\trace.inc

2. Modify trace_on = false to trace_on = true and save the file

3. Browse to C:\Whale-Com\e-Gap\common\conf\trace.ini

4. Go to the last line of the file and add the following lines:

[Trace\WhlFilter]

*=xheavy

[note: please turn off this tracing as soon as you are done, as this will generate heavy logging on system]

My intention here was to look at the conversation between three entities, Mobile device, IAG filter and the back end CAS Server (Active Synch). Starting with request sent from Mobile phone to IAG filter and then from Filter to Webserver and then response all the way back from web server to IAG filter and eventually to mobile device.

So far all looks as expected. Moving further I can see the response coming back from the CAS server to IAG web filter and again nothing looks wrong here. Web server responded back with HTTP 200.

Now if all looks normal and expected then where is the problem ?

I decided to deep dive inside the filter engine on the same transactions (conversation) for analysis and uncover each and every expected function call for this communication.

This is quite a hectic job to analyze the engine tracing as it could contain a lot of data to look at but to keep things simple for this blog post I am cutting short lots of details. Here I was inside the engine, so I looked for errors in the functions that are being called, and found what I was looking for.
Debugging the engine stack showed me the following line in the trace:

* at line 0, file "ActiveSyncLogin.asp".

** 15.01.09 13:42:25.761 INTERNALSITE:GENERAL T3276

ERROR: Failed to access [http://187.67.43.10:80/Microsoft-Server-ActiveSync?User=faisal&DeviceId=IMEI372924929164255&DeviceType=IMEI372924929164255&SaveInSent=T&Cmd=SendMail] [007~ASP 0104~Operation not Allowed~]

Of course the last bit [007~ASP 0104~Operation not Allowed~] caught my attention and I reverted to my favourite search engine live.com and gave a search on this string and there you go with the exact response.

 [007~ASP 0104~Operation not Allowed~] showed interesting bit of information that suggests an amount of data that is larger than the value of the AspMaxRequestEntityAllowed property in the IIS metabase.

If a Content-Length header is present and if the Content-Length header specifies an amount of data that is larger than the value of the AspMaxRequestEntityAllowed property in the IIS metabase. The default value for the AspMaxRequestEntityAllowed property is 204,800 bytes.

This is documented in a KB article written for IIS http://support.microsoft.com/kb/327659 .

Since IIS is the underlying webserver on which IAG is mounted it was clear that metabase restriction on the webserver was blocking larger email attachments through Active Synch trunk. I increased the value to the required size and there we go, end users using non-Windows mobile could now send email attachments of the desired size through IAG active synch trunk as expected.

Please note best practice is not to tweak IIS metabase unless you know what you are doing but for this particular problem it was acceptable for our support partner and his end customers. Last but not least I don’t know how Windows Mobile handle this scenario but they work fine with larger attachments.

Faisal Hussain  CISSP, MCSE Security, MCSE, MCSA, MCTS

CSS Security - Microsoft UK

Scenario

Client computers connected via the IAG network connector (NC) to the LAN could access its network resources normally but failed to run WMI application queries against other computers.

Windows Management Instrumentation (WMI) is implemented using the Distributed Component Object Model (DCOM). This requires proper configuration of the firewall device(s) between the computer performing the WMI query and the destination computer.

In the ISA firewall running on the IAG server, DCOM communication  is allowed when strict RPC compliance is not required for the applicable rule that handles this traffic.  To resolve this problem I looked to see if Strict RPC compliance was enforced. It was. Turning off the strict RPC compliance for the Network Connector Access rule resolved the  issue in this scenario.

Steps to check for and disable strict RPC compliance option  

1) In the ISA server management console select the Firewall Policy on the left pane. Scroll down to the Whale::NetworkConnectorAccessRule under Firewall Policy Rules and right-click on that line, selecting the Configure RPC protocol option.

IAG SP2 introduced support for Dynamics CRM 4.0 Web application. This support enables IAG SP2 to protect and enhance the CRM servers – look here for more details. This support can be extended to the CRM Outlook client using the steps detailed below.

I. Adding the application on IAG

1. In a portal trunk, select to add a new application.

2. Select "Generic Client App" as the application type from the "Client/Server and Legacy Applications" combo-box:

3. Type a name to identify the application:

4. Fill in the server address and port, and make sure that the "Launch Automatically on start" option is checked:

5. In the “Portal Link” page, make sure that the "Add link on portal and toolbar" is unchecked and then click Finish

6. From the trunk’s application list, open the application that you just created. Go to the "Client Settings" tab and check the "Extended" option:

II. Configuring the CRM Outlook Add-on Configuration Manager

Prerequisites: The initial configuration of the add-on should be done from a domain-joined machine.

1. Run the CRM Add-on configuration manager and choose "My Company":

2. In the "Intranet Address" fill in the CRM server's name, uncheck the "Use the same Web address" checkbox, and in "External web address" fill in the IAG portal address followed with a "/MSCRMServices" path.

                                         .

Start working…

Now IAG users can use their CRM Outlook client. All they have to do is log in to the IAG portal. After login they will be able to use their CRM Outlook client for as long as their IAG session is valid.

Author: Chen Kirsch, IAG Product Team Application Group

Reviewer: Meir Mendelovich, Program Manager, IAG Product Team

Implementation Procedure: 

1.       Copy the file you wish to customize from the folder where it is installed by default to the CustomUpdate subfolder that is nested under it.

2.       If you want the changes you make to affect all trunks, copy the file without renaming it. This is always the method you should apply for Web Monitor changes; because the Web Monitor monitors all the trunks in IAG, it cannot be customized per trunk.

If you want the changes you make to be applied to a single trunk, rename the file: <Trunk_Name><Secure(0=no/1=yes)><OrigFile.extension>

Where:

·         <Trunk_Name> is the name of the trunk where you want the changes to take effect.

·         <Secure(0=no/1=yes)> : enter 1 for an HTTPS trunk or 0 for an HTTP trunk.

·         <OrigFile.extension> is the name of the original file, including file extension.

With the release of IAG 2007 SP2 (although this behavior can happen with any new update), we have been receiving some support calls about this subject and we want to bring some awareness about this behavior. Last year we published two posts about Active Sync configuration on IAG 2007:

http://blogs.technet.com/edgeaccessblog/archive/2008/07/24/publishing-microsoft-activesync-through-iag-2007-part-1-of-2.aspx

http://blogs.technet.com/edgeaccessblog/archive/2008/07/29/publishing-microsoft-activesync-through-iag-2007-part-2-of-2.aspx

When you use Part 1 of this article you will notice that step 9 advises to make a modification to the file \Whale-Com\e-Gap\von\InternalSite\ActiveSyncLogin.asp in order to enter the authentication repository. This works, but there is a caveat that wasn’t mentioned in the original post. The caveat is that changes made to IAG’s default ASP/INC/etc. files could be overwritten when software updates are applied to IAG. So the question now is: what should I do?

There are some others approaches to achieve this task and here are the options that you have:

Method A) Add a custom “.inc” file in the CustomUpdate Folder

·         How:

1.       Create a file named [TrunkName](0|1)ActiveSyncLoginStart.inc in ..\Whale-Com\e-Gap\von\InternalSite\inc\CustomUpdate\

2.       Within this file add the following content:

·         Pros: easy to customize, flexible and update independent, will be backed up with an IAG backup.

·         Cons: in comparison to the other methods, this requires an .inc file to be created for each trunk that runs ActiveSync and the file name needs to match the trunk name.

Method B) Create an ActiveSync specific repository that matches the domain name.

·         Pros: Works out of the box. There will be no need to edit or maintain custom files and it will be backed up with an IAG backup.

·         Cons: creates limitation in naming convention of repository.

Method C) Create a CustomUpdate ActiveSyncLogin.asp

·         How:

1.       Copy ActiveSyncLogin.asp from ..\Whale-Com\e-Gap\von\InternalSite to ..\Whale-Com\e-Gap\von\InternalSite\CustomUpdate

2.       Modify the version in the CustomUpdate directory

3.       Open the Advanced Configuration for the ActiveSync trunk

4.       Select the Authentication Tab

5.       Change the Login Page from ActiveSyncLogin.asp to /CustomUpdate/ActiveSyncLogin.asp

Here is the second part (first part is here) of how to secure access to your data center with IAG.

Implementing Data Center access with IAG

Which applications?

As a first stage, I would suggest that you route Web applications through IAG. This is where the user experience will be optimal and most protection will be provided. To do this you will need to publish these applications using the IAG Configuration console, and specify the security policies that will control access to these applications.

You don’t have to publish all Web applications at once through IAG. You can do this incrementally, starting with high business impact applications for which security is a high priority. Let other Web application and non-web traffic continue to flow directly to the application or Web server. Securing non-Web traffic requires additional considerations. The performance overhead will usually be significant, and pre-authentication of non-Web traffic requires IPSec deployment, which is fairly complex. You can read about deploying IPSec for deploying Server and Domain isolation at http://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/.

Making clients to go through IAG instead of directly reaching applications

So how do you make clients access the applications through IAG instead of accessing them directly? There are two potential strategies you can employ:

1.       If your clients access Web applications through an enterprise portal, modify portal links to the applications to point to IAG.

2.       Modify your DNS infrastructure to make clients go to IAG.

Allocate two DNS names to each Web application – one internal and one public.

Change the hostname of the application to be internal DNS name, and configure this internal name on the IAG settings for the published application. For example change http://crm è http://crm-internal and http://app1 to http://app1-internal .

Now there are two ways to make public names to point to IAG –

a.       Add the public DNS name (e.g. http://crm and http://app1) as an additional host name for the IAG trunk and point to the IAG IP address. This is the DNS name that users will use for quick access to the application through IAG. You will also need to include all public DNS application names on the SSL certificate used for trunk configuration, or use a wildcard certificate. This is shown in orange color on the diagram below.

b.      You can use a simple single name certificate with IAG’s portal name only (e.g. http://portal) by setting up a simple Web server to act as a “redirector”. To do this register all public DNS names (e.g. http://crm and http://app1) to resolve to the redirector IP and configure it to redirect all requests to IAG portal (http://portal). This is shown in blue color in the diagram below.

IAG portal

An IAG portal organizes all applications a user is authorized to access, and helps users to discover published applications without memorizing all the links or creating individual bookmarks.

When you deploy IAG in a data center, all your local users can benefit from IAG. If your organization already has a central portal with all corporate applications, you can choose to configure it as the initial IAG application, instead of using the built-in IAG portal. If you choose this option, you can still embed the IAG built-in portal application list as a Web part inside your enterprise portal. See “How to integrate the IAG portal into SharePoint” on how to do this.

IAG and NAP

If you have deployed NAP in your environment, then how do you deploy IAG with a Data Center alongside NAP?

Firstly you need to configure DHCP in order to assign clients that do not comply with NAP policy an IP address in a remediation network. You will then need to expose IAG to the remediation subnet, so that clients located there can access it.

In this scenario, you want IAG to perform endpoint security validation of unmanaged clients, but skip this check for managed computers, as NAP will perform this function for them. This can be achieved by configuring different policies for session access and privileged endpoint policies in the Endpoint Policies section of the trunk properties.

Assign managed clients as privileged endpoints. Do not require any endpoint settings, except for some specific file, folder, registry key or machine certificate that is provisioned on all you corporate desktops, and which is used to distinguish them from unmanaged computers.

Authentication and Single-Sign-On

A design choice that you need to make is whether to authenticate the users on IAG. Pre-authenticating users on IAG prevents any unauthorized traffic from ever reaching application servers. This is an important security function during remote access. As you would like to keep user experience simpler during access of applications from local network, it is desirable that they will not need to type credentials during the access, similar how they access the applications without IAG.

There are two ways to achieve this:

1. Use seamless authentication, when a browser is transparently authentications with IAG, without requiring user to enter credentials explicitly. Rest of this section will focus on how to achieve this with IAG with Integrated Windows Authentication (IWA) or Active Directory Authentication Services (ADFS) and Kerberos Constrained Delegation (KCD).
2. Require no authentication on IAG, so that IAG only enforces client health, but doesn’t pre-authenticate the users. This reduces the security IAG provides, but is usable in many scenarios.

Integrated Windows authentication

The first step is configuring front-end authentication – how users are authenticated by IAG. When you want to publish applications to your internal Active Directory users, the best choice would be Integrated Windows authentication, which uses Kerberos and NTLM protocols. When IWA is used, all users from IAG Active Directory forest and any trusted Active Directory forest will be able to login to IAG without re-typing their credentials. There are few things to be remembered before you configure IWA:

·         IAG server should be a member server of your Active Directory forest. If you plan also to use KCD to provide SSO to backend applications, IAG server and application server must be members of the same domain.

·         If you plan to use Kerberos as part of IWA, all public trunk names must be registered as SPN of IAG server. That includes published SharePoint servers’ external names. For instance if you have a trunk with a public name www.contoso.com and you IAG server is called my-iag-server, then you must access AD account of my-iag-server and add “http/www.contoso.com” as it’s SPN.

For more details about how to plan and configure IAG to use Integrated Windows authentication you can read “About publishing applications to users located on corporate networks with IAG SP2” and “Publishing applications to users located on corporate networks with IAG SP2”

Active Directory Federation Services

While Integrated Windows Authentication is mostly suited for internal users, the solution for your extranet users is to implement ADFS authentication on IAG. You can also use ADFS when establishing two-way trust between users and IAG domain is not possible.

IAG support ADFS v1 NT-tokens mode. There are several prerequisites to remember when you plan to use ADFS authentication on IAG.

·         IAG server should be domain member of Active Directory forest, where your applications (resources) are located.

·         NT-tokens mode requires shadow accounts configured in resource Active Directory forest. IAG supports user-to-user and group-to-user mappings between users’ forest and resource forests.

·         IAG requires that Federation Server Proxy (FS-P) will be implemented on IAG server.

For more information on implementing ADFS on IAG see - Enabling Active Directory Federation Services in IAG SP1. 

If your application supports ADFS authentication, you can allow users to directly authenticate to the application using ADFS, just don’t enable authentication delegation on IAG.

If your application doesn’t support ADFS, you can use Kerberos constrained delegation, described later on, to provide Single Sign-On experience to your partners’ users. By implementing ADFS on IAG, you can provide ADFS login to applications that are not extranet ready.

Authentication delegation and Single Sign-On

The next step is to plan how users will authenticate to the applications. There are several options for you to choose, each of them have different user experience, prerequisites, pros, and cons.

Kerberos constrained delegation provides full Single Sign-On user experience and users are not required to re-type their credentials. When KCD is performed, IAG performs Kerberos authentication to the application on behalf of the user. There are several things to be remembered before enabling KCD on IAG server.

·         The very trivial, but most forgotten one – application must support Kerberos authentication. Sometimes, when application states it supports Windows login, it really supports only the NTLM. A great tool to verify which authentication is supported by your web application is Wfetch.

·         If your application is servers farm that uses Load Balancer or Application Delivery Controller to distribute requests between servers, you’ll have to run all instances of your application on all servers under same security identity. Otherwise Kerberos authentication will not work. This means that instead of running your application pool with “Local System” identity, you’ll have to create application user, register your application SPN for that user and reconfigure all your servers to run application with this user identity. For more information on how to configure Kerberos authentication in IIS 6.0 please read Integrated Windows Authentication (IIS 6.0).

·         IAG server and application server must be members of the same Active Directory domain.

·         When your users reside in separate Active Directory forest, there should be two-way trust between users Active Directory forest and application Active Directory forest.

·         KCD requires Active Directory configuration changes each time you publish a new application that uses KCD. Don’t worry, IAG will help you to make the change easy and will create an LDIF script file that can be imported to your Active Directory, but you’ll need a help from someone with Active Directory administrative rights to actually import it.

All the details are available in “Configuring Kerberos constrained delegation with IAG SP2”

When implementing KCD is impossible you might want to consider implementing authentication pass-through. Since both the user and the application belong to either same or trusted Active Directory forests, we can assume that user can seamlessly login to the application directly using Integrated Windows authentication. The idea of authentication pass-through is to allow the user to authenticate directly to the application, once user authenticated to the IAG. This is possible with the NTLM protocol. So when you decide to use authentication pass-through, you’ll have to disable Kerberos in IAG trunk configuration, disable authentication delegation handling and enable authentication pass-through on IAG server.

When neither of the above options is possible to implement, you can still configure IAG authentication delegation.  User will be prompted for credentials when accessing the application, but only once through the session and these credentials can be reused to all applications that share same authentication server. For instance when you publish number of SharePoint servers that use same Active Directory, user will be prompted for credentials only when accessing first SharePoint server; when subsequently accessing other SharePoint servers, IAG will reuse provided credentials on behalf of the user and provide Single Sign-On experience.

Virtualized Data Centers

Many customers are planning and deploying virtualized data centers today. If you are one of those, you can deploy IAG as a virtual machine using the pre-configured IAG SP2 VHD. See my previous blog post at http://blogs.technet.com/edgeaccessblog/archive/2008/11/26/iag-sp2-goes-virtual.aspx for more details.

Authors

John Neystadt, Architect

Eli Tovbeyn, Sr. Program Manager

Technical Reviewers

Meir Mendelovich, Sr. Program Manager

Ran Dolev, Sr. Support Engineer

Noam Ben-Yochanan, Sr. Program Manager

Oleg Ananiev, Group Program Manager

John Neystadt is here again. Today I am blogging first part of an overview of how to protect Data Center applications with IAG. Hope you are enjoying the holidays. I will blog second part after they are over.

Changing threats blur the difference between remote and local access

For many years network and security departments engineered their networks around the concept of physical security. Establish a security perimeter; guard physical access to a building with human guards and badges; guard network perimeters with an access gateway using strong user authentication; verify endpoint compliance with a security policy that enables restricted access to corporate applications, knowing that when users connect remotely threats are greater than when they connect locally.

However, mobility and increased outsourcing have changed the threat landscape for local access. There are a number of questions that many security departments ask themselves today:

·        How do I know who connects to my Wi-Fi network from the parking lot or lobby?

·        How do I control which applications can be accessed from mobile phones?

·        Do I trust on-site vendors to the same degree as employees?

·        How do I mitigate the risk from guests’ unmanaged laptops that are allowed to access my business applications?

·        How do I enable and secure access to my data center for clients that are not controlled by my IT department. For example:

o   My company has recently merged with or acquired a company that uses a different desktop security standard.

o   My company has outsourced desktop management and I can’t control what is installed on desktops.

o   My IT environment is loosely coupled as is my organization (this is common for government, educational, and many other organizations). I am in control of the data center only, but not of the clients.

·        How do I enforce compliance for all above scenarios, and be able to monitor and audit all these activities?

If you are asking yourself one or more of these questions, than perhaps you are ready for reperimeterization - and IAG 2007 SP2 can help you.

Reperimeterization and the changing role of perimeter security

The idea behind reperimeterization (also known as deperimeterization) is simple. Let’s separate data centers and clients, and route all access to corporate applications through a data center gateway which provides the same level of security as that which we enforce for remote access.

What am I gaining from such a configuration?

1.      I can provides users coming from different domains or partners with  a great seamless single sign-on experience, without requiring them to explicitly enter credentials when accessing Web applications. This can be done using a combination of either Integrated Windows Authentication (IWA) or Active Directory Federation Services (ADFS), and Kerberos Constrained Delegation (KCD) authentication delegation.

2.      I can implement granular access control, based on the endpoint security state of the client (For example, is the endpoint patched? Is it running an antivirus with recent signatures? Is an anti-malware application turned on?). You might ask what the difference is between IAG and NAP endpoint policies. NAP is a great and simple way to enforce and automatically remediate endpoint compliance for environments that have standardized on a single desktop standard, as NAP expects a specific anti-virus or anti-malware to be present. NAP is binary about client compliance. If a client doesn’t comply with NAP, then the client is restricted to the remediation network. You certainly should use NAP for managed client computers. However, when dealing with loosely coupled environments or “unmanaged” computers - when you don’t control the clients and can’t enforce a uniform standard - you need a technology that enables “unmanaged” Windows, Linux and Mac clients to access a restricted set of applications while enforcing policies such as “must have any anti-virus” or “must have any anti-malware software installed”. In addition NAP supports Windows XP SP3 and newer client operating systems, and you can NAP for these client endpoints, in combination with IAG endpoint security to secure Windows 2000 and pre-Windows XP SP3 clients.

3.      I can monitor and log all application access using the IAG Web Monitor.