RC4 Kerberos and AD FS Issues

Posted on Leave a commentPosted in ADFS, kerberos, Office 365

It has become common place to consider the position of the RC4 cipher in TLS connections, but this is not something that you can take from a TLS connection (HTTPS) and assume the same for Kerberos connections. If you do disable RC4 for Kerberos then there are some things to consider, especially is you have ADFS servers in place and multiple forests that are trusted.

If RC4 is disabled in group policy and the trusted domain is Forest Functional Level 2003 then your ADFS logins across the trusts are not going to work. You need a FFL of 2008 (maybe R2) to support AES authentication across the trust (and to ensure the trust supports AES in the trust settings) before you can turn of RC4.

If you have disabled RC4 in the ADFS domain and you try and login with an account in a FFL 2003 trusted forest then Kerberos auth will fail, ADFS will be unable to read the token (the encryption type is wrong) and the fields of the SAML token are invalid. You get a lovely error in ADFS Debug logs that reads as follows (Event ID: 52):

ServiceHostManager.LogFailedAuthenticationInfo: Token of type ‘http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName’ validation failed with following exception details:

System.ArgumentOutOfRangeException: Not a valid Win32 FileTime.

Parameter name: fileTime at System.DateTime.FromFileTimeUtc(Int64 fileTime) at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetPasswordExpiryDetails(SafeLsaReturnBufferHandle profileHandle, DateTime& nextPasswordChange, DateTime& lastPasswordChange) at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName) at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName) at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token) at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)

The GPO setting that removes RC4 encryption needs to be enabled on the domain controllers and on the ADFS servers. This policy is found under the “Network security: Configure encryption types allowed for Kerberos” option as per https://technet.microsoft.com/en-us/library/jj852180(v=ws.11).aspx with only DES and AES.

If this is your issue, then reenable RC4 for Kerberos on the domain controllers and recreate the trust between the forests. Recreating trust after enabling RC4 in GPO meant the new password’s RC4 related keys were stored in the trust object related user account’s password. Then TGT could be decrypted and used for Kerberos successfully.

ADFS Adapter Issues With Upgrading MFA 6.3.1 to Version 7

Posted on 2 CommentsPosted in ADFS, ADFS Connector, MFA, Multi-Factor Authentication, Office 365

Upgrading the ADFS Adapter is not straight forward, though the readme notes for the upgrade make no mention of issues!

To upgrade MFA Server 6.3.1 to 7 (so you can remove .NET 2 as a requirement, as that goes out of support soon) then you need to download the MFA installer to each MFA server and run the installation. Once the installation is complete and you restart the MFA admin application you are prompted about the upgrade for the User Portal, the SDK and you need to update the Mobile App software. You are also required to update the ADFS Adapter – which is great, as the ADFS Adapter has new features in version 7.

But this bit is broken. The ADFS Adapter name has changed and so when you restart the ADFS Server you get the following four errors in the AD FS Admin Event Log:

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Passive protocol pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

and

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Passive protocol TLS pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

and

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Proxy TLS pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

and

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Proxy device TLS pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

Each of these errors have Event ID 105 and the Event Source is AD FS.

To fix these errors you need to unregister the MFA ADFS Adapter by its old name. The cmdlet for doing this is Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication. This is run from an admin PowerShell instance on the primary ADFS Server. The MFA documentation says that you can use .\Register-MultiFactorAuthenticationAdfsAdapter.ps1 and .\Unregister-MultiFactorAuthenticationAdfsAdapter.ps1 to add and remove the adapter from ADFS, but as the adapter name has changed if you use the MFA provided scripts it will only unregister/register the new version of the adapter and leave the old in place.

As you can see from the screenshot below, the ADFS Adapter appears as the Azure Multi-Factor Authentication Server, but it used to be called the Windows Azure Multi-Factor Authentication Provider and so this is the source of the upgrade issue. The upgrade replaces the old named adapter with the new named adapter and does not remove the old named adapter in ADFS’s database!

image

Once User Portal, Adapter, MFA App and SDK are upgraded you can uninstall .NET 2 from your Windows Server 2012 R2 MFA boxes

Office 365 MDM (Mobile Device Management) From A Users Perspective

Posted on Leave a commentPosted in ADFS, ADFS 2.0, ADFS 3.0, IAmMEC, MDM, Mobile Device Management, Multi-Factor Authentication, OD4B, ODFB, Office 365, OneDrive, OneDrive For Business, OWA for Devices

The following list of steps and screenshots are taken during the enrolment process to add an iPhone and an Android phone to Office 365 once the free MDM solution that comes with Office 365 is enabled for the user.

Step Details Image from iPhone Image from Android

1.

Once your IT Administrator enables MDM for your Office 365 account you will get the following email on your device if you already have email configured. It may take 24 hours from the admin configuring MDM for this to arrive. Once this email arrives no further email will arrive from that account any device until the devices are enrolled with the company for management.

01 Initial Email Screenshot_2015-06-29-10-55-47

