When I was younger, I heard a phrase “The cobbler’s children have no shoes” and similar things which implied that frequently, people within a particular industry are less likely to want to utilize their skills as home when they’re not working.    I was reminded of this a few weeks ago while I was on vacation.   I logged onto my work computer and noticed that I was unable to connect to work via DirectAccess.   Upon further investigation, I noticed that the IP Helper Service wasn’t running and that there did not appear to be any settings for DirectAccess present on the computer.  

“No Problem,” I thought, I’ll just connect via VPN, run “klist –li 0x3e7 purge” to flush my computer’s Kerberos tokens, and refresh GPOs via “gpupdate /force”.   Instead of success, I see the following:

Since I was able to accomplish what I needed over VPN and wanted to get back to not working, I decided to just leave the computer connected over VPN, cross my fingers, and look back on it in a few days.   Things always work better after being left alone, right?   The next day, I rebooted and tried again, but saw the same message.   This left me with a difficult decision, spend vacation time troubleshooting my own computer, or turn it off and deal with it later.   I turned it off.

A few days later, I powered on the computer again and found that things hadn’t changed yet.   I connected via VPN and tried another “GPUPDATE /force”, and found that things were still no different.   This time I had some time that I could spend on troubleshooting the problem and decided to take a look.   In the Event Logs, I see an SCECLI 1704 telling me that the GPOs applied successfully.  

Frustrated that I’m getting an error in one window while another tells me that everything is fine, I do what anyone troubleshooting while on vacation does…I powered off the computer and went back to not working.

A couple of days later, I powered on the laptop and found the symptoms had not yet changed.   This time, I decided that I needed to fix the problem.   I opened up a browser and went to bing.com so that I could do a search for the error.   Between the first three results, I was able to find my solution.   I found two hits to TechNet articles which described the same message, but had a variable listed where mine had “LocalGPO”, and I also did not have the event log entries that they referred to.   Those entries were:

http://technet.microsoft.com/en-us/library/dd392577(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/dd392529(WS.10).aspx

The other link was more helpful and contained the exact error, including that the problem was with “LocalGPO”.   That post was: 

It directed me to the file registry.pol under C:\Windows\System32\GroupPolicy.    I looked into that directory and found the following:

Since I was using an elevated command prompt, I tried a rename of the registry.pol file followed by re-applying of the GPOs:

Finally, the GPOs applied successfully.   I was then able to start the IP Helper service and it stayed running.   I looked and saw that my computer was now connected to work via DirectAccess. 

So after trying the tried and true troubleshooting techniques of rebooting and ignoring the problem, I was finally able to do a web search and had my answer in just a few minutes.  Maybe I should have started with that.   Maybe next time.   But spending time troubleshooting computers at home, even work computers, is just not how I wanted to spend my time-off.   The old adage is true:   The Cobbler’s children have no shoes.

This week I was onsite with a customer performing a visit called the Risk and Health Assessment Program for Active Directory (ADRAP).   Within the ADRAP, we collect data on many aspects of their Active Directory environment and discuss a wide variety of topics.   One of the things that we look at is the membership of the various Built-In administrative groups which exist within an Active Directory domain.   One of the conversations which I nearly always am having with customers as we discuss their members of these groups are what sorts of strategies that they can leverage to reduce the number of members in groups such as Administrators and Domain Admins and being able to delegate the permissions that classes of users need when possible instead of placing them into groups which grant them more rights and privileges than they actually need to perform their functions.   This holds as true of accounts which are used by flesh-and-blood users as it is with Service Accounts.   We discuss that if accounts need to be part of the local group Administrators on a subset of machines, don’t place those accounts into Domain Admins, leverage Group Policy Preferences to add it to the local group Administrators and target the GPO to the desired subset of machines.   We discuss delegating specific rights within Active Directory as necessary, and a variety of other strategies that they can leverage in order for accounts to have the rights and privileges required for them to function without giving them additional rights or paths to escalation.   We will discuss the rights granted to the Default Built-In Groups and how and when those can and should be leveraged.

