ACTIVE DIRECTORY / AD CS / RADIUS
BiXCore has its own Windows domain and certificate infrastructure. I built it because I wanted to understand how devices can authenticate to a network using individual certificates, including what happens when one of the supporting services goes down.
I run two Windows Server 2025 domain controllers, with replicated Active Directory and DNS. Adding the second controller meant checking replication, SYSVOL/DFSR, name resolution, authentication and the services that depend on them.
The enterprise certification authority and NDES service are hosted on one controller. I can fall back to the second controller for directory lookups, but that does not automatically give me a second CA or SCEP enrollment server.
The CA issues different types of certificates for Windows machines, domain controllers and managed Android devices. NDES provides SCEP enrollment for mobile clients. FreeRADIUS on OPNsense checks the certificate chain and revocation information, then makes a separate authorization decision.
I use local policies for certain infrastructure identities and LDAPS for eligible domain computer identities. I tested directory fallback with the primary controller unavailable, and verified wired and wireless EAP-TLS on the supported client types.
Before I switched to the Windows enterprise CA, some managed Android devices already had client certificates from an earlier local CA. I kept that CA trusted during the migration so those devices could continue connecting.
When I enabled strict CRL checking in FreeRADIUS, those older devices stopped authenticating. Their certificates were still trusted, but the generated CA bundle contained the new CA's revocation list and not the old one's. The TLS validation failed because it could not find the matching CRL.
I created a valid CRL for the earlier CA and added a small helper to append it after OPNsense regenerates FreeRADIUS's certificate bundle. A startup/configuration hook reapplies that change when the plugin rebuilds its files. I then checked that both CRLs were present, identified their issuers and retested the older Android clients. EAP-TLS worked again with revocation checking still enabled.
The important lesson was that trusting a certificate issuer isn't enough when CRL checking is required: FreeRADIUS needs a usable revocation list for every issuing CA it accepts.
A controller can need the network before it can contact the very directory services used for access decisions. I gave the controller's wired EAP-TLS identity its own appropriate certificate and authorization path, then checked the result against the switch and RADIUS.
It wasn't enough to list a second LDAP endpoint in the configuration. I took the primary endpoint out of service and checked that authorization-related lookups could continue through the other controller.
The server's IPv6 DNS records looked right, but not all addresses were reachable. Packet inspection and the switch's ND security settings led to a fix for the addresses tested.
I set up certificate renewal and CRL publication, but I still want to improve how superseded mobile certificates are retired and test full recovery of the issuing CA.
The directory failover test worked, but restoring the CA and NDES service from an independent backup is a different exercise. The switch's IPv6 neighbor bindings also need to be checked after future upstream prefix changes.
The certificate-based access overview → Windows workstation policies → Monitoring and recovery →