Microsoft Forefront Unified Access Gateway Product Team Blog : IAG

New White Paper: Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG)

edgeaccessblog — Mon, 20 Jul 2009 20:31:59 GMT

Even though we are focused on UAG these days, we and our partners still promote IAG and add more content for our community. Here is a blog cross-post from the CRM team blog on enabling ADFS for CRM using IAG. Most of the content of this paper is also true for UAG and for other applications like SharePoint.

By default, an on-premise implementation of Microsoft Dynamics CRM 4.0 leverages Active Directory (Integrated Windows) Authentication to accommodate access by internal users. However, many businesses also require the ability to provide external users with access to the highly sensitive information that is stored in the CRM system and to accommodate this access without having to create Active Directory trusts.

Because providing external access to internal CRM resources can also introduce potential security risks from both external and internal sources, in these scenarios, the CRM implementation must be protected by a gateway, such as Intelligent Application Gateway (IAG) 2007, which is sensitive to application logic and data and can ensure that internal and external users perform their routine tasks in a secure manner.

By using a combination of IAG and Active Directory Federation Services (ADFS) to establish an authentication gateway, companies can provide access to CRM resources by any identity, from any organization and from any computer, complete with strong authentication and full Single Sign On from the end user to the internal CRM system with a full audit trail (including username and source IP).

The white paper Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG), recently released by the MS CRM Engineering for Enterprise (E2) team, provides high-level guidance on using IAG to implement an ADFS solution for Microsoft Dynamics CRM 4.0. Developed in collaboration with the IAG team in Israel and the CRM Product team in Redmond, the document is available on Microsoft Downloads at:
https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=47ee7f73-6059-4b20-a305-1b8b2b23f0e9

Cheers,

Jim Toland

CRM Engineering For Enterprise

Performing WMI application queries on clients connected via the IAG Network Connector

edgeaccessblog — Tue, 31 Mar 2009 14:35:00 GMT

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.

2) Ensure that the Enforce strict RPC compliance option is not checked for this rule, and click OK.

3) Click Apply to save changes and update the configuration.

If another custom NC rule was created, ensure that the same is true for that rule.

For testing purposes, one other option could be to disable the RPC Filter globally. Care must be exercised as this might affect other rules on the system. If you have determined that it is safe to do so, this can be accomplished by selecting Add-ins on the left pane, selecting the Application Filters tab and right-clicking the RPC Filter. Select the Disable option:

Check the Apply option to save changes and update the configuration.

For more details on WMI and configuration in different scenarios, please check the following link: http://msdn.microsoft.com/en-us/library/aa389290(VS.85).aspx

Author

Renato Menezes

Security Support Engineer – IAG Team

Microsoft – North Carolina

Tech Reviewer

Vic Singh Shahid

Escalation Engineer – ISA /IAG Team

Microsoft – North Carolina

After installing IAG 2007 SP2 - Mobile Devices can no longer synchronize through IAG

edgeaccessblog — Thu, 15 Jan 2009 19:57:00 GMT

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:

<% 'This file defines the repository that is used for ActiveSync for this trunk.

repository = “[RepositoryName]”

· 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

6. Change the On-the-Fly Login Page from ActiveSyncLogin.asp to /CustomUpdate/ActiveSyncLogin.asp

· Pros: Very advanced option that is not recommended unless major parts of ActiveSyncLogin.asp are to be re-written and designed to persist on software updates, will be backed up an the IAG backup

· Cons: Updates to IAG that change ActiveSyncLogin.asp will not be applied to the custom file any changes to the default file will have to be monitored and merged into the custom file manually after every update.

Now you just need to plan which option best fits with your needs and start deploying it.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Tech Reviewers

Ran Dolev

Security Consultant – IAG Team

Microsoft – Israel

Ophir Polotsky

Forefront Edge Supportability Program Manager

Microsoft – Israel

John Redding

Security Support Engineer – IAG Team

Microsoft - Washington

Intelligent Application Gateway (IAG) 2007 Goes into Data Center with Service Pack 2 (SP2) – Part 2

edgeaccessblog — Thu, 08 Jan 2009 18:47:00 GMT

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:

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).
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

Publishing SharePoint with IAG 2007 – Part 1: What is SharePoint AAM and why do we need it?

edgeaccessblog — Sun, 12 Oct 2008 18:47:00 GMT

Hi,

My name is Meir Mendelovich and as a Program Manager in the IAG product group I’m responsible for SharePoint publishing. Over the last year IAG has made a tremendous leap in its SharePoint publishing capabilities. In May 2008 we released an update that introduced a new publishing mechanism and we are continuing to improve it.

In this post series I will elaborate on how this new publishing mechanism works, and will try to explain the logic behind it. I’ll also review some advanced SharePoint configuration options, and the implications for IAG.

Parallel with this blog post series, our User Assistance team recently updated our TechNet content with detailed step-by-step planning and deployment guides for SharePoint publishing.

Let’s start with the question in the post title, “What is SharePoint AAM and why do we need it?” As you know, starting with IAG SP1 Update 2 you can publish SharePoint using two application templates:

