1
00:00:00,440 --> 00:00:00,810
Now,

2
00:00:00,810 --> 00:00:05,660
how are we synchronizing or replicating user passwords from local AD into

3
00:00:05,660 --> 00:00:10,220
Azure AD? The most common perhaps is password hash synchronization. Now please

4
00:00:10,220 --> 00:00:14,770
understand that Azure AD Connect service does not take your local password

5
00:00:14,770 --> 00:00:17,800
hashes and replicate those into the cloud.

6
00:00:17,800 --> 00:00:20,160
That presents a security issue, doesn't it?

7
00:00:20,160 --> 00:00:24,470
Because you've probably heard of rainbow tables attacks against password hashes.

8
00:00:24,470 --> 00:00:29,160
Now, so what the Azure AD Connect engine does, it computes a cryptographic hash

9
00:00:29,160 --> 00:00:32,310
of the local hash and stores that in the cloud.

10
00:00:32,310 --> 00:00:36,460
Now the advantage of password hash sync is that it's easy to set up, and your

11
00:00:36,460 --> 00:00:40,240
users can sign into cloud apps, even when they're away from your corporate

12
00:00:40,240 --> 00:00:44,650
network because the full credential, including the password, is in Azure AD.

13
00:00:44,650 --> 00:00:49,050
Now passthrough authentication is for businesses whose security requirements

14
00:00:49,050 --> 00:00:53,940
are such that you don't want to store any kind of local hash or even a hash of

15
00:00:53,940 --> 00:00:55,380
a hash in the cloud.

16
00:00:55,380 --> 00:01:00,140
In this case, users cannot sign into cloud apps unless their VPNned into

17
00:01:00,140 --> 00:01:04,800
corp net or are on your corp net because you have a reliance or a

18
00:01:04,800 --> 00:01:07,910
dependency on the passthrough authentication agent.

19
00:01:07,910 --> 00:01:11,190
So there's an additional dependency that you need on your local

20
00:01:11,190 --> 00:01:15,800
infrastructure servers that handles those authentication requests and

21
00:01:15,800 --> 00:01:19,610
allows you to overcome that issue of not having a password stored in

22
00:01:19,610 --> 00:01:23,020
Azure AD. You might think then, then why in the world would you want to

23
00:01:23,020 --> 00:01:24,600
do passthrough authentication?

24
00:01:24,600 --> 00:01:25,410
Well, like I said,

25
00:01:25,410 --> 00:01:28,980
it's mainly for businesses that have security requirements to

26
00:01:28,980 --> 00:01:32,660
where all password management and password presence has to be

27
00:01:32,660 --> 00:01:35,030
controlled on‑prem and not in the cloud.

28
00:01:35,030 --> 00:01:37,920
Another idea where the password is not in the cloud,

29
00:01:37,920 --> 00:01:42,580
but authentication is handled completely locally is the federation option.

30
00:01:42,580 --> 00:01:46,380
Azure AD Connect works seamlessly with Active Directory Federation

31
00:01:46,380 --> 00:01:50,300
Services, so you can set up a federation trust relationship between

32
00:01:50,300 --> 00:01:54,030
your local Active Directory environment and Azure AD. And when the user

33
00:01:54,030 --> 00:01:55,890
attempts to sign into a cloud app,

34
00:01:55,890 --> 00:02:00,390
they're redirected to your AD FS farm where they're authenticated locally,

35
00:02:00,390 --> 00:02:02,920
a token is generated, and the user is lead in.

36
00:02:02,920 --> 00:02:05,120
Now the exam doesn't get into federation.

37
00:02:05,120 --> 00:02:12,000
It's mainly password hash synchronization with perhaps a sprinkle of passthrough thrown in.