With this particular customer, they have a need for the users who work within their Network Operations Center (NOC) to be able to handle that front-line sorts of tasks of the end-users within the environment.   This includes tasks such as unlocking accounts, changing passwords, joining computers to the domain, etc.   One of the steps that they took to provide these users the rights that they needed was to leverage the built-in group Account Operators.   They also have a need for users in the NOC to be able to perform these same functions against their peers.   What they discovered was that while membership in Account Operators met their needs for being able to manage the general end-users, it did not, however, meet their need of being able to manage their peers.   They also recognized that they would have benefits if the NOC could unlock the accounts of Domain Admins when those users locked themselves out.   (As happens in many customers, they admittedly have more accounts in the Domain Admins group than they would prefer and some of these accounts are only periodically used and the users with those accounts do not always remember their password.)    Their solution to these shortcomings of the Account Operators group was one faced by many customers, and generally not considered an optimal solution; they added the accounts of the NOC Leads to the Domain Admins group.   Let’s put that another way, in order to be able to manage the accounts which they’d prefer to have not put into the Domain Admins group in the first place, they put more accounts into the Domain Admins group.   If this sounds familiar to you, it is likely because you’ve either seen or worked in an environment where this same decision was made, or know someone who has.  (No judgments from me about this sort of situation, I’ve worked in places with even worse reasoning for putting massive numbers of accounts into Domain Admins.)

We decided to break their two requirements into each part and look at them individually.  There is a common component to both aspects, but we addressed them as separate parts.

First we looked into why the people in their NOC were unable to manage their coworker’s accounts.   This is because these accounts had transitive membership into the built-in group Account Operators.   It was the membership in the Account Operators group which caused the SDProp process to run for these accounts and remove the inheritance which would have normally allowed Account Operators to manage user accounts.   But without the inheritance, they could not manage their peers and it was because of this that their NOC Leads were added into Domain Admins.   We discussed SDProp and AdminSDHolder and they decided that to meet their business need of having these accounts be able to manage each other when required, we would leverage the dsHeuristics attribute to exclude Account Operators from AdminSDHolder.   We leveraged KB 817433 as our guide and set dsHeuristics to a value of 0000000001000001.  This excluded the accounts from the SDProp thread setting their ACE to match that of AdminSDHolder every time the thread runs on the PDC Emulator.   We then had to set the adminCount attribute of the accounts from 1 to 0 (Zero) so that SDProp would stop running for the accounts, and then finally re-enable inheritance on the accounts.   This we did in their test forest with some test accounts, but the process will be repeatable for them in their production forest.   We were then able to verify that these accounts with membership in Account Operators could now manage each other, but had no rights for any of the other protected groups (such as Domain Admins).

Before we move onto the second half of our solution, I want to share some links and references to the words SDProp, AdminSDHolder, and dsHeuristics which I so casually threw around in that previous paragraph.  

Five common questions about AdminSdHolder and SDProp
http://blogs.technet.com/b/askds/archive/2009/05/07/five-common-questions-about-adminsdholder-and-sdprop.aspx

adminCount, adminSDHolder, SDProp and you!
http://theessentialexchange.com/blogs/michael/archive/2008/10/22/admincount-adminsdholder-sdprop-and-you.aspx

Delegated permissions are not available and inheritance is automatically disabled
http://support.microsoft.com/kb/817433

AdminSDHolder, Protected Groups and SDPROP
http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

Description and Update of the Active Directory AdminSDHolder Object
http://support.microsoft.com/kb/232199

AdminSDHolder Thread Affects Transitive Members of Distribution Groups
http://support.microsoft.com/kb/318180

DS-Heuristics attribute
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675656(v=vs.85).aspx

Default groups
http://technet.microsoft.com/en-us/library/cc756898(v=WS.10).aspx

After that bit of fun reading, we then started to look at their second business requirement.   They wanted the staff of their NOC (who are members of Account Operators) to have the ability to unlock the accounts of Domain Admins should these people find themselves needing such a task performed.   This was the last reason why their NOC Leads were members of Domain Admins.   We looked at KB 279723 for guidance and used the following command to grant the Unlock right to the AdminSDHolder object so that the SDProp process would set it onto the members of Domain Admins (and the other protected groups):

