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….