1. SharePoint Server 2007

2. SharePoint Server 2007 (Backward Compatibility)

The second template (Backward Compatibility) is the old method that works like most of IAG applications - whereby IAG analyzes the HTML content that is returned from the application and rewrites the links (a.k.a. link translation, link signature, HAT) so that they point to the IAG external address rather than the application internal address. Here‘s a description of the traditional application publishing mechanism:

What is SharePoint AAM?

AAM (Alternate Access Mapping) is a method that allows a server to perform URL changes on its own, so that reverse proxies such as IAG don’t have to change the content of the pages they serve to external sources.

Using AAM the SharePoint server replies with a page that already contains the public, resolvable from the Internet, URL (“https://HRPortal.contoso.com/b” in the example below) rather than the URL that is used internally (e.g. “http://HRPortal/b”). Each such public URL defines an “AAM zone”. There are up to five AAM zones available in the SharePoint configuration. Each zone has a unique name like “Intranet”, “Extranet” and “Custom”, although from a functional standpoint they are identical and it isn’t important which one is used.

SharePoint selects the AAM zone for each HTTP request according to the HOST header, protocol (HTTP or HTTPS) and port. Each combination of request parameters is defined by an “internal URL” definition. Each AAM zone has one or more internal URLs.

Every time an HTTP request is received, the SharePoint server attempts to match the request to one of the AAM zones’ internal URLs. When the HTTP response to this request is rendered, all the embedded links within it are formatted according to the external URL of that specific zone.

This drawing shows an example for such configuration:

Why do we need AAM?

AAM was created to support scenarios in which several different URLs are used to access the same content. This occurs with components such as load balancers, and with reverse proxies such as IAG. AAM is required in these scenarios because trivial link translation mechanisms fail. They fail because some of the links are embedded into ActiveX components, which cannot be rewritten by the link translation mechanism, or links are composed by scripts running on the client-side, so after the content has already passed through the link translation mechanism. Products that publish SharePoint 2007 without AAM experience reduced SharePoint functionality, with some SharePoint components not working as expected. This is mainly true for:

· Datasheets

· Explorer view

· InfoPath forms

· Office integration

· Excel Services

· Dashboards

I have seen a number of SSL VPN products that attempt to publish SharePoint without AAM and they all fail when publishing most of the above scenarios.

What to remember about publishing SharePoint with AAM

1. Select a new unique external URL to be used for accessing the SharePoint server. This URL is not identical to the IAG trunk’s URL although they must belong to the same parent domain. See an explanation about the domain names here.

2. After publishing SharePoint server using the new template, the SharePoint server AAM settings must be updated with the new external URL. See a step-by-step explanation here.

3. The trunk’s SSL certificate should include the new domain - as explained here.

4. The new domain should be registered on a public DNS server.

Anouncement: Two AES Ciphersuites (128/256 bits) are now supported

edgeaccessblog — Tue, 05 Aug 2008 15:15:00 GMT

Windows 2008 Server and Windows Vista were both released with support for SSL/TLS ciphersuites which use the AES symmetric encryption. Windows 2003 Server was released without these ciphersuites, and so IAG 2007 did not support them either. Recently Microsoft has released a hotfix for Windows 2003 Server which adds two TLS AES ciphersuites, one for 128-bit encryption and one for 256-bit encryption. Installing this hotfix on an IAG 2007 appliance will add support for the TLS AES ciphersuites. More information about the hotfix is available at http://support.microsoft.com/kb/948963/en-us

Publishing Microsoft ActiveSync through IAG 2007 – Part 2 of 2

edgeaccessblog — Tue, 29 Jul 2008 16:40:00 GMT

1. Introduction

We published the first part of this article, which had step by step details of how to configure Microsoft ActiveSync through IAG 2007. In this second part, we will cover troubleshooting the most common issues that we’ve encountered while publishing ActiveSync through IAG 2007.

2. Gathering Data

One of the most important areas that you need to be aware of in troubleshooting ActiveSync, is what data you need to collect. As a rule of thumb the following logs should be enabled for this scenario:

2.1. IAG Trace logs

Follow the steps below to enable this log:

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

[Trace\UserMgrCom]

*=xheavy

5. Save the file

Tracing will now start for both WhlFilter and UserMgrCom,. These logs will be located in \whale-com\e-gap\logs and should be named *.usermgrcom*.log and *.whlfilter.*.log

2.2. Filter log

Follow the steps below to enable this log:

1. Run regedit

2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter

3. Locate the LogFlag DWORD

4. Modify the value from HEX 0 to HEX 4

In about 30 seconds logging will start and the log will be located in \whale-com\e-gap\von\conf\websites\[TrunkName]\Logs\*WhlFilter.log

Note: These logs are very verbose and fill up disk space quickly. Therefore enable these logs only for troubleshooting purposes. After you’re done gathering the data you need, it is strongly recommended to disable all of them.

3. Troubleshooting Scenarios

The environment used for this troubleshooting guide is the following one:

Figure 1 – Basic diagram.

3.1. After completing the IAG configuration by following part 1, I’m getting an error when I try to synchronize my mobile device. I enabled the logs but there is nothing in there.

If this is the first attempt to synchronize after enabling the ActiveSync Trunk and the logs are empty, most likely you are running into a certificate issue. If you enable Netmon trace on the external NIC of the IAG server you will notice the following:

TCP Handshake on port 443

192.168.0.185 192.168.0.181 TCP TCP:Flags=......S., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337408, Ack=0, Win=32768 (scale factor 0) = 32768

192.168.0.181 192.168.0.185 TCP TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=1032, PayloadLen=0, Seq=2541104422, Ack=337409, Win=16384 (scale factor 0) = 16384

192.168.0.185 192.168.0.181 TCP TCP:Flags=...A...., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337409, Ack=2541104423, Win=33580 (scale factor 0) = 33580

SSL Handshake

192.168.0.185 192.168.0.181 SSL SSL: Client Hello.

192.168.0.181 192.168.0.185 SSL SSL: Server Hello. Certificate. Server Hello Done.v

- Ssl: Server Hello. Certificate. Server Hello Done.

- TlsRecordLayer:

ContentType: HandShake

- Version: TLS 1.0

Major: 3 (0x3)

Minor: 1 (0x1)

Length: 1426 (0x592)

- SSLHandshake: SSL HandShake TLS 1.0 Server Hello Done(0x0E)

HandShakeType: ServerHello(0x02)

Length: 70 (0x46)

+ ServerHello: 0x1

HandShakeType: Certificate(0x0B)

Length: 1344 (0x540)

- Cert: 0x1

CertOffset: 1341 (0x53D)

- Certificates:

CertificateLength: 1338 (0x53A)

- X509Cert: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

+ SequenceHeader:

- TbsCertificate: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

+ SequenceHeader:

+ Tag0:

+ Version: v3 (2)

+ SerialNumber: 0x612021a7000000000007

+ Signature: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

+ Issuer: Denver CA,contoso,com

+ Validity: From: 09/26/06 22:45:52 UTC To: 10/10/10 09:18:23 UTC

+ Subject: *.contoso.com

+ SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)

