0

I am having a situation where I need to restrict the user access to change their password in Active Directory (Windows Server 2008 Standard) environment. What I need is to check the Account Options where:

  1. User Cannot Change Password
  2. Password Never Expire

Are there the best way to enforce this policy through Group Policy?

For User cannot change password, I am thinking to do this by disable the Ctrl + Ald + Del from the Group Policy (User Configuration -> Administrative Templates -> System).

Please any thought would be very helpfull.

Many thanks in advance.

2 Answers 2

1

Configure your domain's password policy with a "Maximum password age" of 0 days (unlimited - effectively a global "never expire") and a "Minimum password age" of 998 days (the maximum).

The users will be able to change their passwords after they're 2.7 years old - if that's an issue, then put a to-do item on your calendar for July of 2014 to move the date of their pwdLastSet attribute up manually.

2
  • Thanks Shane for the advice. I will try to apply this to Users Group Policy.
    – Arief
    Feb 19, 2012 at 9:30
  • @Arief That will not work. Only one password policy is applied to the domain through GPO - if you need to have multiple different policies present for different subsets of your users, then you need to utilize fine-grained password policies. Feb 19, 2012 at 18:57
1
  1. Do you want to apply this to all users (this will include your own account)?
  2. There are command line ways to change your own password, blocking ctrl-alt-del will not stop these.

So the real question: why do you want to restrict these accounts? There are probably better approaches.

(Those account options are what you need: why not just set them?)


Based on comment: I would expect a Group Policy applied to the users' OU would be the simplest approach. Ensure users who are exempted are in a separate OU. However password policy is part of Computer Configuration so applies to computers not users. Therefore I expect it won't work unless the two groups of users never use the same computers.

Putting the target users in their own OUs would allow scripting to iterate through all users and ensure these two options are selected (this script could be scheduled). There are lots of examples of scripts to modify all users in an OU (eg. this one). This leaves the initial creation of users: either create from a template user (via copy in the AD tools) or this could also be scripted.

Overall this is a policy which goes against all good practice (changing passwords ensures leaked knowledge of passwords is invalidated), so you'll have to do some extra work to swim against the tide.

4
  • Hi Richard, this is the management decision and of course this is not applied to IT Department. At this stage what I have done was applying through Account Options. I am looking for better solutions as the company at the moment grow pretty good. I do not want to apply this setting to hundreds of users.
    – Arief
    Feb 19, 2012 at 9:32
  • @Arief updated the answer.
    – Richard
    Feb 19, 2012 at 9:52
  • first of all, allow me to apologise for not responding yours in the reasonable time mannger. Also, thank you so much for you prompt response on this. I know that Password Policy need to be aplied to Computers. The thing that I don't understand, why you are expecting that it won't work unless the 2 groups of users never use the same computers. Are you talking about the 2 groups in the seperate OU? In regards to all good practicesm I did brought in the top management meeting that this is not good practices and from the legal side as well.
    – Arief
    Mar 6, 2012 at 22:30
  • @Arief As I understand it computer policy applies to all users of that computer, but then if two different users bring different computer GP (eg. via policies attached to users in different OUs) how will the conflicting policies combine? In the case of remote connections the two users could be logged on at the same time. At the very least testing would be required, but it does seem that this would not be a reliable approach. Better to solve at source by automate setting the right flags on the AD user objects.
    – Richard
    Mar 7, 2012 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .