This video is gold in explaining how to deploy the MS PKI. The root CA pulled generated in the C:\Windows\System32\CertSrv\CertEnroll path already contains the public key. There's no need to explicitly export it again from the server's certificate console.
Troy this video was exceptional! Your thoroughness, humor and clear explanations made this amazing to watch. You have a very special talent for teaching and communicating. Thank you sincerely for all of your hard work putting this together! Just amazing work!
Superb video!! I've done quite a bit of home work prior to watching this, and really appreciate how thorough this is for showing how the complete process works. I'll be watching again to let it sink in.
Just wanted to say thank you for this video, you have a gift of clear, concise presentation. I watched at work, but subbed, liked and here I am commenting. 🙂
Thanks a lot for making this video, I know there has been lot of hours making this complete, your video helped me complete my case study and practical explanation in PKI heirarchy. Have a Good rest of the day!
Video is great, however I'm looking for more of a best practice configuration with some explanation of certain parameters, such as why choosing a specific key length/hash algorithm, specifically in relation to root/subordinate CAs within a production domain. Everything I find are basic configurations, e.g. accepting defaults, or chosen options not explained, which I find frustrating. At any rate thanks for the work you've put into this. Certain aspects are indeed helpful.
I agree with many of the comments thanks Troy! I have referred to this a few time and used your battle plan notes. I have made some changes in my notes that make sense to me. Setting up CA's isn't something done frequently so having notes is key (pun intended)!
Excellent video. Exactly what I needed and the presentation was one of the best I've seen. Thanks for not skipping any steps or assuming people already knew how to do certain things.
Let you in on a secret… AD automatically publishes the Root CA and then intermediary CA u Les’s they aren’t domain joined. Also the AIA and CRL is auto published too. Just build the Standalone on a domain-joined box and shut it down when done
Super video sir Plz provide some videos Active Directory Domain Services on premises PKI services, AD migration and other infra migration activities, planning and troubleshooting. Replication/FSMO, SSO, ADFS Services, DNS, DHCP troubleshooting. Application delegation, Conditional Access, Guest user management, design and implementation. Hands on with Windows platform specialize doing Replication, Migration, Domain Controller, ADTS, ADFS. Along with GPO, Forest.
Thank you SOOOOO much for this tutorial. You did a great job, but what about those AIA & CRL websites you entered to "future proof" the auto enrollment (I guess that's what those entries were for). Isn't there something in IIS you have to configure? Is there another video that goes into that configuration? 👽✌️
I followed your steps. Then I revoked a user certificate, but they can still log into a workstation. How do I make it so that revocation denies logon on Windows?
I've followed this guide step by step, but the Certificate Authority stops working after about a week because the revocation server is offline. How do you prevent this from happening, given that the issuing CA attempts to check in with the Root CA once the CDP Location expires?
Where does OID or the CAPolicy.inf file fit in this? I wonder if a CAPolicy.inf file is a must or not, but I saw it included in many ADCS PKI setup videos.
In a scenario where you have two issuing CAs, would you have them running in a failover cluster or would you run them as two standalone sub CA's? Pros and cons of each deployment type?
For Populate Eventual IIS Publication Point does this location be externally accessible (internet site) or an internal (intranet site) - could you create the sites on the Subordinate CA if necessary? Would there be any trouble for remote workers not on a VPN, other than not being able to access internal resources?
Hello. Great video. Im thinking about standalone root CA. I assume to keep infrastructure safe, root CA server should be offline. So there is the question. Since the server is 99% offline (or even more), is it possible to deploy root CA server on virtual Windows Server in evaluation mode ? Is it legal? Im not sure is wasting one license is worth in case of small company. Thanks :)
(New to this as well so bare with me) It's possible however when creating your PKI in the interest of security, it's common to have the RootCA completely offline. Microsoft recommends building your pki etc. then taking the HDD from the RootCA and locking it in a safe to ensure that it cannot be tampered with in any way. Essentially, once you have your SubCAs setup to issue certs, you no longer need your RootCA, unless you're going to issue CRLs etc. At that point, you'd pop the HDD back in the RootCA, power it up and do what you need to do.
Great video. Now I have a question: I have an older internal root CA (on the domain). Since I cannot change this root CA to subordinate, then can I just stand up 2 new servers following your instructions and bring it online in parallel. Then try to decommission the older root CA by denying/expiring any new request and removing the CA service?
That's a good question. You can definitely have multiple certificate authorities in your domain. The question is how big is the infrastructure and do you need to rely on autoenrollment via GPO? I'd have to dig into this a bit to be definitive, but my thoughts would be that you'd ultimately have to load the respective cert from each CA into the Trusted Root Certificate Authorities store. That means that if you're using autoenrollment, computers and users will end up getting certificates from both authorities. If there's a set of users and computers that for some reason need to use a different CA, I think my move would be to ensure the autoenrollment GPO only applies to my core set of users and computers and then I'd manually enroll the exceptions using the certificate from the alternate CA. Hope that helps!
Thank you Troy this was very well done. I do have an issue though after following all these steps everything seems right and the certificate chain looks correct yet when i create a web server certificate it does not seem to be able to be validated and remains untrusted. What could i be missing? I've made sure the root-ca certificate is imported into the Trusted Root Certification Authorities store on the local computer. I did notice that the certificate does not have Root Certification Authority as it's template type...? could that be an issue? how does the local computer know which certificate to use to validate the web server cert? Any help would be appreciated.
Fantastic video sir. You earned yourself a sub and thank You for sharing knowledge. I do have a question regarding user cert when you removed email cause you do not have Exchange in lab. We do not use exchange in prod. Should I remove it? Or it works with any mail server? Sorry my question may seem dumb Im very new at this and just started my journey
Not a dumb question at all, my friend. I removed the checkbox for email because in this particular isolated lab environment I was only deploying a skeleton set of users with the bare minimum AD properties. In a true production environment your users will nearly always include the email address property, whether you are hosting your own exchange or not. For that reason, I'd leave it in the cert. Hope that clarifies. 🙂
@20:24 - how do you set the timeframe or length of the ent. CA cert? you set the RootCA for 5-years, how do you set the ent. ca cert to 4-years? @25:21 - the issuing CA cert is just 1 year, using this can the enterprise CA issue cert more than a year?
hi Troy ,the video very informative and entertaining and i have greatly benefited from it, But i have a question of how to extend the subordinate CA server authority to distribute the cert to user and machine as i notice the expiration of its " rootCAwithIssueAuth.p7b" is only 1 year period.
does these cmd helps to extend sub CA -certutil -setreg ca\ValidityPeriod "Years" certutil -setreg ca\ValidityPeriodUnits "10" Reboot the Certificate Service or the whole server itself to activate the changes.
Hello troy, I hope you are well, thanks for making this video it has been of great help, I have a question, why is the root ca team not joined to the domain, in my case I must have a scenario where the team is joined to the domain , is that possible?
Hi Leonardo, great question. Yes, you can absolutely have the Root CA server joined to the domain if that suits your design. One of the reasons we might choose a multi-tier PKI (compared to a single-tier where the Root CA is also the issuing certificate server) is to allow for physical isolation of the Root CA server. We typically carefully control physical access to that particular server and, in many cases, sometimes even go so far as to turn the Root CA server off as a security measure to avoid the root certificate store being compromised by a malicious attack. Leaving the Root CA as a standalone server (rather than domain joined) adds to that security, and it also means that we do not need to rely on domain authentication to access and manage the root certificate store. However, leaving the Root CA as a standalone server as I did in this video is simply a design choice. You can absolutely join the Root CA to the domain and the functionality should be exactly the same. Thanks for commenting!
@@leonardolemos1003 Happy to help. AD CS is one way to go, but it's definitely not the only way. Here's an excellent link that outlines some alternative possibilities, namely managed PKI services. www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/ Good luck on your project!
Hi Troy, thanks for the video. Just a quick question regarding the certdata folder. Would this folder need to be shared and access given accordingly for the ROOTCA to see the folder on "10.10.10.10/certdata" Or is that just the information that needs to be published for the SUBCA when it's clients are checking against the CRL?
Hi sulphur - sorry for the slow response. For some reason your comment got flagged as possible spam and I just saw it today. The certdata folder does not need to be specifically shared for the ROOTCA. From the ROOTCA's perspective, all the ROOTCA needs to know is that the certdata folder will be an expansion of the AIA and the ultimate certificate distribution point for the domain. The ROOTCA learns of the folder when we add the extensions to the root certificate, and the inclusion of this information in the certificate details ultimately helps the computers and users in the domain verify the authenticity of the root certificate . I hope that helps! Again, sorry for missing your comment earlier.
Thank you for very good video. When I tested the solution, I noticed that if the user logs in on a new workstation, the certificate is generated again, instead of being downloaded from the previously issued one. What did I do wrong.
Thanks for the great question. The good news is that you've not done anything wrong. In this build, we're not using roaming profiles for the users. In other words, when a user logs in to a workstation, a local profile is built. During this process, a user certificate is generated along with a series of private and public key pairs unique to the user. The user's private keys are stored on the workstation. When a user logs into another workstation, a new local profile is built and the user's original private keys and other user-specific configuration information connected to the first user certificate can't be accessed (because it's all on the previous workstation). The PKI environment therefore treats the user as brand new and generates a fresh user certificate. In environments where users don't frequently change workstations, having the occasional user with multiple user certificates isn't a serious issue. In environments where users "roam", however, this can turn into an administrative challenge to manage all these extra certificates. One solution for this is to configure what's called credential roaming. An excellent article on that topic is right here: learn.microsoft.com/en-us/archive/blogs/askds/certs-on-wheels-understanding-credential-roaming. Hopefully that article gives you some ideas on how to solve the problem if your environment calls for it. Thanks for commenting!
Hi. Prof. Troy, everything was going according to the plan until I got to the cert template part (Time Stamp: TS = 31:15). The folder doesn't show in the root cert tree. I am using Windows Server 2022. I nuked both VMs and started all over, and I got the same result at the same TS. Do you know where I went wrong? I am going to wait before I nuke them and start again.
Additional info: Following your videos, I have created the following infrastructure without a single issue until now. Using VMware Workstation 17 Pro: Host-Only Network: 10.0.11.x: DC01 (AD DS, DHCP, DNS, WinNTP, Failover, [2nd NIC - NAT: 192.168.1.x]), DC02 (AD DS, DHCP, DNS, WinNTP, Failover, [2nd NIC - NAT: 192.168.1.x]), RRAS, NPS01, Internal Win 11 WS (Nessus, Wireshark), ENTCA (AD CS, IIS, [part of the domain]), and ROOTCA (AD CS [standalone]). Created but still need to be added to the domain are Internal Ubuntu 22.04 LTS WS (Management), pfScene, SANS SiFT, Security Onion, CAINE, and Internal Kali WS. External network, Host-Only: 172.16.0.x: External Kali WS (1st aggressor), External Win 10 WS (WFH user), External Ubuntu (2nd aggressor), CIRT - Tsurugi, OPNsense, and OpenStack ([Cloud Network: 172.16.10.x] Compute, Control, Object, and Block nodes). The purpose of this infrastructure is to create a virtual home lab (Windows, Linux, Cloud Infrastructure, Digital Forensic & Incident Response) where I can prepare for some of the certs I need to take, e.g., CrampTIA CySa+ - 003, CEH, etc.
Hi there - sorry you hit a snag there. I reviewed the section of the video that you referenced (thanks for the thorough information, by the way!), and I think I see the problem. On the Root-CA, the Certificate Templates folder doesn't exist in this configuration. The folder you're looking for is actually on the Issuing CA. If you look really closely at the VM that I'm working on at that moment in the video, you'll see that I'm on the machine I've labelled "PKI-Ent-CA." I think I know why it was confusing -- as I was describing the process, I said, "Let's go to the certificate authority." That could have easily construed as referring to the Root CA. I should have said, "Let's go to the CERTIFICATION authority", which is actually the name of the MMC snap-in on the issuing CA where we create and manage those templates. Hope that clears it up!
@@troyberg Thank you so much. With this answer, I will try to fix the issue. On a different note, Would you show us how to add a Ubuntu Desktop 22.04LTS (TestUser) and a Ubuntu Server 22.04LTS (e.g., FTPS, Syslog Collector, AIM, UTM) to the Microsoft infrastructure network that you have been teaching us, Microsft Server 2022, DC01 (with a DC02-Failover)? I am working on it, but I think it should be easier to get Linux and MS working in harmony. The information I am finding online makes MS and Linux act like a divorced couple from hell.
@@troyberg It's working now. The problem was at the Layer 8 from the ISO model. I thought I was logged as the Domain\administrator but I was local. Thank you again.
Hi Troy, how are you? I have a problem when I install the ca certificate on the computer with the role of subordinate, (27:05 Provision Enterprise CA Certificate Authority Service )it returns the following error "The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_e_revocation_OFFLINE)"
Hi Leonardo - in this configuration, that particular error is nearly always associated with a typo or a problem with the Root CA extensions. I'd start troubleshooting by checking against the settings I used at the 8:25 mark in the video, particularly the checkboxes after you add the extensions. Check also that there's no issue with the AIA and the CRL distribution folder that we configure at the 22:11 mark. Hope it comes together for you!
@@troyberg Hello troy, I really appreciate your help, I will review the syntax, I have one last question, is it necessary to prepare the CAPolicy.inf file before installation?
@@aliabukhadair4235 I had the same issue, when on the ROOT CA machine, if you go into CA check your Revoked Certificates by going to properties, and see the CRL publication intervals? mine was set to 1 week, so after 1 week I was getting the same error. I changed the interval, and republished. Retrieved the .crl from from the CertEnroll folder. Moved it to the SUB CA, into the certdata folder, and that corrected the issue. My only thought is will I have to do this manually everytime that cert expires, or is there a way to auto it... ANYWAYS hope this helps!
Excellent video tutorial on PKI, one of the best I have seen on the Internet. You explain very well, congratulations from Colombia.
This video is gold in explaining how to deploy the MS PKI. The root CA pulled generated in the C:\Windows\System32\CertSrv\CertEnroll path already contains the public key. There's no need to explicitly export it again from the server's certificate console.
very clear and well organised video. thanks
Troy! this is amazing work. Glad you had the time to do this!
Troy this video was exceptional! Your thoroughness, humor and clear explanations made this amazing to watch. You have a very special talent for teaching and communicating. Thank you sincerely for all of your hard work putting this together! Just amazing work!
I don't leave comments very often, but thank you. This was a great overview and I was able to follow along and get ADCS set up in my homelab.
Superb video!! I've done quite a bit of home work prior to watching this, and really appreciate how thorough this is for showing how the complete process works. I'll be watching again to let it sink in.
Just wanted to say thank you for this video, you have a gift of clear, concise presentation. I watched at work, but subbed, liked and here I am commenting. 🙂
Wow!, so happy to come across this tutorial, the best one out there on the topic.
Thanks a lot for making this video, I know there has been lot of hours making this complete, your video helped me complete my case study and practical explanation in PKI heirarchy.
Have a Good rest of the day!
Glad you found it helpful!
Best explanation of PKI I ever saw
Thank you so much for providing this Tutorial and Providing the Templates!
Video is great, however I'm looking for more of a best practice configuration with some explanation of certain parameters, such as why choosing a specific key length/hash algorithm, specifically in relation to root/subordinate CAs within a production domain. Everything I find are basic configurations, e.g. accepting defaults, or chosen options not explained, which I find frustrating.
At any rate thanks for the work you've put into this. Certain aspects are indeed helpful.
You are a legend! Just used this lab for my Msc Cybersecurity assessment project.
I agree with many of the comments thanks Troy! I have referred to this a few time and used your battle plan notes. I have made some changes in my notes that make sense to me. Setting up CA's isn't something done frequently so having notes is key (pun intended)!
C'est tellement clair. Merci beaucoup.
It's so clear. Thank you so much.
Excellent video. Exactly what I needed and the presentation was one of the best I've seen. Thanks for not skipping any steps or assuming people already knew how to do certain things.
Let you in on a secret… AD automatically publishes the Root CA and then intermediary CA u Les’s they aren’t domain joined. Also the AIA and CRL is auto published too. Just build the Standalone on a domain-joined box and shut it down when done
one of the Best Video maker who know what to do.
Thankx a lot.
Thanks for the comment! Sincerely appreciated!
Super video sir
Plz provide some videos
Active Directory Domain Services on premises
PKI services, AD migration and other infra migration activities, planning and troubleshooting.
Replication/FSMO, SSO, ADFS Services, DNS, DHCP troubleshooting.
Application delegation, Conditional Access, Guest user management, design and implementation.
Hands on with Windows platform specialize doing Replication, Migration, Domain Controller, ADTS, ADFS. Along with GPO, Forest.
Thanks for the ideas! I'll definitely try to incorporate lots of these. Appreciated!
Top man. Such excellent video. Your energy and presentation skills was very engaging and now i have a working ADCS. Thanks a million
Thank you for your help! The instructions were clear and easy to follow, and I will use this video as a reference.
Thank you! Clear and concise explanation. Engaging delivery also!
wow! thank you a lot! this was a great video. now I understand the big picture 🙂
Best explanation and guide out there, thanks so much for this.
Excellent video, and easy to follow.
Thank you!
Thank you very much appreciated and keep up the great work!
Great guide, thanks for doing this.
Excellent video, thanks!
Excellent video!
Great video
Good, good thank you.
What about setting up IIS and configuring there ? You created a AIA and CRL paths, do they need to be configured in IIS ?
@troyberg +1 on this question
Troy!!!!!!!! You are amazing!!!! Are you teaching some where?
Very useful
Thank you SOOOOO much for this tutorial. You did a great job, but what about those AIA & CRL websites you entered to "future proof" the auto enrollment (I guess that's what those entries were for). Isn't there something in IIS you have to configure? Is there another video that goes into that configuration? 👽✌️
I followed your steps. Then I revoked a user certificate, but they can still log into a workstation. How do I make it so that revocation denies logon on Windows?
Great video, it would be great if you could prepare an ADFS one as well
I've followed this guide step by step, but the Certificate Authority stops working after about a week because the revocation server is offline. How do you prevent this from happening, given that the issuing CA attempts to check in with the Root CA once the CDP Location expires?
I'm having the same issue
Where does OID or the CAPolicy.inf file fit in this? I wonder if a CAPolicy.inf file is a must or not, but I saw it included in many ADCS PKI setup videos.
I wish there was a better word than excellent :)
In a scenario where you have two issuing CAs, would you have them running in a failover cluster or would you run them as two standalone sub CA's? Pros and cons of each deployment type?
For Populate Eventual IIS Publication Point does this location be externally accessible (internet site) or an internal (intranet site) - could you create the sites on the Subordinate CA if necessary? Would there be any trouble for remote workers not on a VPN, other than not being able to access internal resources?
Hello. Great video. Im thinking about standalone root CA. I assume to keep infrastructure safe, root CA server should be offline. So there is the question. Since the server is 99% offline (or even more), is it possible to deploy root CA server on virtual Windows Server in evaluation mode ? Is it legal? Im not sure is wasting one license is worth in case of small company. Thanks :)
Hi Troy, what's the reason behind not having the root CA server domain joined?
(New to this as well so bare with me) It's possible however when creating your PKI in the interest of security, it's common to have the RootCA completely offline. Microsoft recommends building your pki etc. then taking the HDD from the RootCA and locking it in a safe to ensure that it cannot be tampered with in any way. Essentially, once you have your SubCAs setup to issue certs, you no longer need your RootCA, unless you're going to issue CRLs etc. At that point, you'd pop the HDD back in the RootCA, power it up and do what you need to do.
Great video. Now I have a question: I have an older internal root CA (on the domain). Since I cannot change this root CA to subordinate, then can I just stand up 2 new servers following your instructions and bring it online in parallel. Then try to decommission the older root CA by denying/expiring any new request and removing the CA service?
@troyberg Excellent! Now I need to figure out how to specify which CA I want computers and users in certain OUs to use. Any idea on that?
That's a good question. You can definitely have multiple certificate authorities in your domain. The question is how big is the infrastructure and do you need to rely on autoenrollment via GPO? I'd have to dig into this a bit to be definitive, but my thoughts would be that you'd ultimately have to load the respective cert from each CA into the Trusted Root Certificate Authorities store. That means that if you're using autoenrollment, computers and users will end up getting certificates from both authorities.
If there's a set of users and computers that for some reason need to use a different CA, I think my move would be to ensure the autoenrollment GPO only applies to my core set of users and computers and then I'd manually enroll the exceptions using the certificate from the alternate CA.
Hope that helps!
How pki helps in public facing website ?
@10:30 - you did not select to "include in the AIA ext. of issued cert"?
Thank you Troy this was very well done. I do have an issue though after following all these steps everything seems right and the certificate chain looks correct yet when i create a web server certificate it does not seem to be able to be validated and remains untrusted. What could i be missing? I've made sure the root-ca certificate is imported into the Trusted Root Certification Authorities store on the local computer. I did notice that the certificate does not have Root Certification Authority as it's template type...? could that be an issue? how does the local computer know which certificate to use to validate the web server cert? Any help would be appreciated.
Fantastic video sir. You earned yourself a sub and thank You for sharing knowledge. I do have a question regarding user cert when you removed email cause you do not have Exchange in lab. We do not use exchange in prod. Should I remove it? Or it works with any mail server? Sorry my question may seem dumb Im very new at this and just started my journey
Not a dumb question at all, my friend.
I removed the checkbox for email because in this particular isolated lab environment I was only deploying a skeleton set of users with the bare minimum AD properties.
In a true production environment your users will nearly always include the email address property, whether you are hosting your own exchange or not. For that reason, I'd leave it in the cert.
Hope that clarifies. 🙂
Yes it did. Thank you so much!!!!@@troyberg
@20:24 - how do you set the timeframe or length of the ent. CA cert?
you set the RootCA for 5-years, how do you set the ent. ca cert to 4-years?
@25:21 - the issuing CA cert is just 1 year,
using this can the enterprise CA issue cert more than a year?
@29:10 - could you not use the IIS on the Enterprise CA to publish the aia & crl stuff?
hi Troy ,the video very informative and entertaining and i have greatly benefited from it, But i have a question of how to extend the subordinate CA server authority to distribute the cert to user and machine as i notice the expiration of its " rootCAwithIssueAuth.p7b" is only 1 year period.
does these cmd helps to extend sub CA
-certutil -setreg ca\ValidityPeriod "Years"
certutil -setreg ca\ValidityPeriodUnits "10"
Reboot the Certificate Service or the whole server itself to activate the changes.
Hello troy, I hope you are well, thanks for making this video it has been of great help, I have a question, why is the root ca team not joined to the domain, in my case I must have a scenario where the team is joined to the domain , is that possible?
Hi Leonardo, great question. Yes, you can absolutely have the Root CA server joined to the domain if that suits your design.
One of the reasons we might choose a multi-tier PKI (compared to a single-tier where the Root CA is also the issuing certificate server) is to allow for physical isolation of the Root CA server. We typically carefully control physical access to that particular server and, in many cases, sometimes even go so far as to turn the Root CA server off as a security measure to avoid the root certificate store being compromised by a malicious attack.
Leaving the Root CA as a standalone server (rather than domain joined) adds to that security, and it also means that we do not need to rely on domain authentication to access and manage the root certificate store.
However, leaving the Root CA as a standalone server as I did in this video is simply a design choice. You can absolutely join the Root CA to the domain and the functionality should be exactly the same.
Thanks for commenting!
@@troyberg thanks for the answer, I will implement your design, security is a very important factor
@@leonardolemos1003 Happy to help. AD CS is one way to go, but it's definitely not the only way.
Here's an excellent link that outlines some alternative possibilities, namely managed PKI services.
www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/
Good luck on your project!
Hi Troy, thanks for the video. Just a quick question regarding the certdata folder. Would this folder need to be shared and access given accordingly for the ROOTCA to see the folder on "10.10.10.10/certdata" Or is that just the information that needs to be published for the SUBCA when it's clients are checking against the CRL?
Hi sulphur - sorry for the slow response. For some reason your comment got flagged as possible spam and I just saw it today.
The certdata folder does not need to be specifically shared for the ROOTCA. From the ROOTCA's perspective, all the ROOTCA needs to know is that the certdata folder will be an expansion of the AIA and the ultimate certificate distribution point for the domain. The ROOTCA learns of the folder when we add the extensions to the root certificate, and the inclusion of this information in the certificate details ultimately helps the computers and users in the domain verify the authenticity of the root certificate .
I hope that helps! Again, sorry for missing your comment earlier.
Thank you for very good video. When I tested the solution, I noticed that if the user logs in on a new workstation, the certificate is generated again, instead of being downloaded from the previously issued one. What did I do wrong.
Thanks for the great question. The good news is that you've not done anything wrong.
In this build, we're not using roaming profiles for the users. In other words, when a user logs in to a workstation, a local profile is built. During this process, a user certificate is generated along with a series of private and public key pairs unique to the user. The user's private keys are stored on the workstation.
When a user logs into another workstation, a new local profile is built and the user's original private keys and other user-specific configuration information connected to the first user certificate can't be accessed (because it's all on the previous workstation). The PKI environment therefore treats the user as brand new and generates a fresh user certificate.
In environments where users don't frequently change workstations, having the occasional user with multiple user certificates isn't a serious issue. In environments where users "roam", however, this can turn into an administrative challenge to manage all these extra certificates.
One solution for this is to configure what's called credential roaming. An excellent article on that topic is right here:
learn.microsoft.com/en-us/archive/blogs/askds/certs-on-wheels-understanding-credential-roaming.
Hopefully that article gives you some ideas on how to solve the problem if your environment calls for it.
Thanks for commenting!
Hi. Prof. Troy, everything was going according to the plan until I got to the cert template part (Time Stamp: TS = 31:15). The folder doesn't show in the root cert tree. I am using Windows Server 2022. I nuked both VMs and started all over, and I got the same result at the same TS. Do you know where I went wrong? I am going to wait before I nuke them and start again.
Additional info: Following your videos, I have created the following infrastructure without a single issue until now. Using VMware Workstation 17 Pro: Host-Only Network: 10.0.11.x: DC01 (AD DS, DHCP, DNS, WinNTP, Failover, [2nd NIC - NAT: 192.168.1.x]), DC02 (AD DS, DHCP, DNS, WinNTP, Failover, [2nd NIC - NAT: 192.168.1.x]), RRAS, NPS01, Internal Win 11 WS (Nessus, Wireshark), ENTCA (AD CS, IIS, [part of the domain]), and ROOTCA (AD CS [standalone]). Created but still need to be added to the domain are Internal Ubuntu 22.04 LTS WS (Management), pfScene, SANS SiFT, Security Onion, CAINE, and Internal Kali WS. External network, Host-Only: 172.16.0.x: External Kali WS (1st aggressor), External Win 10 WS (WFH user), External Ubuntu (2nd aggressor), CIRT - Tsurugi, OPNsense, and OpenStack ([Cloud Network: 172.16.10.x] Compute, Control, Object, and Block nodes).
The purpose of this infrastructure is to create a virtual home lab (Windows, Linux, Cloud Infrastructure, Digital Forensic & Incident Response) where I can prepare for some of the certs I need to take, e.g., CrampTIA CySa+ - 003, CEH, etc.
Hi there - sorry you hit a snag there. I reviewed the section of the video that you referenced (thanks for the thorough information, by the way!), and I think I see the problem.
On the Root-CA, the Certificate Templates folder doesn't exist in this configuration. The folder you're looking for is actually on the Issuing CA. If you look really closely at the VM that I'm working on at that moment in the video, you'll see that I'm on the machine I've labelled "PKI-Ent-CA."
I think I know why it was confusing -- as I was describing the process, I said, "Let's go to the certificate authority." That could have easily construed as referring to the Root CA. I should have said, "Let's go to the CERTIFICATION authority", which is actually the name of the MMC snap-in on the issuing CA where we create and manage those templates.
Hope that clears it up!
@@troyberg Thank you so much. With this answer, I will try to fix the issue.
On a different note, Would you show us how to add a Ubuntu Desktop 22.04LTS (TestUser) and a Ubuntu Server 22.04LTS (e.g., FTPS, Syslog Collector, AIM, UTM) to the Microsoft infrastructure network that you have been teaching us, Microsft Server 2022, DC01 (with a DC02-Failover)?
I am working on it, but I think it should be easier to get Linux and MS working in harmony. The information I am finding online makes MS and Linux act like a divorced couple from hell.
@@troyberg It's working now. The problem was at the Layer 8 from the ISO model. I thought I was logged as the Domain\administrator but I was local. Thank you again.
@@honeybadger1427 So glad you got it working! Thanks again!
Gonzalez Matthew Hernandez Ronald Walker Melissa
Hi Troy, how are you? I have a problem when I install the ca certificate on the computer with the role of subordinate, (27:05 Provision Enterprise CA Certificate Authority Service )it returns the following error "The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_e_revocation_OFFLINE)"
Hi Leonardo - in this configuration, that particular error is nearly always associated with a typo or a problem with the Root CA extensions. I'd start troubleshooting by checking against the settings I used at the 8:25 mark in the video, particularly the checkboxes after you add the extensions. Check also that there's no issue with the AIA and the CRL distribution folder that we configure at the 22:11 mark. Hope it comes together for you!
@@troyberg Hello troy, I really appreciate your help, I will review the syntax, I have one last question, is it necessary to prepare the CAPolicy.inf file before installation?
Same question. What is the role of CAPolicy file? I need to create one to have te issuer without default templates
@@troyberg hi Troy, I made sure there is no typo with the Root CA extensions, but I still can get the SubCA Certificate Authority service to start
@@aliabukhadair4235 I had the same issue, when on the ROOT CA machine, if you go into CA check your Revoked Certificates by going to properties, and see the CRL publication intervals? mine was set to 1 week, so after 1 week I was getting the same error. I changed the interval, and republished. Retrieved the .crl from from the CertEnroll folder. Moved it to the SUB CA, into the certdata folder, and that corrected the issue. My only thought is will I have to do this manually everytime that cert expires, or is there a way to auto it... ANYWAYS hope this helps!