2.

Click “Enrol your device” link in Step 1 of the email. This will take you to the relevant app store of your device to install the Company Portal (iPhone as shown and Android devices). Windows Phone users will see the Workplace Join settings (not shown)
In the iOS example, the Company Portal app is already installed so we can click Open at the top.

For Android to the right, it shows that the app needs installing from the page they see in the App Store.

02 Clicking Enroll Screenshot_2015-06-29-10-56-20
3. Once the app is installed you are required to login. Enter your Office 365 username.
Upon entering your username you will either be directed to your network to login (if your company uses AD FS to login) or you enter the password here. Step 4 shows the AD FS login page, which will probably have your company logo on it.
If your IT department does not use AD FS you enter your password here (the page will wait for you to enter it)
03 Login Page Screenshot_2015-06-29-10-58-51
4. This is an example AD FS login page with company logo. If you are required to login with other information as well as your password you will be prompted for this as well.

04 ADFS Login Page  
5. Upon login being successful your device will start the enrolment process by connecting to both Office 365 and the device manufacturer to download required secure management info. 05 Enrolling Screenshot_2015-06-29-11-00-07
6. For iOS click Enroll to start the process. For Android you need to click Activate.

The company you are enrolling your phone into will have some rights over some of the data on your phone – for example they will be able to remove the work email account from it if you leave the company.

