Domain Controllers have their own local security policies, just like regular domain members do. Group Policies will also take precedence/override local security policies, just as they do on regular domain members.
As you have witnessed, there are plenty of Group Policy settings that have the ability to "tattoo," or leave their mark on a system's local security policy even after the GPO no longer applies to the computer. Group Policies that do not tattoo a system after the GPO no longer applies generally modify settings under a special "Policies" subkey in the Windows registry. Most Group Policies are well behaved and follow this pattern, but not all of them.
The first obvious solution to manage configuration settings in a domain environment is, if you care about a setting, set it in Group Policy so that it will override any local policy settings.
Another possible solution would be to create and apply Security Templates with the Security Configuration and Analysis tool (mmc snap-in.) I don't see the advantage of doing this over simply defining your baseline configuration settings via Group Policy, but that's the tool to use if you want to apply consistent templates to the local security policies of many machines.
Most admins only promote computers with a known good security configuration to be domain controllers, so yours is not a very common problem.
For auditing, running gpresult /h policy.html
will generate an HTML report that lists all the effective policy settings, including a merging of both Group Policies and Local Policies. So if a computer has a modified Local Policy setting, and no Group Policy overrides it, it will show up there:

From TechNet:
All settings applied through local policy or a Group Policy Object are
stored in a local database on your computer. Whenever a security
setting is modified, the computer saves the security setting value to
the local database, which retains a history of all the settings that
have been applied to the computer. If a policy first defines a
security setting and then no longer defines that setting, then the
setting takes on the previous value in the database. If a previous
value does not exist in the database, then the setting does not revert
to anything and remains defined as is. This behavior is sometimes
called "tattooing."