Intune Certificate Connector and OID 1.3.6.1.4.1.311.25.2
Hi, Way back in May when update KB5014754 broke cert auth for so many orgs it was identified that whilst RPC auto-enrolled certificates will get the new required OID the Intune certificate connector can't do the same. As the timeline on the KB (https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) states that enforcement will happen from updates released on February 14th 2023 is there any indication that a fix will be deployed for the intune certificate connector ahead of that time? We have many customers using intune enrolled certificates to authenticate for AOVPN, WiFi and more which will stop working once this change is enforced. February doesn't seem like a long time away when a solution likely means needing to get the connectors updated and other possible changes.
Unable to change DCOM permissions. Any changes are being reverted. Enrollment of Certificates errors
After 10 years, our Root/Enterprise CA stopped enrolling certificates with a generic access denied message. After several weeks and a lot of hours spent trying to solve for ourselves we decided to open a paid support case at MS So, with the help of Microsoft Premier Support we started a new brand-new/fresh PKI, with two Win2022 servers, Root/Std and SubEnterprise... but the errors are exaclty the same But no avail, it was frustrating because the MSPS was not capable of achieving anything in theirs almost 27 hours of time spent, besides doing the same of check all over again and again, collecting logs to see that it was a access denied error and only using public KB articles and the same set of basic stuff that has been done before Now, I discovered that the issue is related to computer permissions for DCOM (dcomcnfg.exe) on which we give the proper permissions and after some hours, the DCOM permissoes are forcibly back to their original state. So, when e add some entities with rights on DCOM, the enrollment of certficates works very well, but after some time, stops again. So, now I can accelerate the procces and doing a simple "gpupdate", EVEN WITH NO GPOs applied, AT ALL, the DCOM permission changes are reverted back to its orignal ones and the enrollment stops again Tracing with procmon: RegOpenKey HKLM\SOFTWARE\Microsoft\OLE Desired Access: Query Value, Set Value So, the moment of the permissions getting back to its original permissions, are here, and the proccess is : C:\Windows\system32\svchost.exe -k DcomLaunch -p, so, the DCOM itself, it appears to me So: How to avoid this? The closest thing I was able to find, someone with the same problem, there is an article for a DCOM app called Matrikon (RPC tunneled app) saying that if we add a "dummy" user to the permissions, it should solve, but in my case. it doens´t work So.. any adice? Anything I should try? No useful info on EventViewer system/App logs Similar problem, another App https://honeywellprocess.my.site.com/opcsupport/s/article/CHECKWhy-wont-my-DCOM-changes-stick-REF-KB-408 "... If you are changing the Security settings from Default to Customize and it is not necessary to add any new users, when you leave DCOM configuration it will change the settings back to default. ..."
Remote Desktop Connection - How to force a Certificate Revocation method?
Is it possible to force a particular method/protocol for the certificate revocation used by RDC? We have two separate enterprise environments where endpoints occasionally need to cross reference each other's certificate revocation servers. We don't allow LDAP between the two environments. CRL and OCSP is fully accessible. RDC seems to default to LDAP [only] and throws up a warning about not being able to check revocation when there is a cross-environment check required. This isn't pretty. We do have LDAP as the first certificate revocation method in our certificates as I think this is default by design. Does RDC only support LDAP? Alternatively, is there a way to force it to use HTTP/CRL/OCSP? Seems like there should be a nice little registry entry we can inject to set the protocol order.Web enrollment certificate no template
we have deployed a 2-tier CA with window 2019 servers On the Enterprise domain ca we enabled also the web enrollment service. However when we connect to generate certificates we got no templates available We already checked the security permission of the published templates and the user we connect with has the read,enroll permission on the templates. We already tried - different browsers - connecting locally and from remote - we noticed that the CSP field remains in “Loading” Using certificate’s MMC works fine .Computer certificate re-enrollment after ADCS architecture change and certificate revocation
Originally, I set up an ADCS server as an Enterprise Root CA. Automatic certificate enrollment was enabled via a GPO and computers were automatically assigned certificates. The more I learned about ADCS this year, the more uncomfortable I became with this configuration from a security perspective. I added an intermediate SubCA recently which was configured to use the Computer template. I removed the Computer template (and all other templates except for the SubCA template) from the Enterprise Root. Then I revoked all of the computer certificates on the Enterprise Root CA. I figured they would all just re-enroll automatically on the SubCA (I'm using a GPO to enable this) but that is not what happened. They are not re-enrolling. I confirmed that I am able to issue Computer certificates from the SubCA manually using MMC and the Certificates snap-in. I discovered how to remove the old, revoked certificates from the clients with PowerShell but the Get-Certificate applet is simply not working so I cannot issue new certificates from the SubCA. If I have to, I can manually assign new Computer certificates but there has got to be an easier way to do this (I was counting on the automatic certificate enrollment option). Ideally, I just want the computers to automatically obtain new certificates from the new SubCA. My hypothesis that the computers would simply re-enroll on the SubCA after their certificates were revoked proved to be incorrect but I cannot understand why. I've been researching this for about a week now and cannot figure out what I am missing so am hoping one of you may be able to offer some insight.
Active Directory Certificate Services (ADCS)
Our domain has never had a ADCS services. We have approx. 20K AD users. We are looking into deploying a single ADCS Root Server along with NPS and RADIUS server. We are only looking at using this for 802.1x for now, but we may consider for other use in the future. We currently use CA services (godaddy issues wildcard) for use on our servers that are accessible for public use. My question is: Will installing and configuring the new sever as an Enterprise ADCS Server cause any issues with current AD authentication?
