Web Application Proxy Event 13007

Written by Robert Kettel

When you start to use Web Application Proxy Server (WAP) as a replacement for ISA, TMG or UAG and publish Active Sync through it, you might face a lot of Event 13007 warnings in the Microsoft-Windows-Web Application Proxy/Admin event log (I mean, really “a lot”). These are paired with various Event IDs 13006 (“Connection to the backend server failed. Error: (0x80072efe)”).

On the other hand, you don’t get any complaints from the user community. There does not seem to be an impact at all.

Where do these warnings come from? Do they impact our service and can we prevent them from showing up over and over again?

The main cause for the warning 13007 and 13006 is how devices with Exchange Active Sync (EAS) and Direct Push technology connect to Exchange.

Following this Microsoft TechNet article, “a mobile device that’s configured to synchronize with an Exchange 2013 server issues an HTTPS request to the server. This request is known as a PING. The request tells the server to notify the device if any items change in the next 15 minutes in any folder that’s configured to synchronize. Otherwise, the server should return an HTTP 200 OK message. The mobile device then stands by. The 15-minute time span is known as a heartbeat interval.”

With other words, there is a steady HTTPS session for 15 minutes between the EAS device and the Exchange backend which must be supported by all components taking part in the HTTPS session build, usually firewalls, load balancers and (in our case) the WAP servers which proxy the HTTPS session coming from the LBs to the Exchange backend. The long lasting session request is finally terminated by the Exchange server by posting an HTTP 200 message.

Now, looking at the default settings of our WAP servers we find a parameter which can have an influence on that behavior.
The default value for the InactiveTransactionTimeoutSec parameter is 300 (= 5 minutes). That means that if the accessing party does retrieve new responses from the backend service defined in the application settings for more than 5 minutes, the connection is identified as “timed out” and dropped by the WAP server.

From that perspective a connection to the Exchange Backend Service is timed out for the Web Application Proxy (causing a warning event 13007), when
a) the heartbeat interval of Direct Push is longer than the InactiveTransactionTimeoutSec
AND
b) the session was not renewed by the device
AND
c) there was nothing to synchronize in the first 300 seconds of the connection

However, if the device’s HTTPS session is dropped by the WAP server, it will automatically re-initiate a new session (the same what the device would do when getting an HTTP 200 OK message from the backend Exchange server). Therefore this is not a critical behavior at all.

The difference can be found how the device reacts on the dropped connection in comparison with how it handles the HTTP 200 OK post.
In the latter case, the device starts a new HTTPS session with the same heartbeat interval again.
In the first case, the device “assumes” that 15-minute HTTPS requests are blocked and re-initiates a new session with only 8 minutes (480 seconds) – which is still beyond the 300 second default setting of the WAP servers.

To avoid the Event 13007, the InactiveTransactionTimeOutSec parameter needs to be set to a value greater than the defined Active Sync max period. By default, the Active Sync device starts with a 15-minute interval, which would fit into a value of 910 for the InactiveTransactionTimeoutSec.

Since the parameter can be set for each published application individually, you luckily do not need to touch other published applications than Exchange Active Sync.

Example command:

Get-WebApplicationProxyApplication ExchangeActiveSync | Set-WebApplicationProxyApplication –InactiveTransactionsTimeoutSec

Note:

A support engineer with Microsoft Premier stated that there is currently no way to suppress the Event 13007 from appearing in the log files completely.

Work Folders Part 1: Overview and Requirements

Happy business man holding a modern laptop computer with his team in background

Overview und Benefits

Work Folders – one of the most exciting new feature in Windows Server 2012 R2 that creates a lot of new possibilities for Bring Your Own Devices (BYOD) to provide controlled access to data stored on the corporate network. It provides the following benefits:

  • Users can access only their own Work Folders from their personal computers (or various devices) anywhere from centrally managed file servers on the corporate network
  • Enables users to access work files while offline and sync with the central file server (devices also keep a local copy of the users’ subfolders in a sync share, which is a user work folder)
  • Work Folders can co-exist with existing deployments of Folder Redirection, Offline Files, and home folders
  • Security policies can be configured to instruct PCs and devices to encrypt Work Folders and use a lock screen Password
  • Failover Clustering issupported to provide a high availability solution
  • Work Folders can be published to the Internet using the Web Application Proxy functionality (also new to Server 2012 R2), enabling users to synchronize their data whenever they have an Internet connection, without the need of a VPN or Remote Desktop

