locked
AD FS Server 2012 R2 unable to clear Bad Password Count RRS feed

  • Question

  • Hi All,

    I currently have a Microsoft Premier Support call open for this issue, just wanted to put the feelers out to see if anyone else had tackled this in the past.

    We have an ongoing problem with brute force attacks against our ADFS. We have Extranet Lockout enabled, with 3 invalid attempts, observation window of 20 minutes, AD is set to 5 invalid attempts, this is supposed to avoid account lockouts, as AD clears invalid attempts after 15 minutes, however we found this only occurs during the next Kerberos auth attempt.

    If we leave AD FS to manage all of the auth attempts, we try an account 3 times, and then must wait the 20 minute observation window, after the 20 minutes we are free to try another attempt, what should happen is because we are past the 15 minutes clear bad password threshold in AD, it clears down to 0 and the next failed attempt should be attempt 1, instead its becoming attempt 4, therefore they are managing to lock the accounts after 2 observation windows.

    This would only occur when the user does not make any auth attempts via Kerberos so isn't affecting us too badly as users generally make an attempt every time they open a shared drive etc.

    Anyone else tackled AD FS not clearing bad password attempts?

    Monday, October 22, 2018 2:30 PM

Answers

  • I got that. It just works for me :/

    Can you share the output of:

    Get-ADFSProperties
    
    Get-ADDefaultDomainPasswordPolicy


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, October 22, 2018 3:43 PM
  • Please ignore thread - answer found, it was a fine grain AD password policy changing the clear to 30 minutes
    Tuesday, October 23, 2018 11:54 AM

All replies

  • ADFS is not "clearing" the bad password count. AD will use the badPasswordTime to determine if we are passed the observation windows (of the AD policy) in order to restart counting from 0.

    I can't repro your scenario on my lab :( User are blocked at the WAP level, always.

    I don't get what you mean about the Kerberos part. This lockout mechanism is agnostic of the authentication protocol. 



    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, October 22, 2018 3:26 PM
  • So the observation window part works fine, attempts are ignored by AD FS until the observation window (badPasswordTime + 20 minutes) has passed.

    After the 20 minutes, the 3 bad attempts are still showing (checking using Account Lockout Status tool), and I can make a fourth bad attempt

    When testing the same internally, via logging into a machine incorrectly 3 times, after 15 minutes, upon my 4th attempt the bad password count is cleared and that is bad attempt 1, as per design, this just isn't happening with AD FS.

    __

    The below is what we used for our ticket to MS;

    If we make a standard Kerberos authentication attempt from a normal computer within our estate, we make 1, 2, 3 or 4 bad password attempts (Not locking the account), and then wait for 15 minutes, then try again (good or bad password), the counter of bad passwords gets reset and starts again, as expected due to our “Reset account lockout counter after” timer.

    If we make bad password attempts via AD FS (Office 365 login), we get stopped at 3 attempts, as expected due to our settings, and a 20 minute observation window is triggered. After this 20 minute observation window – we make further unsuccessful attempts via AD FS, the bad password count increases, rather than resetting. This then means that after a couple of observation windows have passed, we can eventually lockout the account.

    Monday, October 22, 2018 3:32 PM
  • I got that. It just works for me :/

    Can you share the output of:

    Get-ADFSProperties
    
    Get-ADDefaultDomainPasswordPolicy


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, October 22, 2018 3:43 PM
  • I have removed anything that can identify our customer, and replaced it with CLEARED

    AcceptableIdentifiers                      : {}
    AddProxyAuthorizationRules                 :CLEARED
    ArtifactDbConnection                       : Data Source=np:\\.\pipe\microsoft##wid\tsql\query;Initial 
                                                 Catalog=AdfsArtifactStore;Integrated Security=True
    AuthenticationContextOrder                 : {urn:oasis:names:tc:SAML:2.0:ac:classes:Password, 
                                                 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, 
                                                 urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient, 
                                                 urn:oasis:names:tc:SAML:2.0:ac:classes:X509...}
    AutoCertificateRollover                    : True
    CertificateCriticalThreshold               : 2
    CertificateDuration                        : 365
    CertificateGenerationThreshold             : 20
    CertificatePromotionThreshold              : 5
    CertificateRolloverInterval                : 720
    CertificateSharingContainer                : CLEARED
    CertificateThresholdMultiplier             : 1440
    ClientCertRevocationCheck                  : None
    ContactPerson                              : Microsoft.IdentityServer.Management.Resources.ContactPerson
    DisplayName                                : CLEARED
    IntranetUseLocalClaimsProvider             : False
    ExtendedProtectionTokenCheck               : Allow
    FederationPassiveAddress                   : /adfs/ls/
    HostName                                   : CLEARED
    HttpPort                                   : 80
    HttpsPort                                  : 443
    TlsClientPort                              : 49443
    Identifier                                 : CLEARED
    InstalledLanguage                          : en-US
    LogLevel                                   : {Errors, FailureAudits, Information, Verbose...}
    MonitoringInterval                         : 1440
    NetTcpPort                                 : 1501
    NtlmOnlySupportedClientAtProxy             : True
    OrganizationInfo                           : 
    PreventTokenReplays                        : False
    ProxyTrustTokenLifetime                    : 21600
    ReplayCacheExpirationInterval              : 60
    SignedSamlRequestsRequired                 : False
    SamlMessageDeliveryWindow                  : 5
    SignSamlAuthnRequests                      : False
    SsoLifetime                                : 480
    PersistentSsoLifetimeMins                  : 10080
    KmsiLifetimeMins                           : 1440
    PersistentSsoEnabled                       : True
    PersistentSsoCutoffTime                    : 01/01/0001 00:00:00
    KmsiEnabled                                : False
    LoopDetectionEnabled                       : True
    LoopDetectionTimeIntervalInSeconds         : 20
    LoopDetectionMaximumTokensIssuedInInterval : 5
    PasswordValidationDelayInMinutes           : 60
    SendClientRequestIdAsQueryStringParameter  : False
    WIASupportedUserAgents                     : {MSAuthHost/1.0/In-Domain, MSIE 6.0, MSIE 7.0, MSIE 8.0...}
    ExtranetLockoutThreshold                   : 3
    ExtranetLockoutEnabled                     : True
    ExtranetObservationWindow                  : 00:20:00
    GlobalRelyingPartyClaimsIssuancePolicy     : c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isre
                                                 gistereduser"] => issue(claim = c);c:[Type == 
                                                 "http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier"] 
                                                 => issue(claim = c);
    PromptLoginFederation                      : FallbackToProtocolSpecificParameters
    PromptLoginFallbackAuthenticationType      : urn:oasis:names:tc:SAML:1.0:am:password
    ComplexityEnabled           : True
    DistinguishedName           : CLEARED
    LockoutDuration             : 00:30:00
    LockoutObservationWindow    : 00:15:00
    LockoutThreshold            : 5
    MaxPasswordAge              : 60.00:00:00
    MinPasswordAge              : 1.00:00:00
    MinPasswordLength           : 8
    objectClass                 : {domainDNS}
    objectGuid                  : d4476b77-62a5-4caa-a301-b9c0c06c89b2
    PasswordHistoryCount        : 21
    ReversibleEncryptionEnabled : False



    Tuesday, October 23, 2018 10:50 AM
  • Please ignore thread - answer found, it was a fine grain AD password policy changing the clear to 30 minutes
    Tuesday, October 23, 2018 11:54 AM