WEBVTT

0:00:03.080000 --> 0:00:08.980000
 In this video, we're going to take a
 look at hybrid identities and hybrid

0:00:08.980000 --> 0:00:12.320000
 identity architectures
 in Azure AD.

0:00:12.320000 --> 0:00:16.660000
 Let's take a quick look at what
 we're going to be talking about.

0:00:16.660000 --> 0:00:21.980000
 I'm going to go over hybrid identity,
 what hybrid identity is and what

0:00:21.980000 --> 0:00:26.920000
 the components are, and really what the
 options are with hybrid identity.

0:00:26.920000 --> 0:00:32.040000
 And then we're going to cover some
 supported architectures within the

0:00:32.040000 --> 0:00:35.020000
 concept of hybrid identity.

0:00:35.020000 --> 0:00:39.980000
 So let's get started by mapping out what
 are the components, what is hybrid

0:00:39.980000 --> 0:00:44.200000
 identity and what are the components
 for hybrid identity.

0:00:44.200000 --> 0:00:50.520000
 It starts out with the concept of having,
 of thinking about what Azure

0:00:50.520000 --> 0:00:53.140000
 AD really is and what
 it's used for.

0:00:53.140000 --> 0:00:57.120000
 So if I've got Azure
 AD, here's AAD.

0:00:57.120000 --> 0:01:07.920000
 When it comes down to it, the purpose
 of AAD is to, wrong thing there,

0:01:07.920000 --> 0:01:13.580000
 let's try that again, is to support
 cloud based applications.

0:01:13.580000 --> 0:01:17.960000
 So I have a cloud app, we'll just say
 CA, it's a web based application.

0:01:17.960000 --> 0:01:21.580000
 And I have some user over here.

0:01:21.580000 --> 0:01:29.840000
 And that user wants to access the cloud
 based application, but they need

0:01:29.840000 --> 0:01:31.240000
 to be authenticated.

0:01:31.240000 --> 0:01:37.020000
 And the cloud based application has
 a trust relationship with Azure AD.

0:01:37.020000 --> 0:01:41.420000
 So the user's going to be redirected
 over to Azure AD to perform their

0:01:41.420000 --> 0:01:46.380000
 authentication. Now, once they're authenticated,
 then they get their identity

0:01:46.380000 --> 0:01:53.520000
 back from Azure AD and they can send that
 identity on to the cloud application.

0:01:53.520000 --> 0:01:56.040000
 And the cloud application will accept
 it because again, it's set up a

0:01:56.040000 --> 0:01:59.800000
 trust relationship with Azure AD.

0:01:59.800000 --> 0:02:05.040000
 Now, if you think about your users,
 oftentimes I've got users who have

0:02:05.040000 --> 0:02:10.460000
 accounts in our on premises
 Active Directory.

0:02:10.460000 --> 0:02:13.400000
 So over here I've got Active Directory,
 that's my little Active Directory

0:02:13.400000 --> 0:02:20.560000
 Triangle. And this is my on prem,
 so we'll just say OP for on prem.

0:02:20.560000 --> 0:02:24.440000
 And that user has an account
 on premises as well.

0:02:24.440000 --> 0:02:27.380000
 But what I really don't want to do
 is I don't want to have to maintain

0:02:27.380000 --> 0:02:31.040000
 two different sets of accounts.

0:02:31.040000 --> 0:02:33.980000
 So in other words, it would be really
 painful if I'm a user and I have

0:02:33.980000 --> 0:02:38.400000
 to have one set of accounts to get to
 my applications that are on premises.

0:02:38.400000 --> 0:02:41.220000
 And for the same company, same organization,
 I have to have another set

0:02:41.220000 --> 0:02:43.120000
 of accounts to get
 to my cloud apps.

0:02:43.120000 --> 0:02:47.220000
 So what we do is we synchronize
 the accounts.

0:02:47.220000 --> 0:02:53.940000
 And to synchronize the accounts, we use
 something called Azure AD Connect.

