I had a couple of follow up questions relating to the XP-SP2 security technologies presentation I did on November 30th that relate to how workstations determine when to flip from Domain profile to Standard profile and back again when required. This was a little too deep for the session itself, so I decided to post the information up here.
A really good question came from DavidF from Industry Canada. He asked if the workstation queried GCs (global catalog servers) or DCs (Domain Controllers) to determine the appropriate profile and what would happen in a multiple domain environment in a forest - with different DNS name spaces. It is actually simpler then a custom query and does not rely on network connectivity at the time. Lets take a look at the following scenarios:
I have a managed laptop that is part of the Corp network. I login to corp.example.com and get group policy applied to my system (this could even be a basic domain policy with no additional settings). An entry is put into my registry that indicates that the GPO came from the corp.example.com. My connection specific DHCP managed IP address while at work has a DNS suffix of corp.example.com. The two pieces of info are compared. If they match, I am switched to domain profile. If they don’t – I am in standard profile. Sound easy? Read on.
The next step is if I use my wireless laptop while I am at home or a hotspot suckin’ back some Java (and I don’t mean J2EE). What profile state am I in? My registry will say I last got a GPO from corp.example.com. My internet connection at the hotspot says hotspot.bridgehead.ca. They are compared and result in a miss-match. Because of that – I do NOT get domain profile status, but standard status instead.
The next level of complexity is when I travel with my laptop. I go to our European office with a DNS suffix of eu.example.com. – how does it work now? If it was a complete boot process, my system and I would have authenticated to the domain in the forest. Based on the group policy update interval, I could have my registry reflecting either corp.example.com or eu.example.com. For now lets say my registry entry for the last GPO application says corp.example.com (a different DNS namespace in the example.com DNS hierarchy). My connection specific DNS suffix says eu.example.ca. - they don’t match so I go into standard mode, even though I am in a managed network. But don’t worry – because I am in the managed network, I am still able to get my GPO updates and my registry will eventually reflect that I got an update while connected with eu.example.com. Once this takes place – I will switch to the domain profile.
So as you can see, multiple domain forests with different names spaces don’t throw a wrench into the mix. What does is a manually applied connection specific DNS suffix at the client. Why? Don’t forget DHCP settings are overridden by Manual entries. If you hard code your connection specific DNS suffix to be corp.example.com then I will still be using the domain profile no matter where I am - having that second cup of Java at the café or working in the Europe office. This can be good or bad – What entries for ports and applications are open in the domain profile vs the standard profile?
I don’t know… You created the profiles with adequate planning and testing, didn’t you? < g >
If you would like some more in depth information on this, check out The Cable Guy on Microsoft.com TechNet site. http://www.microsoft.com/technet/community/columns/cableguy/cg0504.mspx