Security

Jordan, haven't hit this one myself, but three things that might help.

Half of it is expected behaviour rather than a bug. The TEAP tech corner page notes that machine certificate attributes are only available when the device does machine auth alone. Once both inner methods use certs, you get the user cert only. So Certificate:Subject-AltName-DNS was never going to survive the full chain, regardless of CP-60444.

For the rest, worth raising CP-55234 on your TAC case. It's in the 6.14.0 resolved issues: RADIUS authorizations now automatically bypass LDAP/AD lookups when the outer identity is anonymous. New in 6.14, on by default, not configurable, and under TEAP with identity privacy the outer identity always is. HPE hasn't linked it to CP-60444, but it's the same release and the same area, so it's worth asking engineering whether one caused the other.

Workaround worth testing: on the machine-only auth that works today, write the machine's group membership to the endpoint record with a Policy Manager Entity Update Enforcement profile, then read it back on the full chain as %{Authorization:[Endpoints Repository]:...}. Use it in role mapping or enforcement, not in an auth source's filter query, which is unsupported and fails outright. Stale by design, but it should hold until the fix lands.

One more to rule out: try the machine filter as a service-level authorization source rather than an extra filter row on the AD source. Different code path, cheap to test.

Gorazd, your SHA-1 issue is documented as CP-58795 in the 6.14 known issues, with custom SHA-256 certs as the workaround. Worth noting it's scoped to RadSec specifically, so if your AP dot1x failure isn't RadSec it's a separate problem.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------

Jordan, haven't hit this one myself, but three things that might help.

Half of it is expected behaviour rather than a bug. The TEAP tech corner page notes that machine certificate attributes are only available when the device does machine auth alone. Once both inner methods use certs, you get the user cert only. So Certificate:Subject-AltName-DNS was never going to survive the full chain, regardless of CP-60444.

For the rest, worth raising CP-55234 on your TAC case. It's in the 6.14.0 resolved issues: RADIUS authorizations now automatically bypass LDAP/AD lookups when the outer identity is anonymous. New in 6.14, on by default, not configurable, and under TEAP with identity privacy the outer identity always is. HPE hasn't linked it to CP-60444, but it's the same release and the same area, so it's worth asking engineering whether one caused the other.

Workaround worth testing: on the machine-only auth that works today, write the machine's group membership to the endpoint record with a Policy Manager Entity Update Enforcement profile, then read it back on the full chain as %{Authorization:[Endpoints Repository]:...}. Use it in role mapping or enforcement, not in an auth source's filter query, which is unsupported and fails outright. Stale by design, but it should hold until the fix lands.

One more to rule out: try the machine filter as a service-level authorization source rather than an extra filter row on the AD source. Different code path, cheap to test.

Gorazd, your SHA-1 issue is documented as CP-58795 in the 6.14 known issues, with custom SHA-256 certs as the workaround. Worth noting it's scoped to RadSec specifically, so if your AP dot1x failure isn't RadSec it's a separate problem.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------

Hi Dustin,

Tested this one, added a new dedicated authorization source with the machine filter, declared at the service level (Authorization Sources) rather than as an extra filter row on the existing AD source. Tried it both with "Use for Authorization" checked and unchecked.

Same result: no machine authorization attributes at all during full TEAP authentication (Method 1 + Method 2 succeeding). I also swapped the filter itself between (&(dNSHostName=%{Certificate:Subject-AltName-DNS})(objectClass=computer)) and the documented (&(sAMAccountName=%{Authentication:TEAP-Method-1-Username})(objectClass=computer)), no difference either way. 

So it looks like this isn't a filter-syntax or source-declaration issue at all, during full-chain TEAP, no machine authorization lookup gets attempted in the first place, regardless of where or how the source/filter is configured. That's consistent with what we're seeing in the debug logs (no LDAP query for the machine object shows up during full-chain, whereas it does show up cleanly during machine-only auth).

Follow-up on the CP-55234 question, TAC confirmed it's not related to CP-60444. Their explanation: the outer identity lookup bypass (CP-55234) happens before authentication, while the authorization lookup issue we're tracking (CP-60444) happens after authentication succeeds, different phases entirely, so the bypass logic doesn't come into play here.

TAC has confirmed the root cause (CP-60444) and is currently working on a fix, expected in an upcoming 6.14.x patch. I'll wait for that to land and report back here once we've had a chance to validate it.

------------------------------
Best regards,
Jordan V.
#ACP-CA
------------------------------


Original Message:
Sent: Jul 29, 2026 10:10 AM
From: DB86
Subject: ClearPass 6.14 - EAP-TEAP machine authorization broken (regression from 6.11 / 6.12)

Jordan, haven't hit this one myself, but three things that might help.

Half of it is expected behaviour rather than a bug. The TEAP tech corner page notes that machine certificate attributes are only available when the device does machine auth alone. Once both inner methods use certs, you get the user cert only. So Certificate:Subject-AltName-DNS was never going to survive the full chain, regardless of CP-60444.

For the rest, worth raising CP-55234 on your TAC case. It's in the 6.14.0 resolved issues: RADIUS authorizations now automatically bypass LDAP/AD lookups when the outer identity is anonymous. New in 6.14, on by default, not configurable, and under TEAP with identity privacy the outer identity always is. HPE hasn't linked it to CP-60444, but it's the same release and the same area, so it's worth asking engineering whether one caused the other.

