Teams / Chrome - Re-enable the application the tab needs to be refreshed "I'm Back"

Issue

When trying to access Microsoft Teams Web Client using Google Chrome, You receive the above message and are unable to use Teams.

Cause

The root cause seems to be blocked cookies, so if you Block 3rd party cookies as part of your security policy, i.e. using Google GPO`s, You will see this message.

Resolution 1 (Recommended) - Enterprise

Rather than enabling all 3rd party cookies, you can simply add the below sites to the "Allow Cookies on these sites" option in your GPO. Or add them directly into chrome.

Resolution 2 - Per User

Get users to add teams.microsoft.com as per below and select the option "Including third party cookies on this site"

What I learned at School Today !! - ADFS / Modern Authentication... and why is its disabled by default in Office 365 (Exchange)....

Hi Folks,

As alluded to in the subject,  I wanted to share some of my findings and understandings around all things ADFS / Modern Authentication and Client Access Polices that have cropped up in conversation pieces / issues / designs of late. 

First of all, none of this information is new as such and much of it is splattered across various blogs in various terminologies and scenarios, What I have tried to do is combine this information into some sort of logical breakdown for what we as a team will probably need to know and understand.

What we know today and what has been for a few years…

So Microsoft offer some pretty standard ADFS Control Policies and scenarios of controlling access to Office 365. (See the below).

All pretty standard and Office 365 and ADFS 2.0 and later (inc 2016) will fully support these scenarios in a  “Out of the Box” Configuration today. ! (But… will see later)

So, Little bit of a scene setter as it were.

Company A (Government / Bank / Lawyers) will mostly look at all these scenarios (As above).

o   1. Block All external Access to Office 365  (Easy, But  kind of defeats the object of O365)

o   2. Block external Access to O365 except ActiveSync (Sounds Cool, so yeah, quite common)

o   3. Block all external Access except for Web Based Apps (So OWA, Sharepoint yada, yada, yada)

o   4. Block external Access based on Group membership (as it says on the tin)

So, let’s say we implement option 2.  (Block External Access except ActiveSync).  This works by looking at client application information sent by the client in the ADFS claims request and decides if its allowed or not. (In this case (x-ms-client-application Microsoft.Exchange.ActiveSync). This information is presented kindly by Exchange Online into the request. (In Basic Authentication mode)

So, it’s pretty clear the claims rule looks at the request (working out a:) its external, as it has come via the Proxy (claims/x-ms-proxy), and b:) contains the claims info for ActiveSync).

So all good right.  No one externally can use Outlook or OWA or Sharepoint, but can sync email using ActiveSync….job done..

The but…. So Introducing Modern Authentication

So this has been on the cards for a while and is in full flight, Well sort of,  Outlook 2016 onwards has this enabled by default from a client perspective. (Outlook 2013 needs SP and RegKey, But supports Modern Auth)

So what does it bring to the table.  A couple of key points that makes things Fizz for us (probably a load more, but that’s for another day I guess) !

1.       Native Support for Multi-Factor Auth (No more app passwords). So aimed at ADFS 2016 and Azure MFA out of the box support!

2.       Better support for “real” seamless SSO  (i.e. When used internally  against ADFS there are no more Authentication prompts !!!!  Yey !!!. Have seen this first hand and works a treat.
Note: It uses WIA (Windows Int Auth so ADFS Proxies don’t support WIA and won’t be seamless external, will still get prompted)

Modern Authentication if “OFF” by default on Office 365

So Modern Auth, sounds awesome right !.. and for a good “%” of all customers it’s a “no brainer”.  However as it stands today Exchange Online has Modern Authentication “Disabled”.  !  But why !! it’s awesome !  it’s also worth noting even if we turn on MA,  legacy clients can still fall back to Basic Auth and carry on working !!.. so what’s the catch. !!!  and until I really looked into this, I wasn’t entirely sure.

The Catch

So, as you guessed it`s around Access Policies. So Customer A (Who has these polices enabled). See`s the benefits of Modern Auth and thinks yes, we need this…  So, they turn it on and a world of pain now opens up on the helpdesk (quite slowly after ~24 hrs because ActiveSync cached auth token etc.…..)  and depending on scenario of course. (so we assume most of our Mobile devices use Microsoft Office / Outlook (IOS / Outlook for Android / Windows Phone).  So what’s happened. All of a sudden only a few users are getting email on their mobile device.  My Chief exec of course and his VIP friends cant on their fancy IPad`s with office and his other funky mobile devices.

So what the F**K..  so what has happened.  So Modern Auth has happened.  As I mentioned MA is supported on Office 2013+.  But is Also supported on Outlook for IOS and Android !!.  (Cool yeah !?)