0:02:53.940000 --> 0:02:57.140000
 And no matter what your architecture,
 we're going to talk about different

0:02:57.140000 --> 0:03:03.240000
 architectures and different options,
 it all starts with Azure AD Connect.

0:03:03.240000 --> 0:03:09.240000
 And this is really just an agent service
 that you install on a machine

0:03:09.240000 --> 0:03:18.500000
 on premises. And what it's going to
 do is synchronize at a minimum your

0:03:18.500000 --> 0:03:22.180000
 objects, your Active Directory objects,
 your selected Active Directory

0:03:22.180000 --> 0:03:24.180000
 objects into Azure AD.

0:03:24.180000 --> 0:03:28.360000
 Now depending on your settings and
 your licensing, there's some right

0:03:28.360000 --> 0:03:30.160000
 back capability as well.

0:03:30.160000 --> 0:03:33.980000
 So we have that whole
 capability there.

0:03:33.980000 --> 0:03:36.640000
 But this is the basic
 idea that way.

0:03:36.640000 --> 0:03:43.880000
 My user over here who has their account,
 they've got an account in the

0:03:43.880000 --> 0:03:48.860000
 on-prem ID and that's the account that
 they want to use when they authenticate

0:03:48.860000 --> 0:03:56.960000
 with Azure AD. Now I'm going to
 clear this and get it back.

0:03:56.960000 --> 0:03:59.620000
 And redraw the parts of it because
 I want to talk about the different

0:03:59.620000 --> 0:04:02.480000
 options for authenticating.

0:04:02.480000 --> 0:04:08.160000
 And so we'll just put the
 pieces back on here.

0:04:08.160000 --> 0:04:16.440000
 And this is my cloud app.

0:04:16.440000 --> 0:04:18.620000
 This is Azure AD.

0:04:18.620000 --> 0:04:28.300000
 This is AAD Connect.

0:04:28.300000 --> 0:04:35.360000
 And this is my user.

0:04:35.360000 --> 0:04:38.600000
 And different hat, same user.

0:04:38.600000 --> 0:04:44.820000
 Now at a minimum, we're going to synchronize
 account information from

0:04:44.820000 --> 0:04:47.260000
 the on-prem into Azure AD.

0:04:47.260000 --> 0:04:53.080000
 And there are a couple of different
 options for that synchronization.

0:04:53.080000 --> 0:05:02.900000
 One option for synchronization
 is to sync without password.

0:05:02.900000 --> 0:05:09.540000
 If I sync without password, I'm going
 to have on-prem accounts and I'm

0:05:09.540000 --> 0:05:13.820000
 going to have those same accounts
 synchronized up into Azure AD.

0:05:13.820000 --> 0:05:18.480000
 However, the user is going to need to
 maintain two different passwords.

0:05:18.480000 --> 0:05:20.700000
 One, I mean they could set them the
 same, but they're going to have one

0:05:20.700000 --> 0:05:25.480000
 password, maintenance effort for the on
-prem and then for the same account,

0:05:25.480000 --> 0:05:29.900000
 I would have a different maintenance
 effort in Azure AD.

0:05:29.900000 --> 0:05:39.220000
 A variation of that is going
 to be sync with password.

0:05:39.220000 --> 0:05:42.840000
 And with sync, let's
 put a C in there.

0:05:42.840000 --> 0:05:49.680000
 Sync with password, what that's going
 to do is that is going to give you,

0:05:49.680000 --> 0:05:57.520000
 give the user the same password, both
 in Azure AD as they have on-premises.

0:05:57.520000 --> 0:06:03.660000
 And that means, of course, when the
 user attempts to log in and they get

0:06:03.660000 --> 0:06:07.880000
 redirected over to Azure AD, they're
 going to present the same credentials

0:06:07.880000 --> 0:06:11.740000
 they would on-premises
 into Azure AD.

0:06:11.740000 --> 0:06:18.940000
 There is a variation of sync with
 password for on-premises users.