dsacls "CN=AdminSDHolder,CN=System,dc=corp,dc=contoso,dc=com" /I:T /G "domain\GroupNameForNOCUsers":rpwp;lockoutTime

We couldn’t use the Account Operators group in that dsacls command, so we used the group of their NOC Users which was nested within it.   At this point, once SDProp ran again, the users could then unlock the Domain Admins but could do no other management tasks for these accounts.   This met their needs and allowed us to remove their NOC Leads from the Domain Admins group.

How to grant help-desk personnel the specific right to unlock locked user accounts
http://support.microsoft.com/kb/279723

The customer was then able to begin looking at the other accounts within the Domain Admins group and begin to plan out ways to delegate the required rights so that many of those accounts could be removed as well.

(NOTE: IP Addresses changed to protect the innocent)

I was onsite with a customer recently who asked me a question:

“What is 2002:836b:0F1E::836b:0F1E and why am I seeing it?”

I explained that this is a 6to4 address and is automatically assigned to the client because they use a globally routable IPv4 range for their IPv4 address range. I pull up calc.exe and in a couple of moments ask if the IPv4 address of his system was 131.107.15.30. After having a brief shocked look, his response was:

“But wait, I’ve looked at KB 929852 and it says that I can disable IPv6 by unchecking the checkbox for IPv6 on the properties of the NIC. So why am I seeing an IPv6 address?”

“Of course,” I say, “but how close did you read 929852?” We pull up the KB and look at the start of the “More Information” section (included below):

IPv6 can be disabled either through the DisabledComponents registry value or through the check box for the Internet Protocol Version 6 (TCP/IPv6) component in the list of items on the Networking tab for the properties of connections in the Network Connections folder. The following figure shows an example.



The DisabledComponents registry key affects all interfaces on the host. However, the check box on the Networking tab affects only the specific interface. The DisabledComponents registry value does not affect the state of the check box. Therefore, even if the DisabledComponents registry key is set to disable IPv6, the check box in the Networking tab for each interface can still be checked. This is expected behavior.

There is one very fine point often overlooked in that second paragraph, it is the second sentence: “However, the check box on the Networking tab affects only the specific interface.” (emphasis mine) What is meant by “affects only the specific interface” is exactly what it says, it unbinds IPv6 from ONLY that particular interface, leaving IPv6 enabled within the IP stack. The result of this is that for systems with a non-Private IPv4 address, a 6to4 address will still be assigned to the system. It also means that other aspects of IPv6 are still enabled and running within the system.

So if your end goal of clearing the checkbox was to disable IPv6 across the entire system, you did not meet your goal. Don’t believe me? Run “netstat –ano” from an elevated command prompt and you’ll see your system listening to the unspecified IPv6 address (::). If you insist that you must disable IPv6, use the DisabledComponents registry key as defined in KB 929852. However, as the KB article says, “We (Microsoft) do not recommend disabling IPv6.”

After this discussion as to why he needed to use DisabledComponents instead of just clearing the checkbox, he asks me how I knew what his IP address was. I explained that the 6to4 address is of the format 2002:WWXX:YYZZ::WWXX:YYZZ where WW, XX, YY, ZZ are the hex representations of the octets of his IPv4 address. We looked back at calc.exe and changed it to “Programmer” under the View menu. This allows us to select Hex and enter 8b, clicking on the Decimal (Dec) radio button displays that the decimal value of 0x83 is 131. Repeating this, we determined that 0x6b is 107, 0F is 15, and 0x1E is 30. So 131.107.15.30 would be 2002:836B:0F1E::836B:0F1E.

