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

Outlook 2010 Office 365 Direct Access Forced Tunnell Disconnected

Scenario
Windows 7 / Outlook 2010 SP2 + Patches Clients using Direct Access and configured for Forced Tunneling. Clients connect via a webproxy via DA Policy. User mailbox is migrated to Office 365 / Exchange online.  

Problem
When on WAN / LAN normal Wi-Fi, there are no issues. But when client connects over Direct Access, Outlook will not connect to Office 365 and says disconnected.  Windows 7 / Outlook 2010 is fully patched.  (this may be where the problem lies). Access to webmail, normal internet is fine.

Solution / Workaround
At the time of writing there is no official word on Microsoft on this issue. (Although we have a pending case, in which I will update accordingly).

But after trial and error, I stumbled across this KB.  (Not directly related but started the cogs turning.)
So I reversed this setting to Disable MAPI/HTTP (MS new way of connecting to Exchange) by adding the below Key.

Key: HKEY_CURRENT_USER\Software\Microsoft\Exchange
DWORD: MapiHttpDisabled
Value: 1

Note: The setting takes a few minutes to kick in, after it updates via AutoDiscover.

So how do you know when this is kicked in ?

 OK,  so where you would normally see the “connection” tab in account settings, when MAPI/HTTP is enabled,  This disappears..:) Once this is disabled.  It reappears..,

 

Once this became active. Outlook connected Via Direct Access !!!!   Thanks MS. Await the Official KB / Hotfix....