1 00:00:02,040 --> 00:00:05,860 Now that we have our trusted certificates published to our clients, 2 00:00:05,860 --> 00:00:10,960 our endpoints, our issuing CAs, our root CAs, and so forth, we're 3 00:00:10,960 --> 00:00:15,220 ready to deploy end‑entity certificates. And there's two options for 4 00:00:15,220 --> 00:00:17,990 doing this that are available to Intune administrators, and that is 5 00:00:17,990 --> 00:00:20,670 PKCS and SCEP. Now. 6 00:00:20,670 --> 00:00:25,990 PKCS stands for Public Key Cryptography Standards, and PKCS has some 7 00:00:25,990 --> 00:00:29,820 real advantages for us in the case of deploying certificates with 8 00:00:29,820 --> 00:00:34,430 Intune because it's really easy to configure. There's no roles or 9 00:00:34,430 --> 00:00:36,200 features required to be installed. 10 00:00:36,200 --> 00:00:38,870 You just have to have a domain‑joined member server for 11 00:00:38,870 --> 00:00:41,080 which to install the Intune connector on. 12 00:00:41,080 --> 00:00:46,360 And this is a huge advantage is that there's no inbound access required, 13 00:00:46,360 --> 00:00:48,640 so you don't have to publish this to the internet. 14 00:00:48,640 --> 00:00:54,060 The connector itself just simply talks outbound to Intune, and it pulls 15 00:00:54,060 --> 00:00:58,410 periodically, so anytime there is a certificate request that needs to be 16 00:00:58,410 --> 00:01:03,810 performed, then that basically is placed into a work queue in Intune, 17 00:01:03,810 --> 00:01:08,440 the connector then pulls Intune, grabs that information, 18 00:01:08,440 --> 00:01:12,600 generates a key pair, has the public key signed by your internal CA. 19 00:01:12,600 --> 00:01:16,500 It will then encrypt that public and private key pair, send it back to 20 00:01:16,500 --> 00:01:21,740 Intune. Intune decrypts it and encrypts it again and sends it to the 21 00:01:21,740 --> 00:01:25,210 endpoint, and the endpoint imports the certificate there. 22 00:01:25,210 --> 00:01:27,310 So, the advantages again, 23 00:01:27,310 --> 00:01:30,460 really super simple to configure, and it just works quite 24 00:01:30,460 --> 00:01:34,600 reliably and importantly does not require inbound access. Now 25 00:01:34,600 --> 00:01:38,580 SCEP, on the other hand, is much, much more complex. By the way, 26 00:01:38,580 --> 00:01:42,270 SCEP stands for Simple Certificate Enrollment Protocol. 27 00:01:42,270 --> 00:01:44,870 This is a legacy protocol that's been around for quite some 28 00:01:44,870 --> 00:01:47,810 time, and it's really kind of showing its age. 29 00:01:47,810 --> 00:01:49,440 It is very complex. 30 00:01:49,440 --> 00:01:54,840 It does require that you install the NDES role, which also includes IIS. 31 00:01:54,840 --> 00:01:58,350 Now NDES stands for Network Device Enrollment Service. 32 00:01:58,350 --> 00:02:02,270 It is Microsoft's implementation of the SCEP standard. 33 00:02:02,270 --> 00:02:03,720 So SCEP is an open standard. 34 00:02:03,720 --> 00:02:06,400 NDES Microsoft's implementation of it. 35 00:02:06,400 --> 00:02:10,120 Here's the real challenge is that when you deploy this, it does 36 00:02:10,120 --> 00:02:14,560 require inbound access, so you have to expose this server to the 37 00:02:14,560 --> 00:02:18,800 public internet, and you can't add any sort of preauthentication or 38 00:02:18,800 --> 00:02:20,600 any sort of authentication checks. 39 00:02:20,600 --> 00:02:25,390 So here's the real problem with this is that the server, the SCEP 40 00:02:25,390 --> 00:02:30,270 NDES server, is a highly privileged machine in your environment. 41 00:02:30,270 --> 00:02:33,560 Using the Microsoft enterprise access model, 42 00:02:33,560 --> 00:02:38,400 it is considered a control plane access, so on par with a domain controller. 43 00:02:38,400 --> 00:02:41,990 In the old tiered model, it was a Tier 0 asset. 44 00:02:41,990 --> 00:02:46,470 So fundamentally, this server is one that should be very, 45 00:02:46,470 --> 00:02:50,730 very highly protected and should have very limited access. 46 00:02:50,730 --> 00:02:54,310 And here's the real challenge is that we now have this control 47 00:02:54,310 --> 00:02:58,440 plane asset, or Tier 0 asset, for which we've installed IIS and 48 00:02:58,440 --> 00:03:00,540 exposed it directly to the internet. 49 00:03:00,540 --> 00:03:03,840 That is a really, really bad idea. 50 00:03:03,840 --> 00:03:07,520 You would never install IIS on a domain controller and push it to the 51 00:03:07,520 --> 00:03:11,960 internet. You shouldn't do so for the NDES SCEP server either. 52 00:03:11,960 --> 00:03:14,250 So for me and for my customers, 53 00:03:14,250 --> 00:03:17,830 that's always a real showstopper because it violates some 54 00:03:17,830 --> 00:03:20,630 of our most basic security practices. 55 00:03:20,630 --> 00:03:23,270 And with that, we recommend that you, as an 56 00:03:23,270 --> 00:03:26,670 administrator, use PKCS whenever possible. 57 00:03:26,670 --> 00:03:31,020 Now, I'm not here to tell you that you can never use NDES SCEP. 58 00:03:31,020 --> 00:03:35,400 If you do that, obviously you're going to accept the risk associated with that. 59 00:03:35,400 --> 00:03:41,020 There may very well be some corner cases where NDES and SCEP are required. 60 00:03:41,020 --> 00:03:42,770 I'm not aware of what those are. 61 00:03:42,770 --> 00:03:45,810 Certainly in the context of Always On VPN, 62 00:03:45,810 --> 00:03:50,040 PKCS works, and we can deploy our device certificates and our user 63 00:03:50,040 --> 00:03:59,000 certificates, and it works flawlessly, so I recommend using PKCS, and that's what we're going to cover in this course.