EAP-TTLS for directory users

EAP-TTLS is the answer to a problem the other methods leave open: authenticating a directory user with their existing password, without certificates and without storing anything password-equivalent on the NAC server.

PEAP cannot do it — MS-CHAPv2 needs an NT hash, and a directory user’s password never leaves the directory. EAP-TLS can, but it costs a PKI and a certificate on every device. EAP-TTLS sits between them: the user types the password they already have, and Taranac verifies it by binding to the directory as that user.

That makes it the natural fit for the population that fits neither of the others — contractors on unmanaged laptops, staff on devices that will never be domain-joined, anything where certificate enrollment is more work than the access is worth. It is also the only password method available when the directory is not Active Directory: OpenLDAP, FreeIPA and the rest hand out no NT hash, so PEAP cannot work against them at all.

How the password is actually checked

The inner method is PAP: the password crosses the tunnel in the clear. That sounds alarming and is in fact the more conservative choice — the reason is worth understanding before you configure anything.

The client builds a TLS tunnel to Taranac, validating the NAC server’s certificate exactly as it does for PEAP. Nothing sensitive has crossed the wire yet.
Inside that tunnel the client sends the username and password as PAP. It is plaintext within TLS — the same protection your browser gives a password on a login form.
Taranac takes that password and, for a directory account, performs an LDAP bind as that user against the directory the account came from — a direct bind as user@domain on Active Directory, or a bind as the account’s distinguished name (resolved inside the configured search bases) on OpenLDAP, FreeIPA and the other types. The directory decides. Taranac never sees a hash, never stores one, and never needs to.
For a local Taranac account the same request is verified against the stored argon2id password hash instead. One method, both identity sources.

PEAP avoids sending the password by proving knowledge of its NT hash — which means the server has to hold that hash, and an unsalted MD4 hash is password equivalent: steal the database and you can authenticate as every user without cracking anything.

EAP-TTLS/PAP inverts the trade. The password is exposed only inside a TLS tunnel you control the endpoint of, and the server stores nothing that can be replayed. For directory accounts it also keeps password policy, lockout and expiry where they belong — in the directory, enforced on every bind.

The one thing you must get right is the tunnel: if a client skips server certificate validation, it will hand the plaintext password to whatever answers. That is why Step 2 of the PEAP guide is not optional here.

Step 1 — Confirm the directory side

EAP-TTLS leans entirely on your LDAP configuration, so check it before touching a client.

The directory is configured and reachable under Settings → LDAP, and users are synced — the account must exist in Taranac with source ldap (Infrastructure → Users). A bind cannot be attempted for a user Taranac does not know.
The account is in a group you can name in policy.
Bind verification uses a short timeout and fails closed — if the directory is unreachable, the request is rejected rather than admitted. Plan for that when the DC is the single point of failure for network access; see 802.1X authentication.

Step 2 — Add the policy rule

Dimension	Value
How (method)	`eap_ttls`
Who (user groups)	your directory group
What / Where / When	Any / Any / Always
Result	an authorization profile, e.g. `Corp-Data`

Placed above the default reject, as always. If you also run EAP-TLS for the same population, the two rules coexist without interfering: the method condition keeps them apart.

Step 3 — Configure the Windows supplicant

Windows 10 and 11 support EAP-TTLS natively — no supplicant to install.

Dialog 1 — the Authentication tab

Set the method to Microsoft: EAP-TTLS, and leave Remember my credentials on: with PAP there is no other way to avoid a prompt (see below).

Ethernet Properties with Microsoft: EAP-TTLS selected as the 802.1X method Windows 10 and 11 ship EAP-TTLS natively — the method is simply in the list.

Dialog 2 — EAP-TTLS Properties

Setting	Value	Why
Enable identity privacy	✅ On, with `anonymous`	The outer identity travels before the tunnel exists, in the clear. This replaces it with a placeholder and reveals the real username only inside TLS
Verify the server’s identity by validating the certificate	✅ On	The tunnel is the entire security model here — see the tip above
Connect to these servers	The NAC server certificate’s CN	Same rules and same traps as PEAP
Trusted Root Certification Authorities	The CA that signed the server certificate	Not your client-certificate CA — a different anchor entirely
Client authentication → Non-EAP method	Unencrypted password (PAP)	The only inner method that works with a directory

TTLS Properties with identity privacy on, PAP selected, and the Windows-credentials option greyed out Identity privacy set to anonymous, the server’s CA trusted, and PAP chosen under non-EAP methods. Note the option directly beneath PAP — greyed out; that is the subject of the next section.

Taranac handles identity privacy properly: it carries the inner identity through and evaluates policy against the real username, so the placeholder in the outer identity costs you nothing in the log or in policy matching.

