Security

 View Only

  • 1.  802.1x causing AD lockouts

    Posted Oct 26, 2025 05:07 AM

    We have a challenge in that when users change their Active Directory password they forget to update it on their wireless clients.  The ends up locking them out of Active Directory and causing very much frustration and slowing our adoption of fully authenticated wireless.

    We were pointed to one solution to use a filter in the authentication source like this: (&(&(sAMAccountName=%{Authentication:Username})(objectClass=user))(!(badPwdCount>=3))) 

    That, worked as designed- it stops the Clearpass from sending additional failures to Active directory (prevents from incrementing the badPwdCount attribute).

    However, it prevents that user from authenticating with any wireless device going forward until ClearPass "sees" the badPwdCount clear.  This is the big problem.   Because Active Directory stores the badPwdCount on individual domain controller (it is not synchronized), we can't tell the user to login to some other device connected to AD (computer or Shibboleth) because there is only the 1 in 3 chance that login will clear the count.

    We have tried a couple of other things.  One of those was to lower the cache timeout to five minutes on the authentication source configuration.  This did not work because the authentication source is set as a single name to round-robin to the domain controllers, and the ClearPass continues to hold on to the same DC.  The other thing we tried was setting up three separate authentication sources - the three domain controllers, and adjusted the service profile to use them.  The CP did try different sources as expected, but the filter above did not work, and so we got locked out of AD.  Even if the filter was set to 1. AD lockout is at 5. So the theory was CP would fail each once and stop, waiting for the attribute to go back to zero.  No good.

    There must be other setups that have run into this problem.  What have you done?  Or have you abandoned central directory authentication and used some other method?



    -------------------------------------------


  • 2.  RE: 802.1x causing AD lockouts

    Posted Oct 26, 2025 05:38 AM

    Move to EAP-TLS 

    For mobile devices, use clearpass onboard to provision the clients certs.



    ------------------------------
    Shpat | ACEP | ACMP | ACCP | ACDP
    Just an Aruba enthusiast and contributor by cases
    If you find my comment helpful, KUDOS are appreciated.
    ------------------------------



  • 3.  RE: 802.1x causing AD lockouts

    Posted Oct 27, 2025 04:59 AM

    The EAP method is not good when the password is expired. Windows cached the expired password.

    The way to avoid it is EAP-TLS or EAP-TEAP, which is more convenient to do.



    ------------------------------
    Give me a Kudo if it is useful.

    Ratchapas
    https://www.facebook.com/Aruba-News-Update-1401095559960142
    ------------------------------



  • 4.  RE: 802.1x causing AD lockouts

    Posted Oct 27, 2025 08:08 AM

    With badPwdCount, you can only treat the symptoms, not the cause. You yourself mentioned the cause: "users change their Active Directory password and forget to update it on their wireless clients."

    Our customers use certificate-based authentication, i.e., EAP-TLS. This means that no passwords are used and users are not blocked in AD. With EAP-TLS, however, you must ensure that the certificates on the end devices are renewed before they expire.



    ------------------------------
    Regards,

    Waldemar
    ACCX # 1377, ACEP, ACX - Network Security
    If you find my answer useful, consider giving kudos and/or mark as solution
    ------------------------------

    Original Message


  • 5.  RE: 802.1x causing AD lockouts

    Posted Oct 27, 2025 12:01 PM

    As mentioned, certificate based authentication is the way to go. But a patch on the problem you have before you can implement certificate based authentication on all devices is to do the following to only treat the device with the faulty password with the badPwdCound rule.

    1. Create a custom attribute in Endpoints database, i.e. BadPassword
    2. Create two new enforcement profiles with type Endpoint Update. One to set the attribute BadPassword to True and one to set it to False
    3. Create two duplicates of the AD source, one with (&(&(sAMAccountName=%{Authentication:Username})(objectClass=user))(!(badPwdCount>=3)))  the other a normal with out (!(badPwdCount>=3)).
      Also change the 3 to just 1 instead.
    4. Create a copy of your 802.1x enforcement policy, add the Endpoint update enforcement profile to set the BadPassword attribute to False
    5. Duplicate your 802.1x service. In the copy add a service filter to check the endpoint database for the BadPassword=True
      Name the service something BadPassword 
      Make sure the AD source is the one with the query (&(&(sAMAccountName=%{Authentication:Username})(objectClass=user))(!(badPwdCount>=1))) 
      Place it above the normal 802.1x service
      Use same role mapping and the updated enforcement policy setting BadPassword to False
    6. In the normal 802.1x service add a new rule as rule number one, or at least very high
      (Radius:Microsoft:MS-CHAP-Error EXISTS) and the Enforcement policy to set the BadPassword attribute to True

    With this configuration a device with a bad password configured will not be able to send more authentications to the AD, but other devices will still be able to do so. When the user has updated the faulty password on the device, a successful authentication must take place on any of the other devices to reset the badPwdCount in AD. If I remember correct the counter is also reset after some time.

    This isn't by any means a "best practice" configuration, but it will solve you problem. And yes, I have seen a customer run this "temporary fix" configuration for 10+ years... ;-) 



    ------------------------------
    Best Regards
    Jonas Hammarbäck
    MVP Guru, ACEX, ACDX #1600, ACCX #1335, ACX-Network Security
    Aranya AB
    If you find my answer useful, consider giving kudos and/or mark as solution
    ------------------------------

    Original Message


Related Content