Skip Navigation
 Search | Directories | Reference Tools
UW Home > UWIN > Computing and Networking > Support > UW Domains 

UW Forest Automated Scripts

The following scripts run on a regularly basis and are intended to help ensure operational functionality and security. Ideas for additional new scripts can be submitted to help@u.washington.edu.

Daily scripts

Weekly scripts

Follow-Up Details

You got a report from one of these scripts. You wonder what it means, why you got it, or what you should do. This section should help with that. If not, submit a question to help@u.washington.edu.

DNS Report

What do I do?

The code queries AD for all the DCs, then queries DNS to see if each DC is listed under the appropriate DNS record. And if any non-expected hosts are listed, it reports those too.

Each DC should have more than 10 DNS entries registered, including A, CNAME, and SRV records. The %systemroot%\system32\config\netlogon.dns file on each of your DCs should have an accurate list of what records should be registered in DNS. If you've turned off the "Dynamically Register" checkbox (as you should), then the A host record will not be listed in this file.

If the report says you have any entries missing, then it's simplest to send the netlogon.dns file from that DC to netops@u.washington.edu and ask them to update all the records.

If the report says there is an entry that shouldn't be there, then just forward that line to netops.

The code queries AD for a list of all the domain controllers listed at cn=servers,cn=seattle,cn=sites,cn=configuration,dc=windows,dc=washington,dc=edu, and assumes this is the authoritative list of domain controllers. In some rare cases, this isn't true; dcpromo either wasn't run to properly remove a domain controller (and remove the object at this location) or dcpromo failed to do this step as it should. If this is the case, the report you got will note:

YourDC has no NTDS object in the configuration partition. This is irregular, and probably indicates that this is not a valid DC, and that dcpromo wasn't run properly or didn't do all expected tasks. There will likely be other false-positives in this report because of this irregular situation. Contact help@u.washington.edu to get assistance manually removing this DC from Active Directory.

And you probably will see other entries noting that that YourDC either is missing records or doesn’t' respond to pings, etc. These other warnings can be ignored—you just need to contact help@u.washington.edu to get that object removed.

How did my DNS records get out of sync?

Many things can cause the DNS records to change. If you replace a DC, but re-use the hostname then the GUID that uniquely identifies the directory object will change. And one of the DNS records is based on that GUID. If you move the PDC emulator role from one DC to another, then a DNS record is out of sync. And of course, if you change IP addresses, then the A record must be changed.

Why do I care?

Operational functionality is at stake. The DNS records are how clients locate domain services, such as Kerberos authentication, LDAP directory searches, password changes, DFS root configuration changes, and replication between domain controllers themselves.

Replication Report

What do I do?

You will have gotten something like this:

  Repl. partner:          OXYGEN
  Failed since:           2003-11-10 13:30.31
  Attempts failed:        5

This means that one of the global catalog servers has been unable to replicate with OXYGEN for more than 24 hours. Collectively the global catalog servers talk with every DC in the forest, so all extended replication problems should be caught by this report.

The most common cause of replication problems is incorrect or missing DNS records. You can either check the DNS records yourself (use the netlogon.dns file & dig) or blindly ask netops@u to update your records.

You may find errors in your Directory Service eventlog. These errors may indicate the cause of the replication failures, perhaps a specific DNS record that is missing or an access problem.

If you can't find the cause, feel free to send help@u.washington.edu an email asking for assistance. We'd be happy to help diagnose the cause.

There is a possibility that there was replication problem more than 24 hours ago that has been fixed recently.

Why do I care?

Failed replication has implications for your services. It can mean that your updates (like password changes) are inconsistent. It can also mean that foundational assumptions are changing, but your services are unaware of them. It also has implications for other organizations in the UW forest. 6-8 other DCs are getting errors complaining about your domain controller. One domain controller failing to replicate may not cause serious operational problems, but as more fail the effect can be very detrimental. Finally, failure to replicate can inhibit major OS upgrades of your domain.

Domain Controllers Report

You will have gotten something like:

  pmcenter.washington.edu has 1 domain controllers.

This indicates that pmcenter.washington.edu only has one domain controller according to Active Directory. Running dcpromo to unpromote a domain controller removes the domain controller role and AD is updated. If you don't agree with the report, you can check your Domain Controller's OU to verify that the report is correct. UW forest policy strongly recommends 2 or 3 domain controllers. 4 or more will also trigger this report.

Having only one domain controller indicates that you don't consider your domain a production domain. Any outage will mean your domain is unreachable by the forest. We would like to encourage you to become an independent forest if this is your intention.

Having 4 or more domain controllers is unnecessary. It greatly increases the security risk to the forest. We'd be happy to chat with you about this.

Running dcpromo (either to promote a second DC or demote an existing DC) will be the usual response to this report.

Missing Hotfixes Report

...to be written...

Vulnerable Domain Trusts Report

What do I do?

You will have gotten something like:

  The admin.washington.edu external domain trust with DATAMGMT 
  has no Sidfiltering protection in place.

This indicates that the external NT4-style domain trust between the admin.washington.edu domain to the NT4 domain DATAMGMT is missing sidfiltering. Sidfiltering prevents a user account from an external domain from asserting a SID via the SIDHISTORY attribute that is inconsistent with that external domain's SID prefix. This limits exposure to a particular exploit that all Windows forests are vulnerable to, as described in Microsoft bulletin MS02-001. Domain admins in domains external to the forest that are trusted by your domain can elevate privileges to domain admins in your domain then to Enterprise Admin. as described in this Microsoft white paper Using Security Identifier (SID) Filtering to Prevent Elevation of Privilege Attacks and this Q article MS02-001: Forged SID Could Result in Elevated Privileges in Windows 2000.

To fix this, you need to follow the instructions in the Q article to implement sidfiltering using netdom.exe.

Why do I care?

A compromised domain admin or enterprise admin account is likely to be a serious and costly incident. Implementing sidfiltering is a small cost to prevent such a high impact vulnerability. Implementing sidfiltering is a UW forest policy and required to participate in the forest.