Dialog 3 — Advanced settings

Specify authentication mode → User authentication, with credentials saved.

Advanced 802.1X settings with single sign-on enabled Note that Save credentials is greyed out here — it becomes available once the mode is User authentication rather than User or computer.

Automatically use my Windows account name and password is greyed out whenever the inner method is PAP. Windows enables it only for MS-CHAPv2 — and MS-CHAPv2 is precisely the method that cannot authenticate a directory account, because it needs an NT hash. The one inner method that works with your directory is the one Windows refuses to auto-fill.

The restriction is defensible rather than arbitrary: MS-CHAPv2 uses the password in a challenge-response and never transmits it, while PAP sends it inside the tunnel. Microsoft will not silently hand the cached logon password to a method that transmits it.

The visible consequence, with single sign-on enabled before logon, is that the user authenticates twice at the lock screen — once to Windows, once to the network:

Windows logon screen asking for network credentials in addition to the Windows password “Windows will try to connect to the network” — a second username and password, on top of the logon itself.

Three ways out, in increasing order of how well they solve it:

Save the credential once. In Advanced settings, set the mode to User authentication — that enables the Save credentials button, which is greyed out under User or computer authentication. Enter the network credentials once and the prompt stops appearing.
Turn single sign-on off, so the network authenticates after logon from the saved credential and the lock screen stays clean. The cost is that the port is unauthenticated before anyone signs in.
Move to EAP-TLS. A certificate needs no typing at all, works before logon, and is the only route to genuinely seamless authentication. This trade — one prompt forever, or a PKI — is the honest reason domains standardise on certificates.

Step 4 — Watch it authenticate

Bounce the port and open Logging → NAC → Authentication. An accept shows the method as EAP-TTLS and the resolved username — the real one, even with identity privacy on.

NAC Auth Log showing EAP-TTLS accepts for a directory user An EAP-TTLS accept for a directory account: the rule that matched (EAP-TTLS · AD_Users → Corp-Data) and VLAN 10. The username is the real one — identity privacy sent anonymous on the wire, and Taranac resolved the inner identity behind it.

If it fails, EAP-TTLS is unusually pleasant to debug: the handler rejects with a specific reason for each gate it applies, and that text reaches the log rather than a generic failure.

Reply message	What it means
`User not found`	No Taranac account matches the inner username — the directory user is not synced
`Account disabled` / `Account locked`	The account exists but its Taranac state blocks it
`Account not yet active` / `Account expired`	Outside the account’s validity period
`Password change required`	A local account flagged must change password. Deliberate: the flag gates 802.1X exactly as it gates the web login, so it cannot be side-stepped. Directory accounts delegate this to the directory
`Password required`	The inner request carried no password — usually the inner method is not PAP
`LDAP authentication failed`	The bind was attempted and the directory refused it — wrong password, or a directory-side restriction
`LDAP config not found for user`	The account is marked `ldap` but carries no domain reference; re-sync it
`No password configured` / `Invalid password`	A local account with no hash, or the wrong password

The distinction that saves the most time is between User not found and LDAP authentication failed: the first means the account never reached Taranac, the second means it did and the directory said no. They send you to completely different places.

Troubleshooting

Symptom	Cause	Fix
Rejected immediately, `User not found`	The directory user is not synced into Taranac	Check Infrastructure → Users for the account with source `ldap`; run a sync
Rejected, `LDAP authentication failed`, password is definitely right	The bind is failing for a directory-side reason, or the wrong domain is attached to the user	Test the same credentials against the DC directly; check the user’s LDAP config
All users fail at once, having worked yesterday	The directory is unreachable — bind verification fails closed	Check connectivity to the DC before touching anything client-side
Rejected, `Password required`	The inner method is not PAP	Set Unencrypted password (PAP) in the client’s Non-EAP methods
Local test account rejected with `Password change required`	Must change password is set on it	Clear the flag, or change the password through the portal
Connection fails before any log entry	Server certificate rejected by the client — TLS never completes	Same fix as PEAP: the right CA, in the machine store, with the server name pinned

When to use what

Situation	Reach for
Directory users, no PKI, unmanaged or mixed devices	EAP-TTLS — existing passwords, nothing stored server-side
Directory users on managed domain machines	EAP-TLS — no passwords at all, and pre-logon machine authentication
Local Taranac accounts, simplest possible setup	PEAP — but accept that an NT hash is stored
Devices with no user at all	MAB with endpoint classification

802.1X authentication — the four methods compared
LDAP directories — directory configuration and sync
NAC policy — conditions and results
802.1X with PEAP — server certificate trust in detail