Exam SC-300 topic 2 question 19 discussion

I'm almost certain that 5 sign-in attempts were tracked, and the user got locked out because of that! For the same 3 passwords in a row, MS counts only 1! "Smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password." - https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout

I tested this, if you stick to the question about Track Sig-In Attempts and the information provided in the question, Azure AD logs will log 11 attempts!!! You are assuming Smart lockout tracks, but there is nothing in the question related to this. If I have the same question in the exam, I will go with 11 as I tested it

Tracked sign-in attempts: 11 Unlock by: Performing a self-service password reset (SSPR) For audit and security purposes, Azure logs ALL sign-in attempts. Smart-Lockout only tracks different wrong passwords for its own logic( 5 in this case), but the question is specifically asking about how many login attempts were tracked and every attempt to login is logged.

OK, presuming the smart lockout reference is the source of truth here. As of today, the default lockout threshold is 10 attempts and the default lockout duration is 60 seconds. THIS is just to mention that 300 secs is not the current default anymore (might have been 2 years ago). ALSO be aware that the 'last three identical hashes'-principle is still valid, and the *lockout counter* is *really* 5, meaning that since the user was locked out, someone has changed the default threshold from 10 to 5 without MSFT being so polite to explicitly inform us examinees about this fact! BUT nevertheless, 11 attempts were *tracked*. Indeed. Read the reference again: "Smart lockout tracks the last three bad password hashes to avoid..." The stress here is on "tracks", and the question was "how many attempts were tracked". FINALLY: SSPR is quite a claim! It will only reset the lockout count to 0 seconds if the user selects the "I forgot my password" option. All in all - absolutely speculative scenario and solution statements. Just learn it by heart and don't mull over it.

Chet Gpt : After reviewing all the comments and considering the provided information and the specific focus of the question on "tracked sign-in attempts," it appears that the most accurate answer should be 11. The logic behind this is that the Sign-In logs will track all 11 sign-in attempts, regardless of the Smart Lockout behavior, as long as they are attempted within the specified time frame. So, the final answer is 11.

11 SSRP

The key here is the 300s lockout value. This is the default value when Smart Lockout is turned on. It’s a trick question to fool you into assuming it isn’t turned on and give 11 as tracked count. The correct answer is 5 count, and SSPR. 🙂

11 SSPR

11 SSPR

This is a stupid question. Tracked where? Conditional Sign-in audit logs get reported to Sign-In logs which will track 11 records, regardless of whether Smart Lockout is configured or not. I get why everyone is saying 4, but the wording is just terrible.

Ele quis dizer rastreio de tentativas de login, não quantas são consideradas para bloqueio, então a resposta correta é 11

For Tracked sign-in attempts, it could be 4, 5, or 11 5: if it tracks the last 3 bad password hashes and doesn't count them if they are repeated 4: if it tracks the last 3 UNIQUE bad password hashes and doesn't count them 11: if by tracked, it is referring to tracked on Azure AD and not tracked on Smart lockout Which is it? This question sucks

Good answer should be: Tracked sign-in: 4 Unlock by: SSPR Why 4? "Smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password." ==> The last pwd was already providen. And then it's not five. Check the 3 last pwd

Set the Lockout threshold, based on how many failed sign-ins are allowed on an account before its first lockout. The default is 10 for Azure Public tenants and 3 for Azure US Government tenants. Set the Lockout duration in seconds, to the length in seconds of each lockout. The default is 60 seconds (one minute).

Welp, I hope this isn't on the test with this wording. Lockout threshold set to 10. Tested with [email protected]. Put in all the passwords provided > Account NOT locked out Put in completely DIFFERENT passwords and the 3rd one locked the account out. So it would seem the correct answer would be 7 with the initial list of passwords provided. SMH MSFT.

I am not sure why it's not 4. This is my understanding: The tracking counter is 0 at the beginning. For the first 3 entries: Pa55w0rd12, the counter will be 1. For the fourth entry: Pa55w.rd12, the counter will be 2. Now following three entries: Pa55w.rd123, the counter will be 3. Since the Smart lockout tracks the last three bad password hashes it should only store hashes of these passwords at this point: Pa55w0rd12, Pa55w.rd12, Pa55w.rd123 For the eighth entry: Pa55word12, the counter will be 4. Now the stored password hashes should be Pa55w.rd12, Pa55w.rd123, Pa55word12. For the following three entries the password hashes are already stored then why should it increment the counter one more time? Please note counter is the number of attempts being tracked.

Perhaps view this article: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout How smart lockout works By default, smart lockout locks the account from sign-in attempts for one minute after 10 failed attempts for Azure Public and Azure China 21Vianet tenants and 3 for Azure US Government tenants. The account locks again after each subsequent failed sign-in attempt, for one minute at first and longer in subsequent attempts. To minimize the ways an attacker could work around this behavior, we don't disclose the rate at which the lockout period grows over additional unsuccessful sign-in attempts. Smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior won't cause the account to lock out. based on the above and the hashes, 5 would be correct answer for "tracked sign-in attempts".