Edit: This scenario is unofrtunately no longer supported by Microsoft. More details can be found here: https://learn.microsoft.com/microsoft-365/enterprise/configure-exchange-server-for-hybrid-modern-authentication
Wouldn't it be awesome to be able to do the following with Outlook Web Access being published in your on-premises environment today?
- Cheap proxy solution to prevent direct internet access to your servers
- Mask the IPs of your on-premises infrastructure
- Enable Azure MFA (Multi-Factor Authentication) for OWA?
- Have a Single-Sign on experience into Outlook Web Application via federation?
- Have the application be selectable from your "My Apps" page (myapps.microsoft.com)
- Have the application be selectable from the "Waffle Menu" of Office 365
If you are looking for any of the above, you are in-luck and we can enable this easily through Azure AD Application Proxy. If you organization is using Office 365 or Azure AD already and have licensing for Azure AD Premium or Basic, you are good to go. If you have the Enterprise Mobility Suite, this will grant you to Azure AD Premium licensing which should make you good to go as well.
- Prerequisite: Enable Kerberos Authentication for Outlook Web Access On-Premises
- Login to one of your domain controllers and open up Active Directory Users and Computers
- Find the Computer object within your organization we will run the Azure AD Connector on later in the tutorial and right click Properties on it
- Select the Delegation tab, select Trust this computer for delegation to specified services only, check Use any authentication protocol, and click on Add...
- Select Users or Computers...
- Type in the machine name and click OK
- Select http and click OK
- Click OK on the Add Services page
- Pre-Requisite: Enable Exchange On-Premises to use Integrated Windows Authentication (instructions for Exchange 2010 or 2013 can be found below)
- Exchange 2010
- Open the Exchange Management Console for your Exchange server
- Expand Server Configuration, select Client Access, under Outlook Web App, right click on your web app and select Properties
- Select the Authentication tab and check Use one or more standard authentication methods. Once checked, check Integrated Windows authentication and click the Apply and OK buttons.
- Open a command prompt
- Execute the iisreset command
- Exchange 2013
- Open the Exchange Administrative Center
- Login to the admin center, click on Servers and select the Virtual Directories tab
- Select server and then double click on the OWA Virtual Directory and select the applications tab
- On the authentication tab, select Use one or more standard authentication methods, select Integrated Windows authentication, and click save
- Open a command prompt
- Execute the iisrest command
- Login to the Azure Portal
- Select All services -> Azure Active Directory on the left side
- Select Application proxy in the sub blade and select + Configure app
- Enter in the following information for the application:
- Name: Outlook Web Access
- Internal URL: https://owa.yourdomain.com/owa/ (this is the internal URL to owa)
- Pre-Authentication: Azure Active Directory
- Connector Group: Default
- Click + Add
- Select OK if not prompted about having a connector
- Once your application is created, you should be redirected to Azure Active Directory -> Enterprise Applications -> Outlook Web Access. On this blade, select Single sign-on and then select the Windows Integrated Authentication button
- Use the following configuration
- Internal Application SPN: http/owa.yourdomain.com
- This is the Service Principal Name to the Exchange Server. The value for this was provided earlier in this tutorial.
- Delegated Login Identity: User Principal Name
- Click Save
- Note: If you cannot do Kerberos based authentication (Integrated Windows Authentication) in your environment, you can Discard the changes continue to use Azure AD Application proxy, however the end user will be prompted for credentials just as if they browsed directly to OWA.
- Go back to All Services -> Azure Active Directory -> Application Proxy and click the Download connector service button
- Click the Accept terms & Download button
- Note: Although the download has a generic name, the download is customized specifically for your application (Outlook Web Access in this case). If you create other applications within your Azure AD tenant, make sure you always use the Download button inside of each application so it generates the correct installer.
- Copy the AADApplicationProxyConnectorInstaller.exe connector to any server in your environment that can access your OWA instance internally and run the installer
- Check I agree to the license terms and conditions and click Install
- Type in your Global Administrator credentials to register the agent to your Azure AD tenant and click Sign in
- Click Close if it shows Setup Success
Optional: You can run the Connector Troubleshooter if you would like. It will install a quick application that will show you the results of the test in your web browser once it has completed.
- Go back to the Azure Portal and navigate to Azure Active Directory -> Enterprise Applications -> Outlook Web Access. Select Users and groups and click the +Add user button to assign the group or users that should use the application.
- Note: This group could be synchronized from on-premises to Azure AD or created in the cloud
- Note: Assigning a user or group to this application will automatically make the application show up in the My Apps portal
- Note: Users or Groups must be defined to use the application or they will receive an error upon logging in
- Login to https://myapps.microsoft.com as one of the assigned users to the Outlook Web Access application
- Select the Outlook Web Access application
If all went well, you should be logged into Outlook Web Access on-premises and see your corresponding mailbox. At this point, I would proceed with adding a vanity domain name that matches your organization as well as corresponding SSL certificate for the domain name instead of leveraging the default msapprpoxy.net domain name. Additionally, you can always find a nice little icon for the application to make it look like OWA as well 🙂
When trying to open a document in Office 2013 ProPlus from Office 365's SharePoint environment, you are periodically prompted for credentials to SharePoint Online, OneDrive, and Lync Onlinet (using your email address and password). Additionally, the affected users are those that have been synchronized from an on-premise Active Directory environment via ADFS.
Side Note: Not sure if this is relevent or not, but we noticed this started to happen after upgrading our ADFS Proxy Servers to Server 2012 R2 (ADFS v3).
You are prompted with the following Sign In box:
Call us overprotective, but we need to verify your account again before opening this document.
Once you try signing in, you receive the following error:
We are unable to connect right now. Please check your network and try again later.
Inside of the Lync 2013 client, you might see the following dialog as well:
Credentials are required
Lync needs your user name and password to connect for retrieving calendar data from Outlook
This error is caused by a variety of different issues. Please try all of the following below.
If you have a single client having issues
- Clearing cache of Internet Explorer
- Running an online repair of Office 365 ProPlus
- Switching Accounts inside of Outlook (File->Office Account->Switch Account)
- Deactiving office from Office 365 settings and reactivating
If this is a widespread issue on multiple machines in your environment
- Verify all proxy servers are functioning
- If you have multiple proxy servers, ensure your Network Load Balancer is functioning correctly
- You might be hitting a known bug with the Office 2013 Suite. See the following KB article on how to try a workaround (this was the fix for an environment I worked on using ADFS and Server 2012): http://support.microsoft.com/kb/2913639
Symptom: When upgrading from ADFS v2.0 to ADFS v3 built natively into Server 2012 R2, I noticed Chrome stopped auto-logging in people when trying to hit the ADFS server from inside the corporate network.
Solution: We need to allow NTLM authentication for the Google Chrome useragent.
- Login to your primary ADFS server
- NOTE: This step is no longer applicable on newer versions of Chrome.
This is only applicable if running extremely old versions of Chrome (v50 or lower) -- the fix has been added in Chrome v51 and higher.
Execute the following command to disable Extended Protection TokenCheck (See notes for what this is at the bottom of this article)
- Set-ADFSProperties –ExtendedProtectionTokenCheck None
- Execute the following command to get the current list of supported user-agents for NTLM authentication
- [System.Collections.ArrayList]$UserAgents = Get-AdfsProperties | select -ExpandProperty WIASupportedUserAgents
- Execute the following command to inject the user agent into a temporary array of user agents already added to ADFS.
- Execute the following command to commit the change.
- Set-ADFSProperties -WIASupportedUserAgents $UserAgents
- Restart the Active Directory Federation Services service on each of the ADFS farm servers for the changes to take effect. You do not need to make any changes to the proxy servers.
Shout out to Jon Payne in the comments section below for the idea of putting all the values into an ArrayList and then committing the arraylist to ADFS vs adding in all the strings manually.
ExtendedProtectionTokenCheck - Copied directly from technet - Specifies the level of extended protection for authentication supported by the federation server. Extended Protection for Authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts a client's credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed or not required by the server when establishing communications with clients. http://technet.microsoft.com/en-us/library/ee892317.aspx
Update: I have released a smart link generator to have these items created automatically, please find this here: http://jackstromberg.com/o365-smart-linksso-link-generator/
Synopsis: One of the biggest problems I have seen with Office 365 is ease in accessibility to all of the Office365 resources. As pointed out on many of the Microsoft forums, SharePoint, CRM, Skydrive, etc. do not automatically complete a single-sign on request when browsing the website.
Problem: When a user browses https://mydomain.sharepoint.com for example, the user is prompted to enter in their email address. What a user expects is that they should automatically be logged in and see sharepoint when navigating to https://mydomain.sharepoint.com Additionally, for whatever reason, users cannot remember the website address to https://mydomain.sharepoint.com Instead, they want to do something like http://sharepoint.mydomain.com
Solution: Create name branded "fancy URLs" that will complete an idp claim to give the user a true SSO experience.
- Open up Internet Explorer
- Navigate to https://mydomain.sharepoint.com
- Press F12 to open up the developer tools console (I am running IE 11, the console looks way different than previous versions of IE)
- Scroll down and select the icon that looks like a little WiFi antenna
- Click the green play button
- Type in your email address as you would to login to sharepoint ([email protected])
- You should be redirected to your ADFS server and inside the network console, you should see a link like https://sts.mydomain.com/adfs/ls/?.................. Copy this link into notepad.
- Remove the extra stuff from the debug console
- Remove everything from cbcxt=..... to wa=wsignin1.0
- Remove the ct%3D1386214464%26 and bk%3D1386214464%26 parameters
- Next, open up another new notepad document named index.html and paste the following text into it
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<meta http-equiv="refresh" content="0; url=https://sts.mydomain.com link goes here" /></head>
- Replace https://sts.mydomain.com link goes here with your new smart link and save the document.
- Upload the index.html file to one of your your webservers
- Create a new A record called sharepoint.mydomain.com pointing to your webserver
- Now when a user browses http://sharepoint.mydomain.com, the user will automatically be redirected to your secure ADFS Proxy and authenticate automatically.
You will need to repeat the steps above for each of the Office 365 products your company uses. The federated addresses do change, so you will have to follow all of the steps over again for each Smart Link you wish to create.
Here is an official article on creating smart links: http://community.office365.com/en-us/wikis/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx
Symptom: After changing the samAccountName (User Principal Name (UPN)) of a user in your on-premise Active Directory environment, run the DirSync tool to update the user on Office 365 (or wait 3 hours) [and have verified the user's new UPN synchronized in the Office 365 admin portal], the user is presented with the following error when trying to sign into Outlook, SharePoint, CRM, etc. on Office 365.
Sorry, but we're having trouble signing you in Please try again in a few minutes. If this doesn't work, you might want to contact your admin and report the following error: 80041034.
Solution: This turns out to be an issue with ADFS (Active Directory Federated Services), caching user account attributes, which prevents a successful login. Here are a couple of solutions to solve this issue:
- Try reupdating/repairing party trust with Office 365.
- Login to one of your ADFS servers.
- Click Start, All Programs, Windows Azure Active Directory, and then select Windows Azure Active Directory Module for Windows PowerShell.
- Execute the following command to connect to Microsoft's online services (when prompted, type in your Office 365 Administrator credentials)
- Execute the following command to update federated trust
- Update-MSOLFederatedDomain –DomainName:<Federated Domain Name>
- Try temporarily disabling Local Security Authority (LSA) credential caching on your AD FS servers (note this can increase the load on your ADFS and AD DS servers)
- Login to each of your ADFS servers and complete the following steps
- Click Start -> Run -> regedit to open up the registry editor
- Navigate to the following registry key
- Right click on Lsa, select New -> DWORD (32-bit) Value
- Enter LsaLookupCacheMaxSize as the value name and press Enter
- Right click on LsaLookupCacheMaxSize and select Modify
- Ensure the value data is set to 0 and select OK
- Verify the user can successfully login. Once they can, continue on to delete the key we created
- Right click on the LsaLookupCacheMaxSize value we created and select Delete
- Reboot all ADFS and ADFS proxy servers in your environment
Microsoft has released an official KB article referencing this issue, you can find it here: http://support.microsoft.com/kb/2535191