Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Secure Store Password Policy - getting the details

Steel Contributor

On our tenant, I get the following Secure Score message:

 

You should make sure that all of your user account passwords have been reset in the timeframe asserted by your password policy. Accounts that have not had their password reset have either been excepted from the policy, or are being unused. In both cases, these accounts are ones that can be targeted by an attacker. We found that you have ____ accounts out of ______ that have passwords older than 7 days beyond your asserted policy. If you reset the passwords on these accounts, your score will go up 1 points.

 

My question is, where is secure score getting this data from and how can I get the same data but with the account details so that I can actually reset the passwords. There are too many to do by hand, I need to create a script but to do that, I need a list of accounts with passwords older than the required limit.

 

How can I generate or access that list?

 

3 Replies

You can get the last password change timestamp via the MSOL/AzureAD powershell module. There are example scripts available that compare that value to the password policy and can even generate notification. Here's one example: https://windowsserveressentials.com/2015/01/23/office-365-email-password-reminder/ 

Thanks Vasil, I'm aware and use that data but it is wrong!

 

Firstly, though we have mandatory password changes every 90d, currently out of 11,630 records, 13 (ignoring external and system entries) are marked with PasswordNeverExpires = True - this should never be the case and demonstrates that there is a problem in AAD.

 

 

Secondly, I have examples where the LastPasswordChangeTimestamp shows a date in April, the PasswordNeverExpires is False and the user is currently (e.g. today) using the system. So this user last changed their password 181 days ago according to the data. How could this be so? Something is dreadfully wrong here.

 

 

This is why I asked the question I did in the way that I did. The Secure Score report is reporting something that I am having difficulty with using the data provided to us - I want to know whether Secure Score is using the same data and therefore likely to have the same failings - or whether it has access to other information.

For interest, we now have an open Premier Support call related to this issue.

 

We have established that some users are definately NOT being prompted for password resets on the required schedule.