0:06:18.940000 --> 0:06:24.980000
 I can set up sync with password
 with SSO, single sign-on.

0:06:24.980000 --> 0:06:30.720000
 Now it's all single sign-on, but specifically
 what the SSO does is it

0:06:30.720000 --> 0:06:34.140000
 makes it easier for people that are
 already logged into the domain.

0:06:34.140000 --> 0:06:38.760000
 So if I'm on a machine locally on the
 domain, I'm logged in and I try

0:06:38.760000 --> 0:06:46.060000
 to go to that cloud app, then I'm actually
 going to be silently authenticated.

0:06:46.060000 --> 0:06:53.760000
 There's JavaScript that's added to your
 browser, your session, and then

0:06:53.760000 --> 0:06:54.940000
 that kind of handles it.

0:06:54.940000 --> 0:06:57.620000
 But that would be sync
 with password with SSO.

0:06:57.620000 --> 0:07:03.600000
 Now in both of those cases, the password
 itself is stored, a hash of the

0:07:03.600000 --> 0:07:06.100000
 password. By the way, I should say
 sync with password doesn't sync the

0:07:06.100000 --> 0:07:08.940000
 password, it syncs a
 hash of the password.

0:07:08.940000 --> 0:07:13.220000
 But in both cases, a hash of your
 password is stored in Azure AD.

0:07:13.220000 --> 0:07:19.300000
 It is also possible to have something
 called pass-through.

0:07:19.300000 --> 0:07:26.820000
 And with pass-through authentication,
 what happens is that when the user

0:07:26.820000 --> 0:07:33.980000
 is redirected to AAD, they will
 enter their credentials.

0:07:33.980000 --> 0:07:37.340000
 Now those credentials are not
 immediately authenticated.

0:07:37.340000 --> 0:07:41.720000
 Instead, they're stored
 in a queue.

0:07:41.720000 --> 0:07:51.780000
 And there is a process running on-prem,
 which is the, I was just saying,

0:07:51.780000 --> 0:07:54.100000
 PT for pass-through process.

0:07:54.100000 --> 0:07:56.960000
 And that's monitoring the queue, and
 what that's going to do, it's going

0:07:56.960000 --> 0:08:01.500000
 to go, it will take the credentials,
 and bring them down, and actually

0:08:01.500000 --> 0:08:06.400000
 submit those credentials on-premises,
 and authenticate you, and then pass

0:08:06.400000 --> 0:08:09.120000
 your authentication back up.

0:08:09.120000 --> 0:08:11.880000
 Now there's a couple of advantages
 of pass-through.

0:08:11.880000 --> 0:08:16.200000
 First of all, if there's an account
 that is disabled on-premises, that

0:08:16.200000 --> 0:08:18.380000
 effect is going to be immediate.

0:08:18.380000 --> 0:08:22.740000
 Whereas if I'm using synchronization,
 it's going to have to wait for the

0:08:22.740000 --> 0:08:28.680000
 next synchronization action for
 any changes to be affected.

0:08:28.680000 --> 0:08:34.040000
 But in this case, if I'm using pass
-through authentication, then it's

0:08:34.040000 --> 0:08:38.480000
 going to be a bit, or it's
 going to be immediate.

0:08:38.480000 --> 0:08:41.440000
 Now of course, I will say that pass
-through authentication does take a

0:08:41.440000 --> 0:08:45.580000
 bit longer than the other authentication
 options because you have this

0:08:45.580000 --> 0:08:48.660000
 what is effectively an
 asynchronous process.

0:08:48.660000 --> 0:08:51.180000
 The user is going to submit their credentials,
 it's going to go into a

0:08:51.180000 --> 0:08:55.360000
 queue, and then that has to be picked
 up, and it's not an instantaneous

0:08:55.360000 --> 0:08:59.220000
 process. Again, it's not a matter of
 minutes, certainly, but it could

0:08:59.220000 --> 0:09:05.060000
 be several seconds depending on your
 throughput for that pass-through