Workaround worth testing: on the machine-only auth that works today, write the machine's group membership to the endpoint record with a Policy Manager Entity Update Enforcement profile, then read it back on the full chain as %{Authorization:[Endpoints Repository]:...}. Use it in role mapping or enforcement, not in an auth source's filter query, which is unsupported and fails outright. Stale by design, but it should hold until the fix lands.

One more to rule out: try the machine filter as a service-level authorization source rather than an extra filter row on the AD source. Different code path, cheap to test.

Gorazd, your SHA-1 issue is documented as CP-58795 in the 6.14 known issues, with custom SHA-256 certs as the workaround. Worth noting it's scoped to RadSec specifically, so if your AP dot1x failure isn't RadSec it's a separate problem.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------

That's a clean negative result, thanks for running it properly. My service-level source idea is dead and your debug logs are why. If no LDAP query for the machine object shows up at all during full chain, then nothing downstream of the lookup matters, and moving the source or reworking the filter was never going to help. Fair enough on CP-55234 too. The pre-auth versus post-auth split makes sense.

Which leaves the endpoint approach as the one that should still work, and your finding is what makes it the right answer rather than just an alternative. It sidesteps the defect entirely because it never needs a machine lookup during the full chain.

Rough shape: on your machine-only service, add a ClearPass Entity Update enforcement profile that writes the machine memberOf values into the endpoint record as a custom attribute. Then on the TEAP service, add the Endpoints Repository as an authorization source and read it back with %{Authorization:[Endpoints Repository]:YourAttribute} in role mapping. Machine-only auth still does a working lookup, so the data gets written. Full chain never has to ask.

One caveat before you build it. The endpoint attribute persists, so a machine that leaves a group keeps the old value until it next authenticates machine-only. Depending on how much those groups gate, you may want a timestamp alongside it so you can age the value out. Still worth it as a bridge until the 6.14.x patch lands.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------


Original Message:
Sent: Jul 30, 2026 09:36 AM
From: JV-008881
Subject: ClearPass 6.14 - EAP-TEAP machine authorization broken (regression from 6.11 / 6.12)

Hi Dustin,

Tested this one, added a new dedicated authorization source with the machine filter, declared at the service level (Authorization Sources) rather than as an extra filter row on the existing AD source. Tried it both with "Use for Authorization" checked and unchecked.

Same result: no machine authorization attributes at all during full TEAP authentication (Method 1 + Method 2 succeeding). I also swapped the filter itself between (&(dNSHostName=%{Certificate:Subject-AltName-DNS})(objectClass=computer)) and the documented (&(sAMAccountName=%{Authentication:TEAP-Method-1-Username})(objectClass=computer)), no difference either way. 

So it looks like this isn't a filter-syntax or source-declaration issue at all, during full-chain TEAP, no machine authorization lookup gets attempted in the first place, regardless of where or how the source/filter is configured. That's consistent with what we're seeing in the debug logs (no LDAP query for the machine object shows up during full-chain, whereas it does show up cleanly during machine-only auth).

Follow-up on the CP-55234 question, TAC confirmed it's not related to CP-60444. Their explanation: the outer identity lookup bypass (CP-55234) happens before authentication, while the authorization lookup issue we're tracking (CP-60444) happens after authentication succeeds, different phases entirely, so the bypass logic doesn't come into play here.

TAC has confirmed the root cause (CP-60444) and is currently working on a fix, expected in an upcoming 6.14.x patch. I'll wait for that to land and report back here once we've had a chance to validate it.

------------------------------
Best regards,
Jordan Vivet
#ACP-CA #ACP-NS #APS-SSE #APC-ClearPass
------------------------------



Original Message:
Sent: Jul 29, 2026 10:10 AM
From: DB86
Subject: ClearPass 6.14 - EAP-TEAP machine authorization broken (regression from 6.11 / 6.12)

Jordan, haven't hit this one myself, but three things that might help.

Half of it is expected behaviour rather than a bug. The TEAP tech corner page notes that machine certificate attributes are only available when the device does machine auth alone. Once both inner methods use certs, you get the user cert only. So Certificate:Subject-AltName-DNS was never going to survive the full chain, regardless of CP-60444.

For the rest, worth raising CP-55234 on your TAC case. It's in the 6.14.0 resolved issues: RADIUS authorizations now automatically bypass LDAP/AD lookups when the outer identity is anonymous. New in 6.14, on by default, not configurable, and under TEAP with identity privacy the outer identity always is. HPE hasn't linked it to CP-60444, but it's the same release and the same area, so it's worth asking engineering whether one caused the other.

Workaround worth testing: on the machine-only auth that works today, write the machine's group membership to the endpoint record with a Policy Manager Entity Update Enforcement profile, then read it back on the full chain as %{Authorization:[Endpoints Repository]:...}. Use it in role mapping or enforcement, not in an auth source's filter query, which is unsupported and fails outright. Stale by design, but it should hold until the fix lands.

One more to rule out: try the machine filter as a service-level authorization source rather than an extra filter row on the AD source. Different code path, cheap to test.

Gorazd, your SHA-1 issue is documented as CP-58795 in the 6.14 known issues, with custom SHA-256 certs as the workaround. Worth noting it's scoped to RadSec specifically, so if your AP dot1x failure isn't RadSec it's a separate problem.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------