AAA and network access
Check network admission and application permissions separately. Record how devices join the network and what each operator or service may access afterwards.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
General integration baseline; directory schema, EAP method, RADIUS attributes, authorisation policy, and recovery design are deployment specific.
On this page
Overview#
Authentication proves an identity to a defined assurance level. Authorisation decides what that identity may do. Accounting records what was requested and decided. Keep network admission, device administration, operator login, API authorisation, and physical access decisions as separate policy layers even when they use the same directory.
802.1X, EAP, and RADIUS#
IEEE 802.1X defines port based network access control with a supplicant, authenticator (switch/access point), and authentication server.1 EAP provides the authentication framework; an EAP method supplies actual credentials and security properties.2 RADIUS commonly carries EAP and authorisation attributes between authenticator and server.3
Design and test:
- machine/device identity, certificate issuance, private key protection, trust roots, renewal, revocation, replacement, and clock dependency;
- authenticated server validation by the supplicant, without it, credentials may be offered to an impostor;
- exact EAP method and inner method; “supports 802.1X” is insufficient;
- VLAN/ACL/role result, reauthentication, session timeout, change of authorisation, accounting, and failure/reject behaviour;
- boot sequencing when network, DNS, time, CRL/OCSP, directory, or RADIUS is unavailable;
- controlled critical/fallback VLANs that can't become permanent bypasses.
MAC Authentication Bypass is possession of a spoofable address, not strong authentication. If unavoidable for legacy devices, isolate it to device specific least privilege and pair it with switch port/topology monitoring.
Classic RADIUS has legacy protection limitations. RFC 6614 and RFC 9765 are both Experimental RFCs, so publication alone isn't a deployment recommendation. RFC 6614 encapsulates the existing RADIUS packet format in TLS and therefore retains MD5 based packet authenticators and attribute obfuscation mechanisms inside the protected connection; validate TLS peer identity and never infer that the inner format was modernized.4 RADIUS/1.1 in RFC 9765 requires TLS 1.3, removes those MD5 packet mechanisms, and changes protocol behaviour, so it requires explicit client/server support and can't be enabled as a transparent port change.5
LDAP, Active Directory, and Kerberos#
LDAP v3 protocol operations are defined by RFC 4511; Kerberos V5 by RFC 4120.67 Active Directory combines LDAP directory access, Kerberos, DNS and Microsoft specific protocols rather than being “just LDAP.”8
- Use TLS with full server identity validation or a product supported signed/sealed bind. Don't send simple bind passwords on plaintext LDAP.
- Use a dedicated service identity with minimum search base, attributes and operations; never bind an application as a domain administrator.
- Pin schema/attribute semantics and stable immutable identifiers. Display name, email, or DN can change and must not be the sole authorisation key.
- Resolve nested groups, cycles, replication delay, disabled/deleted users, duplicate names, referral chasing, paging/size limits, and cache expiry explicitly.
- Fail closed for privileged commands while preserving an engineered local emergency/recovery path. Don't make door egress or certified life safety behaviour depend on a live directory lookup.
- Prevent LDAP filters, DNs, log records, and UI labels from being constructed through unescaped user input.
Microsoft documents LDAP signing controls for Active Directory Domain Services; exact defaults and enforcement vary with supported Windows versions and configuration, so inspect the deployed policy rather than assuming.9