Enrolment conditions will be enforced based on your companies requirement for using phones to access company data, for example a PIN number of a minimum length (see http://bit.ly/o365mdm for more on this)

06 Notice About Enrolling Screenshot_2015-06-29-11-00-55
7. Enrolment goes through a series of steps with the screen changing a few times automatically. Within a seconds you end up at the “Install” screen. Click Install to add the management profile for the displayed company here.

Android and Windows Phone have less steps to go through.

07 Certificate 1 Screenshot_2015-06-29-11-03-50
8. A unique encryption key is generated for your device when using iOS devices.

For Android, you need to accept the compliance requirements configured by your administrator. If you do not complete these requirements then business applications will not be available on the device.

08 Key Generation 1 Screenshot_2015-06-29-11-20-47
9. You need to click install at the personal settings screen when using iOS devices.

For Android, once compliance requirements are set (in this case a PIN number is entered). Note that for iOS, you have 1 hour to enter a PIN number to become compliant, but not for the Android.

09 Warning Screenshot_2015-06-29-11-22-49
10. You need to confirm that you trust this company for remote management of your device when using iOS devices.

For Android you need to name and install the certificate.

10 Install Trust Screenshot_2015-06-29-11-23-05
11. The management profile is installed and you can click Done when using iOS devices. 11 Profile Installed  
12. Device checks that it is enrolled and what the device settings are and if these settings are compatible with the companies required restrictions on the device.

On Android you may get a prompt about entering a PIN number or other compliance requirements if you did not enter them earlier

12 Checking  
13. Enrolment is confirmed. Notice that my device(s) are displayed and my current device is not compliant with company policy (the red exclamation mark).

For Android devices, the My Devices tab will show your devices, including if there are any compliance issues.

13 Enrolled  
14. Clicking my device in the Company Portal app shows the compliance status of the device. Here the device is still checking compliance 14 Checking Compliance 1st Time  
15 And here the device is shown not to be compliant.

For Android devices not in compliance, it shows an Enrollment update available (if you did not meet compliance requirements during the Company App enrollment process) or if you are not compliance (for example device is not encrypted) then it will show that the device is not in compliance as shown.

15 Not In Compliance Screenshot_2015-06-29-11-36-13
16 Details on compliance state is iOS shows the “This device is not in compliance” message.

Further details on the compliance failure are shown under the message. In this case the iOS device is unable to set up an email profile on the device and the Android devices need a longer password and device encryption

16 Not In Compliance Details Screenshot_2015-06-29-11-36-27
17 Clicking the “Unable to set up email on the device” message shows the full details. In this case the device already has an email profile configured and for the iPhone this needs to be removed and the Company Portal will recreate it. It is this recreated email profile that the iPhone/iPad can manage.

Android and Windows Phone users do not need to delete their email profile and have the device recreate it but Compliance requirements must still be met.

17 Actual Reason for not in compliance Screenshot_2015-06-29-11-37-47
18 For the iPhone/iPad the steps to delete the existing profile are Settings > Mail, Contacts, Calendars > Click the email profile > click Delete Account

For Android, if the device is compliant in the Company App then you need to check Exchange Server to validate this for you so that your email continues to work. Back in the email program view the enrollment email as shown – click hyperlink #2 in the email and sign into the web based Device portal

18 Deleting original email profile Screenshot_2015-06-29-11-57-54
19 Once the account is deleted on the iOS device it is not visible in the list of email accounts.

In this example the iCloud account remains along with two Exchange / Office 365 accounts that are not managed by MDM. You can only have one MDM managed account per device at any given time.

Other compliance settings may be required such as a PIN number. You have 60 minutes in iOS to enable this if required.

19 Seeing list of email profiles - work email is gone  
20 Once the Company App checks for compliance again and if you are compliant, a new email profile for your work appears. Clicking it (called “Office 365 email”) requires entry of your password.

In Android, once the device is shown as compliant in #2 of the email, click the hyperlink for #3 in the email. Click Allow on the certificate prompt if you see one.

20 Work Email Profile Arrives Screenshot_2015-06-29-12-00-26
21 You then see the email profile created. Compare this to the image in Step 19 for the difference.

An Android, you will be informed that your device has successfully authenticated for email.

21 Email Configured Automatically Screenshot_2015-06-29-12-00-40
22 It is possible to rename the email profile. In this case it is via Settings > Email, Contacts, Calendars > Office 365 email > Account and then change the “Description” value 22 Renaming Email Profile  
23 Updated email profile listed 23 Email Profile listed  
24 Email should now sync with your device again. Notice that the email about needing to set up MDM is now missing and has been removed automatically.

On the Android, drag the Inbox screen down to refresh it and your emails will appear.

24 Email available on device, enrollment email not available now Screenshot_2015-06-29-12-01-57
25 Now that the device is compliant (excepting the PIN number, which gives you 60 minutes of grace to complete this step) you can start other Office 365 aware applications. Here we are going to sign into OneDrive and show our OneDrive for Business data 25 Other Apps Screenshot_2015-06-29-12-03-12
26 Your app requires a login 26 Login for other apps Screenshot_2015-06-29-12-03-58
27 Which if you have an AD FS additional login you may also see 27 ADFS Login  
28 Your other app is now working, and in the case of OneDrive for Business did not need configuring 28 Other App Also Working  

How To Change Your Office 365 App Password

Posted on 6 CommentsPosted in ADFS, app password, Azure, IAmMEC, MFA, multi-factor auth, Multi-Factor Authentication, Office 365

If you are enabled for Multi-Factor Authentication (MFA) in Office 365 then you will need an App Password for some applications that do not support MFA. The user interface for creating a new App Password is well hidden in Office 365 (its not on the Password page for example).

Post updated in 2016 to take account of the changes in the Office 365 portal.

Here is how to find it now:

  1. The user logs into Office 365 portal (http://portal.office.com) and clicks their photo to the top-right of the page
  2. Click View Account
  3. Click Security and Privacy menu to the left or the Manage Security and Privacy link on the main area of the page
  4. Click Additional Security Verification
  5. Click Update your phone numbers used for account security
  6. Answer your phone to approve your request to go to this page (you will need to do this if this is your first time with MFA enabled)
  7. Click “app passwords” on the top menu (this is not visible if you do not have MFA enabled). This takes you to https://account.activedirectory.windowsazure.com/AppPasswords.aspx. You can (and therefore should) bookmark this page now so you don’t need these instructions again!
  8. Create yourself an additional app password and give it a description.
  9. Use the new app password in the program that you need to login to.

Here is how to find it (in the old Office 365 portal)

  1. The user logs into Office 365 portal (http://portal.office.com) and clicks the cog icon to the top-right of the page
  2. Click Office 365 Settings
  3. Scroll down past Password and choose Additional Security Verification
  4. Click Update my phone numbers used for account security
  5. Answer your phone to approve your request to go to this page (you might not be asked for this)
  6. Click “app passwords” on the top menu. This takes you to https://account.activedirectory.windowsazure.com/AppPasswords.aspx. You can (and therefore should) bookmark this page now so you don’t need these instructions again!
  7. Create yourself an additional app password and give it a description.
  8. Use the new app password in the program that you need to login to.

Continuing Adventures in AD FS Claims Rules

Posted on 7 CommentsPosted in 2013, activesync, ADFS, ADFS 3.0, exchange online, https, Office 365, Outlook, OWA for Devices, Web Application Proxy

There is an excellent article at http://blogs.technet.com/b/askds/archive/2012/06/26/an-adfs-claims-rules-adventure.aspx which discusses the use of Claims Rules in AD FS to limit some of the functionality of Office 365 to specific network locations, such as being only allowed to use Outlook when on the company LAN or VPN or to selected groups of users. That article’s four examples are excellent, but can be supplemented with the following three scenarios:

  • OWA for Devices (i.e. OWA for the iPhone and OWA for Android)
  • Using Outlook on a VPN, but needing to set up the profile when also on the VPN
  • Outlook restrictions when using MAPI over HTTP

OWA for Devices and AD FS Claims Rules

OWA for Devices is an app available from the Apple or Android store and provides mobile and offline access to your email, adding to the features available with ActiveSync. Though OWA for Devices is OWA, it also uses AutoDiscover to configure the app. Therefore if you have an AD FS claim rule in place the blocks AutoDiscover you will find that OWA for Devices just keeps prompting for authentication and never completes, though if you click Advanced and enter the server name by hand (outlook.office365.com) then it works.

Using OWA for iPhone/iPad diagnostics (described on Steve Goodman’s blog at http://www.stevieg.org/2013/08/troubleshooting-owa-for-iphone-and-ipad/) you might find the following entries in your mowa.log file:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=NSURLErrorDomain Code=-1012 “The operation couldn’t be completed. (NSURLErrorDomain error -1012.)” UserInfo=0x17dd2ca0 {NSErrorFailingURLKey=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, NSErrorFailingURLStringKey=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml}”

And following the failure to reach https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml successfully you might see the following:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=ExchangeURLConnectionError Code=2 “Timeout timer expired” UserInfo=0x17dc6eb0 {NSLocalizedDescription=Timeout timer expired}”

and the following:

[PAL] PalRequestManager.OnError(): ExchangeURLConnectionError2: Timeout timer expired

[autodiscover] Autodiscover search failed. Error: ExchangeURLConnectionError2: Timeout timer expired

[actions] Action (_o.$Yd 27) encountered an error during its execution: Error: Timeout timer expired

[autodiscover] TimerCallback_PeriodicCallback_HandleFailedAutodiscoverSearch took too long (XXXms) to complete

The reason is that the first set of AutoDiscover lookups work, as they are connecting to the on-premises endpoint and authentication for this endpoint does not go through AD FS. When you reach the end of the AutoDiscover redirect process you need to authenticate to Office 365, and that calls AD FS – and that might be impacted by AD FS claims rules.

The problem with OWA for Devices and claims rules can come about by the use of the AD FS Claims Rules Policy Builder wizard at http://gallery.technet.microsoft.com/office/Client-Access-Policy-30be8ae2. This tool can be adjusted quite easily for AD FS 2012 R2 (change line 218 to read “If (($OSVersion.Major –eq 6) –and ($OSVersion.Minor –ge 2))” (look for AD FS servers that are –ge [greater or equal to 2] rather than just 2). The AD FS Claims Rules Policy Builder has a setting called “Block only external Outlook clients” – and this blocks Outlook, Exchange Web Services, OAB and AutoDiscover from being used apart from on a network range that you provide. The problem is that you might want to block Outlook externally, but allow OWA for Devices to work.

To solve this problem make sure you do not block AutoDiscover in the claims rules. In the “Block only external Outlook clients” option, its the 2nd claim rule that needs to be deleted, so you end up with just the following:

image

With AutoDiscover allowed from all locations, but EWS and RPC blocked in Outlook, you still block Outlook apart from on your LAN, but you do not block OWA for Devices. Use exrca.com to test Outlook Autodiscover after making this change and you should find that the following error is not present when AutoDiscover gets to the autodiscover-s.outlook.com stage.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user user@tenant.mail.onmicrosoft.com.

The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.

An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).HTTP Response Headers:

If you changed an existing claims rule you either need to restart the AD FS service or wait a few hours for it to take effect.

Outlook with AD FS Claims Rules and VPN’s

As mentioned above, Outlook can be limited to working on a given set of IP ranges. If you block AutoDiscover from working apart from on these ranges (as was the issue causing OWA for Devices to fail above) then you can have issues with VPN connections.

Imagine the following scenario: Web traffic goes direct from the client, but Outlook traffic to Office 365 goes via the LAN. A split tunnel VPN scenario.

In this example, if AutoDiscover and initial profile configuration has never run you have a claims rule that allows Outlook to work on the VPN (as the public IP’s for your LAN/WAN are listed in the claims rules as valid source addresses), but AutoDiscover fails due to the same rules (as the web traffic is coming from the client and not the LAN). Therefore AutoDiscover fails and Outlook is never provisioned, so it appears as if Outlook is being blocked by the claim rules even though you are on the correct network for those claim rules.

Outlook with MAPI over HTTP

A new connection protocol was released with Exchange Server 2013 SP1 called MAPI/HTTP. The plan is that this will replace RPC/HTTP for Outlook Anywhere connections over time, but as RPC/HTTP works fine for on-premises there is not a massive uptake in this protocol for on-premises Exchange deployments.

For Exchange Online though that is a different matter. At the time of writing most of my clients are still connecting to Exchange Online over RPC/HTTP but my Microsoft email account has been using this protocol for a long while now. In the last week though a newly provisioned tenant for a customer of mine has had MAPI/HTTP as the protocol on the first (and so far) only mailbox to migrate. The problem with this is that the AD FS claim rule for x-ms-client-application with a value of Microsoft.Exchange.RPC is not valid for MAPI/HTTP connections.

Therefore if you are an Exchange Online user with claims rules for AD FS you need to add two more rules. These would have the same IP ranges as your Microsoft.Exchange.RPC rule and would be identical to this rule in every way, just the x-ms-client-application string needs to look for the following (one rule for each):

  • Microsoft.Exchange.Mapi
  • Microsoft.Exchange.Nspi

The Microsoft.Exchange.Mapi rule can be named “Outlook MAPI/HTTP” and the Nspi rule can be named “Outlook MAPI Address Book”. You need to keep the Exchange Web Services and Exchange Address Book rules in place, but once all users are migrated to MAPI/HTTP you can remove the Microsoft.Exchange.RPC rule.

Note that Exchange Online caches your AD FS credential’s for 24 hours for connections from a single IP address, so if you successfully connect to Exchange Online (say because you have not got the Microsoft.Exchange.Mapi block in place) then you will not connect back to AD FS for 24 hours and so not be affected by new rules that are added after you connect. If you want to test if your new Microsoft.Exchange.Mapi block rules work then you need to connect to Exchange Online via a different IP address, so a trip to the nearest coffee shop in the quest for network lockdown on your companies expense is called for!

Intermittent Error 8004789A with AD FS and WAP 3.0 (Windows Server 2012 R2)

Posted on Leave a commentPosted in 2012 R2, 2013, ADFS, ADFS 3.0, Office 365

This error appears when you attempt to authenticate with Office 365 using AD FS 3.0 – but only sometimes, and often it was working fine and then it starts!

I’ve found this error is due to two things, though there are other reasons. The full list of issues is at http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx.

I found that this occured if the WAP servers and the ADFS servers where at different timezones (not just times)

And I found that if the domain schema level is no 2012 R2 then you need to run the script included to copy settings between the ADFS servers. Certificates expire every 20 days, or when they are manually changed, so this script needs running by hand at or before these regular changes.

The second of these two issues though has been fixed in the June 2014 update for Windows Server 2012 R2. The fix is documented in http://support.microsoft.com/kb/2964735 and the update (the June 2014 update) is at http://support.microsoft.com/kb/2962409

Changing AD FS 3.0 Certificates

Posted on 6 CommentsPosted in 2012, 2012 R2, ADFS, ADFS 3.0, certificates, IAmMEC, Office 365, WAP, Web Application Proxy

I am quite adept at configuring certificates and changing them around, but this one took me completely by surprise as it has a bunch of oddities to consider.

First the errors: Web Application Proxy (WAP) reported 0x80075213. In the event log the following:

The federation server proxy could not establish a trust with the Federation Service.

Additional Data
Exception details:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

User Action
Ensure that the credentials being used to establish a trust between the federation server proxy and the Federation Service are valid and that the Federation Service can be reached.

And

Unable to retrieve proxy configuration data from the Federation Service.

Additional Data

Trust Certificate Thumbprint:
431116CCF0AA65BB5DCCD9DD3BEE3DFF33AA4DBB

Status Code:
Exception details:
System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()

This was ultimately caused by the certificate on the AD FS Server having been replaced in the user interface, but this did not replace the certificate that HTTP was using or the published web applications and the certificates they were using.

So here are the steps to fix this issue:

AD FS Server

  1. Ensure the certificate is installed in the computer store of all the AD FS servers in the farm
  2. Grant permissions to the digital certificate to the ADFS Service account. Do this by right-clicking the new digital certificate in the MMC snap-in for certificates and choosing All Tasks > Manage Private Keys. Grant read permission to the service account that ADFS is using (you need to click Object Types and select Service Accounts to be able to select this user). Repeat for each server in the farm.
  3. In the AD FS management console expand service > certificates and ensure that the service communications certificate is correct and that the date is valid.
  4. Open this certificate by double-clicking it and on the Details tab, check the value for the Thumbprint.
  5. Start PowerShell on the AD FS Server and run Get-AdfsSslCertificate (not Get-AdfsCertificate). You should get back a few rows of data listing localhost and your federation service name along with a PortNumber and CertificateHash. Make sure the CertificateHash matches the Thumbprint for the service communications certificate.
  6. If they do not, then run Set-AdfsSslCertificate -Thumbprint XXXXXX (where XXXXX is the thumbprint value without spaces).
  7. Then you need to restart the ADFS Server.
  8. Repeat for each member of the farm, taking them out and in from any load balancer configuration you have. Ensure any SSL certs on the load balancer are updated as well.

Web Application Proxy

  1. Ensure the certificate is installed in the computer store of the web application proxy server as well. Permissions do not need to be set for this service.
  2. Run Get-WebApplicationProxySslCertificate. You should get back a few rows of data listing localhost and your federation service name along with a PortNumber and CertificateHash. Make sure the CertificateHash matches the Thumbprint for the service communications certificate. If it does not use Set-WebApplicationProxySslCertificate -Thumbprint XXXXX to change it. Here XXXXX is the thumbprint value without spaces.
  3. Restart WAP server and it should now connect to the AD FS endpoint and everything should be working again.
  4. Check that each Web Proxy Application is using the new certificate. Do this with Get-WebApplicationProxyApplication | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint XXXXXX (where XXXXX is the thumbprint value without spaces). This sets all your applications to use the same certificate. If you have different certificates in use, then do them one by one with Get-WebApplicationProxyApplication | Format-Table Name,ExternalCert* to see what the existing thumbprints are and then Get-WebApplicationProxyApplication “name” | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint XXXXXX to do just the one called “name”.

Configuring Exchange On-Premises to Use Azure Rights Management

Posted on 7 CommentsPosted in 2010, 2013, 64 bit, aadrm, ADFS, ADFS 2.0, DLP, DNS, exchange, exchange online, https, hybrid, IAmMEC, load balancer, loadbalancer, mcm, mcsm, MVP, Office 365, powershell, rms, sharepoint, warm

This article is the fifth in a series of posts looking at Microsoft’s new Rights Management product set. In an earlier previous post we looked at turning on the feature in Office 365 and in this post we will look at enabling on-premises Exchange Servers to use this cloud based RMS server. This means your cloud users and your on-premises users can shared encrypted content and as it is cloud based, you can send encrypted content to anyone even if you are not using an Office 365 mailbox.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Exchange Server integrates very nicely with on-premises RMS servers. To integrate Exchange on-premises with Windows Azure Rights Management you need to install a small service online that can connect Exchange on-premises to the cloud RMS service. On-premises file servers (classification) and SharePoint can also use this service to integrate themselves with cloud RMS.

You install this small service on-premises on servers that run Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2. After you install and configure the connector, it acts as a communications interface between the on-premises IRM-enabled servers and the cloud service. The service can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=40839

From this download link there are three files to get onto the server you are going to use for the connector.

  • RMSConnectorSetup.exe (the connector server software)
  • GenConnectorConfig.ps1 (this automates the configuration of registry settings on your Exchange and SharePoint servers)
  • RMSConnectorAdminToolSetup_x86.exe (needed if you want to configure the connector from a 32bit client)

Once you have all this software (or that which you need) and you install it then IT and users can easily protect documents and pictures both inside your organization and outside, without having to install additional infrastructure or establish trust relationships with other organizations.

The overview of the structure of the link between on-premises and Windows Azure Rights Management is as follows:

IC721938

Notice therefore that there are some prerequisites needed. You need to have an Office 365 tenant and turn on Windows Azure Rights Management. Once you have this done you need the following:

  • Get your Office 365 tenant up and running
  • Configure Directory Synchronization between on-premises Active Directory and Windows Azure Active Directory (the Office 365 DirSync tool)
  • It is also recommended (but not required) to enable ADFS for Office 365 to avoid having to login to Windows Azure Rights Management when creating or opening protected content.
  • Install the connector
  • Prepare credentials for configuring the software.
  • Authorising the server for connecting to the service
  • Configuring load balancing to make this a highly available service
  • Configuring Exchange Server on-premises to use the connector

Installing the Connector Service

  1. You need to set up an RMS administrator. This administrator is either the a specific user object in Office 365 or all the members of a security group in Office 365.
    1. To do this start PowerShell and connect to the cloud RMS service by typing Import-Module aadrm and then Connect-AadrmService.
    2. Enter your Office 365 global administrator username and password
    3. Run Add-AadrmRoleBasedAdministrator -EmailAddress <email address> -Role “GlobalAdministrator” or Add-AadrmRoleBasedAdministrator -SecurityGroupDisplayName <group Name> -Role “ConnectorAdministrator”. If the administrator object does not have an email address then you can lookup the ObjectID in Get-MSOLUser and use that instead of the email address.
  2. Create a namespace for the connector on any DNS namespace that you own. This namespace needs to be reachable from your on-premises servers, so it could be your .local etc. AD domain namespace. For example rmsconnector.contoso.local and an IP address of the connector server or load balancer VIP that you will use for the connector.
  3. Run RMSConnectorSetup.exe on the server you wish to have as the service endpoint on premises. If you are going to make a highly available solutions, then this software needs installing on multiple machines and can be installed in parallel. Install a single RMS connector (potentially consisting of multiple servers for high availability) per Windows Azure RMS tenant. Unlike Active Directory RMS, you do not have to install an RMS connector in each forest. Select to install the software on this computer:
    IC001
  4. Read and accept the licence agreement!
  5. Enter your RMS administrator credentials as configured in the first step.
  6. Click Next to prepare the cloud for the installation of the connector.
  7. Once the cloud is ready, click Install. During the RMS installation process, all prerequisite software is validated and installed, Internet Information Services (IIS) is installed if not already present, and the connector software is installed and configured
    IC002
  8. If this is the last server that you are installing the connector service on (or the first if you are not building a highly available solution) then select Launch connector administrator console to authorize servers. If you are planning on installing more servers, do them now rather than authorising servers:
    IC003
  9. To validate the connector quickly, connect to http://<connectoraddress>/_wmcs/certification/servercertification.asmx, replacing <connectoraddress> with the server address or name that has the RMS connector installed. A successful connection displays a ServerCertificationWebService page.
  10. For and Exchange Server organization or SharePoint farm it is recommended to create a security group (one for each) that contains the security objects that Exchange or SharePoint is. This way the servers all get the rights needed for RMS with the minimal of administration interaction. Adding servers individually rather than to the group results in the same outcome, it just requires you to do more work. It is important that you authorize the correct object. For a server to use the connector, the account that runs the on-premises service (for example, Exchange or SharePoint) must be selected for authorization. For example, if the service is running as a configured service account, add the name of that service account to the list. If the service is running as Local System, add the name of the computer object (for example, SERVERNAME$).
    1. For servers that run Exchange: You must specify a security group and you can use the default group (DOMAIN\Exchange Servers) that Exchange automatically creates and maintains of all Exchange servers in the forest.
    2. For SharePoint you can use the SERVERNAME$ object, but the recommendation configuration is to run SharePoint by using a manually configured service account. For the steps for this see http://technet.microsoft.com/en-us/library/dn375964.aspx.
    3. For file servers that use File Classification Infrastructure, the associated services run as the Local System account, so you must authorize the computer account for the file servers (for example, SERVERNAME$) or a group that contains those computer accounts.
  11. Add all the required groups (or servers) to the authorization dialog and then click close. For Exchange Servers, they will get SuperUser rights to RMS (to decrypt content):
    image
    image
  12. If you are using a load balancer, then add all the IP addresses of the connector servers to the load balancer under a new virtual IP and publish it for TCP port 80 (and 443 if you want to configure it to use certificates) and equally distribute the data across all the servers. No affinity is required. Add a health check for the success of a HTTP or HTTPS connection to http://<connectoraddress>/_wmcs/certification/servercertification.asmx so that the load balancer fails over correctly in the event of connector server failure.
  13. To use SSL (HTTPS) to connect to the connector server, on each server that runs the RMS connector, install a server authentication certificate that contains the name that you will use for the connector. For example, if your RMS connector name that you defined in DNS is rmsconnector.contoso.com, deploy a server authentication certificate that contains rmsconnector.contoso.com in the certificate subject as the common name. Or, specify rmsconnector.contoso.com in the certificate alternative name as the DNS value. The certificate does not have to include the name of the server. Then in IIS, bind this certificate to the Default Web Site.
  14. Note that any certificate chains or CRL’s for the certificates in use must be reachable.
  15. If you use proxy servers to reach the internet then see http://technet.microsoft.com/en-us/library/dn375964.aspx for steps on configuring the connector servers to reach the Windows Azure Rights Management cloud via a proxy server.
  16. Finally you need to configure the Exchange or SharePoint servers on premises to use Windows Azure Active Directory via the newly installed connector.
    • To do this you can either download and run GenConnectorConfig.ps1 on the server you want to configure or use the same tool to generate Group Policy script or a registry key script that can be used to deploy across multiple servers.
    • Just run the tool and at the prompt enter the URL that you have configured in DNS for the connector followed by the parameter to make the local registry settings or the registry files or the GPO import file. Enter either http:// or https:// in front of the URL depending upon whether or not SSL is in use of the connectors IIS website.
    • For example .\GenConnectorConfig.ps1 –ConnectorUri http://rmsconnector.contoso.com -SetExchange2013 will configure a local Exchange 2013 server
  17. If you have lots of servers to configure then run the script with –CreateRegEditFiles or –CreateGPOScript along with –ConnectorUri. This will make five reg files (for Exchange 2010 or 2013, SharePoint 2010 or 2013 and the File Classification service). For the GPO option it will make one GPO import script.
  18. Note that the connector can only be used by Exchange Server 2010 SP3 RU2 or later or Exchange 2013 CU3 or later. The OS on the server also needs to be include a version of the RMS client that supports RMS Cryptographic Mode 2. This is Windows Server 2008 + KB2627272 or Windows Server 2008 R2 + KB2627273 or Windows Server 2012 or Windows Server 2012 R2.
  19. For Exchange Server you need to manually enable IRM as you would do if you had an on-premises RMS server. This is covered in http://technet.microsoft.com/en-us/library/dd351212.aspx but in brief you run Set-IRMConfiguration -InternalLicensingEnabled $true. The rest, such as transport rules and OWA and search configuration is covered in the mentioned TechNet article.
  20. Finally you can test if RMS is working with Test-IRMConfiguration –Sender billy@contoso.com. You should get a message at the end of the test saying Pass.
  21. If you have downloaded GenConnectorConfig.ps1 before May 1st 2014 then download it again, as the version before this date writes the registry keys incorrectly and you get errors such as “FAIL: Failed to verify RMS version. IRM features require AD RMS on Windows Server 2008 SP2 with the hotfixes specified in Knowledge Base article 973247” and “Microsoft.Exchange.Security.RightsManagement.RightsManagementException: Failed to get Server Info from http://rmsconnector.contoso.com/_wmcs/certification/server.asmx. —> System.Net.WebException: The request failed with HTTP status 401: Unauthorized.”. If you get these then turn of IRM, delete the “C:\ProgramData\Microsoft\DRM\Server” folder to remove old licences, delete the registry keys and run the latest version of GetConnectorConfig.ps1, refresh the RMS keys with Set-IRMConfiguration –RefreshServerCertificates and reset IIS with IISRESET.

Now you can encrypt messages on-premises using your AADRM licence and so not require RMS Server deployed locally.

OWA and Moving Mailboxes to Office 365

Posted on Leave a commentPosted in 2010, ADFS, ADFS 2.0, certificates, exchange, exchange online, federation, Office 365, organization relationships, owa, powershell

Lets imagine a scenario where you are using an on-premises Exchange Server and users’ use Outlook Web App, and then you move some mailboxes to the Office 365 cloud with Hybrid Coexistence enabled. The user might not know their mailbox has been moved and so yesterday they went to https://mail.company.com/owa, but today they need to visit https://outlook.com/owa/company.com (where company.com is the domain name in your login name).
But becuase the user does not know that their mailbox has been moved when they visit https://mail.company.com/owa they get an error that their OWA URL is out of date.
To fix this, and provide the user with the correct URL (https://outlook.com/owa/company.com) then you need to set the TargetOwaURL property of the Organization Relationship that you have configured for your Office 365 service domain.

Set-OrganizationRelationship name -TargetOwaURL https://outlook.com/owa/company.com

Now when users login with an account that has been moved to the cloud they will be told that their mailbox has moved, and that they should visit https://outlook.com/owa/company.com.
Some organizations though have an issue with this URL – it does not mention the company name in the domain name bit, and a name such as http://webmail.company.com/owa would be preferred for mailboxes moved to the cloud. To present the user with this URL after they login to on-premises OWA or for a URL that you can just tell them to use you need to do two things:

  1. Create a CNAME record in DNS for webmail that has outlook.com as the target FQDN. The CNAME record can be anything that is not already in use for the domain (for example it could be mail if that is not in use).
  2. The TargetOwaURL property of the Organization Relationship needs to be http://webmail.company.com/owa. The TargetOwaURL must finish with /owa or the on-premises OWA redirect page will error and the domain name used must be the domain name in your login name.

The outlook.com server will take the CNAME value provided by the browser and do realm discovery on this name – that is it will redirect you to the correct login server for your domain.

Publishing ADFS Through ISA or TMG Server

Posted on 2 CommentsPosted in 2010, 2013, 64 bit, active directory, ADFS, ADFS 2.0, certificates, exchange, exchange online, https, isa, mcm, microsoft, Office 365, pki, tmg

To enable single sign-on in Office 365 and a variety of other applications you need to provide a federated authentication system. Microsoft’s free server software for this is currently Active Directory Federation Server 2.0 (ADFS), which is downloaded from Microsoft’s website.

ADFS is installed on a server within your organisation, and a trust (utilising trusted digital certificates) is set up with your partners. If you want to authenticate to the partner system from within your environment it is usual that your application connects to your AFDS server (as part of a bigger process that is better described here: http://blogs.msdn.com/b/plankytronixx/archive/2010/11/05/primer-federated-identity-in-a-nutshell.aspx). But if you are outside of your organisation, or the connection to ADFS is made by the partner rather than the application (and in Office 365 both of these take place) then you either need to install ADFS Proxy or publish the ADFS server through a firewall.

This subject of the blog is how to do this via ISA Server or TMG Server. In addition to configuring a standard HTTPS publishing rule you need to disable Link Translation and high-bit filtering on the HTTP filter to get it to work.

Here are the full steps to set up AFDS inside your organisation and have it published via ISA Server – TMG Server is to all intents and purposes the same, the UI just looks slightly different:

  1. New Web Site Publishing Rule. Provide a name.
  2. Select the Action (allow).
  3. Choose either a single website or load balancer or use ISA’s load balancing feature depending on the number of ADFS servers in your farm.
  4. Use SSL to connect:
    image
  5. Enter the Internal site name (which must be on the SSL certificate on the ADFS server and must be the same as the externally published name as well). Also enter the IP address of the server or configure the HOSTS files on the firewall to resolve this name as you do not want to loop back to the externally resolved name:
    image
  6. Enter /adfs/* as the path.
  7. Enter the ADFS published endpoint as the Public name (which will be subject or SAN on the certificate and will be the same certificate on the ADFS server and the ISA Server):
    image
  8. Select or create a suitable web listener. The properties of this will include listening on the external IP address that your ADFS namespace resolves to, over SSL only, using the certificate on your ADFS server (exported with private key and installed on ISA Server), no authentication.
  9. Allow the client to authenticate directly with the endpoint server:
    image
  10. All Users and then click Finish.
  11. Before you save your changes though, you need to make the following two changes
  12. Right-click the rule and select Configure HTTP:
    image
  13. Uncheck Block high bit characters and click OK.
  14. Double-click the rule to bring up its properties and change to the Link Translation tab. Uncheck Apply link translation to this rule:
    image
  15. Click OK and save your changes.

ADFS should now work through ISA or TMG assuming you have configured ADFS and your partner organisations correctly!

To test your ADFS service connect to your ADFS published endpoint from outside of TMG and visit https://fqdn-for-adfs/adfs/ls/idpinitiatedsignon.aspx to get a login screen