+ Tag3:

+ Extensions:

+ SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

+ Signature:

HandShakeType: Server Hello Done(0x0E)

Length: 0 (0x0)

192.168.0.185 192.168.0.181 SSL SSL: Client Key Exchange. Change Cipher Spec. Encrypted Handshake Message.

192.168.0.181 192.168.0.185 SSL SSL: Change Cipher Spec. Encrypted Handshake Message.

192.168.0.185 192.168.0.181 TCP TCP:Flags=...A...F, SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337659, Ack=2541105897, Win=33580 (scale factor 0) = 33580

What happen here is that the *.contoso.com certificate was issued by a CA (the Denver machine) that the client (Windows Mobile) does not trust. To fix this problem follow the instructions from KB915840 to add the root CA certificate to your mobile device.

3.2. I have added the root CA certificate to my mobile device and I was able to connect and synchronize just fine. However, after working for a while, I’m now getting the message below when I try to synchronize:

Figure 2 – Error trying to synchronize

This is a very generic error, so the best approach here is to get a Netmon trace, but this time on the internal interface of the IAG server. Gather also the logs that were enabled in session 1. Let’s see the result:

From UserMgrCom log:

Authentication Request

** 25.07.08 10:05:52.257 USERMGR_SERVICE:GENERAL T5900

AuthenticateUser got [CAuthenticateUserIn:

m_repository = [AD]

m_user = [administrator]

m_password = [**Confidential**]

m_domain = [contoso]

m_param_vec = <EmptyField>

m_site_name = [activesynctrunk]

m_secure = [1]

m_session_id = [22B36058-D0B7-4A6E-A8A6-EDD7DF35E325]

m_login_type = [2]

m_source_ip = [192.168.0.183]

]

* at line 334, file "src/UserMgrCore.cpp".

** 25.07.08 10:05:52.257 CONFIGMGR_SERVICE:GENERAL T5900

Get the site [activesynctrunk] secure [1] info.

* at line 555, file "src/SiteContainer.cpp".

Authentication Succeed:

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Authenticate the user [administrator] domain [contoso] in the ldap server [10.1.1.6] port [389] dn [CN=Users,DC=contoso,DC=com] type [Active Directory]

* at line 320, file "src/Ldap.cpp".

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Connect user [administrator] domain [contoso].

* at line 2178, file "src/Ldap.cpp".

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Connect with bind auth negotiate.

* at line 2209, file "src/Ldap.cpp".

** 25.07.08 10:05:52.288 USERMGR_SERVICE:GENERAL T5900

Connect success

After authentication, IAG needs to contact the Exchange Server to access the ActiveSync URL. At this point, IAG attempts to resolve the name of the Exchange server, as specified in step 6 of the previous article. If the name cannot be resolved the connection will fail, as seen below:

10.1.1.5 10.1.1.6 DNS DNS:QueryId = 0x8442, QUERY (Standard query), Query for mail.contoso.com of type Host Addr on class Internet