Requirements

Work Folders Server – a server running Windows Server 2012 R2 for hosting sync shares with user files:

  • Install the File and Storage Services role
  • Work folders is managed through Server Manager for a centralizing view of sync activity
  • Multiple sync shares can be created on a single Work Folders Server
  • You can grant sync access to groups (by default, administrators don’t have access to files on the sync share)
  • Possibility to define a device policies per sync share
Work Folders in Server Manager

 

User devices – best functionality is given with Windows 10, Windows RT 8.1, or Windows 8.1 operating systems; Windows 7, iPad, and iPhone clients are also supported

  • Files remain in sync across all user devices
  • Users work with their Work Folders like with any other folder. The only difference is that when right-click the Work Folders icon, they got the option to force synchronization with the server, and then to other devices
  • Users can access and use Work Folders from different devices, irrespective of their domain Membership

Written by B. Rajic.

ADFS – How to enable Trace Debugging and advanced access logging

Dieser Beitrag wurde am 18.11.2015 um 22:38:18 in Cloudy Migration Life veröffentlicht

ADFS – How to enable Trace Debugging and advanced access logging
Debugging an Active Directory Federation Services 3.0 farm together with the Web Application Proxy servers in front can be a very complex task when you think of all the different constellations that can be served by this technology. Especially when it comes to access from mobile devices and Microsoft Online as relying Party.
In principle, trace debugging can have 3 target scopes:

  • Trace debugging on the backend – on WAP servers and ADFS servers to see how the authentication request is terminated
  • Trace debugging on the accessing device – to see how the authentication request is initiated
  • Network trace to see the authentication flow travels from device to the ADFS farm and back. Actually you need to terminate the SSL connection with a special tool like Fiddler to inspect the content.

For many professionals the Fiddler trace will be the most complex way to start debugging, especially when you are acting in secured and controlled enterprise network. Many apps on mobile devices (e.g. the Office Apps for Android) also show poor logging and tracing capabilities to show what the app is actually doing in terms of federated authentication.

Therefore, we should utilize the complete debugging capabilities of ADFS as preferred option. As long as there is a communication between device and WAP/ADFS servers, we fortunately receive a lot of information from the Trace logs of the backend servers.

STEP 1: Set Trace level and enable ADFS Tracing log:
Please enable the debugging logging on the ADFS 3.0 Server:
Open an elevated CMD window and type the following command: C:Windowssystem32>wevtutil sl “AD FS Tracing/Debug” /L:5

In Event Viewer highlight “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”

In Event Viewer highlight “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Navigate to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging immediately.

 


Navigate to AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
It is difficult to scroll and search in the events page by page in the Debug Log. Therefore save all Debug events into an *.evtx file first.


Open the saved log again. Now you can scroll and search a lot smoother through the events.

STEP 2: Enable Object access auditing to see access data in security logs:
If we want to see exhausting data about access activities on the ADFS servers we have to tun on object access auditing (not account logon auditing). You have to enable auditing in 2 locations on the ADFS server.

  1. Turn on auditing in the ADFS GUI. On the primary ADFS server right-click on Service and activate “Success audits” and “Failure audits”. This setting is valid for all ADFS servers in the farm.
  2. To make this setting actually work, you have to do a second step on the ADFS server in the Local Security Policy (unless there is a similar Group Policy setting coming from the Active Directory structure).
    Open the GPO Editor, navigate Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy and configure “Audit Object Access” with “Success” and “Failure”. This setting has to be made in the Local Security Policy on each ADFS server (or a GPO is set on OU or different level in Active Directory).
  3. Looking at the security event logs of the ADFS servers, you will notice a much higher amount of events coming in which provide a much higher level of insights.

It is a good starting point to exactly note the time when running e.g. an access attempt and then look up the timestamps (+ offset for runtime) in both event logs, ADFS Trace Debugging and Security.


“Missing-Partition-for-run-step” error when starting first Import job in Microsoft Azure AD Sync

After installing the latest Version of Azure AD Sync we received the error “missing-Partition-for-run-step” in the Operation pane of the Synchronization Service Manager when trying to start the Full Import as very first step in our Run Profile.

The error only shows up when both is true:

  • The AD Forest as source of the Synchronization is a multi-Domain Forest
  • You configured the Azure AD sync to synchronize not all Domains of the Forest

