Weird Group Policy Issue

markulous

So I've got a single forest using 2012 R2 functional domain. I inherited this environment so this is the first time I've created any GPOs for this domain. We are using terminal servers, so the ultimate reason I had to create this GPO was to restrict users. Right now they login onto the 2012 R2 TS and they've got access to Powershell, cmd, admin tools, all kinds of bad stuff, etc. The policy was created easily enough, I applied it to that OU where the users reside (they were all User Config GPOs) and everything looked good. It was link enabled, no exclamation marks anywhere, nothing blocking inheritance, etc. Well I login as that user (or create a test user) and nothing is different. I run a gpresult and nowhere to be found is any mention of that GPO (in applied or denied).

I tried logging onto another TS to rule that out and it behaves the same way. I created a test policy that's obviously much less restrictive. If I apply it to that same departmental OU as the other one, it won't apply. If I apply it to the entire User OU, it again will not apply. Now if I apply it to the entire domain, it will actually apply.

I checked replication between the 3 DCs using repadmin and everything looked fine. I looked at the SYSVOL folder on all of the DCs and the GPO is being created there on all of them.

Any ideas? I'm going to have to call MS Support if not.

PJ_Sneakers

The GPO's get applied to computers, not users. So linking it to the user OU doesn't do anything to the users. Probably the reason it works when you apply to the entire domain, is most likely because it is applying all the way down to your TS servers.

This link might be able to help: https://www.petri.com/forums/forum/microsoft-networking-services/terminal-services/7434-group-policy-only-on-terminal-server?t=7184

markulous

They are user configurations though, not computer configurations. In my other environment I have almost the same setup and it's only linked to the users GPO and it works. Won't that also lock anyone else logging in there and not just the end-users?

PJ_Sneakers

Oh I gotcha. Hmm. Is the OU marked to block inheritance?

If all else fails you can use security filtering to deny the exceptioned groups access to the GPO, which would effectively exempt them from getting it applied when they log on.

markulous

As a test I actually tried applying it to the OU of the TS but it wasn't enforcing there either.

Nope, inheritance isn't blocked. Do you mean apply it at the domain level but then just use security filtering to take away authenticated users and only add the users security group for that OU?

PJ_Sneakers

Well you will always need authenticated users to have access. It would be the other way way around, more like a blacklist of user groups.

Edit: also, have you run rsop yet?

PJ_Sneakers

Any loopback policies?

markulous

I ran RSOP but didn't see any issues.

I didn't see any loop back policies. It seems like a pretty standard setup and not a ton of policies created.

I also tried turning off ESET in case the firewall for some strange reason was blocking them.

I suppose as a last resort I could do explicit denies on all other users but that seems like a really wonky setup lol

markulous

Just realized they don't have any MS support so this won't go over well. They already think I don't know what I'm doing since I get the blame lol.

I wonder if it's these terminal servers. Only other thing I can think is try to login to some other kind of box and/or try to create a fresh OU outside of this Users OU and see if that works. Otherwise they'll have to pay for MS support or I should be gone within a month that the next poor sap can fix it.

instant000

I wouldn't advocate leaving it for the next chap ....

I saw a case where something wasn't working as expected similarly.

You may need to do your gpresult, and double-check everything, and make sure there isn't another policy being applied (that conflicts with the setting that you are trying to change) .... To experiment, you could disable policies one by one, do an update, then test to see if you can locate the conflicting policy.

Once it's located, dig through with a fine-toothed comb, and you should be able to spot the conflict.

Hope this helps!

markulous

Gpresult isn't showing anything but that's not a bad idea disabling policies one by one either.

I'll try my best but there will unfortunately be quite a bit of stuff for the next guy due to staffing issues.

PJ_Sneakers

Make a testing OU. Disable inheritance on it, and then link and test policies on it one by one.

markulous

Wow, something is really jacked. This makes no sense. I disabled inheritance and during a maintenance window I even disabled the default domain policy for a short while and it still won't show the policy anywhere (RSOP or gpresult). I tried logging into another server as the user and it did the same thing. I really don't know at this point what the reason is.

PJ_Sneakers

What happens if you put the user in the test OU and only link the new GPO to it?

markulous

Yep I tried that when I toggled the default domain policy. Still no go

PJ_Sneakers

Maybe the file or share permissions on SYSVOL are jacked?

markulous

That could be. I can take a look at that. I don't think the previous guy would have screwed with NTFS or share permissions on SYSVOL, but it's worth checking.

On a side note, I got a pretty funny +1 rep for this thread saying "who cares, just bounce"

blargoe

I ran into a weird GP issue like this one time that turned out to be related to a domain controller that my grossly coworker improperly cloned from the hard drives of another domain controller. SYSVOL replication stopped working and hadn't worked for months, but we didn't catch it until we started making GPO changes one day. So most of the domain controllers didn't even have the GPO in its store because of this.

If you are running domain controllers that were cloned, P2V, you might be having the same issue. Or sysvol replication could be broken for some other reason. Look for errors in your AD logs, FRS, etc.

markulous

The new group policy actually replicated to all 3 domain controllers, although now that I think about it the amount of SID folders in there didn't match from DC1 to DC3. There's gotta be something with replication or some weird GP/setting applied to the domain controllers.

I don't know if he cloned them. They're all on a Hyper-V but they were setup months before I got here.

markulous

I'm a dummy

There actually was one policy that had a loopback on it that I must have missed (I checked them all initially). Once I took that off the user policies started applying.

Now I have to figure out why the terminal servers won't accept certificates from Microsoft or Google (but some other HTTPS sites are fine). Wouldn't be too big of an issue except Office won't pass the security tokens for the end-users.