Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Group Policies - Permission to Change Password 1

Status
Not open for further replies.

Stevehewitt

IS-IT--Management
Jun 7, 2001
2,075
GB
Hey,

I have spent days working on this problem, and I just cannot fix it! Please help!! :) :

In the last few month user have not been able to change their password when they are made to by the system. ("User must change password at next logon", the change password every "X" days etc.). When they try to the system saids that they do not have permission to change. This is wrong! There is no tick in the box of the users saying they cannot change their password, and as far as I am aware there is no Group Policy that stops this.

I have created a new user, in a new OU which blocks policy inheritance. Same problem.

Any ideas?

Cheers,

Steve Hewitt
Systems Manager
 
Also, when the system doesn't ask them to do it, the user can change the password! E.G. If they go Ctrl - Alt - Del and click Change Password they can, but if they log on and the system says they have to change they're password before they logon to the network then they cannot change it!

Thanks,

Steve Hewitt
Systems Manager
 
How about admin, can they change their password when they logon? The block policy is ineffective if it has been prevented at a higher level (so don't count on it for your OU in this case). Maybe you should run the security and analysis tool to see what you have versus what you want. Is this the root domain? You have got to play with Group Policy some more. This is GP related from what I can see. I you running in mixed mode or multi platform? There are many variables to be considered.


MCP 2000
 
Its a Win2k Server network and clients run XP Pro and Win2k Pro. The admin can change password no probs, just not users. The analysis tool - where can I find it? Its the OU below the Domain.

Cheers,

Steve Hewitt
Systems Manager
 
The security configuration and analysis tool can be found within the mmc. It seem like you are the admin for a department or branch of a company. From your last post you indicated that it's an OU bellow the domain that you are having problems with. I will think that at the domain level, the senior admin have set policies so that you can't override them. For example, at the domain level, a policy could be in place that allow users to change their password every 60 days. Also the domain admin could check the box that prevent OUs admins from blocking policy. What could be happening is that at the OU level the policy is to change password every 30 days. Knowing that the OU policy is applied last, users are prompted to change their password. When they try, the attempt will fail because the domain admin has prevented the OU admin ability to chage group policies that are set at the domain level. In this case, I will talk to the domain admin or if you are the domain admin look at the conflicts between the domian policies and the OU policies.

MCP 2000
 
Hey,

No, I'm the Admin for the entire Domain, but I have a seperate OU for the normal Domain Users. I will use the analysis tool - thanks.

Cheers. Have a Star! ;-)


Steve.
 
Some policies only work properly when they are applied at the domain level. I beleive account policies and IPSec are two of these.
 
Creating a new USER in a new ou will not help you test this problem. Password policies you will notice come under the COMPUTER section of GPOs. I am almost certain that it is only at domain controller level that these policies apply, so only domain level and DC OU policies will affect your password policies.

As for the IPsec policies mentioned by the other chap, I have them running to prevent terminal service use, and have respond only on the client PCs and the preventative measures enabled both on servers and DCs.

Hope to have helped.
 
Hi again,

I have checked the domain policy. I've even reset it so that all values are either not configured (e.g. password renewal) or disabled (complexitity).

Still hasn't worked. This test user is not in a OU and now directly below the domain GPO.

Any more ideas? This has really baffled me!

Thanks,

Steve.
 
Have you tried creating a new policy and setting it as the default policy and deleting the old policy?

MCP 2000
 
No I haven't. It would be a big problem as users policies would be screwed! I may try it at a weekend. Thanks for the suggestion though, I didn't think of that.

Steve Hewitt
Systems Manager
 
Maybe I should have told you about the gpmc before. Download it from Why you at it, read up on some of the features of the group policy management console. One of those feature is the ability to backup and restore policies. So now you don't have to worry about schewing up users access. If the new policy is give you problem, you can simply restore the old policy in a matter of seconds. I can't list here the many powerful features of gpmc. Checkout the q&a session at the microsoft address I provided.

MCP 2000
 
HEY!

I'VE FIXED IT!

The problem is actually a Win2k / XP bug! MS Product Support basically said that if the Win2k Server has a DWORD value for RestrictAnnoymous to 2, then you will get this problem on XP clients. There are 2 solutions:

1. Change the DWORD value to 1 or 0. This didn't work for me as I had to restart the server, and as soon as someone logged onto the server the DWORD got changed back to 2 - so I deleted it! :)

2. Phone up MS, shout and scream until they give you Hotfix Q328817 which will be included as part of WinXP SP2. I would demand it, and becuase its a fault in WinXP it should also be free.

Good Luck,


Steve.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top