By default the Azure AD Installation procedure creates a default run profile that includes all partition (domains) for the Import, while we filtered out the root domain in the Connector configuration.
To resolve the problem you need to clean up the Run Profile created by the Azure AD Sync wizard automatically. From Connectors pane select “Configure Run Profiles” and delete the run steps that include the unwanted “domains”. After the cleanup, you will successfully run the Import job.

New Release of DELL Migration Manager for Exchange 8.11

While we were all waiting for the arrival of Migration Manager for Exchange 9.0, DELL Software released a new version 8.11 of its Exchange migration flagship.

New in the release 8.11 is the support for installing the Migration Manager components on Windows Server 2012 and 2012 R2 OS platforms. On the other hand, installations on Windows Server 2008 and Windows 7 are not supported anymore:

  • Migration Manager supports migration from the source Exchange 2013 organization to the target Exchange 2010 or Exchange 2013 organization using Native Move Job.
  • All Dell Migration Manager components can now be installed on Microsoft Windows Server 2012 and Microsoft Windows Server 2012 R2
  • Operating systems not supported from Migration Manager console:
    – Microsoft Windows Server 2008 Service Pack 1 or higher (x86 edition)
    – Microsoft Windows 7 Service Pack 1 or higher (x64 edition)
    – Microsoft Windows Server 2008 Service Pack 1 or higher (x64 edition)
    – Microsoft Windows 7 Service Pack 1 or higher (x86 edition)
  • Operating systems not supported from Migration Agent for Exchange:
    – Microsoft Windows Server 2008 Service Pack 1 or higher (x86 edition)
    – Microsoft Windows Server 2008 Service Pack 1 or higher (x64 edition)
    – Microsoft Windows 7 Service Pack 1 or higher (x86 edition)

You can find a complete list of changes and release related information of the product here:

https://support.software.dell.com/download-install-detail/5775891?prodjid=1-7GCB8-249&utm_campaign=42330-32498-SU-GL-MigrationManagerforExchange&utm_medium=email&utm_source=Eloqua

Recommended Blog Post: The good, the bad and sIDHistory

Based on various experiences with Exchange 2010 behavior after an Exchange and Active Directory Inter Forest Migration, Exchange PRO Ingo Gegenwarth published this interesting Post:

The clueless guy

This post is about my personal journey with a cross-forest migration.

When it comes to account migration there is no way to do so without sIDHistory. It would be really hard to have a smooth migration without.

By using this attribute a end-user most likely won’t experience any impact…..unless you start doing a cleanup of this attribute.

In terms of Exchange users might see something like this

Calendar_Error

or this

Inbox_Error

But what’s behind those issues and how could you mitigate this? I was part of a migration, where those issues popped up and I’m going to describe how you could determine possible impact for end-users before it happens.

View original post 3,675 more words

Exchange Migration first & Mailbox Folder Permissions

In many inter forest migration projects, the mailbox migration to the new Exchange Organization into the new forest is performed first and the user migration is performed in a separate step at a later time. After the mailbox migration and before migrating the user objects, you have a classic Resource Forest scenario. Users are created as disabled user accounts in the target forest, receiving a linked mailbox, connected to the source Active Directory user. Important AD attribute in this scenario is msExchMasterAccountSID. This attribute of the disabled target user object holds the objectSID of the source user account. This allows to connect to the own mailbox and shared mailbox resources (Delegate permissions etc.) with the active source user object.

ExMigirst01

Did you ever thought about mailbox folder permissions in this scenario? 

For every migrated folder permission (e.g. with QMM for Exchange) and also every time a user manually adds mailbox folder permissions for another (not Active Directory migrated) user in the target mailbox, the SID of the source user object is added to the mailbox folder permissions. In this example, we’ve selected the not migrated user UserA from the Global Address list and added him as delegate for the Inbox and the calendar for the Info MBX:  ExMigirst02

At some point, the Active Directory migration will start. During this process, the user account in the target domain will be activated and the Linked Mailbox is converted to a User Mailbox. This action will clear the attribute msExchMasterAccountSID. This is necessary because the target account will now be used to access the own mailbox and resources of other mailboxes. If a migrated user is now added to the mailbox folder permissions, the target SID will be added and no longer the source SID. Let’s use the mailbox example above and add the migrated user UserB as additional delegate for the Calendar of the Info MBX:ExMigirst03