so here’s the curve ball.  When using MA, it’s now “browser based” and is more agnostic on what service is using the authentication. So what has changed?, The Information that was originally in the claims request from exchange (ActiveSync) is no longer embedded in the request,  With modern authentication all clients will use Passive Flows (WS-Federation).  And has we have not allowed “web based” applications and only allowed ActiveSync. These users can no longer get their email ….!!!  Ok, so what next, just turn it off ?  or look to the future ?.. Well “WE (pro`s)”  look to the future of course. !  don’t we?

So, there is no real Like for like option. but here are some options I have looked at that are dead easy to create with ADFS 2016, using some awesome built-in policy templates and rules.

- Option 1.  – We can base external Access to only allow “members of a certain group”.  But this then allows all access (OWA, Sharepoint, Outlook and ActiveSync, un-managed devices)

- Option 2 – Full Microsoft World ,  Fully deploy Intune MDM and use Intune Policies, force                  enrollment etc.

- Option 3 – If using 3^rd Party MDM, i.e. MobileIron, and only allow access from MobileIron IP Sentries,  but this rule alone won’t then allow access for other devices / laptops etc. for your Execs.

- Option 4 – Exchange Mobile Device Polices (Quarantine / Approve) for each user,  very Admin intensive…  not really viable for more than a 50/hundred users/devices..

So no perfect replacement, but we can be a little clever with access polices with and / or scenarios,  so my personal favorite is, we can combine, let’s say Option 1 and Option 3.. ! so this will give us….

-          Allow All “managed”  devices

-          Allow our VIPs / Mobile power workers full access based on Security group…

So as an example, this would look like…

So there you go,   In essence, that’s why we now know why MA is turned off by default and what we need to consider for Company’s who want to control access to O365 when we get into FULL MA World.

  

Sorry, if it’s a little long winded, but it’s a lot shorter than trawling google and TechNet for days on end !!!...

Azure AADConnect error sync-generic-failure Group WriteBack

Issue

During Sync`s you may receive an error something like "sync-generic-failure" With no real information on what the error is. No issues seem to be seen, and is rather just cosmetic. But we don`t like errors right !!!

Fig 1 - AAD Connect Error

Possible Cause

During the setup of AAD Connect, you may or may not have noticed the option for "Group Write-Back"  (At the time of writing this is still in preview). However, even though this sounds cool, there are some pre-reqs that need to be adhered too.  (i.e. Exchange 2013 cumulative update 8 or Later).  So in this case the platform we saw was still only Exchange 2010 !.  And a group was created on O365 and was trying to write-back to On-Prem. 

REF: https://docs.microsoft.com/en-gb/azure/active-directory/connect/active-directory-aadconnect-feature-preview#group-writeback


Solution

Either Disable "Group Write-Back", Remove the Groups created directly in Office 365 or Install the version of Exchange stated above.

Outlook 2013 / 2016 Windows 10 Very slow, Search, Save Attachments, explorer

Scenario

you have Outlook 2013, 2016 and probably running windows 10. PC pretty good spec (8+GB RAM, SSD). However Outlook runs extremely slow, mainly during searches or just saving attachments to the file system., Normal suggestions, Check Anti-Virus, Disable Add-Ins make no difference.


Cause

After many a day patching, removing add-ins, repairing. I came across a article with something related to windows 10 with slowness in Windows folders. (Link at the Bottom for Ref:). The penny dropped.  We are a heavy cloud users with Office 365, SharePoint, One Drive etc.., and a "feature" of Windows 10 is to always show folders and files recently accessed,  so If I have SharePoint URL`s, Other remote locations, which are either not online or just slow really seems to impact the performance of windows explorer and adversely into Outlook !!

Cause

Simply remove the above options by :

1. Opening Windows Explorer
2. Click the 'view' tab.
3. Click 'Options' button.
4. On the 'General' Tab, clear the two privacy options, and click 'Clear' File explorer history

Close, Open Outlook.  WOW. Back to some kind or normality
 

Azure / Office 365 Pass Through Authentication / Selective Authentication & Sub-Domain

Azure / O365 Pass Through Authentication / Selective Authentication & Sub-Domain

PTA

As you may have seen PTA (Pass Through Authentication)  is now in preview. Which in general terms is great news for Standard Azure / O365 Installs to remove the reliance ADFS.

However, as anything new, let’s see the where the limitations are….(AKA Finger in socket test). This also sparked a couple other scenarios…(side related), which I just wanted to share.

So a real life scenario is here we need to provide “selective authentication” within the same tenant .  (Basically we need to direct users from @xyz.com domain and Abc.com domains to their own hosted ADFS AD / service for Authentication. Mainly for autonomous control and not relying on someone else’s  infrastructure (Apart from the AD Connect server)

 This is done by registering each domain with Azure and providing the ADFS Sign-in URL`s…Job done..! (New-msolfederateddomain / convert-MsolDomainToFederated)

(We could use a Shared ADFS service, but this would need “Full forest Trusts” / connected WAN etc.., but as mentioned, antonymous control is key here)

So each domain will provide their own ADFS, Which does the job..(but needs an awful lot of kit spread around the place let’s say ~6 Servers per ADFS solution (2 WAP, 2 ADFS, 2 DC`s + DMZ`s, Load Balancers!), so for example  say we have 5 ADFS solutions, ~30 servers….and so on…

So…  PTA, so what can PTA bring to the table in this scenario. (bearing in mind still in preview). Do we just  stick some agents on DC`s and remove the 30 Plus servers  and DMZ`s, Load Balancers?

Mmm., But what about “selective authentication”, as the whole point is we don’t want to rely on someone else’s servers / forest ?...  , so looking under the bonnet a little (fine print), it turns out that “multi-forest” is supported but must have a “Trust” in place..  so the assumption is that this relys on UPN Suffix routing to route the request to the relevant DC…  (I have posted this question to the site above for response).

So in this scenario, PTA would fail, as we do not have Trusts or Routing or DNS in place for cross forest !

Selective Authentication / Sub-Domains

So, the above investigative work highlighted some potential gotcha`s, with selective authentication withinin the same tenant and what’s possible across tenants.

(Credit: this brought me to http://blog.enowsoftware.com/solutions-engine/using-selective-authentication-per-subdomain-in-office-365)

So, Scenario., we have contoso.com in our tenant, using ADFS and all good.  , We then purchase a new company, and we want them to be known and use NW.contoso.com …. (but as above they are still technically separate, own AD, ADFS, exchange….).

so we add the NW.contoso.com sub-domain to our O365 Tenancy, all good, and we want to enable their local ADFS federation to authenticate anyone using @nw.contoso.com…

So we go and we set this up accordingly in ADFS…..  (Convert-MsolDomainToFederated -DomainName nw.contoso.com –SupportMultipleDomain). Etc…… BUT. ! WTF?

And if we try and login to O365. The new domain will be recognised, but redirected to the parent domains ADFS….!!  Ouch..

Why !?  well, This is down to the inherited link to the parent domain that is created by default if the parent domain already exists…..

So..what now.  well, in all honestly not a lot, and if you’re in this position, it’s down to poor planning or just not knowing, what you know now !!!

However one option (other than rip it up and start again), and one I didn’t think possible.  (but have tested and is valid).  You can actually assign a subdomain to a new O365 tenancy / Azure, even if the parent domain is registered elsewhere in azure !!!!! So the restriction in azure are only at one level, which for a change is a nice little quirk…J

So……… what if your loaded with this before hand ? can we get this solution to fly ? using a single tenant……YES !!!!

As per the accredited link, we simply need to register the subdomains before we create the Parent domain, as you can see, this breaks the root domain link…

We can then assign the required “selective authentication” against these sub-domains from the required ADFS servers.

…but, again a down side, once the parent is created, any additional sub-domains will pick up the inheritance from the parent….. and root authentication traffic to the parent ADFS…

One for the back pocket if nothing else….

Quest Migration Manager (MAGE) Microsoft.Exchange.WebServices.Data.ServiceResponseException: Access is denied. Check credentials and try again.

Issue
During a Mailbox or Calendar sync job, you may receive an error similar to the below on a particular mailbox (s).

"Microsoft.Exchange.WebServices.Data.ServiceResponseException: Access is denied. Check credentials and try again. "

All permissions are set correctly and you can connect via EWSEditor , All AD permissions look correct (inheritance, Full Access)

Problem
Time for spot the difference.  For some reason the "Self" permission was not showing in Exchange Management Shell. (Even though was showing in AD!!)

Missing Self Permission

Added Self Permission

Solution
Re-Add the self permission via EMC and re-synchronize the mailbox. Viola !!!

AutoDiscover fails with 0x80040413 Hybrid Office / 365

Scenario

During a recent Office 365 Hybrid Deployment, we utilized an existing set of Exchange 2010 CAS Servers (Clue) to preform the required Federation, MRS Proxy and AutoDiscover functions. All configuration tasks where completed without error. The Microsoft RCA (Remote Connectivity Analyzer) passed and test mailbox moves worked fine.

The Issue
However.! During the testing of AutoDiscover with setting up Outlook over the web (no SCP)
we discovered this would fail. Upon checking the Outlook "Test E-Mail AutoConfiguration" we were presented with the failure "0x80040413" Failed

Fig 1. AutoDiscover error

The Cause
So, as I mentioned above, The RCA gave us the "all clear", However it did carry a "warning". This is normally to do with some certificate warning on old windows mobile devices. However I decided to drill down through the RCA to find a warning I have "never" seen before. it was the test for "Checking the IIS configuration for client certificate authentication"
There was a warning something like (sorry, did not screen shot) "Client certificate authentication was detected" And a statement around setting to ignore. Upon checking the IIS Virtual Directory for AutoDiscover, Indeed this setting was set to "Accept"

Fig 2. This is what caused the issue.

The Solution
Pretty obvious now, and so it seems from the (Clue) I find myself victim of inheriting a configuration that had been "tampered" with.  So simply set the SSL settings client certificate to Ignore.  All good !

Fig 3. Set back to Ignore. The resolution