Group Policy Processing Aborted When No DC in Subnet - Packet Fragmenting?
-
I'm hoping someone can at least point me in the right direction. I'll try to keep this simple but I can give more details if needed.
Basically, I have almost 30 IPSEC VPN sites connected out of our main office. The main office is running pfSense 1.2.2 to connect all of these sites together. The rest of the environment is primarily Microsoft based. All sites that have a domain controller locally at the office in the same subnet work fine. The problem occurs when there is a site with no domain controllers in the subnet. The users can log on to their domain accounts just fine so authentication to the domain controller at the main site through the VPN is happening, but none of the group policies are being applied. In the Application Event Log I see a series of the following message:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 8/20/2009
Time: 6:47:59 PM
User: NT AUTHORITY\SYSTEM
Computer: ****
Description:
Windows cannot obtain the domain controller name for your computer network. (An unexpected network error occurred. ). Group Policy processing aborted.For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I have read through the link from the Help and Support Center and have tried a few of the options but it has been several months since I've worked on this issue. Does anyone have any experience with this or information to help me determine why this is happening?
-Edited title to reflect relevance to pfSense-
-
Sounds like a DNS issue. Are you certain that your not loggin in to you clients with cached credentials?
–Seth
-
I second Seth's diagnostic - sounds VERY much like you're not actually authenticating in realtime against the DC.
Have you done basic DNS tests from a workstation using a local user account?
-
I agree it does sound like it is not being authenticated or that it is a DNS issue but I don't think it is.
It's not cached credentials because I can take a user that has never logged into the machine before and and they log on successfully. Also, cached credentials are limited to around 10 or 12 logons before re-authenticating with the server and these machines have been out being used for months with no logon problems.
It's not DNS because I can ping and access system shares by name such as \domain.local\SYSVOL. Also if I type "echo %logonserver%" it shows that they logged on to the domain controller from the main site.
Bern, what would using a local account to test DNS do that a domain account would not? Just curious.
-
Have you added your subnets to AD Sites and Services? This will be used to determine in what site the client is located, depending on the site a Domain Controller's ip is returned when resolving you domain name. Make sure your Microsoft windows client subnets are listed and linked in AD S&S.
-
I realize now I should mention why I think this relates to pfSense. When researching this in the past I found:
http://www.servernewsgroups.net/group/microsoft.public.windows.server.active_directory/topic13192.aspx
the first comment on this page refers to fragmented packets being dropped by the VPN http://www.eventid.net/display.asp?eventid=1000&eventno=1441&source=Userenv&phase=1So I have enabled the Clear DF bit instead of dropping rule in Advanced Setup thinking this would solve the problem. I have no option on some of the locations which are still using Linksys VPN routers but on some of them there is the pfSense router on the remote side as well as the main office ("hub" for VPN connections). Does this need to be enabled on both sides to be effective? I'm looking now at the logs on 2 computers at one remote location that has a pfSense box in place and it looks like maybe the GPOs are being applied successfully! I'll try to check another later today.
pakjebakmeel, yes the subnets are added. The subnets for locations that do not have a DC are in the main office "Site" so they will use the DC on the first hop across the VPN.
-
Ok, so maybe it is working at the locations with pfSense at the remote site as well and the Clear DF bit instead of dropping rule set on both sides. I checked another location with a Linksys router at the remote site and the computers there still have the issue. Can anyone confirm that this option is doing what I think it is and needs to be enabled on both sides?
-
Can anyone tell me if it makes sense that this problem would be fixed with that option checked?
Can someone tell me if it needs to be set at both locations? I'm thinking it will only happen on packets leaving the box that has the option set so anything leaving from another VPN endpoint will drop the packets… is that correct?
-
I wanted to let anyone know who is having this issue that having the option Clear DF bit instead of dropping enabled on both sides of the VPN tunnel fixed the problem for me.
There is another fix which I found in my own old documentation I had tried but it only works for the user policies and not computer policies. It has to do with editing the registry.
Hope someone else will find this useful.