In this example, UserB will of course not have any problems accessing the Info MBX. But what happens if UserA will be migrated and the user starts accessing the Info MBX with TARGETDOMAIN\UserA? The SID of the target account has no permissions on the Inbox and the Calendar folder. Will UserA loose access to these folders now? Generally, the answer is YES, UserA will lose access! But…

In Active Directory Migration projects, it is best practice to migrate the SIDHistory to the target user account. In this case, the objectSID of the source user is copied to the attribute SIDHistory of the target account. For our example, it means that UserA will not lose access to the Info MBX because his Access Token contains the Source SID which has permissions on the Inbox and Calendar folder in the Info MBX.

SIDHistory CleanUp & mailbox folder permissions?

Clearing SIDHistory is part of most of the migration projects. Before clearing the SIDHistory attribute of the target accounts, it is required to replace the source SIDs with the corresponding target SIDs inside the mailbox folder permissions. This process is called ReACLn. Without this action, many users will lose access to shared mailbox resources when the SIDHistory attribute is cleared.


Exchange Processing Wizard (Part of Dell Migration Manager for Active Directory)

Dell migration Manager for Active Directory contains the Exchange Processing Wizard. This wizard is able to replace existing source SIDs with the matching target SIDs for permissions inside the exchange environment. The wizard is using the matching information in the QMM AD LDS database, created during the directory synchronization.

To ReACL permissions inside the mailboxes, we have to select the option “Update client permissions”:

ExMigirst04

Now we can choose to process all Public Folders and Mailboxes or select individual Mailboxes or Public Folder or even skip Public Folders or Mailboxes completely:

ExMigirst05

The wizard provides the possibility to only process one server or process multiple servers in parallel.

Known limitation of the Exchange Processing Wizard:

The wizard is unable to set the Free/Busy permissions Free/Busy time, subject, location. After processing, the permission is changed to Free/Busy time only:

ExMigirst06


Good to know – Check real SID behind folder permissions

Get-MailboxfolderPermission: Unfortunately, as long as the SIDHistory is set for a user, Exchange will always resolve the permissions to the target account. So Exchange will always show the TARGETDOMAIN\User although in fact the source SID has permissions on the mailbox folder. You will also see the same result if you query folder permissions via EWS (e.g. with EWSEditor).

MFCMAPI:

To check which SID is really behind the permission, you can use MFCMAPI to access the mailbox.

  1. Create a new profile for mailbox and disable Exchange Cached Mode.
  2. Start MFCMAPI
  3. Click Session->Logon and choose the profile you’ve created in step 1.
  4. Double Click the Mailbox entry and now navigate to the folder for which you want to display the permissions.
  5. On the right side, now double click PR_NT_SECURITY_DESCRIPTOR

In the Smart View, you can see which SID is really behind the Access Control Entry.

SSL Hardening for Web Application Proxy Servers

The Web Application Proxy (WAP) Servers act as an SSL termination instance towards the Internet. External connections that try to access the Active Directory Federation Services (ADFS) farm or internal applications that are published via the Web Application Proxy will terminate their SSL connections at the Web Application Proxy. Unfortunately, the Windows 2012R2 server default settings allow a lot of SSL Cipher Suites that are publically known as weak or “outdated” like SSLv3, DES encryption and key length below 128bit. The preferred Server Ciphers of a freshly installed and updated Windows 2012R2 server are SSLv3    168 bits        DES-CBC3-SHA TLSv1    256 bits        AES256-SHA Therefore from a network security standpoint it is mandatory to harden the SSL settings on the Web Application Servers BEFORE opening the WAP server in the DMZ for incoming Internet connections. The best option to harden the SSL settings on a standalone Windows Server 2012R2 is to modify the Local Group Policy: From a commandline run: “gpedit.msc”. In the computer section navigate to “Administrative Templates – Network – SSL Configuration Settings”  Edit the “SSL Cipher Suite Order”:

The listed Cipher suites can be exported and adjusted to the actual security requirements by deleting the unwanted Ciphers from the list. As a minimum all combinations that contain SSL2, SSL3, DES, 3DES, MD5 elements are deleted as well as all combination with a cipher length below 128bit.

Information

The list needs to be sorted in a way that the preferred SSL ciphers are on top.

Afterwards create a string of the values from list and separate each cipher by “,” without any blank. Don’t leave a “,” at the end of the string. The input box in the GPO menu has a limited size. Make sure that your string fits into this limit. If not, delete further ciphers which are not widely used.

