2 hours 42 minutes
Hello and welcome back to the office. 3 65 Migration primer. Course I'm gonna shorter Jim Daniels. And for this lesson, we're on Model three. Identity Lesson five. Azure Active Directory connects
In this lesson. We're gonna cover some of the pros and cons of Azure A D Connect
as well as some of the features
as your A D Connect or a D Connect
is the directories synchronization tool that copies or on premise accounts into Azure A. D.
You can also filter which accounts sinking as radi
cloud based accounts that originate in the cloud do not copy to on premise.
Remember earlier we discussed Azure 80
is what office 3 65 uses toe. Authenticate
so as you're 80 connect is the bridge from your Own Premise. Active directory
to populating those values in those fields. In Azure 80
there are two main authentication methods within Azure 80 connect.
The 1st 1 is password hash
in this authentication method, password hashes or sink
from your local 80 into azure. 80
users have the same password on premise, and in Azure 80
password is never sent to Azure 80 or stored in Azure A D. in clear text.
Authentication takes place in Azure a d.
It seems the hash. Instead of the password
passed through authentication.
All the counts are still competency in Azure a D
password hashes or not present
in Azure 80
and forces or on premises, user account states on log one Hours and authentication takes place at a one premise software agent.
All right, so past the room.
It's sort of a hybrid between a DFS and password hash as Radi connect.
It's a fairly new authentication method, but a lot of people are moving toward this because it doesn't require the same infrastructure investment that a DFS does.
So let's take a look at password hash, synchronization and this diagram your on premise organizations. On the left hand side, you have your own premise. Users. You have a server running as your 80. Connect
the user accounts or present
because remember your local out of directory
feeds into as Radi Connect and Mass. How it gets into Azure i d.
When a user goes to authenticate,
they authenticate straight to Azure 80.
As Ready has a copy of the accounts and the hash passports from your own premise user.
So in this model,
nothing comes back home from
now. It'll get passed through authentication
with this one. Your user
tries access, and I happened. Will use office 3 60 Follow, for example.
After they try access the app the users redirected to Azure A D to sign in.
All right, so we're still in the cloud.
At that point, the user enters user name and password information.
The user name and encrypted
password is placed in a queue and as radi,
then it goes to the one premise agent
that takes a request from the queue.
The agent then decrypt the password. Using the private key
validates the user name and passport against
one premise. Active directory
that a director returns. A result to the agent
agent returns. The result to azure A. D as a radi then completes a sign and process if the result of successful user has access.
This looks very similar to a DFS,
except that utilizes as your a D
and a one prim agent.
As far as azure a D connect. Their requirements are pretty simple.
You have to have in as your 80 10
again. Everyone has one. As soon as you sign up for officer in 65.
You have to Adam verify the domain Using Azure Active directory
on premise. You have to have a 2003 plus 80 scheme and force functional level.
Your D C. That is used by Azure 80 Connect cannot be a read only domain control.
You have to have it installed on a Windows Server 2008 or two plus,
which shouldn't be that bad, because that is even doing end of life here soon in 2020
as your active directory 80 Connect server, you need to have dot net 451 or above and Power shell three or above.
All right, So here's a quiz
Cloud created user accounts seemed to own premise Active directory When using
as Radi Connect,
we talked briefly about this toward the opening.
The answer that is false.
It does not run back the whole entire object.
Let's look at some of the options within. As Radi connect,
you have the ability to select which domains and oh used to sink. If you have a certain OU that contains user objects that will never have a cloud presence,
I don't think it
password right back.
You can enable self service password reset in Officer 65
that allows a user to reset their credentials
in Officers 65. And it writes that password value back into your own premise. Active directory.
So the update, the password. It also reflects him with azure A D, and it goes in and replace him with your local out of directory,
you have exchanged hybrid options.
You have passwords, sink versus password hash.
You also get a choose which active directory attributes You want to think
you can map attributes into custom attributes, and I drive a directory custom sink rules as well. It's very flexible
for daily management. For those users.
These are objects or manage one premise out of the right jury. The daily Management for Azure 80 connect
for your users is exactly the same as your A DFS.
You're going to manage all of the out of directory. Ashby's confrim,
um, with a duck or any of you. Other 80 tools office 3 65 specific attributes such as licensing and other cloud attributes. You manage those either in the 3 65 admin center or in the azure 80 at in center
So, to recap,
as your 80 connect is a tool that sinks on Premise 80 data into as your active directory
as your 80 Connect supports both passed through and password hash authentication models.
Password Right back is a feature supported by as your 80 connect
and allows users to reset their passwords and unlock their accounts from the cloud.
Thank you for taking time to joining me in this lesson. I hope to see you for the next one. Thank you.