I have included the Security section in my appsettings.json so that I could update the Security -> UserPassword -> RequiredLength and Security -> UserPassword -> MaxFailedAccessAttemptsBeforeLockout which both of these properties have been update correctly so now the required length for a password is 12 and the max failed attempts is 3.
Had a quick look through the source to try and see where this is going awry.
In Asp.NET identity the notion of whether someone is locked out is based on the DateTime value set when the lockout occurs, eg if you've configured it to be an hour, the date will be set for an hours time, and when that passes the user won't be considered to be locked out.
But historically Umbraco hasn't followed this convention, instead there has been a bit field in the database for a user called 'noconsole'
You can see in Umbraco's mappers that the value of a User entity's IsLockedOut is set to be the value in the database of NoConsole.
it sort of looks to me, that if this map is used, the if the noconsole value is true in the database, then IsLockedOut will be true - and the LockoutEnd date will be set to the Maximum value of Datetime... which will mean the check to see if LockoutEnd is < that the current DateTime will always fail?
But think you'd probably need to pull down the source and set a breakpoint to see what exactly is going on here.
Thanks for the detailed reply that is really helpful! I think you are right with your last assumption as it looks like if the user is locked out it is just using the DateTime.MaxValue and not checking if there is a user defined value,
I've not pulled down the source code and ran it locally before but I think I will try that and see if that is the case.
UserDefaultLockoutTimeInMinutes is being ignored.
I have included the Security section in my appsettings.json so that I could update the Security -> UserPassword -> RequiredLength and Security -> UserPassword -> MaxFailedAccessAttemptsBeforeLockout which both of these properties have been update correctly so now the required length for a password is 12 and the max failed attempts is 3.
I have also updated the UserDefaultLockoutTimeInMinutes from the default of 43200 (30 days) to 5 (minutes), I failed to login 3 times to force a lockout and no matter how long I wait I can't log back in so I think this setting isn't being applied correctly, has anyone ran into this issue before? I used the documentation here: https://docs.umbraco.com/umbraco-cms/reference/configuration/securitysettings#user-default-lockout-time-in-minutes
Any help would be really appreciated.
Hi Ryan
Had a quick look through the source to try and see where this is going awry.
In Asp.NET identity the notion of whether someone is locked out is based on the DateTime value set when the lockout occurs, eg if you've configured it to be an hour, the date will be set for an hours time, and when that passes the user won't be considered to be locked out.
But historically Umbraco hasn't followed this convention, instead there has been a bit field in the database for a user called 'noconsole'
You can see in Umbraco's mappers that the value of a User entity's IsLockedOut is set to be the value in the database of NoConsole.
https://github.com/umbraco/Umbraco-CMS/blob/2b629693950818865a9f8ee316ec7bc1538d287f/src/Umbraco.Infrastructure/Persistence/Mappers/UserMapper.cs#L26
When AspIdentity was implemented for Umbraco the methodology looks to be trying to use the DateTime field to set the lockout time
https://github.com/umbraco/Umbraco-CMS/blob/2b629693950818865a9f8ee316ec7bc1538d287f/src/Umbraco.Infrastructure/Security/UmbracoUserManager.cs#L236
and when it checks if someone is locked out:
https://github.com/umbraco/Umbraco-CMS/blob/2b629693950818865a9f8ee316ec7bc1538d287f/src/Umbraco.Web.Common/Security/BackOfficeUserManager.cs#L65
You can see it's checking IsApproved flag, and the falls through to call the base AspNet Identity logic...
(so only thought is it a DateTime difference, eg if you can look in the database, can you confirm the DateTime is set to be the correct UTC time?)
And then, could you also check if 'noconsole' is being set on the User when you trigger the lockout, as the only other thing I spotted...
... is in the mapping of the LockoutEnd DateTime
https://github.com/umbraco/Umbraco-CMS/blob/2b629693950818865a9f8ee316ec7bc1538d287f/src/Umbraco.Infrastructure/Security/IdentityMapDefinition.cs#L110
it sort of looks to me, that if this map is used, the if the noconsole value is true in the database, then IsLockedOut will be true - and the LockoutEnd date will be set to the Maximum value of Datetime... which will mean the check to see if LockoutEnd is < that the current DateTime will always fail?
But think you'd probably need to pull down the source and set a breakpoint to see what exactly is going on here.
regards
marc
Hey Marc,
Thanks for the detailed reply that is really helpful! I think you are right with your last assumption as it looks like if the user is locked out it is just using the DateTime.MaxValue and not checking if there is a user defined value,
I've not pulled down the source code and ran it locally before but I think I will try that and see if that is the case.
Thanks again.
Linking this to the Issue:
https://github.com/umbraco/Umbraco-CMS/issues/14561
(in case anyone is finding this and wants to see what happened next...)
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.