0:09:05.060000 --> 0:09:09.740000
 service to pick the data up
 and then authenticate you.

0:09:09.740000 --> 0:09:13.980000
 Now, let's see if I can
 go back far enough.

0:09:13.980000 --> 0:09:20.360000
 I'm going to take that out and
 talk about another option.

0:09:20.360000 --> 0:09:24.260000
 Another option is something
 called federation.

0:09:24.260000 --> 0:09:27.980000
 You may be familiar
 with federation.

0:09:27.980000 --> 0:09:31.400000
 I'm actually going to have to redraw
 this because I could only back out

0:09:31.400000 --> 0:09:33.900000
 so much with the tools
 that I'm using.

0:09:33.900000 --> 0:09:37.080000
 We'll just pop that
 back in real quick.

0:09:37.080000 --> 0:09:39.120000
 Just redraw the parts.

0:09:39.120000 --> 0:09:41.840000
 But we're going to talk
 about federation now.

0:09:41.840000 --> 0:09:45.680000
 Same parts. A little bigger
 for some reason.

0:09:45.680000 --> 0:09:51.900000
 Same part, so. This is my CAAD.

0:09:51.900000 --> 0:09:59.960000
 I've got my active directory, and I
 still have, I'm going to say, AADC

0:09:59.960000 --> 0:10:02.220000
 for AAD Connect.

0:10:02.220000 --> 0:10:07.420000
 That is still synchronizing my identities,
 but I'm now going to implement

0:10:07.420000 --> 0:10:10.720000
 a federation server.

0:10:10.720000 --> 0:10:14.940000
 The default federation
 server is ADFS.

0:10:14.940000 --> 0:10:19.780000
 There's actually two components to ADFS,
 but right now we're just going

0:10:19.780000 --> 0:10:22.460000
 to put it in here as ADFS.

0:10:22.460000 --> 0:10:34.860000
 The idea, if I'm using ADFS, is that
 the user, I'll wear a slightly larger

0:10:34.860000 --> 0:10:42.800000
 hat, when the user attempts to authenticate
 with the cloud app, user gets

0:10:42.800000 --> 0:10:51.200000
 redirected to Azure AD, but then the
 user further gets redirected to ADFS.

0:10:51.200000 --> 0:10:55.820000
 The user is going to present their
 credentials directly through ADFS,

0:10:55.820000 --> 0:11:01.240000
 and ADFS is going to authenticate
 them directly on premises.

0:11:01.240000 --> 0:11:05.960000
 At this point, Azure AD is not actually
 performing the authentication.

0:11:05.960000 --> 0:11:14.980000
 What happens is that ADFS generates
 a token for the user.

0:11:14.980000 --> 0:11:19.220000
 That token has the claims, the information
 associated with the user.

0:11:19.220000 --> 0:11:22.880000
 It's signed by a certificate that's
 understood by, or it's actually been

0:11:22.880000 --> 0:11:24.900000
 registered in Azure AD.

0:11:24.900000 --> 0:11:26.300000
 There's a whole process.

0:11:26.300000 --> 0:11:32.640000
 What happens is that gets sent back
 with the redirection back into AD.

0:11:32.640000 --> 0:11:35.100000
 Now, I should note, all these redirection
 are going to be transparent

0:11:35.100000 --> 0:11:42.140000
 to the user. Now, AAD gets that user's
 identity from the token sent from

0:11:42.140000 --> 0:11:46.480000
 ADFS. The problem is that the
 cloud app doesn't know ADFS.

0:11:46.480000 --> 0:11:51.440000
 As far as the cloud app is concerned,
 the relationship is solely between

0:11:51.440000 --> 0:11:53.720000
 the cloud app and the AAD.

0:11:53.720000 --> 0:11:58.940000
 Cloud app doesn't care how AAD authenticates,
 but it expects AAD to do

0:11:58.940000 --> 0:12:00.500000
 the authentication.

0:12:00.500000 --> 0:12:06.680000
 What happens when you're using a federated
 process is that when the token

0:12:06.680000 --> 0:12:11.460000
 comes back, when the identity comes
 back to Azure AD, it's going to then

0:12:11.460000 --> 0:12:16.440000
 regenerate its own token, signed with
 a certificate that is understood

0:12:16.440000 --> 0:12:18.420000
 and trusted by the cloud app.

0:12:18.420000 --> 0:12:21.740000
 Then what happens?

0:12:21.740000 --> 0:12:28.820000
 That's going to be sent back, redirected
 to the cloud app, and then that

0:12:28.820000 --> 0:12:33.020000
 token is used to authenticate
 within the cloud app.

0:12:33.020000 --> 0:12:41.160000
 That is the configuration for the implementation
 for a federated approach.

0:12:41.160000 --> 0:12:48.000000
 There's really four different approaches
 to authentication using AAD with

0:12:48.000000 --> 0:12:50.280000
 integrating with your on-prem.

0:12:50.280000 --> 0:12:54.720000
 Your first is synchronized
 without password.

0:12:54.720000 --> 0:12:57.380000
 That's going to be the
 simplest, if you will.

0:12:57.380000 --> 0:13:00.880000
 You're just synchronizing the account,
 the user's maintaining two passwords.

0:13:00.880000 --> 0:13:06.700000
 The next step up would be synchronizing
 with password, which is really

0:13:06.700000 --> 0:13:07.700000
 not the password.

0:13:07.700000 --> 0:13:12.140000
 It's really the password hash.

0:13:12.140000 --> 0:13:15.320000
 Then you have pass through authentication
 where the user presents their

0:13:15.320000 --> 0:13:19.420000
 credentials to Azure AD, but they're
 authenticated on-premises.

0:13:19.420000 --> 0:13:24.300000
 You really move into the fully on-premises
 mode, which is with a federated

0:13:24.300000 --> 0:13:26.820000
 service, which is going to be the most
 powerful option, giving you the

0:13:26.820000 --> 0:13:30.740000
 most flexibility, but also require
 the most configuration.

0:13:30.740000 --> 0:13:37.200000
 Now, let's go ahead and take a look
 at some of the architectures that

0:13:37.200000 --> 0:13:43.840000
 are supported with Azure AD and integration
 with the on-prem environment.

0:13:43.840000 --> 0:13:48.560000
 The first is the simplest, and that
 is you have a single forest and you

0:13:48.560000 --> 0:13:53.660000
 have a single synchronization server,
 a single Azure AD Connect server,

0:13:53.660000 --> 0:13:55.720000
 and a single tenant.

0:13:55.720000 --> 0:13:57.400000
 That's easy to do.

0:13:57.400000 --> 0:14:04.620000
 Now, an alternative version of this
 is that you have multiple forests,

0:14:04.620000 --> 0:14:09.020000
 but you're still using
 a single sync server.

0:14:09.020000 --> 0:14:12.260000
 You're still using a single
 implementation of Azure AD.

0:14:12.260000 --> 0:14:20.360000
 Now, with this architecture, we have
 the ability to do this easily, but

0:14:20.360000 --> 0:14:25.900000
 this is only going to work
 if I've got isolated users.

0:14:25.900000 --> 0:14:31.480000
 In other words, I don't have any users
 that are in common or are shared

0:14:31.480000 --> 0:14:33.680000
 across the different forests.

0:14:33.680000 --> 0:14:38.760000
 In other words, I don't have, let's say,
 a resource and account architecture.

0:14:38.760000 --> 0:14:45.440000
 I have two completely separate forests,
 and I'm using the same sync server

0:14:45.440000 --> 0:14:47.280000
 for them. That's fine.

0:14:47.280000 --> 0:14:54.980000
 Now, alternatively, I could have multiple
 forests with a single sync server

0:14:54.980000 --> 0:15:00.540000
 and a single tenant, but in this
 case, I need to match users.

