Security

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn’t, inspect the user’s group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment—user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn't, inspect the user's group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment-user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan

Hi Andrea,

The quarantine ACL appears correctly defined; it mirrors the dynamic ACL approach we apply on wired ports until user authentication succeeds.

Please now verify user-certificate auto-enrolment for every Active Directory security group authorized for TEAP:

1. Log on to an affected workstation and open certmgr.msc. Under Personal → Certificates, confirm that a certificate issued from the designated user-authentication template is present.

2. If the certificate is absent, ensure each relevant security group has Read, Enroll, and Autoenroll permissions on that template.

3. Confirm that the Certificate Services Client – Auto-Enrollment GPO is enabled for users and scoped to the OUs containing those groups.

After checking for this, a gpupdate /force  on the client should do the trick for the users to get a user certificate from the CA. 

Regards,
Vigan

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn't, inspect the user's group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment-user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan

Today a user with the issue :(

The machine and user certificate are already in the user pc. The certificate was created yesterday

In the clearpass log TeapMethod 1 EAP-TLS complete with success, it get machine name from the machine certificate. Teap-Method-2-Status Failure, with empty username.

This is correct while user is on login screen before insert credentials. Once user insert credentials, windows stuck on welcome screen, and I can't see clearpass log.

In controllers, the quarantine role permit access to CA, intermediate CA, DCs, service dns, kerberos ldp and ldps port on the entire network.

User stucks for about 20 minutes, than he connect to wired cable: clearpass log TEAP method 2, he get the desktop and wifi connection....

I don't know what else to look at: I would have to get between the PC and the network and understand what it is trying to do

Hi Andrea,

The quarantine ACL appears correctly defined; it mirrors the dynamic ACL approach we apply on wired ports until user authentication succeeds.

Please now verify user-certificate auto-enrolment for every Active Directory security group authorized for TEAP:

1. Log on to an affected workstation and open certmgr.msc. Under Personal → Certificates, confirm that a certificate issued from the designated user-authentication template is present.

2. If the certificate is absent, ensure each relevant security group has Read, Enroll, and Autoenroll permissions on that template.

3. Confirm that the Certificate Services Client – Auto-Enrollment GPO is enabled for users and scoped to the OUs containing those groups.

After checking for this, a gpupdate /force  on the client should do the trick for the users to get a user certificate from the CA. 

Regards,
Vigan

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn't, inspect the user's group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment-user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan

Hi Andrea,

Since the certificates are already in place, how is the wifi authentication profile configured on the NIC.

Are you using both user or computer authentication, or just computer authentication?

You can also double check this EAP-TEAP tech note from HPE for reference MAYBE you might have missed something on the WIFI side.

https://arubanetworking.hpe.com/techdocs/NAC/tech-corner/teap/

Hope this might help :).

Cheers,

Vigan

Original Message:
Sent: Jun 25, 2025 03:57 AM
From: andrea.armellini
Subject: clear pass quarantine hang

Today a user with the issue :(

The machine and user certificate are already in the user pc. The certificate was created yesterday

In the clearpass log TeapMethod 1 EAP-TLS complete with success, it get machine name from the machine certificate. Teap-Method-2-Status Failure, with empty username.

This is correct while user is on login screen before insert credentials. Once user insert credentials, windows stuck on welcome screen, and I can't see clearpass log.

In controllers, the quarantine role permit access to CA, intermediate CA, DCs, service dns, kerberos ldp and ldps port on the entire network.

User stucks for about 20 minutes, than he connect to wired cable: clearpass log TEAP method 2, he get the desktop and wifi connection....

I don't know what else to look at: I would have to get between the PC and the network and understand what it is trying to do

Original Message:
Sent: Jun 20, 2025 04:11 AM
From: vigan
Subject: clear pass quarantine hang

Hi Andrea,

The quarantine ACL appears correctly defined; it mirrors the dynamic ACL approach we apply on wired ports until user authentication succeeds.

Please now verify user-certificate auto-enrolment for every Active Directory security group authorized for TEAP:

1. Log on to an affected workstation and open certmgr.msc. Under Personal → Certificates, confirm that a certificate issued from the designated user-authentication template is present.

2. If the certificate is absent, ensure each relevant security group has Read, Enroll, and Autoenroll permissions on that template.

3. Confirm that the Certificate Services Client – Auto-Enrollment GPO is enabled for users and scoped to the OUs containing those groups.

After checking for this, a gpupdate /force  on the client should do the trick for the users to get a user certificate from the CA. 

Regards,
Vigan

Original Message:
Sent: Jun 20, 2025 02:28 AM
From: andrea.armellini
Subject: clear pass quarantine hang

Original Message:
Sent: 6/19/2025 10:35:00 AM
From: vigan
Subject: RE: clear pass quarantine hang

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn't, inspect the user's group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment-user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan

My doubt is that the issue come with windows hello for business, where user call Azure AD and Kerberos Server Key like this schema. In quarantine role pc obtains the dhcp and vlan is trusted to internet. Azure AD should be trusted without user auth in my firewall, so up to now I have always ruled out that it was a navigation problem....i have to go in deep here.
Yesterday I had another pc with issue: user was trying with finger print and login stuck at welcome screen. I ask him to insert active directory password (not windows hello Pin) and he got desktop immediately

Original Message:
Sent: Jun 25, 2025 05:50 AM
From: vigan
Subject: clear pass quarantine hang

Hi Andrea,

Since the certificates are already in place, how is the wifi authentication profile configured on the NIC.

Are you using both user or computer authentication, or just computer authentication?

You can also double check this EAP-TEAP tech note from HPE for reference MAYBE you might have missed something on the WIFI side.

https://arubanetworking.hpe.com/techdocs/NAC/tech-corner/teap/

Hope this might help :).

