Security

Hello Folks, 

 

I have a Clearpass running a wired dot1x wired service with AD authentication, with Windows 10 PCs environment, 

I'm facing an issue where employee decide to self-reset password through SSPR (self-service password reset/win10 feature), 

As you may know, reset password occurs prior to submitting credentials for AD authentication, 

once I click the reset button, I notice that PC submit a dot1x authentication to get access to the network using "defaultuser1" with a default password. 

because this username isn't defined in any source of authentication, the user failed to authenticate, and thus user can't connect to the network to reset the password, 

 

any workaround for SSPR with clearpass? 

 

some resources to understand how SSPR works,

https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-sspr-windows

 

thank you all.

 

 

 

 

Anyone can suggest a solution?

You could create a local user in CPPM with those credentials and allow it access to a limited access VLAN which allows them to get to the domain controller hosting AD only to reset the password. You could even leverage using the production VLAN assignment, but pass down a dACL to limit the access, that way it's on a per-session basis. 

 

I would hope that won't happen to often, but would be a quick workaround. Other option is to leverage machine and user-based authentication for 802.1X. That would allow the device to be on the domain with machine credentials before needing to type in a password and authenticate via user-auth. Assuming this is a domain-joined asset.

The same idea I had to create a local user, but the challenge is the password created along with "defaultuser1'' is random.

No PCs are not domain joined, and machine authentication isn't in use,

hopeful there is another way to do that.

Honestly your most simple solution here might be to have them hardwire to reset. Sometimes simple is better and it's not the prettiest option but may be the easiest to manage. If I think of anything else we can do with CPPM I'll post it here. My only other though is a PSK network specifically for this purpose and maybe only broadcast in a tech area, but again, is it too much for what your looking to accomplish? Maybe.
________________________________

Please note that if you have received this message in error, you are hereby notified that any dissemination of this communication is strictly prohibited. Please notify me immediately by reply e-Mail and delete all copies of the original message.

Hello,
authentication is a wired dot1x =), it's a bit challenging to setup static ports without dot1x for users to reset their password.

Thank you, Haring, hope we can come up with a workaround solution from CP side,

Sorry about that, too many posts :-). How about leveraging MAC auth in
addition to 802.1X? If device is Computer pass back dACL to limit access to
only DC and that would give enough access to change password?

** Editing this post ** 

 

MAC address service won't match, because as I mentioned, the win10 PC submit credentials @ the dot1x stage, 

I have a question for you: is there a way to authenticate an account without verifying the password? with that way, an authentication coming from "defaultuser1" will be accepted and placed in a restrictive VLAN or dacl pushed along with. 

Haring,
Any new idea, about the question i posted?

is there a way to authenticate an account without verifying the password? with that way, an authentication coming from "defaultuser1" will be accepted and placed in a restrictive VLAN or dacl pushed along with.

I am familiar with that on the Guest module, but for Policy Manager, I
would have to look deeper into it. I would consider checking the
authentication method of EAP-PEAP and see if there are any options in
there. If there are, you probably want a separate service specifically for
that username, but does open up the risk of having someone using that
account and getting production access without needing the password. It's
basically like a PSK network at that point where the username is the key
and needs to be kept secret.

We've seen this behaviour in our environment as well, same issue for wired and wireless (user authentication attempted for defaultuser1 when attempting to perform SSPR).

 

We have certificate EKU filtering for the auth profiles so the authentication attempt fails due to no valid certificate to use for auth.

 

For some reason SSPR only 'breaks' when attempting over wireless - I guess it takes slightly longer to associate as well?

 

We can work around the problem by using 802.1X machine auth only, which is not ideal (wanting to elevate privileges with subsequent user logons).

 

Has anyone found another solution to this?