0:15:00.540000 --> 0:15:07.440000
 What that is, I might have, let's say,
 this is maybe my accounts forest,

0:15:07.440000 --> 0:15:08.940000
 and this is my resource.

0:15:08.940000 --> 0:15:12.880000
 I've got my users up in the A forest,
 and I've got things like printers

0:15:12.880000 --> 0:15:16.260000
 and database servers and everything
 else in the resource.

0:15:16.260000 --> 0:15:22.160000
 But I've got users from the
 A that have rights in the R.

0:15:22.160000 --> 0:15:25.480000
 They're going to have
 references in the R.

0:15:25.480000 --> 0:15:29.100000
 In that case, I need
 to match these users.

0:15:29.100000 --> 0:15:34.140000
 I can have a full mesh where I've got
 multiple two-way trusts or, again,

0:15:34.140000 --> 0:15:35.640000
 this account resource.

0:15:35.640000 --> 0:15:40.700000
 All you have to do is say, okay, here's
 how user records are matched in

0:15:40.700000 --> 0:15:41.920000
 these two different forests.

0:15:41.920000 --> 0:15:45.160000
 For example, matched based
 on email address.

0:15:45.160000 --> 0:15:48.760000
 If it sees the same email address in
 different forests, it knows that's

0:15:48.760000 --> 0:15:53.520000
 the same user. That
 is another option.

0:15:53.520000 --> 0:16:05.660000
 And then another option that we have
 is really a version of single forest,

0:16:05.660000 --> 0:16:08.260000
 single tenant. That's multiple
 forests, multiple tenant.

0:16:08.260000 --> 0:16:12.220000
 I've got multiple forests, and each
 one is really independent, and each

0:16:12.220000 --> 0:16:18.640000
 one is associated with
 a different tenant.

0:16:18.640000 --> 0:16:26.580000
 Now, I can, using Azure ADB to be,
 just like I could have trusts in my

0:16:26.580000 --> 0:16:31.900000
 on-prem environment, I can set up B
 to B relationships with guest users

0:16:31.900000 --> 0:16:36.960000
 across my different tenants,
 and that's fine.

0:16:36.960000 --> 0:16:38.740000
 That is absolutely an option.

0:16:38.740000 --> 0:16:40.840000
 That's going to be, if you have multiple
 forests, that's really going

0:16:40.840000 --> 0:16:43.540000
 to be the easiest of the options.

0:16:43.540000 --> 0:16:51.580000
 Now, I also, as a kind of last architecture
 here, I might have a single

0:16:51.580000 --> 0:16:55.880000
 forest with multiple domains, but I want
 each domain to go to a different

0:16:55.880000 --> 0:17:04.960000
 tenant. For example, maybe I've got
 my primary corp users, let's go back

0:17:04.960000 --> 0:17:07.800000
 there for a second.

0:17:07.800000 --> 0:17:17.360000
 There we go. I've got my primary corp
 users, but I also have a fairly

0:17:17.360000 --> 0:17:21.960000
 independent R&D set of users.

0:17:21.960000 --> 0:17:23.900000
 I've got a subdomain for R&D.

0:17:23.900000 --> 0:17:32.260000
 Well, I want my subdomain, my R&D
 folks, to go to the R&D tenant.

0:17:32.260000 --> 0:17:37.540000
 I could actually set up filtering in
 the synchronization so that each

0:17:37.540000 --> 0:17:43.720000
 of my synchronization is filtered
 to the appropriate set of users.

0:17:43.720000 --> 0:17:47.500000
 What you want to be careful with, of course,
 if you've got multiple tenants

0:17:47.500000 --> 0:17:54.600000
 associated with the same forest, you
 want to make sure that you don't

0:17:54.600000 --> 0:17:57.440000
 have overlap because
 that can get bad.

0:17:57.440000 --> 0:18:07.040000
 That is another option with this concept
 of on-prem identity and multiple

0:18:07.040000 --> 0:18:09.300000
 on-prem identities.