Daily Worklog: 2026-02-15

Overview

Date: 2026-02-15 (Sunday)

Location: Remote

Focus: Xianming Linux EAP-TLS Delivery Prep, iPSK HA Home Enterprise Documentation, Monday CISO Meeting Preparation

Carried Over from 2026-02-14

  • netapi bulk endpoint commands - COMPLETED

  • netapi staticGroupAssignment fix - COMPLETED

  • Create DACL (DACL_CORP_PRINTERS)

  • Create AuthZ Profile (AuthZ_DOMUS_Printers)

  • Deploy FreeIPA on kvm-01

  • Xianming Linux EAP-TLS - final testing

Priority 1: Xianming Linux Delivery (Due Monday)

Deliverables Checklist

  • Certificate chain installed (/etc/ssl/certs/)

  • Private key protected (/etc/ssl/private/, mode 0600)

  • NetworkManager 802.1X connection configured

  • Password flags fixed (identity-flags=0, private-key-password-flags=4)

  • EAP-TLS authentication PASSING (not MAB)

  • dACL applied: DACL_LINUX_RESEARCH_AD_AUTH

  • AD connectivity verified (Kerberos ports 88, LDAP 389/636)

  • SSH from admin workstation verified

  • Documentation in DEPLOY-2026-02-14-xianming-ding-linux-ad-auth.adoc

ISE Policy Requirements

Component Value

Policy Set

Wired_802.1X_Closed

Authentication Rule

EAP-TLS with AD certificate

Authorization Profile

Linux_Research_AD_Auth

dACL

DACL_LINUX_RESEARCH_AD_AUTH

dACL Rules (DACL_LINUX_RESEARCH_AD_AUTH)

remark ### ACTIVE DIRECTORY AUTHENTICATION ###
permit tcp any host {ad-dc-ip} eq 88      # Kerberos
permit udp any host {ad-dc-ip} eq 88
permit tcp any host {ad-dc-ip} eq 389     # LDAP
permit tcp any host {ad-dc-ip} eq 636     # LDAPS
permit tcp any host {ad-dc-ip} eq 3268    # Global Catalog
permit tcp any host {ad-dc-ip} eq 3269    # GC SSL
permit udp any host {ad-dc-ip} eq 53      # DNS
permit tcp any host {ad-dc-ip} eq 53

remark ### SSH MANAGEMENT ###
permit tcp any host {admin-workstation} eq 22

remark ### INFRASTRUCTURE ###
permit udp any host {dns-server} eq 53
permit udp any host {ntp-server} eq 123
permit icmp any any

remark ### BLOCK RFC1918 LATERAL MOVEMENT ###
deny ip any 10.0.0.0 0.255.255.255 log
deny ip any 172.16.0.0 0.15.255.255 log
deny ip any 192.168.0.0 0.0.255.255 log

remark ### PERMIT INTERNET ###
permit ip any any

Verification Commands

# Check certificate auth in ISE
netapi ise dc query "
SELECT
    USERNAME,
    AUTHENTICATION_PROTOCOL,
    AUTHORIZATION_PROFILES,
    FRAMED_IP_ADDRESS,
    TIMESTAMP_TIMEZONE
FROM RADIUS_AUTHENTICATIONS
WHERE USERNAME LIKE '%xianming%' OR USERNAME LIKE '%research%'
ORDER BY TIMESTAMP_TIMEZONE DESC
FETCH FIRST 5 ROWS ONLY
"

# Verify EAP-TLS (not MAB/Lookup)
netapi ise mnt session <MAC>

Priority 2: iPSK HA Home Enterprise Documentation

Source Reference

CHLA production design: Principia/02_Assets/PRJ-ISE-IPSK-CHLA-ANTORA/runbooks/diagrams/ipsk-ha-production.svg

Tasks

  • Review CHLA iPSK HA architecture

  • Adapt for home enterprise (domus)

  • Create domus-infra-ops/projects/ipsk-manager-ha.adoc

  • Create architecture diagram

  • Document failover procedure

  • Prepare for Monday meeting with Ben Castillo

