Solved

Computer Picking Up Old GPO from Server

Posted on 2014-04-08
8
1,418 Views
Last Modified: 2014-04-17
Hello.  I was having problems logging into machines with any domain user account.  I needed to explicitly add a domain user to a machine before that user could log in.  

I adjusted an old Default Domain Policy so that the setting for "Allow log on locally" is for Domain Users, Domain Admins and local Admins.  (It was lacking the "Domain Users" group and I believe this is what was creating this situation)

At first, this setting seemed work and I could go to a machine and domain users could log in no problem.  Then, it seemed to be randomly, it stopped working.  When I checked the GPO on the server, the policy was still the adjusted one.  However, when logging in locally, I noticed the local security policy had reverted back to the old one and disallowed domain users to log in without being added explicitly.  

I have researched this ad nauseum and have not gotten too far with this.  I have removed and rejoined the domain, I have tried to create a new default domain policy etc... I have looked into the registry but don't understand too much about that, hoping there was a way to change a setting or find the old policy and destroy it.  

Client is Windows 7 and Server 2008 R2.  Any other ideas?
0
Comment
Question by:jaxjags
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
8 Comments
 
LVL 16

Expert Comment

by:Raymond Peng
ID: 39987495
On the client machine can you run RSOP to see what GPOs are in effect?
Please also open cmd > gpresult /h and it will output to an html file.  Check what groups / gpos the user is in and applied.

Is it only applying to this user or all users?  If it's just one, try removing them from all groups and OU for testing purposes.
0
 

Author Comment

by:jaxjags
ID: 39991904
Thanks.  I ran the RSOP on the machine and it says it is getting the default domain policy and that html file reflects that change!  However, when I go to "local security policy" it shows the old GPO and still behaves according to that old GPO.

It happens to any user I try to log in with... any domain user is locked out, except domain admins which is on the old GPO as permitted any way.

Now I think I'm more confused!
0
 
LVL 16

Expert Comment

by:Raymond Peng
ID: 39992267
Just to confirm - you're applying to an OU with computers?

I would try creating a test OU and have 2 test pcs in there.  Link only the policy you want to test to it. Run gpupdate / force and see what it picks up.
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 

Author Comment

by:jaxjags
ID: 39994362
Thanks.  Yes I am apply to OU with computers.  It is inherited via the Default Domain Policy.  I also went ahead and tried to link directly even though I shouldn't need to.  By adding the "Users" group it worked... for a few hours.  By the time I signed back in the next morning, it once again reverted back to the old domain settings and said I can't log in using this method.  When running RSOP it says it's getting settings from default domain policy but these are NOT the settings on the server.  

Is there any way to find some rogue, old copy of the default domain GPO?  

What's even more confusing, is that I am testing this on two PCs.  The one I am speaking about and another one that IS picking up the new Domain Policy and HOLDING those settings without reverting back... perhaps this is a clue?
0
 

Author Comment

by:jaxjags
ID: 39994376
Check that last paragraph... now the same condition is happening to both machines in that OU.  Even if I move the machines to a different OU, it picks them up.
0
 
LVL 16

Accepted Solution

by:
Raymond Peng earned 500 total points
ID: 39994574
Try the following

Source:

http://community.spiceworks.com/how_to/show/27566-old-gpo-still-applying

1.      
Disconnect PC from the domain
Start --> run (Windows key + r ) --> sysdm.cpl --> Change --> select 'workgroup' button and type 'workgroup' in the field below.
Click OK --> Enter domain admin credentials --> Click OK
Click 'OK' --> Click 'OK'--> Click 'Close' --> Click 'Reboot Now'

2.      
Delete C:\WINDOWS\security\Database\secedit.sdb
"Deleting this file, completley trashes the group policies on the PC and forces a brand new refresh from the domain controller" - AndrewRead

This can also be done via command line:
Delete C:\WINDOWS\security\Database\secedit.sdb

Exercise caution when operating from the command line as misspelling or changing the ordering of your command can have unintended consequences

3.      
Reboot the computer
4.      
Join the computer to the domain
Start --> run (Windows key + r ) --> sysdm.cpl --> Change --> select 'Domain' button and type the Fully Qualified Domain Name (FQDN) in the field below.
Click OK --> Enter domain admin credentials --> Click OK
Click 'OK' --> Click 'OK'--> Click 'Close' --> Click 'Reboot Now'

5.      
GPUpdate /force /boot
This need to be run from either the run box or cmd.exe
1). Start --> run (Windows key + r ) --> gpupdate /force /boot
or
2). Start --> run (Windows key + r ) --> cmd --> OK --> gpupdate /force /boot

This command will force the computer to get any GPO's, that are applicable, from the Domain Controller and will rebuild the secedit.sdb database. Your computer should also reboot if it has any GPO's that only run when the PC starts up.
0
 

Author Comment

by:jaxjags
ID: 40002368
Thank you for that guidance.  Unfortunately, the domain policy applies but over night it reapplies the old one again.  So stuck at the same spot.
0
 

Author Closing Comment

by:jaxjags
ID: 40007431
These were all great steps to take to resolve this issue.  Unfortunately, the true issue was found in the Replication Log on the domain controller.  It was stuck in an error state and was not working properly.  I had Microsoft find that and fix it for a fee.

Event ID: 13568  "JRNL_WRAP_ERROR"

http://social.technet.microsoft.com/Forums/en-US/d88385dd-ba83-43d4-8bc7-85e15aa1ae58/event-id-13568
0

Featured Post

Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Suggested Courses

635 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question