Jump to content

Recommended Posts

Posted

You can now do this with group policy, you may need to create a Staff user policy set it in there and apply it to them.

 

I would have a baseline user for all users, then separate staff and student ones to do such as this with.

Posted
Off the top of my head, not with 2008. I think you can set a base password policy but it is a but tri my. 2012, possibly R2, brought in the AD admin center that could set password policies by user group.
Posted (edited)

We've got this in place on 2008 R2. Can't quite remember the procedure, but I know we needed to use ADSI Edit to set it up, rather than just ADUC.

 

This looks like the right sort of thing - https://blogs.technet.microsoft.com/seanearp/2007/10/06/windows-server-2008-fine-grained-password-policy-walkthrough/

 

Once you've created a password policy object in ADSI Edit, you can modify the object's msDS-PSOAppliesTo attribute in ADUC to point to your staff security group, so that only staff are subject to the policy.

Edited by jthompson
Posted
Sorry not something I've had to do but there was a section under account policies and password policy I had a tinker with years ago.

 

What you're thinking of is the domain password policy. This dates back to the dawn of AD from when it was introduced back with Windows 2000. You can only have one password policy per domain.

 

The way that you've got to think of it is like this: When you log onto a domain PC, you're not authenticating against the PC's own user database, you're authenticating against the domain controller's. If you try to set the password policy in the place that you're thinking of, you'd be setting it against the local PC rather than the domain controller. This is why you can only have one of these "legacy" password policies per domain.

 

Windows 2008 introduced a concept called Fine Grained Password Policies. These are applied to AD Security Groups rather than to machines. You could only set them up with ADSI Edit back then but there are now PowerShell commands that were brought in with Windows 2012 iirc to define them.

Posted
Ahhh i have heard of fine-grained policies but never used. Thanks. It works with 2008 as well ?

 

You might as well upgrade to a newer OS and then implement this. You have less than 6 months left with server 2008.

Posted

Id say its not advisable to force password expiration anymore.

 

Microsoft guidelines even suggest not to and rather set complexity requirements

Posted
Id say its not advisable to force password expiration anymore.

 

Microsoft guidelines even suggest not to and rather set complexity requirements

 

We've used a fine-grained password policy to give staff passwords higher complexity requirements than student passwords. We also have a max age on staff passwords, but it's quite long (best part of a year). Initially, on setting the new complexity requirements, we needed a max age to go with it so as to force staff off their old passwords and onto new, more complex ones. I decided to leave the max age limit in place, but yes, the affect of password expiry on password hygiene (sticky notes on desks, not committing them to memory, etc.) is definitely something to consider.

Posted
Id say its not advisable to force password expiration anymore.

 

Microsoft guidelines even suggest not to and rather set complexity requirements

 

Absolutely. We're looking at changing away from "traditional" ideas of password expiry. It's counter-intuitive, but Microsoft have far better data on password use, vulnerability, etc. than we all do.

Posted
I'd say its not advisable to force password expiration anymore.

Ditto! In addition to Microsoft, the NCSC and NIST advise the same too.

 

The problems with forcing regular password expiry « National Cyber Security Centre

 

Regular password expiry is a common requirement in many security policies. However, in the Password Guidance published in 2015, we explicitly advised against it. This article explains why we made this (for many) unexpected recommendation, and why we think it’s the right way forward.

 

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know

 

The don’ts

Now for all the things you shouldn’t do.

 

No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”

 

Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as pA55w+rd.

 

No password hints. None. If I wanted people have a better chance at guessing my password, I’d write it on a note attached to my screen.

 

People set password hints like rhymes with assword when you allow hints. (Really! We have some astonishing examples from Adobe’s 2013 password breach).

 

Knowledge-based authentication (KBA) is out. KBA is when a site says, “Pick from a list of questions – Where did you attend high school? What’s your favourite football team? – and tell us the answer in case we ever need to check that it’s you.”

 

No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.

 

The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

 

For reference here's Microsoft's guidance...

 

www.microsoft.com/en-us/research/publication/password-guidance (PDF)

  • Thanks 1
Posted
Id say its not advisable to force password expiration anymore.

 

Microsoft guidelines even suggest not to and rather set complexity requirements

 

I'd agree with this.

Posted
On the other hand, it's nice to know that staff can't stick for years with whatever password got quietly breached from Yahoo! or LinkedIn x number of years ago. You can tell people to not reuse passwords as much as you like, and to not sign up to things using their school email address, but one (easy) way to actually mitigate it is to give passwords a maximum age, to reduce the chances of anything appearing on haveibeenpwned. I think it also helps to train people out of that condition whereby having to change their years old password is akin to being told that you've just run over their cat on purpose.
Posted
You can tell people to not reuse passwords as much as you like, and to not sign up to things using their school email address, but one (easy) way to actually mitigate it is to give passwords a maximum age, to reduce the chances of anything appearing on haveibeenpwned.

The following Chrome extension might be worth deploying too. It will tell users as soon as their password has been pwned and nag them each time they type it in with a message listing which data breach it has been in. :)

 

www.edugeek.net/forums/downloads/196509-okta-passprotect-chrome-checks-your-passwords-have-i-been-pwned.html

Posted
Hi all,

 

Been asked to set staff to have passwords expire after a certain number of days not pupils ? What would be the best way to do this please ?

 

...well I'd start by asking why....and wondering who is making this request.

 

It may the right thing to do....but simply because you are being asked to do it...doesn't make it a good thing to do.

 

There is quite a lot of useful discussion on line about setting this as policy.....and there is quite a lot of evidence that forcing users to change passwords ends up with users choosing to simply modify passwords numerically - such as password123, password125, password126 - or to rotate passwords depending on the number allowed in the history....

 

Far better to educate users about what makes a good password in the first place....and reminding users never to use the same password for different systems/logons...so that a compromised password does not make several systems vulnerable.

 

...now if you were arguing for 2 factor authentication...I might give some support for that....

 

Those with technical knowledge should not simply and blindly follow instructions...but use that knowledge to challenge whether what is being asked is the correct solution to the problem.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...