Warning!

It looks like simply activating the new local GPO by running “gpupdate /force” is not sufficient. Please reboot the WAP servers one-by-one after setting the SSL cipher policy

However, before we open the firewall, an internal test should be executed to validate the SSL hardening. You can run the sslscan tool (you can download from here sslscan) from another computer in the DMZ or the WAP server itself. DNS resolving of the federation or application name must resolve to the external Load Balancer or interface of the WAP server. Example for SSL Server Ciphers before SSL Hardening (left side) and after SSL Hardening (right side):

When the Web Application Proxy server has been connected to the Internet finally, a second check can be achieved by using one of the proven Internet based SSL scan tools, e.g. https://www.ssllabs.com/ssltest/ .

You can find a string of the recommended SSL ciphers for importing into local GPO here.

Active Directory Federation Services 3.x Technology Basics

cropped-9876564.jpg

Active Directory Federation Services (AD FS) provides Web single-sign-on to authenticate a user to related external hosted Web applications. AD FS performs this by securely sharing digital identity and entitlement rights or claims across security and enterprise boundaries.

AD FS supports distributed authentication and authorization over the Internet to provide access to resources that are offered by trusted partners.

Another aspect of ADFS technology can be found in providing external access from Internet connections to internal resources. In that case the ADFS server can provide an additional layer of security by offering various pre-authentication methods, while the second part of the ADFS technology, the Web Application Proxy server (WAP) acts as a Reverse Proxy by terminating the incoming SSL connections.

In version 3.0 of the ADFS technology, the WAP server cannot be run without ADFS server in the backend, which stores the configuration of the WAP servers. The WAP servers themselves are “stateless” and therefore easy to scale up behind a Layer 4 Load Balancer.

ADFS Server Farms

The Active Directory Federation Services technology can be scaled out by deploying multiple ADFS servers in a farm model. The servers share the same configuration information which is stored in a database on each server (Windows Internal Database (WID) model) or in a central SQL store. In most of the implementations, the WID model is used.
For using the WID model, the configuration can only be modified on the Primary ADFS server and is then replicated to all other ADFS servers of the same farm.
To find the Primary Server use the command “get-adfssyncproperties” on one of the ADFS servers:

Web Application Proxy server

The Web Application Proxy Server is typically the Internet facing component of the Active Directory Federation Services technology. Located in the DMZ, the Web Application Proxy (WAP) servers act as reverse proxy server and terminate the incoming SSL connects from the Internet to the published applications.
Web Application Proxy servers are N to 1 connected to a specific ADFS server (farm). Multiple WAP servers can be easily configured for Layer 4 Loadbalancing.
Since WAP servers are “stateless”, they do not store any persistent configuration information, but load the information from the Primary ADFS server. Therefore a WAP server cannot exist without underlying ADFS server and needs to be installed after the ADFS farm has been deployed.

When acting as reverse proxy for client access using IWA (Integrated Windows Authentication) or when serving non claims aware application access based on Kerberos, the WAP servers must be able to perform Kerberos Constrained Delegation. The WAP server presents a Kerberos token on behalf of the accessing client or user, which in consequence requires the WAP server to be a member of an Active Directory domain. Unfortunately the domain membership of the WAP server means to open a lot more ports from the DMZ to the internal network, which is a disadvantage from network security perspective.

For that reason, applications that do not require Kerberos Constrained Delegation should always be published on non domain based WAP servers, where the exception is to publish applications on domain based WAP servers.

Example for ADFS Farm structure:

Notes Migrator for Exchange (NME) Version 4.12 released

Notes Migrator for Exchange Version 4.12 released

Dell published the Version 4.12 of the Notes Migrator for Exchange. The new features are:

  • Configurable Subject field for migrated meetings in resource calendars – Set the Subject field as the actual meeting Subject or the organizer of the meeting to mimic native Outlook behavior
  • Custom, string-based migration filters for Mail/Calendar items and address books – Limit the data pulled from the migrating NSFs using the Data Migration Wizard
  • Expanded time counters – The elapsed and remaining time counters have been expanded to correctly report migration runs longer than 24 hours
  • Configurable locale for target folder names — Specify which locale section (in its Task Parameters) to use when assigning folder names to Outlook folders

Since there has also been a lot of bugfixing in the new version, we recommend to update installations.