User requested this because...
While #21955 aims to deliver integration between ADCS (specifically NDES - SCEP), users that require a secure delivery of certificates will not allow inbound connections from an MDM to ADCS. Why? Inbound connections to a PKI are bad and as part of hardening the PKI, inbound connections should be denied. More information: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786426(v=ws.11)
In the interim...
Fleet would have to connect inbound to the PKI, which is inherently insecure for most security conscious organizations.
Eventually...
Fleet would have an extensive array of PKI variants that can be configured for certificate issuance to macOS, iOS, iPadOS, windows, and Linux hosts.
Potential solutions
Build an ADCS connector that can poll the Fleet server in an outbound connection (maybe websocket) to determine if a certificate is needed from ADCS.
Additional notes:
The managed host should generate and never share their private key. Why? Generating a private key on the device management server and then sharing that over the wire to the host is not as secure as storing the private key on the endpoint in certificate stores like the system keychain on macOS, where the private key is not exportable.
The composition of Fleet - ADCS via DCOM would be like:
Fleet (Cloud) <- DMZ <- Fleet/ADCS Connector (Internal, on prem) <-> ADCS (internal, on prem)
We could split the work into two phases: first, only create a CSR on the Fleet server (to achieve parity with the competition); second, allow the host to request a cert with a SCEP profile, keeping the private key on the host.
Gong snippet: not available, see notes doc
Problem
User requested this because... While #21955 aims to deliver integration between ADCS (specifically NDES - SCEP), users that require a secure delivery of certificates will not allow inbound connections from an MDM to ADCS. Why? Inbound connections to a PKI are bad and as part of hardening the PKI, inbound connections should be denied. More information: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786426(v=ws.11)
In the interim... Fleet would have to connect inbound to the PKI, which is inherently insecure for most security conscious organizations.
Eventually... Fleet would have an extensive array of PKI variants that can be configured for certificate issuance to macOS, iOS, iPadOS, windows, and Linux hosts.
Potential solutions
Build an ADCS connector that can poll the Fleet server in an outbound connection (maybe websocket) to determine if a certificate is needed from ADCS.
Additional notes:
Fleet (Cloud) <- DMZ <- Fleet/ADCS Connector (Internal, on prem) <-> ADCS (internal, on prem)
Additional research articles: https://macnotes.wordpress.com/2020/11/10/can-jamf-adcs-connector-use-azure-web-app-proxy/
https://docs.omnissa.com/bundle/CertificateAuthorityIntegrations/page/ADCSViaDCOM.html
https://morgansimonsen.com/2012/01/24/an-overview-of-groups-used-by-active-directory-certificate-services/