iPSK HA Architecture (Home Enterprise)

                    ┌─────────────────┐
                    │   9800-CL-WLC   │
                    │   (Primary)     │
                    └────────┬────────┘
                             │ RADIUS
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
       ┌──────────┐   ┌──────────┐   ┌──────────┐
       │  ISE-01  │   │  ISE-02  │   │ iPSK-Mgr │
       │ (Primary)│   │(Secondary│   │ (ODBC)   │
       └──────────┘   └──────────┘   └──────────┘
                             │
                    ┌────────┴────────┐
                    │   PostgreSQL    │
                    │  (iPSK Store)   │
                    └─────────────────┘

Priority 3: Monday CISO Meeting Preparation

Meeting Context

Topic: Research VLAN Segmentation

Stakeholders: CISO, Network Manager, Security Team

Conflict: Team opposes dedicated Research VLAN, arguing: - L3 routing already forwards traffic between VLANs - Only security gain is broadcast/collision domain isolation - Management overhead not worth it

Your Position: VLAN + dACL (Defense in Depth)

Layer 2 Security Benefits (VLAN provides):

Threat VLAN Mitigation

ARP Spoofing

ARP cache poisoning attacks contained to VLAN. Attacker cannot MITM devices across VLANs without L3 compromise.

MAC Flooding

CAM table exhaustion attacks contained to single VLAN. Switch remains functional for other VLANs.

DHCP Attacks

Rogue DHCP server and DHCP starvation contained to VLAN. DHCP snooping scope is per-VLAN.

Broadcast Storms

Broadcast traffic (ARP, DHCP, mDNS) limited to VLAN. No impact on production networks.

Discovery Protocols

mDNS, LLMNR, SSDP, NetBIOS discovery limited to VLAN. Reduces reconnaissance surface.

STP Attacks

Spanning tree topology attacks (root bridge takeover) contained to VLAN.

Why dACL Alone is Insufficient:

  1. dACLs are L3/L4 only - They filter after IP routing. ARP spoofing, MAC flooding, and broadcast attacks happen BEFORE dACL evaluation.

  2. dACLs can fail silently - Misconfiguration, ISE outages, or CoA failures leave endpoints unprotected.

  3. Discovery happens before authentication - mDNS/LLMNR/SSDP broadcasts reveal devices before 802.1X completes.

  4. Defense in depth - Security best practice requires multiple independent controls. VLAN + dACL = two layers.

Counter-Arguments to "L3 Routing Already Configured"

Their Argument Your Counter

"L3 already routes between VLANs"

L3 routing is controlled by ACLs. VLANs provide L2 isolation BEFORE traffic reaches L3.

"Only gain is broadcast isolation"

Broadcast isolation prevents ARP spoofing, DHCP attacks, and discovery protocol leakage. These are REAL attack vectors.

"Management overhead"

One-time VLAN creation vs ongoing risk of L2 attacks. Compliance frameworks require segmentation.

Compliance References

  • NIST 800-53 SC-7 - Boundary Protection (network segmentation)

  • CIS Control 12 - Network Infrastructure Management

  • ISO 27001 A.13.1.3 - Segregation in networks

  • PCI-DSS 1.2 - Network segmentation

Current (IoT VLAN):
  Research Workstations ──┬── IoT Devices ──┬── Printers
                          │                 │
                    [Same L2 broadcast domain]
                    [ARP/mDNS/LLMNR shared]

Proposed (Dedicated Research VLAN):
  Research VLAN 40        IoT VLAN 50        Printer VLAN 60
  ┌─────────────┐         ┌──────────┐       ┌──────────┐
  │ Researchers │         │ IoT/BYOD │       │ Printers │
  └──────┬──────┘         └────┬─────┘       └────┬─────┘
         │                     │                  │
         └─────────────────────┼──────────────────┘
                               │
                        [L3 Router/Firewall]
                        [ACLs control inter-VLAN]
                        [dACLs per-user enforcement]

Session Notes

FreeIPA Deployment (ipa-01) - COMPLETED

Successfully deployed FreeIPA identity server on Rocky 9 GenericCloud image.

VM Details:

  • Hostname: ipa-01.inside.domusdigitalis.dev

  • IP: 10.50.1.100

  • Realm: INSIDE.DOMUSDIGITALIS.DEV

  • BaseDN: dc=inside,dc=domusdigitalis,dc=dev

Key Accomplishments:

  • Deployed Rocky 9 VM via cloud-init (headless)

  • Fixed /etc/hosts (cloud-init sets hostname to 127.0.0.1)

  • Installed FreeIPA with --no-ntp --no-host-dns (DNS on bind-01)

  • Rotated Directory Manager password after accidental exposure

  • Regenerated cacert.p12 with new DM password (learned NSS DB password location)

  • Backed up CA cert to dsec (~/.secrets/certs/d000/freeipa/cacert.p12.age)

  • Stored NSS DB password in gopass (v2/DOMUS/servers/ipa-01/nss-db)

  • Verified all services running (sudo ipactl status)

  • Kerberos ticket obtained (kinit admin)

Runbook Updates:

  • Added cloud-init eth0 vs enp1s0 gotcha

  • Added /etc/hosts fix (sed delete + recreate)

  • Added heredoc for passwords with special characters

  • Added NSS Certificate DB password location

  • Added p12 regeneration after DM password rotation

  • Added dsec backup procedure with age encryption

Lessons Learned:

  1. Rocky cloud images use eth0 with altname enp1s0 - check ip link

  2. cloud-init sets hostname to 127.0.0.1 in /etc/hosts - must fix before FreeIPA install

  3. cacert.p12 password is set at install time - doesn’t auto-update when DM password changes

  4. NSS DB password is in /var/lib/pki/pki-tomcat/conf/password.conf (internal=)

  5. Use heredoc for passwords with quotes/special chars - single quotes break

Next Steps:

  • Join FreeIPA to ISE as external LDAP identity source

  • Create printer service account for EAP-TTLS authentication

AD Group-Based 802.1X Authorization - VALIDATED

Implemented and validated AD group-based authorization for Linux EAP-TLS authentication. Machine certificate authentication now maps to AD computer group membership for authorization policy matching.

AD Groups Added to ISE:

netapi ise add-ad-groups DOMUS_DC01 "GRP-*"
Table 1. Groups Retrieved
Group Purpose

GRP-Users-Admins

Admin user accounts

GRP-Users-Standard

Standard user accounts

GRP-Computers-Linux-Admin

Linux admin workstations (used for authz)

GRP-Computers-Linux-Standard

Linux standard workstations

GRP-Computers-Windows

Windows workstations

GRP-Computers-Mac

Mac workstations

GRP-Servers-Linux

Linux servers

GRP-Servers-Windows

Windows servers

Authorization Rule Created (Compound Condition):

Compound conditions require multiple --and flags. A single --and only creates one condition. To match BOTH EAP-TLS AND AD group membership, use:

netapi ise add-authz-rule "Domus-Wired 802.1X" \
  "Linux_Computer_AD_Auth" \
  "Linux_EAPTLS_Admins" \
  --and "Network Access:EapAuthentication:EAP-TLS" \
  --and "DOMUS_DC01:ExternalGroups:contains:inside.domusdigitalis.dev/Groups/Security/GRP-Computers-Linux-Admin" \
  --rank 0

Rule JSON (compound condition with ConditionAndBlock):

{
  "rule": {
    "name": "Linux_Computer_AD_Auth",
    "rank": 0,
    "state": "enabled",
    "condition": {
      "conditionType": "ConditionAndBlock",
      "isNegate": false,
      "children": [
        {
          "conditionType": "ConditionAttributes",
          "dictionaryName": "Network Access",
          "attributeName": "EapAuthentication",
          "operator": "equals",
          "attributeValue": "EAP-TLS"
        },
        {
          "conditionType": "ConditionAttributes",
          "dictionaryName": "DOMUS_DC01",
          "attributeName": "ExternalGroups",
          "operator": "contains",
          "attributeValue": "inside.domusdigitalis.dev/Groups/Security/GRP-Computers-Linux-Admin"
        }
      ]
    }
  },
  "profile": ["Linux_EAPTLS_Admins"]
}

Validation on modestus-razer:

netapi ise dc session "98:BB:1E:1F:A7:13"
Session Output
Policy Set:    Domus-Wired 802.1X
AuthZ Profile: Linux_EAPTLS_Admins
Auth Method:   dot1x
NAD Port:      GigabitEthernet1/0/1
Session ID:    0A32010A0000077C27167DCD

Switch Verification:

netapi ios exec "show access-session interface gi1/0/1 de"
Key Output
User-Name:      modestus-razer.inside.domusdigitalis.dev
Status:         Authorized
Vlan Group:     Vlan: 10
ACS ACL:        xACSACLx-IP-LINUX_EAPTLS_PERMIT_ALL-69680320
Method:         dot1x (Authc Success)

Key Learnings:

  1. Machine auth vs User auth: EAP-TLS with machine certificate authenticates the COMPUTER account, not the user. AD group conditions must match computer groups (e.g., GRP-Computers-Linux-Admin), not user groups.

  2. SSSD cache staleness: AD group membership changes may not reflect immediately in Linux id output. Use sudo sss_cache -E && sudo systemctl restart sssd to force refresh.

  3. netapi output formats: Use -f json or -f yaml BEFORE the subcommand for structured output:

    • netapi ise -f json get-authz-rules "Domus-Wired 802.1X" | jq '.[]'

  4. AD group naming: Groups appear in ISE with full DN path: inside.domusdigitalis.dev/Groups/Security/GRP-Computers-Linux-Admin

TEAP Configuration for Windows Home Users - COMPLETED

Implemented TEAP (Tunnel Extensible Authentication Protocol, RFC 7170) for Windows home users as a GPO alternative. Full programmatic deployment via PowerShell.

Documentation Created:

  • domus-ise-windows/docs/asciidoc/modules/ROOT/pages/teap-configuration.adoc

  • PowerShell script Configure-TEAP.ps1 for 100% programmatic setup

  • Supports both EAP-TLS and EAP-MSCHAPv2 inner methods

ISE Policy Configuration (via API):

Table 2. Domus-Wired 802.1X
Type Rule Name Identity/Profile

Authentication

TEAP_Wired_Auth

Windows_Cert_Profile

Authorization

TEAP_Machine_User_Success

Domus_Secure_Profile

Authorization

TEAP_Machine_Only

Domus_Secure_Profile

Authorization

TEAP_User_Only

Domus_Secure_Profile

Table 3. Domus-Secure 802.1X (Wireless)
Type Rule Name Identity/Profile

Authentication

TEAP_Windows_Auth

Windows_Cert_Profile

Authorization

TEAP_Machine_User_Success

Domus_Secure_Profile

Authorization

TEAP_Machine_Only

Domus_Secure_Profile

Authorization

TEAP_User_Only

Domus_Secure_Profile

Authorization

TEAP_Windows_Secure

Domus_Secure_Profile

EAP Chaining Logic:

  • Machine + User both succeeded → Full DATA_VLAN access

  • Machine only succeeded → Full access (pre-login Windows updates)

  • User only succeeded → Full access (BYOD scenario)

Commands Used:

# Check ISE allowed protocols for TEAP
curl -ks -u 'domus_ers_admin:PASSWORD' -H 'Accept: application/json' \
  'https://10.50.1.20:9060/ers/config/allowedprotocols/92613980-8c01-11e6-996c-525400b48521' | jq '.AllowedProtocols.teap'

# Create TEAP authentication rule (wired)
curl -ks -u 'domus_ers_admin:PASSWORD' \
  -H 'Content-Type: application/json' -H 'Accept: application/json' \
  -X POST -d @/tmp/teap-auth-rule.json \
  'https://10.50.1.20/api/v1/policy/network-access/policy-set/2c2e6b05-a29c-46a4-a0ee-7fcea4853e47/authentication'

# Create TEAP authorization rule with EAP chaining
curl -ks -u 'domus_ers_admin:PASSWORD' \
  -H 'Content-Type: application/json' -H 'Accept: application/json' \
  -X POST -d @/tmp/teap-chain-both.json \
  'https://10.50.1.20/api/v1/policy/network-access/policy-set/2c2e6b05-a29c-46a4-a0ee-7fcea4853e47/authorization'

# Update rule to change DenyAccess → Domus_Secure_Profile
curl -ks -u 'domus_ers_admin:PASSWORD' \
  -H 'Content-Type: application/json' -H 'Accept: application/json' \
  -X PUT -d @/tmp/teap-update.json \
  'https://10.50.1.20/api/v1/policy/network-access/policy-set/POLICY_ID/authorization/RULE_ID'

# Verify TEAP rules
curl -ks -u 'domus_ers_admin:PASSWORD' -H 'Accept: application/json' \
  'https://10.50.1.20/api/v1/policy/network-access/policy-set/2c2e6b05-a29c-46a4-a0ee-7fcea4853e47/authorization' | \
  jq '.response[] | select(.rule.name | test("TEAP")) | {name: .rule.name, profile: .profile[0]}'

JSON Payloads:

TEAP Authentication Rule
{
  "rule": {
    "default": false,
    "name": "TEAP_Wired_Auth",
    "rank": 1,
    "state": "enabled",
    "condition": {
      "conditionType": "ConditionAttributes",
      "isNegate": false,
      "dictionaryName": "Network Access",
      "attributeName": "EapTunnel",
      "operator": "equals",
      "attributeValue": "TEAP"
    }
  },
  "identitySourceName": "Windows_Cert_Profile",
  "ifAuthFail": "REJECT",
  "ifUserNotFound": "REJECT",
  "ifProcessFail": "DROP"
}
TEAP EAP Chaining Authorization Rule
{
  "rule": {
    "default": false,
    "name": "TEAP_Machine_User_Success",
    "rank": 0,
    "state": "enabled",
    "condition": {
      "conditionType": "ConditionAndBlock",
      "isNegate": false,
      "children": [
        {
          "conditionType": "ConditionAttributes",
          "isNegate": false,
          "dictionaryName": "Network Access",
          "attributeName": "EapTunnel",
          "operator": "equals",
          "attributeValue": "TEAP"
        },
        {
          "conditionType": "ConditionAttributes",
          "isNegate": false,
          "dictionaryName": "Network Access",
          "attributeName": "EapChainingResult",
          "operator": "equals",
          "attributeValue": "User and machine both succeeded"
        }
      ]
    }
  },
  "profile": ["Domus_Secure_Profile"]
}

Key ISE IDs:

  • Policy Set (Wired): 2c2e6b05-a29c-46a4-a0ee-7fcea4853e47

  • Policy Set (Wireless): 9557d91c-591b-4d8d-9898-657a62f28d76

  • Certificate Profile: Windows_Cert_Profile

  • Authorization Profile: Domus_Secure_Profile

Pending:

  • Push domus-ise-windows changes (git push)

  • Test TEAP from Windows machine

LDAP Fallback Authorization - EXPLORED

Explored creating an LDAP-based fallback authorization rule using FreeIPA (ipa-01) as an alternative to AD groups.

Current ISE Identity Sources:

Name Type Groups Available

DOMUS_DC01

Active Directory

GRP-Computers-Linux-Admin, GRP-Users-Admins, etc. (8 groups)

ipa-01

FreeIPA LDAP

ipausers, printers (2 groups)

Challenge: Machine Auth vs User Auth

EAP-TLS with machine certificates authenticates the COMPUTER account, not a user:

  • AD: Computer objects can be members of security groups → works

  • FreeIPA: Hosts are separate from users, stored in hostgroups not user groups

ISE LDAP Config Issue:

Current ipa-01 LDAP store searches:

groupDirectorySubtree: cn=groups,cn=accounts,...  ← user groups only

For machine auth, need to also search:

groupDirectorySubtree: cn=hostgroups,cn=accounts,...  ← host groups

FreeIPA Current State:

ssh ipa-01 "ipa hostgroup-find"
Output
1 hostgroup matched: ipaservers

Options Identified:

  1. Full FreeIPA hostgroup integration:

    • Create hostgroup (ipa hostgroup-add linux-admins)

    • Enroll hosts via ipa-join

    • Update ISE LDAP config for hostgroups

    • Create authz rule with ipa-01:ExternalGroups

  2. EAP-TLS only fallback (simpler):

    • Create lower-priority rule matching just EAP-TLS

    • No group requirement - any valid cert = access

    • Faster to implement

Decision: Deferred pending further architecture discussion.

Runbook Updated:

  • domus-ise-linux/runbooks/linux-ad-auth-dacl.adoc v2.2

  • Section 2.10.2: Fixed dual --and syntax for compound conditions

  • Section 2.10.3: Updated JSON to show ConditionAndBlock with children array

Certificate-Based Authorization - DOCUMENTED

Designed and documented certificate-based authorization using X.509 subject fields (OU and O) instead of external identity source lookups.

Naming Convention Established:

Field Home (Domus) Work (CHLA)

O (Department)

Domus-Infrastructure

Research

OU (Role)

Domus-Admins, Domus-Analysts, Domus-Users

Research-Users

Role Hierarchy (Home):

OU Who Trust Level

Domus-Admins

Evan (infra admin)

Full trust - everything

Domus-Analysts

Gabriel (future)

Elevated - analysis tools

Domus-Users

Gabriel (now)

Standard - no infra SSH

Certificate Subject Format:

CN=modestus-razer.inside.domusdigitalis.dev, OU=Domus-Admins, O=Domus-Infrastructure

ISE Authorization Rules (cert-based):

netapi ise add-authz-rule "$POLICY_SET" \
  "Domus_Infra_Admins" \
  "$AUTHZ_EAPTLS" \
  --and "Network Access:EapAuthentication:EAP-TLS" \
  --and "Certificate:Subject Organizational Unit:contains:Domus-Admins" \
  --and "Certificate:Subject Organization:contains:Domus-Infrastructure" \
  --rank 0

Benefits over AD/LDAP groups:

  • No external identity source dependency

  • Works if AD is down

  • Self-documenting (openssl x509 -noout -subject)

  • Portable across environments

Runbook Updated:

  • Section 2.10 → Certificate-Based Authorization (Recommended)

  • Section 2.11 → AD Group-Based Authorization (Alternative)

Wireless 802.1X Auth Rule Fix

Problem: Wireless EAP-TLS hitting BYOD instead of Linux_Cert_Domus_Infra authz rule.

Root Cause: BYOD_Certificate_Auth authentication rule at rank 0 matched ALL EAP-TLS traffic before EAP_TLS_Certificate_Auth at rank 2. Both rules have condition: Network Access:EapAuthentication equals EAP-TLS.

Fix: Deleted BYOD_Certificate_Auth from Domus-Secure 802.1X policy set to allow EAP_TLS_Certificate_Auth to process EAP-TLS.

# Delete BYOD auth rule that was catching all EAP-TLS
netapi ise delete-auth-rule "Domus-Secure 802.1X" "BYOD_Certificate_Auth"

Also added wireless authz rule:

netapi ise add-authz-rule "Domus-Secure 802.1X" \
  "Linux_Cert_Domus_Infra" \
  "Linux_EAPTLS_Admins" \
  --and "Network Access:EapAuthentication:EAP-TLS" \
  --and "CERTIFICATE:Subject - Organization:equals:Domus-Infrastructure" \
  --rank 0

Current Domus-Secure 802.1X Auth Rules:

Rank Rule Name Identity Source

0

TEAP_Windows_Auth

Windows_Cert_Profile

1

EAP_TLS_Certificate_Auth

AD_Cert_Profile

2

iPSK AuthC

iPSKManager

3

FreeIPA_EAP-TLS_Auth

ipa-01

4

Default

Internal Endpoints

Wireless Authentication Rule (DOMUS PKI)

Added auth rule for Vault/DOMUS-issued certs (using existing Test_Linux_CertAuth identity source):

netapi ise add-auth-rule "Domus-Secure 802.1X" "Linux_EAP_TLS_Auth" "Test_Linux_CertAuth" --rank 0

Test_Linux_CertAuth is a Certificate Authentication Profile configured for DOMUS-ROOT-CA chain. Should be renamed to Domus_Linux_CertAuth in future cleanup.

Wireless Authorization Profile Fix

Problem: EAP-TLS auth succeeded but WLC disconnected with reason=250 after successful auth.

Root Cause: Linux_EAPTLS_Admins profile has daclName: LINUX_EAPTLS_PERMIT_ALL. dACLs are wired-only - WLC doesn’t support them without FlexConnect local switching.

Fix: Use Domus_Secure_Profile (no dACL) for wireless:

# Delete rule with wired profile
echo "y" | netapi ise delete-authz-rule "Domus-Secure 802.1X" "Linux_Cert_Domus_Infra"

# Recreate with wireless-compatible profile (no dACL)
netapi ise add-authz-rule "Domus-Secure 802.1X" \
  "Linux_Cert_Domus_Infra" \
  "Domus_Secure_Profile" \
  --and "Network Access:EapAuthentication:EAP-TLS" \
  --and "CERTIFICATE:Subject - Organization:equals:Domus-Infrastructure" \
  --rank 0

Key Insight: Wired vs Wireless authorization profiles:

Attribute Wired Wireless

dACL

✓ Supported

✗ Not supported (unless FlexConnect)

VLAN

✓ Supported

✓ Supported

authzProfileType

SWITCH

SWITCH (same)

Current Domus-Secure 802.1X Auth Rules (after fix):

Rank Rule Name Identity Source

0

Linux_EAP_TLS_Auth

Test_Linux_CertAuth

1

TEAP_Windows_Auth

Windows_Cert_Profile

2

EAP_TLS_Certificate_Auth

AD_Cert_Profile

3

iPSK AuthC

iPSKManager

4

FreeIPA_EAP-TLS_Auth

ipa-01

5

Default

Internal Endpoints

Research Certificate Deployment (modestus-aw)

Testing research dACL pattern for CHLA deployment using modestus-aw as test endpoint.

Create Vault PKI Research Role

On certmgr-01 (after unseal with 2 keys):

vault write pki_int/roles/research-client \
  allowed_domains="inside.domusdigitalis.dev" \
  allow_subdomains=true \
  max_ttl="8760h" \
  ou="Research-Users" \
  organization="Research"

Issue Research Certificate

vault write -format=json pki_int/issue/research-client \
  common_name="modestus-aw.inside.domusdigitalis.dev" \
  ttl="8760h" > /tmp/modestus-aw-research-cert.json

jq -r '.data.certificate' /tmp/modestus-aw-research-cert.json > /tmp/modestus-aw-research.crt
jq -r '.data.private_key' /tmp/modestus-aw-research-cert.json > /tmp/modestus-aw-research.key

# Verify
openssl x509 -in /tmp/modestus-aw-research.crt -noout -subject
# Output: O=Research, OU=Research-Users, CN=modestus-aw.inside.domusdigitalis.dev

vault operator seal

Deploy to modestus-aw

From modestus-razer:

scp certmgr-01:/tmp/modestus-aw-research.crt /tmp/
scp certmgr-01:/tmp/modestus-aw-research.key /tmp/
scp /tmp/modestus-aw-research.crt modestus-aw:/tmp/
scp /tmp/modestus-aw-research.key modestus-aw:/tmp/

On modestus-aw:

sudo cp /tmp/modestus-aw-research.crt /etc/ssl/certs/modestus-aw-eaptls.pem
sudo cp /tmp/modestus-aw-research.key /etc/ssl/private/modestus-aw-eaptls.key
sudo chmod 600 /etc/ssl/private/modestus-aw-eaptls.key

Create ISE Authorization Rule for Research

netapi ise add-authz-rule "Domus-Wired 802.1X" \
  "Linux_Cert_Research" \
  "Linux_EAPTLS_Permit" \
  --and "Network Access:EapAuthentication:EAP-TLS" \
  --and "CERTIFICATE:Subject - Organization:equals:Research" \
  --rank 0

Validate

sudo nmcli conn down "Wired-802.1X-Vault"; sleep 3; sudo nmcli conn up "Wired-802.1X-Vault"

netapi ise dc query "SELECT TIMESTAMP_TIMEZONE, USERNAME, AUTHORIZATION_RULE, AUTHORIZATION_PROFILES FROM RADIUS_AUTHENTICATIONS WHERE CALLING_STATION_ID = '08:92:04:38:11:9C' ORDER BY TIMESTAMP_TIMEZONE DESC FETCH FIRST 1 ROWS ONLY"
Result
AUTHORIZATION_RULE: Linux_Cert_Research
AUTHORIZATION_PROFILES: Linux_EAPTLS_Permit

Next: Apply Research dACL

The Linux_EAPTLS_Permit profile uses LINUX_RESEARCH_ZERO_TRUST_V2 dACL. Test ACL restrictions:

  • Block lateral movement (RFC1918)

  • Permit AD auth (Kerberos, LDAP, DNS to DC)

  • Permit SSH from admin workstation

  • Permit internet

dACL Test Results (modestus-aw at 10.50.40.102)

Lateral Movement Test
# From modestus-aw
ping -c 1 10.50.1.1
Result: BLOCKED ✅
PING 10.50.1.1 (10.50.1.1) 56(84) bytes of data.
--- 10.50.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss
AD DNS Test
dig SRV _kerberos._tcp.inside.domusdigitalis.dev @10.50.1.50
Result: PERMITTED ✅
;; ANSWER SECTION:
_kerberos._tcp.inside.domusdigitalis.dev. 600 IN SRV 0 100 88 dc-01.inside.domusdigitalis.dev.
Internet Test
ping -c 1 8.8.8.8
Result: PERMITTED ✅
1 packets transmitted, 1 received, 0% packet loss
SSH Connectivity Test (from modestus-razer)
nc -zv 10.50.40.102 22
Result: PERMITTED ✅
Connection to 10.50.40.102 22 port [tcp/ssh] succeeded!

SSH AD User Authentication Gap

Issue: AD user SSH authentication cannot work on modestus-aw because SSSD is not installed.

# Check SSSD status on modestus-aw
ssh modestus-aw "systemctl is-active sssd; pacman -Q sssd 2>/dev/null || echo 'sssd not installed'"
Result
inactive
sssd not installed

Impact: The dACL permits SSH connections (network layer), but the target machine cannot authenticate AD users without SSSD.

Resolution Options:

  1. Install and configure SSSD on modestus-aw for AD user authentication

  2. Continue using local user authentication (already works)

Local User SSH Test
ssh modestus@10.50.40.102
# Works with local user + SSH key
AD User SSH Test (apples-to-apples with CHLA)
ssh evanusmodestus@inside.domusdigitalis.dev@10.50.40.102
Result: FAILS - target not configured for AD auth
Permission denied (publickey).
Target sshd_config status
ssh modestus-aw "grep -E '^(AuthenticationMethods|PasswordAuthentication|GSSAPIAuthentication|UsePAM)' /etc/ssh/sshd_config"
Result
PasswordAuthentication no
# Missing: GSSAPIAuthentication yes
# Missing: UsePAM yes

For CHLA deployment: Target machines need SSSD installed and configured before AD user SSH can work. This is independent of the dACL.

CHLA Pre-requisites for AD User SSH (user@domain@host):

The ISE dACL permits SSH from admin workstations, but the TARGET machine must have:

  1. sssd package installed

  2. /etc/sssd/sssd.conf configured for AD realm

  3. PAM configured to use sssd (/etc/pam.d/sshd, /etc/pam.d/system-auth)

  4. Machine domain-joined (realm join or adcli join)

  5. /etc/ssh/sshd_config configured:

    GSSAPIAuthentication yes
    UsePAM yes

Without these, the SSH connection succeeds (dACL permits) but authentication fails (no GSSAPI/PAM).

Pending Tasks

  • Xianming Linux - Certificate installation

  • Xianming Linux - NetworkManager configuration

  • Xianming Linux - EAP-TLS authentication test

  • Xianming Linux - dACL verification

  • iPSK HA - Review CHLA architecture

  • iPSK HA - Create home enterprise diagram

  • Monday prep - Finalize VLAN security presentation

  • FreeIPA deployment on kvm-01 - COMPLETED

References