WEBVTT 00:00.000 --> 00:02.850 >> Hello. Now we'll talk a little bit more about 00:02.850 --> 00:06.090 how Kerberos is like the carnival I described earlier, 00:06.090 --> 00:09.040 but this will be a little bit more technical. 00:09.040 --> 00:12.675 You log into the server, your domain controller. 00:12.675 --> 00:14.190 That domain controller is 00:14.190 --> 00:15.720 actually running a service called 00:15.720 --> 00:19.735 the authenticating service or the AS. 00:19.735 --> 00:22.125 When I sit down and login, 00:22.125 --> 00:23.700 my login credentials are sent 00:23.700 --> 00:25.665 to the authenticating service. 00:25.665 --> 00:28.515 In exchange for proving my authenticity, 00:28.515 --> 00:30.666 the authenticating service gives me something 00:30.666 --> 00:34.724 >> called the TGT or ticket granting ticket. 00:34.724 --> 00:37.535 >> That's like my wrist strap at the carnival. 00:37.535 --> 00:39.980 That's what I get for coming in the proper way. 00:39.980 --> 00:42.260 That TGT stays with 00:42.260 --> 00:45.035 me throughout my duration in the domain or the realm, 00:45.035 --> 00:46.340 and it proves that I came in 00:46.340 --> 00:49.320 the proper way. It's a token. 00:49.340 --> 00:53.025 Now, let's say I want to print to server A. 00:53.025 --> 00:55.850 In the background, what is happening is that I'm 00:55.850 --> 00:57.260 basically going to something 00:57.260 --> 01:00.681 called the ticket granting service or TGS. 01:00.681 --> 01:03.134 >> I'm saying here's my TGT, 01:03.134 --> 01:05.385 >> I want to print to server A. 01:05.385 --> 01:08.510 The TGS sees that I have a TGT and gives me 01:08.510 --> 01:10.457 a ticket to print to server A. 01:10.457 --> 01:13.445 >> I get my ticket, I send my print job to the printer, 01:13.445 --> 01:15.264 >> and all is well. 01:15.264 --> 01:17.840 >> Now, let's say I want to access 01:17.840 --> 01:19.865 something from the database service. 01:19.865 --> 01:21.859 Do I have to go back through the authenticating 01:21.859 --> 01:23.300 service and re-log in? 01:23.300 --> 01:28.180 No. I have to go back to the ticket booth or the TGS. 01:28.180 --> 01:29.880 Just like the carnival, 01:29.880 --> 01:32.095 it's one-time through the admissions booth 01:32.095 --> 01:34.195 or authenticating service, 01:34.195 --> 01:38.085 and many times to the ticket booth or TGS. 01:38.085 --> 01:40.410 That is Kerberos. 01:40.410 --> 01:43.130 This is great because we don't have to keep 01:43.130 --> 01:45.310 proving our credentials over and over. 01:45.310 --> 01:47.930 Then ultimately what happens is that we keep 01:47.930 --> 01:50.660 this token with us for the duration of our login, 01:50.660 --> 01:52.160 and we just simply need to carry 01:52.160 --> 01:53.720 the ticket granting service or 01:53.720 --> 01:57.395 a ticket each time we want to go access new services. 01:57.395 --> 01:59.540 The ticket granting service and 01:59.540 --> 02:01.190 the authenticating service are 02:01.190 --> 02:03.785 two rules that are running on the same system. 02:03.785 --> 02:07.580 The system that houses the TGS and the AS is 02:07.580 --> 02:12.145 called the KDC or key distribution center. 02:12.145 --> 02:17.145 The TGS plus the AS equals the KDC. 02:17.145 --> 02:20.260 That's really at the heart of Kerberos. 02:20.920 --> 02:24.620 Kerberos isn't perfect. Nothing is. 02:24.620 --> 02:26.510 It's very time sensitive, 02:26.510 --> 02:28.655 which is actually a good thing. 02:28.655 --> 02:31.540 It mitigates the risk of replay attacks, 02:31.540 --> 02:33.020 but at the same time, 02:33.020 --> 02:35.000 all of your clocks on the network have to be 02:35.000 --> 02:37.475 synchronized within five minutes of each other. 02:37.475 --> 02:39.320 Otherwise, you'll find that 02:39.320 --> 02:40.520 certain clients can't log 02:40.520 --> 02:42.655 in and you'll get a Kerberos error. 02:42.655 --> 02:45.215 Also, the ticket granting ticket 02:45.215 --> 02:48.020 is stored locally on your workstation. 02:48.020 --> 02:50.675 If your workstation gets compromised, 02:50.675 --> 02:52.340 then someone else could have access to 02:52.340 --> 02:54.430 resources as if they were you. 02:54.430 --> 02:57.435 Now, if your KDC is hacked, 02:57.435 --> 03:00.620 that's a big deal because the key distribution center 03:00.620 --> 03:03.805 is your ultimate list of passwords and all credentials. 03:03.805 --> 03:06.195 So all security is lost. 03:06.195 --> 03:08.760 That's a single point of failure. 03:08.760 --> 03:11.625 It can also be a performance bottleneck. 03:11.625 --> 03:13.340 Finally, it is still 03:13.340 --> 03:16.055 vulnerable to password guessing attacks. 03:16.055 --> 03:18.935 Kerberos doesn't do anything to prevent that, 03:18.935 --> 03:20.960 but it is still considered worth those 03:20.960 --> 03:23.830 risks that way you can have single sign-on. 03:23.830 --> 03:26.510 To review, Kerberos is 03:26.510 --> 03:29.630 a network authentication protocol and operates on 03:29.630 --> 03:33.220 port 88 and it uses symmetric cryptography. 03:33.220 --> 03:35.870 That's something you might see on the test. 03:35.870 --> 03:38.300 You can expect to see several questions 03:38.300 --> 03:39.830 on the exam about Kerberos in 03:39.830 --> 03:41.270 general because it's 03:41.270 --> 03:44.730 a very important protocol and service.