10.1.1.6 10.1.1.5 DNS DNS:QueryId = 0x8442, QUERY (Standard query), Response - Name Error

To fix this problem enable the IAG server to resolve the name that appears in step 6 of the previous article. After fixing this problem, you should see the following traffic on the internal network:

10.1.1.5 10.1.1.6 DNS DNS:QueryId = 0x234E, QUERY (Standard query), Query for mail.contoso.com of type Host Addr on class Internet

10.1.1.6 10.1.1.5 DNS DNS:QueryId = 0x234E, QUERY (Standard query), Response - Success, 49, 0

10.1.1.5 10.1.1.6 TCP TCP:Flags=......S., SrcPort=1718, DstPort=HTTP(80), PayloadLen=0, Seq=1407512359, Ack=0, Win=32768 (scale factor 0) = 32768

10.1.1.6 10.1.1.5 TCP TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=1718, PayloadLen=0, Seq=2078452756, Ack=1407512360, Win=16384 (scale factor 0) = 16384

10.1.1.5 10.1.1.6 TCP TCP:Flags=...A...., SrcPort=1718, DstPort=HTTP(80), PayloadLen=0, Seq=1407512360, Ack=2078452757, Win=32768 (scale factor 0) = 32768

10.1.1.5 10.1.1.6 HTTP HTTP:Request, POST /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 401, URL: /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 TCP TCP:[Continuation to #48]Flags=...AP..., SrcPort=HTTP(80), DstPort=1718, PayloadLen=409, Seq=2078454217 - 2078454626, Ack=1407512979, Win=64916 (scale factor 0) = 64916

10.1.1.5 10.1.1.6 HTTP HTTP:HTTP Payload, URL: /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 TCP TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=1718, PayloadLen=0, Seq=2078454626, Ack=1407512992, Win=64903 (scale factor 0) = 64903

10.1.1.5 10.1.1.6 HTTP HTTP:Request, POST /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 100, URL: /Microsoft-Server-ActiveSync

5. Conclusion

This troubleshooting guide covers two common problems that might arise when configuring a Microsoft ActiveSync Trunk on IAG 2007. Although this article does not cover all possible issues and resolutions, it should give you a good overview of the troubleshooting steps, and the approach to gather and analyze data for ActiveSync publishing through IAG 2007.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Technical Reviewer

Ran Dolev

Security Consultant – IAG Team

Microsoft – Israel

Publishing Microsoft ActiveSync through IAG 2007 – Part 1 of 2

edgeaccessblog — Thu, 24 Jul 2008 04:04:00 GMT

1. Introduction

Publishing Microsoft ActiveSync through IAG 2007 in theory is pretty straight forward. When I say in theory it is because just following the wizard steps may not be enough. There are some scenarios that require you to make customizations to the configuration after finishing execution of the wizard.

This post will be divided in two parts as follow:

· Part 1: Will explain how to create a Microsoft ActiveSync Trunk and how to customize authentication. We will also use the Windows Mobile 6.1 Professional Emulator to simulate the external Mobile device.

· Part 2: Will explore the most common issues with IAG and ActiveSync, and how to troubleshoot them.

2. Scenario

For the purpose of this guide, IAG 2007 is a standalone server, the mobile device is a Windows Mobile 6.1 device, and the Domain Controller is running Exchange 2007 with active sync enabled for all users.

3. Configuring the ActiveSync Trunk

Open the IAG 2007 Configuration Console and follow the steps below:

1) On the main menu, expand HTTPS Connections, right click on it and choose New Trunk. Select Webmail Trunk as show below:

Figure 1 – Selecting the trunk type.

2) Click Next and choose the option Microsoft ActiveSync as show below:

Figure 2 – Choosing the Webmail trunk type.

3) Click Next and type the trunk name, the external IP and the ports that this trunk will listen on, as showed below:

Figure 3 – Trunk information.

4) Click Next and in the “Step 4 Authentication” window you will select the authentication repository. For the purpose of this demo we are using a repository named “AD” which is an Active Directory repository. To select the repository click the Add button and select your repository from the list. There is no need to adjust any of the remaining settings and you can leave the options at their defaults, click Next.

Figure 4 – Selecting the authentication repository.

5) In the next window you should select the certificate that will be used for this trunk. For this demo we are going to use the wildcard certificate *.contoso.com as show below:

Figure 5 – Certificate selection.

6) Click Next and now you need to type the information about your Exchange Server. The IP address, port number and the hostname are all required. After finishing that click Next to continue.

Figure 6 – Certificate selection.

Note: For this purpose of this demo we are going to use HTTP (port 80) to communicate with the Exchange Server, this is to facilitate the troubleshooting we will do in Part 2.

7) Again, you will need to specify which authentication repository you will use so IAG can auto reply to authentication requests that Exchange might send out. We must select the same authentication repository we set earlier to allow the system to negotiate authentication without having to prompt you again for authentication. Click Next.

Figure 7 – Authentication repository for auto reply.

8) Click Next, leave the default endpoint policy selected and then click in Finish to conclude the wizard.

Figure 8 – Endpoint policy Selection.

