you know there are things in life that people talk about in strange terms they
say yeah that'll happen when pigs fly or when the cows come home or when a
certain place might freeze over and as strange as this introduction may sound
we do have one of these things to talk about today in reference to the cloud
and that is creating trusts between our on-premise domain and Azure Active
Directory domain services I'm Dean Cefola and this is the Azure Academy
this is an exciting and unexpected video because the azure ad domain services
model was always set up as a managed domain controller in the cloud that just
functioned as a domain as a service so it wasn't something that you could ever
manage you didn't really have any rights inside the domain and this move to make
azure ad domain services something that is more accessible to on-prem
environments is really the direct result of your feedback and helping us to
constantly improve products in Azure so this video in particular came to my
attention because it was requested by one of the members of our community so
thank you for that and this is also a call to action if you have anything that
you're interested in that we don't currently have please let me know and
we'll be happy to create that for you first thing that we should do is we
should set a framework for why this actually exists going against the
original model so let's take a look at the azure Doc's well in our Doc's page
we'll go to products and on the Left we'll go down to identity and then
Active Directory for domain services and over on the left under tutorials we'll
go to create a forest thrust so the basic use case here is if you're
familiar with the red forest concept or tier 0 tier 1 tier 2 concepts these are
basically ways to set out your directory structures so that you can have layers
of protection now in these high secure or highly dispersed environments
sometimes customers do not want to have a tool like azure ad connect sending
data out of their trusted tr02 the public cloud
and in those cases then you're obviously not doing password hash saying poor
password right back and it's also common to see that there are smart cards or MFA
devices like RSA tokens or USB keys that are in those environments to control
those privileged access workstations to be able to get into those tr0 assets and
part of that red forest type design is where we set up a resource forest
what is a resource forest well basically it's where we can do identity
pass-through because of our trust as you can see in the picture here but the
identities themselves only reside in the on-prem domain and so when a user
authenticates their authentication will hit as your ad domain services and
redirect over the trust back to on-prem so this is in lieu of those azure ad
connect features so a nice thing about this as well especially if you're
migrating to the cloud is this means that you do not have to change
everything about your application as you do the move if you have domain
controllers still on Prem and nothing in the cloud then you can set up ad domain
services with this trust and then you can move those applications one
component at a time and then the last thing that we should mention up front is
what exactly is a trust a trust is a relationship between two domains or two
forests and these trusts can be in several different manners they can be
one-way or two-way which one way is this object trusts this object a two-way
trust would be that they trust each other and then there is transitive and
non transitive and so this particular relationship is non transitive but a
transitive relationship would be when I trust you I trust everyone you trust so
in this case this is non transitive because we're only trusting from Azure
ad domain services back to your primary Active Directory that we are
establishing the trust with so if there are any other trusts from your ad to
somewhere else we will not be trusting them you'd have to set up separate
trusts for each of those we're gonna do a five-step process today and first
thing is we'll be deploying as your ad domain services then we'll be
configuring our on-prem ad in order to be able to forward requests then setting
up the inbound trust on our on-prem a b-side setting up the outbound trust on
ad domain services and then doing some testing to make sure everything works as
expected let's jump over to the azure portal so
the first thing we need to do is set up our azure ad domain services so I've got
that up at the top here we need to hit create and in order for you to be able
to do this you do need to be a global administrator within Azure Active
Directory so I'll put this in a resource group that I already have set up and
then we have to give our domain a name and then at the bottom we select what
location we want you to play in and we have the choice now of a forest type so
we'll be changing from user to resource and that is going to set up our trust
abilities and we'll hit next for the network and I've already got a network
set up for this and then hit next here for the administration side and we'll
leave the settings here as default which will give our global admins rights
inside as your ad domain services and we'll hit next and now we have these
synchronization and here we can choose scoped or all if we choose scoped then
we'll have to select a group and that group will be the group that we
synchronize over so by default we have as raid EDC administrators these are the
admins of the azure ad domain service and we can also add other groups for
example I could add my admins or I could also add my wbd users so I can add any
groups that I want and then they would be synchronized over but in this case
I'm just going to select all and then hit review and create and it validates
that everything is okay and then we push create and because this is a one-time
event we're getting a extra warning here to make sure that we've done everything
exactly as we want it because once we do we will not be able to change it you'd
have to delete and throw away as your ad domain services and start again but I'm
okay with everything so I'll hit OK now this deployment of as ready domain
services takes about 20 to 40 minutes so in the meantime we need to set up a
domain controller at the top here we'll type deploy and we'll go to deploy a
custom template and at the load a github QuickStart template at the bottom we're
gonna type the word domain and we'll select active directory new domain and
then hit select template and we'll create a new resource group for this
we'll put this in the east us as well and then we need to give our basic
information here then we check the box at the bottom and click purchase and now
that deployment is in progress and this will take about 10 minutes as well
as your ad domain services has completed building and we can see it's currently
running and we have right in the center the ability to create a trust which will
come back to that in a moment so let's go check out our domain controller that
we also set up and we can see that we have a availability set along with a OS
and data disc a load balancer one network card one public IP one
virtual machine and we also got a virtual network created so in order to
make this network able to talk to Azure ad domain services instead of having a
VPN or Express route kind of connection I've set up v-net peering and the
peering basically allows both networks to talk to each other in both directions
and back in the resource groups let's look at the resource group where ad
domain services actually lives now this looks very similar to the domain
controller build-out that we just looked at because azure ad domain services is
basically a managed domain controller instance in the cloud inside this
instance there are two VMs each one has their own NIC they're tied to a load
balancer with an NS G and a public IP address on a network now getting to our
trust first thing we need to do is set up some DNS settings on our domain
controller and for that we're gonna need the private IP addresses of our two VMs
which we can get either from going to our virtual network and seeing what IP
addresses we've gotten to our devices or we can find that in Azure ad domain
services under properties we can see them right there as well so I'll just
copy those let's go to our on Prem domain controller so I've already logged
in and opened the DNS manager which is installed by default when you make the
system a domain controller what we're gonna do is set up a forwarder so I'm
gonna right-click on the server and go to properties then we'll go to the
forwarders tab and hit edit and then we'll type in our IP address here and
those have validated even though it cannot resolve the DNS name we'll hit OK
and we'll apply and hit OK there as well now when a DNS request comes in that
this server is unaware of how to resolve it it will have somewhere to forward
those requests into as any domain services and what we need to
do next is start domains and trusts and we'll right-click on our domain and go
to properties here and we'll go to the trusts tab and then we'll click the new
trust button and we'll need to add the dns name for the forest that we're going
to talk to and we can find that back in Azure so we'll just copy the name of our
AADDS instance and then we'll hit next and this is going to be a forest trust
and then this is going to be one way incoming because the AADDS instance is
going to send requests to our internal domain and then we'll hit next and this
will be created for this domain only we'll hit next then we need to set up a
password for this trust then we'll hit next and we've got our review here and
we can see our domain name from ad domain services that this is an incoming
trust it is a forest type trust and then our outgoing authentication level is
forest wide as well we can it next and we can hit next now to configure the new
trust and we'll click yes to configure the new trust now and we need to type in
the user who has permissions in the ad DS domain and then we can click Next and
then click finish so our trust on this side has been done
and now in order to complete the connection we need to do the ad DS side
so let's go there okay and in Azure we'll go to our ad DS instance and click
the Create trusts and we have a warning here at the top that we cannot do this
part until we've created the outbound trust on our on-prem which we have just
finished it will click Add here and then we need to give our trust a name and we
need to enter the name of our forest on Prem and the password that we set up and
then we need the IP addresses of our DNS servers on Prem as well and then we can
click Save at the top that finished in about two minutes and then you can see
at the bottom here what domain we are connecting to and the DNS information
that we entered we're gonna now go into our on Prem domain controller and then
see how we can leverage this resource forest that now we have a trust with
this is a server a DVM and the domain is on
a massager academy.com and you can see up here in the command prompt I'm logged
in with my local admin user and that is a member of this local domain so now
I've got another VM that I've stood up in Azure and this VM is joined to the
azure ad domain services domain and it's just called testtrustVM.AADDS.MSAzureAcademy.com
however when I do my command to see who I am and you can
do that with Who am I space forward slash fqdn and I push enter you can see
that I am that same user from the on-premise domain even though the VM
itself is part of the azure ad domain services domain so that's the nature of
a resource forest now what can we do with this well we can get access back to
all of our on-prem resources that this user has access to for example there are
a series of shares that are open and we go into IT here and we can see a bunch
of different programs that we could install and scripts for example we can
open this PowerShell file and then we could run this script if we want to or
we could run this JSON file and open that notepad so we can access file
sharers we can access printer services and then we can also do things
leveraging our security groups across domains as well so here in our VM that's
joined to the azure ad domain services domain we've created a share folder on
the C Drive and in here we've created another folder and this is called the no
trust share and if I look at properties under sharing we can see under the
permissions that this is shared with my temp user we go back to our on-prem we
can see that folder from that VM as well but when we try to access it we only get
basically read-only access we can't create any kind of files here because we
don't have any permissions how can we make something like this work across
this resource trust and we'll create for ourselves inside this as your ad domain
services active directory will create a new OU you and we'll call this local
object and hit okay and inside here we'll
create a new group and we'll call this file server access and we'll change our
scope to domain local and inside that group we'll go to add some members and
you can see by default we can see only the domain that we are a part of but we
can change our location to our on-prem that we are trusted with and we'll hit
advanced here and find now and it wants us to provide our credentials for the
on-prem domain and we can see at the bottom all of our users from that
trusted on-prem domain we're gonna just add all domain users just to make it
easy and hit OK and we'll apply and ok that so now we'll go and set up a new
share here and we'll call this Ross forest share and then we'll go to the
properties here then we'll go to the Security tab and we'll push the edit
button then we'll add our local group for the file server access and ok and
will allow modify here and we'll hit apply and ok and then we'll go to the
sharing tab we'll share and then permissions here and then we'll select
change permissions for this and we'll hit apply and ok on all these windows
and back on our on Prem system we'll hit refresh and there is our cross forest
share it we'll open that up and then go to right click new folder and we can
create a new folder here and I'll create one for my user and then within there
we'll create a new text file and we'll just put hello world in there and that's
saved so let's go back to our ad domain services system and we can see all of
that from here as well so hope that you've enjoyed looking at this brand new
feature how we can finally enable cross forest trusts with Azure ad domain
services and our other on Prem or azor based domains and this is going to
certainly help open up some of those use cases where we cannot use Azure ad
Connect as well as if we have other security precautions in the environment
like privileged access workstations smart cards or USB based MFA tokens
cetera we can leverage that trust to help us get things done in the cloud so
if you thought this was a good video please do click on the subscribe button
and join us here at the Azure Academy and while you're down there click on
that like button as well as the notification icon so you
can get an email when our videos come out which is roughly once a week and
this video was requested by one of the members of our community so if you have
a request for a video that you would like to see made please do give us some
comments down below on what you'd like and how that would benefit the community
and we'll be happy to make that video for you so thanks very much for joining
us today and we will see you in the next video happy learning