This got us back to the discussions about how they can prevent 6to4 Addresses from being generated on their systems. There are 4 methods which could be used to disable IPv6 on their systems: The DisabledComponents key with a value of 0x1, The DisabledComponents key with a value of 0xffffffff, Group Policy, or manually via use of the netsh command. We discussed the pros & cons of these methods. Setting DisabledComponents to 0x1 will disable all tunneling adapters (ISATAP, 6to4, Teredo, IP-HTTPS) on the system, but leave the system capable of leveraging Native IPv6 addressing once they begin deploying it within their infrastructure; setting DisabledComponents to a value of 0xffffffff will disable all of IPv6 on the systems (except for the loopback adapter), but will have to be changed to 0x1 or deleted when they begin an IPv6 deployment within their infrastructure; Group Policy allows for any of the tunneling adapters to be disabled independent of the others and provides the most flexibility for the future of their infrastructure; Utilizing netsh to disable 6to4 would be a manual process which would not easily scale across multiple systems and would be a manual process to re-enable in the future.

We setup a GPO so that they could begin testing the behavior of their systems with 6to4 being disabled via GPO. The setting we defined in the GPO was “6to4 State” with a value of “Disabled”. We then re-selected the IPv6 checkbox on the properties of the NIC on the system we targeted the GPO to. The setting was located under:

Computer Configuration –> Policies –> Administrative Settings –> Network –> TCPIP Settings –> IPv6 Transition Technologies

As illustrated above, the state of the other Transition Technologies can also be controlled via GPO.

After this GPO applied to the computer, the computer was behaving as they had originally intended them to be behaving; there was no 6to4 Address present. Because we had replaced the IPv6 checkbox on the properties of the NIC, the system did have a Link Local Address (one which begins FE80::/64), but these are not routable addresses and do not register in DNS.

If you MUST insist on disabling portions or all of IPv6, consider either using Group Policy to disable the individual Transition Technologies which you wish to have disabled or leverage a value of 0x1 for the DisabledComponents key to disable all Transition Technologies. NOTE: Avoid deploying a value of 0x1 to mobile workstations if they will be leveraging DirectAccess as this will prevent them from having the ability to connect to the DirectAccess server as they would have leveraged these tunneling mechanisms for that connection; if it is only the 6to4 Addresses which are of a concern while on the corporate network, then disable only these adapters via GPO to these clients so that they can still leverage ISATAP, Teredo, and IP-HTTPS to connect to DirectAccess. If you MUST insist on disabling ALL of IPv6, then use 0xffffffff for DisabledComponents; the same caveat for mobile workstations attempting to leverage DirectAccess applies here as well.

The customer then asked me what can they do to prevent visiting computers which are on their network from being able to connect to DirectAccess servers from their own networks. We discussed how the connections to a DirectAccess server will connect to their own DirectAccess server via IPv6 and that they would require either a Native IPv6 address or a Transition Address to connect to their DirectAccess infrastructure. Since the customer’s network isn’t yet providing Native IPv6 addresses, they only have to worry about people leveraging Transition Technologies. Both ISATAP and 6to4 utilize IP Protocol 41 to encapsulate the IPv6 packets as payload of the IPv4 packets, so blocking outbound IP Protocol 41 at their network egress points will prevent ISATAP and 6to4 connections originating from their network. Teredo utilize UDP packets at port 3544, so blocking outbound UDP 3544 packets will block Teredo traffic from originating from their network. IP-HTTPS encapsulates the IPv6 packet as SSL encrypted payload of HTTPS packets (port 443), since their network allows for unfiltered outbound SSL traffic, IP-HTTPS connections could originate from their network. We discussed utilizing things such as either a separate VLAN for guests/vendors which doesn’t route to the corporate network and leveraging IPsec within their corporate network to provide domain isolation as some possible methods of protecting the internal network from unmanaged computers (but that sort of planning is another topic for another day).

Before I left, the customer asked me how they’ll be able to re-check the IPv6 checkbox on their systems once they’ve deployed a GPO with their desired settings for IPv6. This was one of those times when I did not have good news to give a customer. There is no programmatic way that I know of to directly determine the value of the checkbox and no programmatic way to toggle the value of the checkbox. They will be manually placing the checkbox back over time as they connect to systems and update their system images to no longer have the checkbox unchecked.