9) Since the repository name (AD) is not the same as the domain name (CONTOSO) we need to edit the file \Whale-Com\e-Gap\von\InternalSite\ActiveSyncLogin.asp and change the line below:

Figure 9 – Customizing the activesynclogin.asp file.

10) After changing that, save the file and close it.

11) In the IAG Configuration Click in File and Activate (or CTRL + G), type your passphrase if it is requested.

12) Click Activate and OK.

4. Testing the Access

Now that this feature is enabled on the IAG, let’s see how it will be presented to the final user. As mentioned before we are going to use the Windows Mobile 6.1 Emulator to simulate the external Mobile device. The exact image that is going to be used in this demo is called Windows Mobile 6 Professional. Here are some briefings about this tool:

- Make sure to bind the application to the network where you are testing access from. Refer to the article Establish Network Connectivity on the Emulator from Microsoft TechNet for more information on this.

- Use the Windows Mobile 6 Emulator help file to configure the IP address, name resolution and Exchange Connectivity. You also can use the tips from this blog post to configure the device.

- To get more experience with this tool you also can practice using the TechNet Virtual Labs for Windows Mobile with Exchange 2007.

After configuring the Windows Mobile Emulator client to access the trunk in Active Sync you can try to synchronize. After synchronize you should see the Windows Mobile window showing the user’s inbox as show the example below:

Figure 10 – Windows Mobile Emulator.

5. Conclusion

In the first part of this guide we saw how to create the trunk and use the Windows Mobile Emulator to synchronize from the outside network. The next part of the guide we will explore the most common issues with IAG and ActiveSync and how to troubleshoot them.

Stay tune.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA

Walk-through for RSA SecurID Authentication for IAG 2007 – Part 2 of 2

edgeaccessblog — Wed, 23 Jul 2008 03:27:00 GMT

Last post we reviewed the RSA Agent configuration, now we are going to cover the IAG.

IAG 2007 Configuration

• Install the RSA Authentication Agent on the IAG server.

• IAG 2007 uses the RSA supplied authentication agent to communicate with and verify credentials against, the RSA Authentication Manager. The RSA Authentication Agent is typically supplied with your RSA software package. It is also available directly from RSA.

• NOTE: The installation of the RSA Authentication Agent on the IAG server will update the GINA on the server. However, you can still provide AD credentials when logging in to the IAG 2007 server.

• Test authentication and create the Node Secret

• After installing the RSA Authentication Agent, and rebooting the server, launch the RSA Security Center application on the IAG server. In RSA Security Center, select ‘Authentication Test’ and click the ‘Test’ button. In the Authenticator drop-down list, select ‘Key fob, standard card, PINPad. For User name, enter a user name that has been created on the RSA Authentication Manager. For Passcode, enter the Passcode shown on the token that is currently associated with the user name entered.

This test will:

1. Verify the connection between the IAG server and the RSA Authentication Manger

2. Verify that the credentials and Passcode supplied are valid

3. Establish the Node Secret between the IAG server and the RSA Authentication Manager. The established Node Secret is stored in the registry on the IAG server.

Figure 1

• Configure RSA SecurID authentication on the IAG server

• In the IAG Configuration application, under HTTPS Connections, select the relative Portal/Trunk. Under the ‘Security & Networking’ section, click Configure next to ‘Advanced Trunk Configuration’.

• In the Advanced Trunk Configuration dialog, select the Authentication tab and click ‘Add’. In the ‘Authentication and User/Group Servers dialog, click ‘Add’.

• In the ‘Add Server’ dialog, select ‘ACE’ in the Type drop-down list. Enter a name to represent this authentication server (i.e. SecurID). Enter the IP address of the RSA Authentication Manager server. The default port for SecurID authentication is 5500. If the RSA Authentication Manager has been configured with an alternate/non-default port, enter the port number here. Click OK. Activate the Configuration.

Figure 2

• The Portal login page will now have the SecurID authentication type available. Note that if you have configured multiple Authentication servers in your Portal, when logging into the Portal, you will need to make sure you select the RSA SecurID authentication type from the available choices in the ‘Directory’ drop-down list.

Figure 3

Author

Richard Barker

Security Support Engineer – ISA/IAG Team

Microsoft – NC

Publishing Windows 2008 Terminal Services Farm (session broker) behind IAG 2007

edgeaccessblog — Tue, 22 Jul 2008 17:08:00 GMT

The Terminal Server Session Broker Load Balancing feature allows to evenly distribute the session load between servers in a load-balanced terminal server farm. With TS Session Broker Load Balancing, new user sessions are redirected to the terminal server with the fewest sessions.

Using TS Session Broker to load balance sessions involves two phases:

1. In the first phase, initial connections are distributed by a preliminary load-balancing mechanism, such as Domain Name System (DNS) round robin. After a user authenticates, the terminal server that accepted the initial connection queries the TS Session Broker server to determine where to redirect the user.

2. In the second phase, the terminal server where the initial connection was made redirects the user to the terminal server that was specified by TS Session Broker. The redirection behaviour is as follows:

•	A user with an existing session will connect to the terminal server where their session exists.
•	A user without an existing session will connect to the terminal server that has the fewest sessions.

For more details on Session broker please refer to the following TechNet article:

http://technet2.microsoft.com/windowsserver2008/en/library/902a6081-9ecd-45ec-96ee-f51097d71c8c1033.mspx?mfr=true

Publishing Terminal Server farm using Windows 2008 Session Broker server behind IAG 2007 appears to be a challenge. You would be essentially publishing it as one of the Terminal Services application over an HTTP/S Trunk. The problem is when you publish the session broker server via IAG assuming that DNS Round Robin configured for load balancing will enable session broker to distribute the terminal session to the backend farm effectively it will not work for end user connecting through IAG to this farm.

IAG is aware of only one published Terminal Server – the Session Broker – and will therefore route terminal service requests from end users only to this server. What Session Broker does for load balancing at the backend is that it redirects sessions to another terminal server in the farm, and this is essentially a new session request from IAG perspective each time.

When, after being load balanced, this traffic is sent from the client back through IAG towards another terminal server in the farm, IAG will not treat this as a valid request since in the IAG configuration the Terminal Services application exposes only the Session Broker server. With this configuration when a client connects via IAG server to a Session Broker managed farm, the client gets an error message saying “the client cannot connect to the remote computer”, as no handling is performed by the IAG SSL VPN components on the client side in order to intercept RDP traffic to this other terminal server.

To solve this problem we have to consider using Socket Forwarder and publishing the entire Terminal Server farm and not only the Session Broker server.

Here is the step by step configuration:

1. Publish the Terminal Server application for the entire farm by specifying all the terminal servers IP addresses (single/ranges/subnets) and hostnames (all listed manually or by using wildcards).

2. Set one Terminal Server as the jump-start and set it as a lead server.

3. The MSTSC.exe client will connect initially to that server, but if the TS session broker will "redirect" to another terminal server in the farm (either by its name or its IP address) the Socket Forwarding component will intercept and route that RDP traffic to the appropriate server seamlessly.

4. Without Socket Forwarder installed, only the first server on the list is supported.

Author: Faisal Hussain

Developer Support - Security

UK GTSC Developer Internet Team

Walk-through for RSA SecurID Authentication for IAG 2007 – Part 1 of 2

edgeaccessblog — Tue, 22 Jul 2008 16:58:00 GMT

RSA Authentication Manager Server Configuration

Disclaimer: Many of the steps outlining the configuration of the RSA Authentication Manager software are not directly supported by Microsoft. They should be used as a guideline to help familiarize and guide you in this configuration. For additional assistance in directly configuring the RSA Authentication Manager Software, please review your RSA SecurID documentation.

Creating Users and Agent Hosts

• Import Tokens from Seeds files

The seed can be an *.asc or *.xml file and is typically supplied with the token<s>. The seed is the tokens’ factory encoded random key. Each token has a unique key (seed). The seed file is imported into the associated RSA Authentication Manager server.

• Add users and assign a Token to each user

User accounts information is added to the RSA Authentication Manager. These accounts can be AD accounts or manually created. Each account created is assigned a Token.

Figure 1

• Synchronize the Token

Each Token has a built-in clock that must be in sync with the RSA Authentication Managers’ clock. If the Tokens’ clock is out of sync, authentication will fail. It is typically a good idea to synchronize the Token after assigning it to a user.

• Create Agent Host

Agent Hosts are servers or devices that directly authenticate against the RSA Authentication Manager. In this case, the Agent Host is the IAG server.

• Use the resolvable FQDN for the Agent Host

When creating the Agent Host entry, make sure to use the Fully Qualified Domain Name of the IAG server. Also make sure that the RSA Authentication Manager server can correctly resolve this FQDN to the correct internal IP address of the IAG server.

• Select “Net OS Agent” as the Agent Type

Figure 2

• Activate Users on the Agent Host.

For any Agent Host to successfully authenticate a user, that users account must be Activated on that Agent Host.

Figure 3

Create Configuration Files and Node Secrets

• Create SDCONF.REC file for the Agent Host

The SDCONF.REC can be generated for each Agent Host. Or a single SDCONF.REC can be generated for all Agent Hosts. The SDCONF.REC contains RSA Authentication Manager configuration information. This includes ports, processes, etc., essential to the authentication service.

• Copy each SDCONF.REC file from the RSA Authentication Manager to its matching Agent Host computer (i.e. IAG server). Copy to …\system32 folder on the IAG server.

Author

Richard Barker

Security Support Engineer – ISA/IAG Team

Microsoft – NC

Configuring and Troubleshooting File Access through IAG 2007 – Part 2 of 2

edgeaccessblog — Thu, 10 Jul 2008 22:39:00 GMT

1. Introduction

Most of the problems that could potentially occur with this feature are usually exposed during implementation. In many situations problems happen because key points were not considered or addressed prior to the implementation. During the troubleshooting phase the most important thing is to know how to gather the right information in order to analyze and identify the root cause. This part of the post will focus on this piece and it is an important one.

2. Scenarios

