Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a user whose password expiration popup won't appear even though he's within the 14 day window configured within his group policy settings. He's running Windows XP Pro Service Pack 3 logging into a Windows 2003 domain. He is wired on the LAN. Even when he logs into the network, confirms that his network connections work fine, logs off (no shutdown or restart), then attempts to log back in, he still never sees the popup. I would think that this would confirm that the network is already fully initialized. If he logs into a remote server, he sees the popup, no problem. It only seems to be an issue with his PC.

Microsoft has stated that this issue was corrected in Windows XP Service Pack 1.

Does anyone know what else I should check?

share|improve this question
    
This might do better on Server Fault. –  ChrisF Feb 1 '10 at 16:17
add comment

migrated from superuser.com Feb 1 '10 at 17:01

This question came from our site for computer enthusiasts and power users.

3 Answers

I've seen this with users who never shut down their machines. I'd try rebooting it and see if it picks it up.

share|improve this answer
    
This user has rebooted his machine and still nothing... –  Mark Feb 1 '10 at 18:00
add comment

Try going to Local Security Settings on his machine, and under Local Policies/Security Options look at the "Interactive Login: Prompt User to Change Password" Setting.
If he is a local admin, maybe he overrode the setting, or GPO did not apply it for some reason. I'm a local Admin on my PC, and it looks like I can change the setting.

Update: Changed the setting to 7 days on my laptop, then restarted the laptop. The setting did NOT revert to the Domain Policy.

share|improve this answer
    
We're not using Group Policy. We've looked at that setting as well and it's set to the default value of 14 days. –  Mark Feb 5 '10 at 20:21
add comment

Here is how it works: With an Active Directory domain, group policies get applied to users, depending on which security group they belong to. You could, for instance, have security groups with different permissions for billers, front desk, IT department, CEOs.
Those group policies get applied to DOMAIN users as well as LOCAL users, but the least restrictive policy is applied.
This means that if a user has been given local admin privileges, then it does not matter what the group policy says he is allowed to do on his own computer. The GPO still controls his access to network resources, but not to the local computer.
The proper way to administer users in an active directory situation is to create groups, assign permissions and users to groups, instead of giving people local admin rights and thereby nullifying any and all hard work done, because that user becomes an edge case which has to be handled separately (by telling him to change his password, or changing the GPO on his computer to specify a password expiration time, which is not the way you want to handle this).

You cannot fix the situation which you have presented without changing the way you think about it. YOU MUST remove his local admin rights and set up a domain-level permission to install and control his machine, which will inherit from the topmost-level GPO which sets the password-changing policy.

This will get you started with group policies, but is by no means sufficient.

share|improve this answer
    
So, essentially, you're saying that I would have to completely restructure my GPO policies to make this work for a handful of users out of 20,000, even though it works for the majority just fine, correct? –  Mark Feb 19 '10 at 13:45
    
If you already have something in place, you just have to add a Group Policy Object which handles the requirements of that handful of users. You can choose which policies do and do not get inherited from above, so you can handle your edge cases on the domain side and get rid of any and all unwanted local behavior. –  Trevoke Feb 19 '10 at 14:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.