Author: Glenn Byron · License: MIT · Latest release:
v1.4
Technical reviewers: Skip directly to the repository map, architecture, lab kit, lessons learned, or compliance evidence. Additional technical detail is organized in the technical overview.
I built a personal Windows identity and security laboratory to understand how physical smart cards, Active Directory, certificate authorities, Kerberos, VPN authentication, security baselines and federal-style evidence fit together.
The project began with a practical question: could I build and troubleshoot a working certificate-based login environment instead of only reading about one? The result is an evidence-backed lab containing PowerShell automation, infrastructure-as-code, physical YubiKey testing, Windows event evidence, SCAP/STIG assessment, Ansible remediation, recovery notes and repeatable operator guides.
This is a personal learning and portfolio project. It is informed by federal CAC/PIV, ICAM, RMF and Zero Trust practices, but it is not a DoD system, official CAC issuer, production deployment, certification, accreditation or Authority to Operate.
Defense systems depend on more than individual technologies working in isolation. Identity, certificates, endpoints, directory services, networks, security policy, recovery and evidence must operate together across ownership boundaries.
This lab demonstrates experience with several of those intersections:
- Windows certificate authentication and Kerberos rather than password-only access;
- physical-token verification instead of trusting a successful enrollment message;
- Active Directory, AD CS, Group Policy and network integration;
- STIG/SCAP assessment, bounded remediation and honest treatment of remaining findings;
- RMF-style traceability between requirements, controls, implementation and evidence;
- repeatable PowerShell, Ansible, Git and CI workflows; and
- safe go/no-go decisions when a security-sensitive operation is not yet proven recoverable.
Those are transferable systems-engineering and DevSecOps skills for NAVAIR, DoD program offices, defense contractors and other regulated environments. The project demonstrates how I learn, integrate, troubleshoot and verify complex systems; it does not substitute for program-specific training, an active clearance, an authorization decision or production federal experience.
Passwords alone are vulnerable to theft, reuse and phishing. Smart-card login changes the authentication model: the user needs a physical cryptographic device and a PIN, while the private key stays on the device.
Making that work requires much more than inserting a card. Several systems must agree:
- Active Directory must identify the user and authorize login.
- A certificate authority must issue the correct certificate.
- The physical device must generate and retain the private key.
- Windows must select the intended card and certificate provider.
- Kerberos must trust the certificate chain and revocation information.
- Group Policy must apply the intended login and card-removal behavior.
- Operators need safe enrollment, recovery, auditing and troubleshooting procedures.
I built the lab to understand those boundaries as one system.
The repository contains:
- a Hyper-V Windows lab with Active Directory and AD CS;
- physical YubiKey PIV enrollment and Windows smart-card login;
- certificate-authenticated Azure point-to-site VPN testing;
- PowerShell automation for lab construction, enrollment, validation and health checks;
- SCAP/STIG assessment and an Ansible remediation workflow;
- security control mappings and personal-lab RMF-style templates;
- CI checks for secrets, PowerShell quality, dependencies and workflow security; and
- incident notes explaining what failed, why it failed and how I verified the repair.
The repository also contains two-tier PKI and broader Zero Trust reference designs. Those designs are intentionally distinguished from the smaller live lab boundary that produced the recorded evidence.
The project contains two related architecture views. Keeping them separate is important because the live evidence and the longer-term reference design are not the same claim.
Personal Hyper-V laboratory
Physical YubiKey
PIV key + certificate
|
| card + PIN
v
Windows workstation ---------------> Azure P2S VPN
smart-card credential provider certificate / EAP-TLS proof
|
| Kerberos PKINIT
v
Active Directory + personal-lab AD CS
user mapping, certificate issuance,
Group Policy, events and revocation data
|
v
SCAP assessment + Ansible remediation
retained findings and before/after evidence
This is the path supported by the repository's live screenshots, events and scan results. The lab used private address space, fictional lab identities and disposable credentials.
Offline root CA
normally powered off and isolated
|
| signs issuing-CA certificate
v
Enterprise issuing CA
issues user and device certificates
|
+--------------------+
| |
v v
Windows smart-card Certificate-authenticated
logon / Kerberos network services
The two-tier view explains how an isolated trust anchor and online issuer can separate duties and reduce routine exposure of the root key. It is retained as an architecture and build reference. It is not evidence that this personal lab was a federal hierarchy or production certification authority.
For the deeper diagrams, network decisions and designed-versus-deployed notes, see the architecture blueprint, lab topology and framework selection.
User inserts physical YubiKey and enters PIN
|
v
YubiKey proves possession using its on-device private key
|
v
Windows validates certificate, intended use and trust path
|
v
Active Directory / Kerberos validates the mapped identity
|
v
Windows creates the approved user session
The important security property is that the credential private key remains on the physical token. A successful certificate enrollment is not enough by itself; the operator must prove that Windows used the intended physical device.
The lab demonstrated physical YubiKey enrollment, certificate placement, Windows smart-card login and Kerberos PKINIT evidence. It also demonstrated workstation locking when the accepted card was removed within the tested configuration.
The same lab identity model was exercised through an Azure point-to-site VPN using certificate authentication. The environment was built, tested and torn down as a bounded learning exercise.
SCAP Compliance Checker measured the domain-controller baseline at 44.95% against the selected Windows Server 2022 STIG benchmark. A guarded Ansible remediation pass raised the recorded result to 86.7%. High-disruption and high-complexity changes remained disabled, and unresolved or manual items were retained rather than relabeled as compliant.
See the compliance report index for benchmark, date and scoring details.
During enrollment, Windows reported success—but the credential had silently landed on a TPM virtual smart card instead of the physical YubiKey. That meant the workflow appeared successful while failing the intended physical-device assurance boundary.
I diagnosed the mismatch, documented the cause and added a verification method that checks the selected reader, provider, certificate and public key rather than trusting the enrollment dialog. The full case is documented in Silent VSC fallback discovery.
That incident changed how I approach engineering evidence: a green status is not proof unless it verifies the property the system was supposed to protect.
A parameterized run of the PKI health monitor exposed five defects that a skip-only baseline had hidden, including:
- an overly broad certificate-store filter;
- a StrictMode null-handling failure;
- CRL corruption caused by treating binary content as text;
- a mismatch between expected and actual
certutiloutput; and - an invalid CA command/configuration format.
The fixes and observed output are preserved in the PKI health bug-fix log.
| Area | Evidence level | Boundary |
|---|---|---|
| Physical YubiKey Windows login | Demonstrated | Personal Windows/AD CS lab with retained screenshots and events |
| Kerberos certificate authentication | Demonstrated | PKINIT evidence in the accepted lab path |
| Azure certificate VPN | Demonstrated | Bounded build, connection proof and teardown |
| Domain-controller STIG remediation | Demonstrated | Recorded SCAP result improved from 44.95% to 86.7% |
| PowerShell lab automation | Built and selectively executed | Individual scripts identify their own prerequisites and evidence |
| Phase 8 Zero Trust modules | Built, not fully executed | Syntax/static validation is not live-system proof |
| Two-tier offline-root architecture | Reference design | Do not treat it as evidence of a federal or production hierarchy |
| RMF documents | Personal-lab templates | Not an ATO or government authorization package |
More detail is available in Project scope and evidence.
The project taught me how to:
- integrate Active Directory, AD CS, Windows, networks and physical tokens;
- diagnose failures that cross identity, certificate, device and policy boundaries;
- separate a design claim from an observed result;
- use SCAP results to guide bounded remediation instead of chasing a score;
- preserve unresolved findings and safe stop conditions;
- write operational runbooks and evidence that another person can review; and
- treat recovery, revocation and operator safety as part of the system rather than afterthoughts.
These are the parts I would emphasize in an interview—not simply the number of scripts in the repository.
AI tools were used as learning and troubleshooting aids: to organize notes, explain technical concepts, review code and point out possible mistakes. I designed, built, configured, operated, tested and validated the laboratory and made all final engineering and publication decisions. AI assistance was later used to review and improve the repository's public-facing documentation.
The longer disclosure is in AI-assisted development.
| Reader | Recommended path |
|---|---|
| Hiring manager or recruiter | Project narrative → demo walkthrough → lessons learned |
| Systems or PKI engineer | Repository map → architecture → lab kit |
| DevSecOps reviewer | Ansible/STIG workflow → CI workflows → change history |
| Security or RMF reviewer | Scope boundary → compliance reports → RMF templates |
| Someone rebuilding the lab | Onboarding → lab-day checklist → troubleshooting |
Use this material only in an isolated laboratory that you own or are authorized to administer. Review every command, use fictional identities and preserve an independent recovery path. Never place passwords, PINs, PUKs, management keys, private keys, production certificates or real organizational data in this repository.
See SECURITY.md for reporting and security policy for repository handling rules.
This repository is provided for education and portfolio review. It is not security, legal, compliance, procurement or operational advice. Do not run its administrative commands on a production, employer, customer or government system without the system owner's authorization, independent review, backups and a tested recovery path.
References to CAC, PIV, NIST, DISA, CISA, DoD, Microsoft, Yubico and other organizations or products describe the technologies and guidance studied. They do not imply sponsorship, endorsement, certification, compatibility approval or government affiliation.
The repository's original source and documentation are released under the MIT License. Third-party tools, standards, product names, scan content and referenced materials remain subject to their own licenses, terms and trademarks. The MIT license does not turn external material into project- owned content or provide authorization to operate the lab in another environment.