While I did include this link on one of my previous posts, I’m including it again because I’ve seen many questions asking about Microsoft products and their support for IPv6. Here is the link to the Common Engineering Criteria:

Microsoft Common Engineering Criteria Overview
http://www.microsoft.com/CEC/en/us/cec-overview.aspx#data-ipv6

Microsoft Common Engineering Criteria Scorecards (IPv6 Support is under "Data Center and Enterprise Readiness")
http://www.microsoft.com/CEC/en/us/cec-scorecards.aspx?display=tech#

As someone who works with computers, I’m often getting calls from my family and friends asking me to clean viruses off of their computers.    Generally, they’ve avoided my earlier encouragement to install Microsoft Security Essentials and now they find themselves dealing with computers that are not behaving as they should (they also ignore my other encouragements about using “In-Private Browsing” in IE8 & IE9 to browse to sites that are questionable, not running attachments, etc.).   So for this reason, I keep a DART CD (Diagnostics and Recovery Toolkit) from MDOP (Microsoft Desktop Optimization Pack) so that I can run Microsoft Standalone System Sweeper.

Well, starting today, my life should become a lot easier.   A beta of a standalone version of System Sweeper was available here:  http://connect.microsoft.com/systemsweeper and is now available here:   http://windows.microsoft.com/en-US/windows/what-is-windows-defender-offline    In conjunction with Microsoft Safety Scanner (which released last month) from http://www.microsoft.com/security/scanner/en-us/default.aspx, I’ve now got places to point people that hopefully means I won’t have to head over to as many houses.

I ran across this info when an e-mail at work referenced a ZDNet posting about the release of the beta of System Sweeper.

In my mind, the cool thing about our AV products is that they all share the same AV engine, be it Windows Defender, Microsoft Malicious Software Removal Tool, Windows Live OneCare (retired), Forefront Client Security, Forefront Endpoint Protection, the MS AV engine in the Forefront Server Security for <insert app here> products, Microsoft Security Essentials, or Microsoft Standalone System Sweeper.   So once the AV team includes something in the appropriate portion of the definitions leveraged by that particular product, all the products leveraging that portion of the definitions can detect/remove the offending software.   Why reinvent the wheel and make inefficiencies that don’t need to exist.     When I go to fix a friend’s computer, I’ll just download the full definitions for Microsoft Security Essentials from here via the Microsoft Security Portal and load them into System Sweeper once it is running.

This will save me a TON of time with my friends & family able to solve their own problems.

UPDATE:  4/13/2012   The Beta of System Sweeper has now released and is called Windows Defender Online.     URLs in the post updated to reflect this change.

As a follow-up to my earlier post about leaving IPv6 enabled in the OS and bound to the NICs, I wanted to share some additional resources from my IE bookmarks:

Arguments against disabling IPv6
http://blogs.technet.com/b/netro/archive/2010/11/24/arguments-against-disabling-ipv6.aspx

How will it affect your business if you do not embrace IPv6?
http://blogs.technet.com/b/erenturk/archive/2010/11/17/how-will-it-affect-your-business-if-you-do-not-embrace-ipv6.aspx

IPocalypse Now
http://blogs.technet.com/b/canitpro/archive/2011/01/31/ipocalypse-now.aspx

IPv6 Forums
http://social.technet.microsoft.com/Forums/en-US/ipv6/threads

US Federal Directive to Support IPv6
http://blogs.technet.com/b/ipv6/archive/2010/10/01/us-federal-directive-to-support-ipv6.aspx

Why do I need to care for IPv6?
http://blogs.technet.com/b/erenturk/archive/2010/10/22/why-do-i-need-to-care-for-ipv6.aspx

Microsoft Common Engineering Criteria Overview
http://www.microsoft.com/CEC/en/us/cec-overview.aspx#data-ipv6

Microsoft Common Engineering Criteria Scorecards (IPv6 Support is under "Data Center and Enterprise Readiness")
http://www.microsoft.com/CEC/en/us/cec-scorecards.aspx?display=tech#

Also be aware of World IPv6 Day and Windows post from the IPv6 team.