Cheers,

Vigan

Original Message:
Sent: Jun 25, 2025 03:57 AM
From: andrea.armellini
Subject: clear pass quarantine hang

Today a user with the issue :(

The machine and user certificate are already in the user pc. The certificate was created yesterday

In the clearpass log TeapMethod 1 EAP-TLS complete with success, it get machine name from the machine certificate. Teap-Method-2-Status Failure, with empty username.

This is correct while user is on login screen before insert credentials. Once user insert credentials, windows stuck on welcome screen, and I can't see clearpass log.

In controllers, the quarantine role permit access to CA, intermediate CA, DCs, service dns, kerberos ldp and ldps port on the entire network.

User stucks for about 20 minutes, than he connect to wired cable: clearpass log TEAP method 2, he get the desktop and wifi connection....

I don't know what else to look at: I would have to get between the PC and the network and understand what it is trying to do

Original Message:
Sent: Jun 20, 2025 04:11 AM
From: vigan
Subject: clear pass quarantine hang

Hi Andrea,

The quarantine ACL appears correctly defined; it mirrors the dynamic ACL approach we apply on wired ports until user authentication succeeds.

Please now verify user-certificate auto-enrolment for every Active Directory security group authorized for TEAP:

1. Log on to an affected workstation and open certmgr.msc. Under Personal → Certificates, confirm that a certificate issued from the designated user-authentication template is present.

2. If the certificate is absent, ensure each relevant security group has Read, Enroll, and Autoenroll permissions on that template.

3. Confirm that the Certificate Services Client – Auto-Enrollment GPO is enabled for users and scoped to the OUs containing those groups.

After checking for this, a gpupdate /force  on the client should do the trick for the users to get a user certificate from the CA. 

Regards,
Vigan

Original Message:
Sent: Jun 20, 2025 02:28 AM
From: andrea.armellini
Subject: clear pass quarantine hang

Original Message:
Sent: 6/19/2025 10:35:00 AM
From: vigan
Subject: RE: clear pass quarantine hang

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn't, inspect the user's group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment-user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan

Azure Active Directory (Azure AD) cannot be used as a direct authentication source for EAP-based methods such as EAP-TLS or EAP-TEAP in Aruba ClearPass. This is because Azure AD does not support legacy protocols like RADIUS or LDAP, which are required during the 802.1X authentication handshake.

This is confirmed in Aruba's official documentation, which states that the Azure AD authentication source in ClearPass is only used for authorization purposes, after a successful authentication event such as certificate-based EAP-TLS. ClearPass queries Azure AD (via the Microsoft Graph API) to retrieve user attributes like group membership for policy enforcement:
https://arubanetworking.hpe.com/techdocs/ClearPass/6.11/PolicyManager/Content/CPPM_UserGuide/Auth/AuthSource_Azure.htm

If direct authentication against cloud identities is required, you must deploy(if you haven't already) Azure AD Domain Services (AAD DS). AAD DS provides LDAP and Kerberos support, which allows systems like ClearPass to perform traditional authentication workflows:
🔗 https://learn.microsoft.com/en-us/azure/active-directory-domain-services/overview

The recommended and supported model by both Aruba and Microsoft is to use certificate-based authentication (EAP-TLS or TEAP) combined with Intune and NDES/SCEP to provision certificates to Azure AD-joined devices:
https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep

In this model, ClearPass handles certificate validation during authentication, and Azure AD provides authorization context afterwards.

My doubt is that the issue come with windows hello for business, where user call Azure AD and Kerberos Server Key like this schema. In quarantine role pc obtains the dhcp and vlan is trusted to internet. Azure AD should be trusted without user auth in my firewall, so up to now I have always ruled out that it was a navigation problem....i have to go in deep here.
Yesterday I had another pc with issue: user was trying with finger print and login stuck at welcome screen. I ask him to insert active directory password (not windows hello Pin) and he got desktop immediately

Original Message:
Sent: Jun 25, 2025 05:50 AM
From: vigan
Subject: clear pass quarantine hang

Hi Andrea,

Since the certificates are already in place, how is the wifi authentication profile configured on the NIC.

Are you using both user or computer authentication, or just computer authentication?

You can also double check this EAP-TEAP tech note from HPE for reference MAYBE you might have missed something on the WIFI side.

https://arubanetworking.hpe.com/techdocs/NAC/tech-corner/teap/

Hope this might help :).

Cheers,

Vigan

Original Message:
Sent: Jun 25, 2025 03:57 AM
From: andrea.armellini
Subject: clear pass quarantine hang

Today a user with the issue :(

The machine and user certificate are already in the user pc. The certificate was created yesterday

In the clearpass log TeapMethod 1 EAP-TLS complete with success, it get machine name from the machine certificate. Teap-Method-2-Status Failure, with empty username.

This is correct while user is on login screen before insert credentials. Once user insert credentials, windows stuck on welcome screen, and I can't see clearpass log.

In controllers, the quarantine role permit access to CA, intermediate CA, DCs, service dns, kerberos ldp and ldps port on the entire network.

User stucks for about 20 minutes, than he connect to wired cable: clearpass log TEAP method 2, he get the desktop and wifi connection....

I don't know what else to look at: I would have to get between the PC and the network and understand what it is trying to do

Original Message:
Sent: Jun 20, 2025 04:11 AM
From: vigan
Subject: clear pass quarantine hang

Hi Andrea,

The quarantine ACL appears correctly defined; it mirrors the dynamic ACL approach we apply on wired ports until user authentication succeeds.

Please now verify user-certificate auto-enrolment for every Active Directory security group authorized for TEAP:

1. Log on to an affected workstation and open certmgr.msc. Under Personal → Certificates, confirm that a certificate issued from the designated user-authentication template is present.

2. If the certificate is absent, ensure each relevant security group has Read, Enroll, and Autoenroll permissions on that template.

3. Confirm that the Certificate Services Client – Auto-Enrollment GPO is enabled for users and scoped to the OUs containing those groups.

After checking for this, a gpupdate /force  on the client should do the trick for the users to get a user certificate from the CA. 

Regards,
Vigan

Original Message:
Sent: Jun 20, 2025 02:28 AM
From: andrea.armellini
Subject: clear pass quarantine hang

Original Message:
Sent: 6/19/2025 10:35:00 AM
From: vigan
Subject: RE: clear pass quarantine hang

Hi Andrea,

In a comparable TEAP rollout we traced intermittent user-authentication failures back to certificate auto-enrollment. Machine auth completed, but Windows had no user certificate to present because some AD groups lacked the required auto-enroll permissions on the PKI template.

It may be worth confirming that:

every security group referenced by your network-access policies has at least Read and Enroll (preferably Autoenroll) rights on the user-auth certificate template;

the Certificate Services Client – Auto-Enrollment GPO setting is enabled for both Computer and User configurations and applies to all OUs that hold user accounts.

A quick workstation check (certutil -pulse or gpupdate /force) followed by a look for Event ID 6 in the Application log will show whether a user cert is issued. If it isn't, inspect the user's group memberships and the template ACLs.

Aligning auto-enrollment permissions across all relevant AD groups resolved the problem in our environment-user certificates issued automatically and TEAP moved cleanly from the machine to the user phase.

If you need the exact template ACL we used, let me know.

Best regards,
Vigan