For the purpose of this guide, there it will be presenting two problems and the approach for the troubleshooting. Let’s start with the first problem:

I’m configuring the File Access, when I click in Domain and then click in Refresh, the right pane shows up blank and the status bar is already showing as Ready.

Before even start to troubleshoot this, it is important to find out if you are really capable to browse the Network Neighborhood / Windows Network through Windows Explorer. If you are not, than fix this first before move on. A good start to address issues with computer browser in the OS side is by following the KB 188305.

I fixed this part, now I’m able to browse using Windows Explorer and also through IAG. However, when I select a computer, click apply, select share and click in refresh it says: No shares in this server. But it does have because I can access directly from start / run and type the UNC path for that share.

The question remains: are you able to access this share using Windows Explorer? If not then you need to fix this first before move on to IAG. Simply access directly the UNC path just proves that you have the path (no roadblock in the middle) and the authorization to access, but the browser list it is different. This is the reason why you need to address the browsing side first.

What you can also do in order to get more information about the error is by enabling the IAG File Access tracing. To do that, follow the steps below:

1) Open the folder \Whale-Com\e-Gap\von\InternalSite\inc\ and edit the trace.inc file.

2) Change the value trace_on to true (trace_on=true) and save the file.

3) Open the folder \Whale-Com\e-Gap\common\conf\ and edit the trace.ini file. Go to the bottom of the file and add the line below:

[Trace\ShareAccess]

*=xheavy

Note: hit ENTER after *=xheavy to commit.

4) Save the file and reproduce the problem.

5) The log files will be located at \Whale-Com\e-Gap\logs and the file name will be following the standard below:

SERVERNAME.ShareAccess.default.DATE.TIME.log

If you want to go beyond, what you can do is also enable Netmon in the internal interface of IAG and starts the capture while trying to configure the resource.

Ok I got the file, now what should I do?

This file is really verbose and has lots of information that can help to identify the root cause for the problem. Let’s take a look in the main portion of this log file:

Here we start validating the user:

** 19.06.08 16:23:27.161 SHAREACCESS:GENERAL T3860

SetUserData start: domain=[contoso], user=[administrator]

* at line 129, file "src/ShareEnum.cpp".

The validation is done successfully:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3860

SetUserData end: domain=[contoso], user=[administrator] - SUCCESS

* at line 143, file "src/ShareEnum.cpp".

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: path [servers/server] type [2]

* at line 458, file "src/Settings.cpp".

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: after reading the xml include all 1

* at line 503, file "src/Settings.cpp".

Number of share that were previously selected:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: num of shares [2]

* at line 513, file "src/Settings.cpp".

The share in the DALLAS computer is marked as it needs to show the shared folders:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: the share [CONTOSO\DALLAS] is marked [1] have the provider [MS]

* at line 538, file "src/Settings.cpp".

No need to show the shared folders in the IBIZA computer:

** 19.06.08 16:23:27.171 SHAREACCESS:GENERAL T3956

CSettings::GetObjects: the share [CONTOSO\IBIZA] is marked [0] have the provider [MS]

* at line 538, file "src/Settings.cpp".

Starts to enumerate the shares:

** 19.06.08 16:23:27.181 SHAREACCESS:GENERAL T3860

AdmEnumerateShares start

* at line 92, file "src/ShareEnum.cpp".

Failed to enumerate the shares:

** 19.06.08 16:28:10.138 SHAREACCESS:GENERAL T3860

AdmEnumerateShares end - FAIL

* at line 118, file "src/ShareEnum.cpp".

Ok, we failed to enumerate the shares, now we need an extra help from netmon trace. Let’s see what we have it:

In the beginning of the trace we have the server DALLAS announcing itself as the master browser:

DALLAS 10.255.255.255 BROWSER BROWSER:Host Announcement, ServerName = DALLAS

Later one, the handshake…

IBIZA DALLAS TCP TCP:Flags=......S., SrcPort=2395, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2961358224, Ack=0, Win=65535 (scale factor 0) = 65535

DALLAS IBIZA TCP TCP:Flags=...A..S., SrcPort=NETBIOS Session Service(139), DstPort=2395, PayloadLen=0, Seq=2095277429, Ack=2961358225, Win=16384 (scale factor 0) = 16384

IBIZA DALLAS TCP TCP:Flags=...A...., SrcPort=2395, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2961358225, Ack=2095277430, Win=65535 (scale factor 0) = 65535

.. and the IAG server trying to retrieve information directly from DALLAS but it doesn’t receive and answer:

IBIZA DALLAS NbtSS NbtSS:SESSION REQUEST, Length =68

Then IAG Server starts to broadcast trying to find someone that has list:

IBIZA 10.255.255.255 BROWSER BROWSER:Get Backup List Request

IBIZA 10.255.255.255 NbtNs NbtNs:Query Request for CONTOSO <0x1B> Domain Master Browser

IBIZA 10.255.255.255 BROWSER BROWSER:Get Backup List Request

IBIZA 10.255.255.255 NbtNs NbtNs:Query Request for CONTOSO <0x1B> Domain Master Browser

IBIZA 10.255.255.255 BROWSER BROWSER:Get Backup List Request

