# Security # pfSense - VLANs Setup [https://nguvu.org/pfsense/pfsense-baseline-setup/](https://nguvu.org/pfsense/pfsense-baseline-setup/) [https://www.youtube.com/watch?v=b2w1Ywt081o](https://www.youtube.com/watch?v=b2w1Ywt081o) # Security - Windows LDAPS Cert This is to setup a Windows ADCS #### Windows Certificate These command are to install ADCS, this will take a while to complete. ##### Step 1: Install Active Directory Certificate Services (AD CS) ```powershell Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools ``` ##### Step 2: Assign EnterpriseRootCA Role ```powershell Install-AdcsCertificationAuthority -CAType EnterpriseRootCA ``` Type "Y" for the installation question This will update the server ```powershell gpupdate /force ``` ##### Step 3: Verify AD CS Role is Installed Go to server manager and verify by refreshing the page and that the AD CS Role was installed [![image.png](https://docs.sflservicesllc.com/uploads/images/gallery/2026-02/scaled-1680-/QJZimage.png)](https://docs.sflservicesllc.com/uploads/images/gallery/2026-02/QJZimage.png) Step 4: Create Certificate Template Run the following ```powershell certsv.msc ``` # Security - Retrieve Windows Root CA Certificate for Import This is to retrieve a Windows certificate that was configured [HERE](https://docs.sflservicesllc.com/books/all-others-stuff/page/security-windows-2025-ldaps-cert-and-export-kerberos-keytab "Windows Certificate Installation") # Security - Export Kerberos KeyTab from Windows Root CA #### KeyTab Export To export the KeyTab from the Windows CA server, in this case it is for KeyCloak mentioned [HERE](https://docs.sflservicesllc.com/books/security/page/security-windows-ldaps-cert "KeyTab Export") Run this in PowerShell ```powershell cd \temp ktpass -princ HTTP/server.domain.com@SERVER.DOMAIN.COM -mapuser user@DOMAIN.COM -pass '' -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -out keycloak.keytab dir ``` This will show you the newly create KeyTab [![image.png](https://docs.sflservicesllc.com/uploads/images/gallery/2026-02/scaled-1680-/image.png)](https://docs.sflservicesllc.com/uploads/images/gallery/2026-02/image.png) # pfsense - LDAP to Windows 2025 without CA To be able to hook up pfsense to Windows 2025 default AD you need to add a Group Policy to override the defaults in windows 2025 server
Domain Controller Policy ===Computer Configuration ======Policies =========Windows Settings ============Security Settings ===============Local Policies ==================Security Options =====================Domain controller: LDAP server channel binding token requirements: "When Supported" =====================Domain controller: LDAP server signing requirements: "None" =====================Domain controller: LDAP server Enforce signing requirements: "Disabled" =====================Network security: LDAP client encryption requirements: "Negotiate Sealing" =====================Network security: LDAP client signing requirements: "Negotiate Signing"
Taken from [here](https://forum.netgate.com/topic/187453/ldap-authentication-with-active-directory-windows-server-2025-bind-fails/3) # Security - Create a Code Signing Template Here’s a step-by-step guide to create a new **code signing certificate template** in Active Directory Certificate Services (**AD CS**) based on the built-in "Code Signing" template. This new template can be used by domain users (from your current domain or trusted domains in the same forest) to enroll for code signing certificates. The phrase "for a different domain name" likely means you want certificates where the **subject name** (or Subject Alternative Name / UPN) reflects a different domain/organization/branding (e.g., "Code Signing Authority - othercompany.com" instead of the user's actual AD name like ""). The standard "Code Signing" template builds the subject from Active Directory (user's CN + UPN), which ties it to the enrolling user's domain identity. To allow a custom / different subject name (common for organizational code signing certs), set the template to **Supply in the request**. This lets the user provide their own subject during enrollment (via certreq.exe, MMC Certificates snap-in, or PowerShell). **Important security note**: Setting "Supply in the request" without tight controls is risky (ESC vulnerabilities like ESC1/ESC2). Limit enrollment to a small, trusted group (e.g., developers or a code-signing admins group). Avoid enabling this broadly for all Domain Users unless necessary. #### Step 1: Open the Certificate Templates Console - Log in to a domain-joined machine with Enterprise Admin rights (or delegated rights to manage templates). - Run certtmpl.msc (Certificate Templates MMC snap-in). #### Step 2: Duplicate the Built-in Code Signing Template - In the list, find the template named **Code Signing**. - Right-click it → **Duplicate Template**. - In the **Compatibility** tab (if shown): - Certification Authority: Windows Server 2016 / 2019 / 2022 (or highest supported). - Certificate recipient: Same or highest. - Click **OK** to open the new template properties. #### Step 3: Configure General Tab - **Template display name**: Something descriptive, e.g., Custom Code Signing - OtherDomain or Code Signing - branding.otherdomain.com. - **Template name**: Auto-filled (spaces removed from display name). - **Validity period**: 1–3 years (common for code signing; match your policy). - **Renewal period**: e.g., 6 weeks. - Check **Publish certificate in Active Directory** if you want the cert discoverable (usually **not** needed for code signing). #### Step 4: Request Handling Tab - **Purpose**: Signature and encryption (default is fine; code signing mainly needs signature). - Check **Allow private key to be exported** (very common for code signing — developers often need to export to other machines or build servers). - **Minimum key size**: 2048 (or 4096 for stronger security). - Uncheck **Strong private key protection** unless required. #### Step 5: Subject Name Tab (Key Change for "Different Domain Name") - Select **Supply in the request** (this is the main change — it allows custom subject during enrollment instead of pulling from AD). - This enables users to specify a different/common organizational name (e.g., CN = "Code Signing", E = "[sales@otherdomain.com](mailto:signing@otherdomain.com)"). - **Do NOT** select "Build from this Active Directory information" unless you want the cert tied to the user's actual AD name/UPN. #### Step 6: Extensions Tab - **Application Policies** → Ensure **Code Signing** is present (it should be inherited). - You can add others if needed (e.g., **Time Stamping** via additional policies). - **Key Usage**: Digital signature (required), non-repudiation (recommended). - Optional: Add **Certificate Template Information** extension if you want to include metadata. #### Step 7: Security Tab (Critical — Restrict Enrollment) - Remove **Domain Users** / **Authenticated Users** if present (or set their permissions to **Read** only). - Add your intended group(s), e.g.: - A security group like "Code Signing Users" or "Developers - OtherDomain". - Grant them **Read** + **Enroll** (and **Autoenroll** if you want GPO auto-enrollment, though rare for custom-subject code signing). - **Do not** give Domain Users Enroll unless this is intentional (very broad). #### Step 8: Issue the New Template on Your CA - Open **certsrv.msc** (Certification Authority snap-in) on your CA server. - Right-click **Certificate Templates** → **New** → **Certificate Template to Issue**. - Select your new template (e.g., Custom Code Signing - OtherDomain) → **OK**. # Security - Code Signing Enroll User For Different Domain This is how to enroll into a cert from the users computer. #### How Users Enroll for Certificates with Custom ("Different") Domain Name Users with Enroll permission can now request a certificate: **Option A – Using MMC (easiest for testing)** 1. Run certmgr.msc (Current User). 2. Right-click **Personal** → **All Tasks** → **Request New Certificate**. 3. Select your enrollment policy (Active Directory Enrollment Policy). 4. Choose your new template. 5. When prompted, click **Details** → **Properties**. 6. On **Subject** tab: Enter custom values (e.g., Common name = "OtherDomain Code Signing Authority"). 7. On **Subject** tab: Enter custom values (e.g., Organtization = "SFL Services LLC"). 8. On **Subject** tab: Enter custom values (e.g., Locality = "Loveland"). 9. On **Subject** tab: Enter custom values (e.g., State = "Ohio"). 10. On **Subject** tab: Enter custom values (e.g., Country = "US"). 11. On **Extensions** tab: Add SAN if needed (e.g., email=). 12. Enroll. **Using certreq.exe (scriptable / automated)** Create an .inf file:
codesign-request.inf
```powershell [Version] Signature="$Windows NT$" [NewRequest] Subject = "CN=Code Signing, O=SFL Services LLC, L=Loveland, S=Ohio, C=US" ; You can make Subject empty if you prefer only SAN / no CN, but most code signing tools expect a CN KeySpec = 1 KeyLength = 4096 ; 3072 or 4096 is strongly recommended in 2025+ Exportable = TRUE ; Usually yes for code signing MachineKeySet = FALSE ; User context (most common for code signing) SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider" ProviderType = 24 RequestType = PKCS10 KeyUsage = 0x80 ; digitalSignature = required for code signing [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.3 ; Code Signing EKU ; Optional: if you really want to add DNS SANs (rare for pure code signing) [Extensions] 2.5.29.17 = "{text}" _continue_ = "dns=www.sflservicesllc.com&" _continue_ = "email=sales@sflservicesllc.com" ``` Then:
Create a powershell script **createCert.ps1**, Run the script
**Note:** Change the template name to the name you chose when creating [HERE](https://docs.sflservicesllc.com/books/security/page/security-create-a-code-signing-template "Code Signing Template Create") it with no spaces.
```powershell certreq -new codesign-request.inf codesign.csr certutil -dump codesign.csr certreq -submit -attrib "CertificateTemplate:YourTemplateName" codesign.csr codesign.cer certreq -accept codesign.cer certutil -store my ```