locked
Intune Co-management, certificates and configuration policies RRS feed

  • Question

  • Not sure if I am on the right tangent, but we have a bunch of Windows 10 Enterprise 1709 machines that are going to use user-based certificates for managing access to a VPN solution. We could go to Active Directory but had a concern that the user certificate could expire if the machine is off the network long enough.

    This approach might be over-engineering things a bit, but I thought that Intune could deliver the user certificate to the device meaning that if the user certificate is expired, Intune could deliver an updated certificate. What has me a bit confused is the wording around co-management because it seems to exclude some policies. It sounds like compliance policies are supported but not configuration policies when managing a Windows 10 device via CM and MDM. So, in short, is my idea doomed to fail or is this something I should be able to do with machines in a co-management configuration?


    www.bighatgroup.com


    • Edited by Kevin KaminskiMVP Monday, November 20, 2017 11:49 PM Made a better title for post
    Monday, November 20, 2017 11:21 PM

Answers

  • Intune only supports SCEP for certificate enrollment and issuance which does not handle user certificates; only device certificates.

    Also, Co-management supports all functions, some are just handled by ConfigMgr and some by Intune based on your preferences.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, November 21, 2017 1:58 AM

All replies

  • Intune only supports SCEP for certificate enrollment and issuance which does not handle user certificates; only device certificates.

    Also, Co-management supports all functions, some are just handled by ConfigMgr and some by Intune based on your preferences.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, November 21, 2017 1:58 AM
  • Intune today currently only supports SCEP enrollment for user certificates, not machine certificates. There is a popular feature request pending for computer certificate support.

    http://blog.auth360.net

    Monday, September 17, 2018 5:52 PM
  • That's not correct and the UserVoice isn't really saying that either. The UV is wanting the cert to be pushed before a user logs on. That doesn't mean the certs issued today are per user, they are still per system but aren't delivered until after a user logs on. Thus, my statement above is correct as SCEP issues client auth certs which are machine specific (by definition, client auth certs are always machine specific).

    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, September 17, 2018 6:30 PM
  • Not disagreeing with you Jason. It's just a bit more nuanced. The certs issued are per user, it's just that the management engine (Intune) pins it to the device with its use case. 

    A client authentication certificate, one with the Client Authentication EKU (1.3.6.1.5.5.7.3.2), can exist in either the user or machine/computer store of the Windows 10 client. That's driven by what is defined in the certificate template in AD CS. A Smart Card User template for example contains the client authentication EKU, per user enrolled with smart card.

    If you use Intune to deploy the certificate via SCEP profile, it mandates use of a Subject Alternative Name, in the form of UPN / mail, leading the enrolling Windows 10 client to parse this as a user certificate enrollment request, not a computer one.



    http://blog.auth360.net

    Monday, September 17, 2018 7:48 PM
  • Hmmm, disagreeing is fine. I'm not always right and based on your more thorough reply, I'd say I'm probably not in this case.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, September 17, 2018 8:10 PM
  • Me either... it's a fluid field. The joy of cloud is that something that doesn't work today, might tomorrow and we have to reboot, rinse, repeat.. 

    http://blog.auth360.net

    Monday, September 17, 2018 9:16 PM