IBIZA 10.255.255.255 NbtNs NbtNs:Query Request for CONTOSO <0x1B> Domain Master Browser

IBIZA 10.255.255.255 NbtNs NbtNs:Query Request for CONTOSO <0x1E> Browser Service Elections

For this particular problem, the issue was with the DALLAS server: customer installed a personal firewall on it and it was blocking the UDP traffic.

3. Conclusion

We can conclude it here that this is more likely a networking issue rather than an IAG issue. Therefore the test of accessing the share directly through UNC cannot be considered conclusive. You really need to focus on the Windows Browsing through Windows Explorer.

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

Technical Reviewer

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA

Configuring and Troubleshooting File Access through IAG 2007 – Part 1 of 2

edgeaccessblog — Thu, 10 Jul 2008 22:36:00 GMT

1. Introduction

One of the features that IAG 2007 offers is the capability to allow access to internal shares in a secure and easy manner. A corporate user in the office is able to browse the network neighborhood to access shares. Sometimes, users need to do the same task but remotely and it is within this scenario that IAG 2007 differentiates itself from others. The File Access feature allows you to configure the servers that remote clients can use to access shares and files over the web through the portal.

You might be asking: how this series of posts differentiates itself from the IAG User Guide?

Although the IAG User Guide is very complete in most tasks that we have on IAG, we have received lots of feedbacks about customer ready documentation. In other words: the public uses the IAG 2007 User Guide as their main reference, but they also need separate guides for some tasks with more details on the troubleshooting side for that feature.

This post will be presented in two parts:

· The first one will cover the requirements, caveats and configuration

· The second part will cover troubleshooting steps to narrow down the problem and help to find the solution.

2. Scenario

For the purpose of this guide, IAG 2007 is member of the domain CONTOSO. There is an ISA Server 2006 in the edge publishing the portal using HTTPS.

3. Before You Begin

Before you begin it is important to emphasize some key points that you need to address before start the configuration:

· File Access is dependent on Computer Browser therefore it is recommended that you have a good understanding of the requirements for this feature to work properly on the platform side. For more information on this, read the How Computer Browser Service Works paper from Microsoft TechNet.

· The above statement means that if the Windows Server that IAG 2007 is installed, can’t browse the network neighborhood through Windows Explorer, IAG also will not able to do it. Therefore it is recommended to work on this side, make it work smoothly before start to configure IAG .

· If you have a firewall in between IAG 2007 and the Internal Network, make sure to allow the Computer Browser ports to pass through. For more info on these ports check the session Computer Browser on the Service overview and network port requirements for the Windows Server system article at Microsoft Help and Support.

· Review the requirements for joining an IAG 2007 to the Windows Domain (pages 215 to 217 of the IAG User Guide).

If you are compliant with all those points, them it is time to move on and configure the File Access feature.

4. Configuring File Access

Open IAG 2007 Configuration console and follow the steps below:

1) On the main menu, click in Admin and then File Access.

Figure 1 – Accessing File Access.

2) The following warning message will appear if you are configuring this feature for the first time:

Figure 2 –File Access warning about the NetBIOS requirement.

3) Click OK and the File Access window will appear, but right after that it also prompts you for authentication. Here you need to type a domain credential for a user that has permission to browse through the network and access those shares. You should use an account with Domain Admins privileges at least for this configuration phase.

4) The File Access window will appear and might not initially populate the right pane; however this could be due the browse delay. Here what it is really important to be sure is that you wait until the status bar shows as Ready. Do not click in other parts of the window if the status bar is saying Busy, wait until all the components are loaded.

Figure 3 –File Access window, attention on the status bar where it says Ready.

5) Select the domain, in this case CONTOSO and click in Apply. Wait until the status bar says Ready and click in Servers in the left pane.

Figure 4 – Server’s selection.

6) Click in Refresh and wait. This can take really long if your domain has lots of servers. A good test to do before start the configuration is see how long it takes to browse the servers for this domain using Windows Explorer.

7) Select the Server that you want to access the shares and click in Apply, wait until is ready and click in Shares in the left pane.

8) Notice that in the top right side, where it says Select Domain to Refresh, you now have the domain\server. What you need to do to show the shares is click in Refresh and wait until it shows up.

9) When the shares appear, select each shared folder that you want to make it available to the user through the portal and click in Apply.

Figure 5 – Selecting the shares.

10) Click in Close.

After enabling the File Access feature you now need to publish it through the portal, to do that follow the steps below:

1) In the Applications Pane, click in Add.

2) Select the first built in service which is File Access and click in Finish.

3) Click in File and Activate (or CTRL + G).

4) Type your password and activate.

5. Testing the Access

Now that this feature is enabled on the IAG, let’s see how it will be presented to the final user. First thing to remember is that the endpoint computer needs to be compliant with the policy to be able to access this feature. Here it is the screen that will appear on the client side when it tries to access this feature:

Figure 6 – File Share in the User’s perspective.

Next session you will learn tools and techniques to troubleshoot File Access on IAG 2007.

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

Technical Reviewer

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA