This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Use these questions to verify that role placement, trust authorization, availability, and recovery have been treated as distinct design problems.
A production proposal uses one online enterprise root because there are only 500 users. Which response best addresses the topology decision?
Add an online policy authority without assessing custody or recovery requirements.
Accept the proposal because the user count limits the impact of a root compromise.
Assess assurance, compromise impact, recovery, renewal, and trust replacement. Start with a protected offline standalone root and an online enterprise issuer.
Web Enrollment, NDES, CES, Online Responder, and the CA are installed on one issuing server, but only autoenrollment is used. What should the design authority do?
Keep every service installed so future workloads can use it without design review.
Map each service to a workload, retire unused services through change control, and separate required web, registration-authority, or responder roles where practical.
Put a load balancer in front of the server and keep all installed roles.
Two issuing CAs publish the same template. CA01 is down, but some renewals don't move to CA02. Which set of design gaps should be investigated?
Missing replication of the CA01 database into CA02, missing shared serial numbers, and different private keys.
The root must be online, the template must be renamed, and all clients must clear their trusted root stores.
Untested client or enrollment-service selection, different configuration or permissions on CA02, and pending requests bound to CA01 or issuer-pinned workloads.
A smart-card certificate chains to a trusted root and validates for time and revocation, but only one domain controller rejects sign-in. The command certutil.exe -enterprise -viewstore ntauth on that controller lacks the renewed issuing CA certificate. What should be checked before adding anything locally?
certutil.exe -enterprise -viewstore ntauth
The forest NTAuth object, configuration-partition replication, Group Policy or autoenrollment processing, and the local enterprise NTAuth cache.
Whether revocation checking can be disabled on the affected domain controller.
Whether installing the issuing certificate in the local trusted root store bypasses the rejection.
An application pins <IssuingCA01Name>, while AD DS authentication uses certificates from <IssuingCA02Name>. Does adding CA02 to NTAuth satisfy the application?
<IssuingCA01Name>
<IssuingCA02Name>
Yes, once both issuing authorities publish the same template.
Yes. NTAuth membership overrides an application's issuer pin.
No. The application's pin or trust policy is independent and must be deliberately changed and tested.
Forest A trusts Forest B at the AD DS level. Can Forest B's issuing CA immediately issue smart-card certificates accepted by Forest A?
No. Explicitly design enrollment authorization, root and chain distribution, issuer authorization in Forest A, mapping, revocation, and incident governance.
Yes, after installing only the root certificate in Forest A.
Yes. The directory trust automatically shares templates, root trust, and NTAuth authorization.
Two issuing CAs use separate partitions on one network HSM administered by one team. Which availability claim is unsafe?
The authorities have distinct keys but share dependencies that require recovery planning.
The authorities are fully independent failure domains because their keys are in different partitions.
A shared hardware or administrative failure can interrupt both authorities.
A team proposes a policy CA between the root and issuers but can't name a separate policy, custodian, legal boundary, or removal requirement. Should the design be approved?
Yes. An extra tier always improves assurance even when its controls are identical.
Yes. A policy tier removes the need to recover the root authority.
No. Require evidence of a meaningful boundary before accepting another tier.
Both issuing CAs are healthy, but clean non-domain clients fail validation after a web-server outage. Which service objective failed?
Certificate issuance availability, because healthy authorities can't publish new templates.
Validation publication availability.
Administrative availability, because the offline root must approve every client chain.
The Enterprise Admin group is permanently local administrator on both issuing CAs, controls templates, and holds all HSM quorum tokens. What is the design problem?
One identity plane can change policy, operate the authorities, and use or recover keys without independent controls.
The group can't administer certificate templates because templates are local to each issuing authority.
Quorum custody makes forest-level privileges unnecessary to review.
The root is offline, but no one has tested its HSM since the last CRL publication 11 months ago. The next CRL expires in two weeks. Is offline status providing sufficient assurance?
No. Invoke the approved ceremony early, verify hardware, quorum, and backups, publish with overlap, and shorten the test interval.
Yes. Keeping the root powered off guarantees that its next publication operation will succeed.
Yes. Online issuing authorities can sign a replacement root CRL if the root doesn't start.
In the applied two-issuer design, which failure does the second issuer not solve?
A planned maintenance window on the first issuer when critical profiles and client failover have been tested on the second.
A shared publication outage or another common trust, hardware, network, administrative, or configuration failure.
Loss of the first issuer for a workload already authorized and tested to enroll through the second.
You must answer all questions before checking your work.
Was this page helpful?
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?