Registry tatooing refers to the old style workstation policies that Windows NT4 Server used. You also see these on a network if you are connecting to a Samba server, because it uses the old System Policy model. Policy changes in this system are permanently applied to the Registry as values that are never undone unless you explicitly remove them or change them to a different value. On a client, you edit these policies using the System Policy Editor and then the Config.pol file gets downloaded to the client at logon and is applied to the registry as keys and values.
Windows 2000/2003 Group Policy works in a different and much better way. The policy settings that are applied from GPOs do not make permanent changes to the registry. If you remove a setting from the policy, it will automatically revert to the default value for that setting. This makes policy operation more efficient since you don’t need to set a value for every policy. It also ensures that default values that are defined in the GPOs will work when they say they will.
Tatooing is the effect of the old style policies onto a workstation running Windows 2000 or later. The System Policy model was used by older desktop versions of Windows, including all Win9x systems (95, 98, ME) and Windows NT4 Workstation. However it can also be applied to Windows 2000/XP workstations when the PDC is Windows NT4 or Samba (may vary with version of the latter). The GPO model that we have today was introduced on Windows 2000 Server and Windows 2000 Professional. There are two parts to it, the server component and the desktop client component, and you have to have both of them to use it. Hence, an older desktop OS connecting to a Windows 2000 or later server still uses the old System Policy model, and a modern desktop OS (Windows 2000 or later) connecting to an older server (NT4/Samba) still uses System Policy.
We came originally from a Samba server to Windows 2003 domain controllers, and we saw these effects on our XP workstations. One of the first ones that I remember was connected with the policy setting that reads "Connect home drive to the root of the share". When you set up a user account you specify a home drive letter and path. This policy setting overrides the path so that only the share is used and the drive letter connects to the root of that share. The default for this setting is to be disabled, but we found that we had to specifically disable it because, I presume, the default had been overridden by tatooing.
Another possible example I have just noticed is remote shutdown. We reinstalled a pile of machines, and they all started to give "Access denied" errors when we tried to run a script on the server to shut them down remotely. There must have been a setting tatooed into the registry that allowed the remote shutdown to occur with the right user permissions (the script is running as the domain administrator). There are a few options I have to try to see which is the best way of resolving this.