March, 2011

Ned here again folks. We introduced granular auditing in Windows Vista and a few years later we released Advanced Audit Policy Configuration. Legacy Windows audit policy didn’t go away, of course. To make things interesting, all of this can be configured through domain policy, local policy, multiple-local policy, per-user, or using command-line tools. Like most security policy that has evolved through 20 years of Windows, it’s a bit of a Frankenstein’s monster. Making sense of what settings are actually in place in Win7 and 2008 R2 can be a real pain in the neck. Today we’ll see if I can make it easier.

Fire good!

A Scenario

You commonly configure audit settings using the following:

• Domain based group policy (via GPMC.MSC)
• Local policy (via GPEDIT.MSC)
• Directly (only advanced audit policy, via auditpol.exe)

But depending on how you set the policy, your reporting tools may be misleading you around effective settings. For instance, I have specified the following policies using the following techniques.

1. I have a legacy audit policy applying from domain policy that configures Object Access auditing:

2. I have advanced audit configuration applying from domain policy that sets AD changes, account lockouts, and logons:

3. I have advanced audit configuration applying from local policy for process startup and termination:

4. I have granular audit settings configured using auditpol.exe /set for file share access:

Pro tip: this is not awesome auditing technique, on a number of levels. :) Just for demo purposes, mmmkay?

Initial Results

Now I generate a resultant set of policy report. I am not using RSOP.MSC as it’s deprecated and often wrong and generally evil. I run GPRESULT /H foo.htm instead:

Looks pretty good so far. I can’t see my policy that I set through auditpol.exe though; that kinda sucks but whatevah.

So now I start generating some audit events for the areas I am tracking from my four audit points. Immediately I see some weirdness:

• All the advanced audit configuration coming from “Local Group Policy” and “Advanced Audit DC Policy” is working great.

• My event log should be flooded with Object Access events but there are zero. 
• Accessing file shares doesn’t generate any audit events.

The lack of Object Access auditing is expected: as soon as you start applying Advanced Audit Configuration Policy, legacy policies will be completely ignored. The only way to get a Win7/R2 computer to start using legacy policy is to set the security policy “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” to DISABLED. That disables the use of the newer policy type. Then you must clear the existing advanced policy from the machines (auditpol.pol /clear, having a blank audit.csv file, etc). The system isn't optimal, but the intention was never for you to go back.

Not seeing the File Share events makes sense too: after all, I created domain based and local policy to set all of this; they are just blowing away my local settings, right?

Yes and no.

First, I delete my link for the “Advanced audit DC policy” and run GPUPDATE /FORCE. Now I am only getting local policy settings for process creation and termination as expected. If I then re-run my auditpol /set /subcategory:”file share” /success:enable command and access a file share, I get an event. Yay team. Except after a while, this will stop working, because the local policy setting is going to reapply when the computer restarts or every 16 hours when security policy is reapplied arbitrarily.

Here’s where things get weird.

Unlike most security settings that directly edit registry keys as preferences, advanced audit policy stores all of its local security policy values in an audit.csv file located here:

%systemroot%\system32\grouppolicy\machine\microsoft\windows nt\audit\audit.csv

Which is then copied here:

%systemroot%\security\audit\audit.csv

But the domain-based policy settings are in an audit.csv in SYSVOL and that is never stored locally to the computer. So examining any of them is rather useless. Unfortunately for you, those audit.csv files are what RSOP data is returning, not the actual applied settings. And if you use legacy tools like SECEDIT.EXE /EXPORT it won’t even mention the advanced audit configuration at all – it was never updated to include those settings.

The Truth

All of this boils down to one lesson: you should not trust any of the Group Policy reporting tools when it comes to audit settings. There’s only one safe bet and it’s this command:

auditpol.exe /get /category:*

Only auditpol reads the actual super-top-secret-eyes-only-licensed-to-kill-shaken-not-stirred registry key that stores the current, effective set of auditing policy that LSASS.EXE consumes:

HKEY_Local_Machine\Security\Policy\PolAdtEv

If it’s not in that key, it’s not getting audited.

Before you get all excited and start plowing into this key, understand that this key is intended to be opaque and proprietary. We don’t really document it and you certainly cannot safely edit it with regedit. In fact, as an experiment I once renamed it in order to see if it would be automatically recreated using “default, out of box” settings. Instead, the computer refused to boot to a logon prompt anymore! I had to load that hive using regedit in WIN PE and name it back (Last Known Good Configuration boot does not apply to the Security hive). If you want to write your own version of auditpol you use the function AuditQuerySystemPolicy (part of the gigantor Advapi32 library of Authorization functions; have fun with that goo and don’t call me about it, it’s grody).

As a side note - if you want a safe way to remove auditing settings you can easily clear that registry key by running auditpol /clear and removing policy. That puts you to “nothing”. If you want to restore to “out of the box” experience you would use auditpol /backup on a nice clean unadulterated repro computer that was installed from media and never joined to a domain. That gives you the “before”. Then if you ever want to reset a computer to OOB you auditpol /restore it.

Until next time.

Ned “Wait. Where are you going? I was going to make Espresso!” Pyle

Hi folks, Ned here again. I recently wrote a KB article about some expected DCDIAG.EXE behaviors. This required reviewing DCDIAG.EXE as I wasn’t finding anything deep in TechNet about the “Services” test that had my interest. By the time I was done, I had found a dozen other test behaviors I had never known existed. While we have documented the version of DCDIAG that shipped with Windows Server 2008 – sometimes with excellent specificity, like Justin Hall’s article about the DNS tests – mostly it’s a black box and you only find out what it tests when the test fails. Oh, we have help of course: just run DCDIAG /? to see it. But it’s help written by developers. Meaning you get wording like this:

Advertising
Checks whether each DSA is advertising itself, and whether it is advertising itself as having the capabilities of a DSA.

So, it checks each DSA (whatever that is) to see if it’s advertising (whatever that means). The use of an undefined acronym is an especially nice touch, as even within Microsoft, DSA could mean:

• Digital Signature Algorithm
• Dynamic Structure Array
• Distributed Systems Architecture
• Directory System Agent <-- it’s this one
• Directory Service Agent <-- except when it’s this one

Naturally, this brings out my particular brand of OCD. What follows is the result of my compulsion to understand. I’m not documenting every last switch in DCDIAG, just the tests. I am only documenting Windows Server 2008 R2 SP1 behavior – I have no idea where the source code is for the ancient Support Tools version of DCDIAG and you aren’t paying me enough here to find it :-).  The Windows Server 2008 RTM through Windows Server 2008 R2 SP1 versions are nearly identical except for bug fixes:

KB2401600 The Dcdiag.exe VerifyReferences test fails on an RODC that is running Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;en-US;2401600

KB979294 The Dcdiag.exe tool takes a long time to run in Windows Server 2008 R2 and in Windows 7
http://support.microsoft.com/default.aspx?scid=kb;EN-US;979294

KB978387 FIX: The connectivity test that is run by the Dcdiag.exe tool fails together with error code 0x621
http://support.microsoft.com/default.aspx?scid=kb;EN-US;978387

Everything I describe below you can discover and confirm yourself with careful examination of network captures and logging, to include the public functions being used – but why walk when you can ride? Using /v can also provide considerable details on some tests. No internal source code is described nor do I show any special hidden functionality.

For info on all the network protocols I list out – or if you run into network errors when using DCDIAG – see Service overview and network port requirements for the Windows Server system. I went pretty link-happy in general in this post to help people using it as a reference; that way if you just look at your one little test it has all the info you need. I don’t always call out name resolution being tested because it is implicit; it’s also testing TCP, UDP, and IP.

Finally: this post is more of a reference than my usual lighthearted fare. Do not operate heavy machinery while reading.

Initial Required Tests

This tests general connectivity and responsiveness of a DC, to include:

• Verifying the DC can be located in DNS.
• Verifying the DC responds to ICMP pings.
• Verifying the DC allows LDAP connectivity by binding to the instance.
• Verifying the DC allows binding to the AD RPC interface using the DsBindWithCred function.

The DNS test can be satisfied out of the client cache so restarting the DNS client service locally is advisable when running DCDIAG to guarantee a full test of name resolution. For example:

Net stop "dns client" & net start "dns client" & dcdiag /test:verifyreplicas /s:DC-01

The initial tests cannot be skipped.

The initial tests use ICMP, LDAP, DNS, and RPC on the network.

Editorial note: Blocking ICMP will prevent DCDIAG from working. While blocking ICMP is highly recommended at the Internet-edge of your network, internally blocking ICMP traffic mainly just leads to administrative headaches like breaking legacy group policy, breaking black hole router detection (or leading to highly inefficient MTU sizes due to lack of a discovery option), and breaking troubleshooting tools like ping.exe or tracert.exe. It creates an illusion of security; there are a great many other easy ways for a malicious internal user to locate computers.

Advertising

This test validates that the public DsGetDcName function used by computers to locate domain controllers will correctly locate any DCs specified with in the command line with the /s, /a, or /e parameter. It checks that the server successfully reports itself with DS_Flags for:

• DC
• LDAP server
• Writable or Read-Only DC
• KDC
• Time Server
• GC or not (and if claiming to be a GC, if the is GC ready to respond to requests )

Note that “advertising” is not the same as “working”. For instance, if the KDC service is stopped the Advertising test will fail since the flag returned from DsGetDcName will not include KDC. But if port 88 over TCP and UDP are blocked on a firewall, the Advertising test will pass – even though the KDC is not going to be able to answer requests for Kerberos tickets.

This test is done using RPC over SMB (using a Netlogon named pipe) to the DC plus LDAP to locate the DCs site information.

CheckSDRefDom

This test validates that your application partition cross reference objects (located in “cn=partitions,cn=configuration,dc=<forest root domain>”) contain the correct domain names in their msDS-SDReferenceDomain attributes. The test uses LDAP.

I find no history of anyone ever seeing the error message that can be displayed here.

The test uses LDAP.

CheckSecurityError

This test does a variety of checks around the security components of a DC like Kerberos. For it to be more specifically useful you should provide /replsource:<some partner DC> as the default checks are not as comprehensive.

This test:

• Validates that at least one KDC is online for each domain and they are reachable (first in the same site, then anywhere in the domain if that fails)
• Checks if packet fragmentation of Kerberos over UDP might be an issue based on current MTU size by sending non-fragmenting ICMP packets
• Checks if the DC’s computer account exists in AD, if it’s within the default “Domain Controllers” OU, if it has the correct UserAccountControl flags for DCs, that the correct ServerReference attributes are set, and if the minimum Service Principal Names are set
• Validates that the DCs computer object has replicated to other DCs
• Validates that there are no replication or KCC connection issues for connected partners by querying the function DsReplicaGetInfo to get any security-related errors

When the /replsource is added, a few more tests happen. The partner is checked for all of the above also, then:

• Time skew is calculated between the servers to verify it is less than 300 seconds for Kerberos. It does not check the Kerberos policy to see if allowed skew has been modified
• Permissions are checked on all the naming contexts (such as Schema, Configuration, etc.) on the source DC to validate that replication and connectivity will work between DCs
• Connectivity is checked to validate that the user running DCDIAG (and therefore in theory, all other users) can connect to and read the SYSVOL and NETLOGON shares without any security errors. It also checks IPC$, but inability to connect there would have broken many earlier tests
• The "Access this computer from the network" privilege on the DC is checked to verify it is held by Administrators, Authenticated Users, and Everyone groups
• The DC's computer object is checked to ensure it is the latest version on the DCs. This is done to prove replication convergence since a very stale DC might lead to security issues for users, problems with the DCs own computer account password, or secure channels to other servers. It checks versions, USNs, originating servers, and timestamps

These tests are performed using LDAP, RPC, RPC over SMB, and ICMP.

Connectivity

No matter what you specify for tests, this always runs as part of Initial Required Tests.

CrossRefValidation

This test retrieves a list of naming contexts (located in “cn=partitions,cn=configuration,dc=<forest root domain>”) with their cross references and then validates them, similar to the CheckSDRefDom test above. It is looking at the nCName , dnsRoot, nETBIOSName, and systemFlags attributes to:

• Make sure the names or DNs are not invalid or null
• Confirm DNs are not otherwise mangled with CNF or 0ADEL (which happens during Conflict or Deletion operations)
• Ensure the systemFlags are correct for that object
• Call out any empty (orphaned) replica sets

The test uses LDAP.

CutoffServers

Tests the AD replication topology to ensure there are no DCs without working connection objects between partners. Any servers that cannot replicate inbound or outbound from any DCs are considered “cut off”. It uses the function DsReplicaSyncAll to do this which means this “test” actually triggers replication on the DCs so use with caution if you are the owner of crud WAN links that you keep clean with schedules, and certainly consider this before using /e.

This test is rather misleading in its help description; if it cannot contact a server that is actually unavailable to LDAP on the network then it gives no error or test results, even if the /v parameter is specified. You have to notice that there is no series of “analyzing the alive system replication topology” or “performing upstream (of target) analysis” messages being printed for a cutoff server. However, the Connectivity test will fail if the server is unreachable so it’s a wash.

The test uses RPC.

DcPromo

The DCpromo test is one of the two oddballs in DCDIAG (the other is ‘DNS’). It is designed to test how well a DCPROMO would proceed if you were to run it on the server where DCDIAG is launched. It also has a number of required switches for each kind of promotion operation. All of the tests are against the server specified first in the client DNS settings. It tests:

• If at least one network adapter has a primary DNS server set
• If you would have a disjoint namespace based on the DNS suffix
• That the proposed authoritative DNS zone can be contacted
• If dynamic DNS updates are possible for the server’s A record. It checks both the setting on the authoritative DNS zone as well as the client registry configuration of DnsUpdateOnAllAdapters and DisableDynamicUpdate
• If an LDAP DClocator record (i.e. “_ldap ._tcp.dc._msdcs.<domain>”) is returned when querying for existing forests

The test uses DNS on the network.

DNS

This series of enterprise-wide DNS tests are already well documented here:

http://technet.microsoft.com/en-us/library/cc731968(WS.10).aspx

The tests use DNS, RPC, and WMI protocols.

FrsEvent

This test validates the File Replication Service’s health by reading (and printing, if using /v) FRS event log warning and error entries from the past 24 hours. It’s possible this service won’t be running or installed on Windows Server 2008 or later if SYSVOL has been migrated to DFSR. On Windows Server 2008, some events may be misleading as they may refer to custom replica sets and not necessarily SYSVOL; on Windows Server 2008 R2, however, FRS can be used for SYSVOL only.

By default, remote connections to the event log are disabled by the Windows Server 2008/R2 firewall rules so this test will fail. KB2512643 covers enabling those rules to allow the test to succeed.

The test uses RPC, specifically with the EventLog Remoting Protocol.

DFSREvent

This test validates the Distributed File System Replication service’s health by reading (and printing, if using /v) DFSR event log warning and error entries from the past 24 hours. It’s possible this service won’t be running or installed on Windows Server 2008 if SYSVOL is still using FRS; on Windows Server 2008 R2 the service is always present on DCs. While this ostensibly tests DFSR-enabled SYSVOL, any errors within custom DFSR replication groups would also appear here, naturally.

By default, remote connections to the event log are disabled by the Windows Server 2008/R2 firewall rules so this test will fail. KB2512643 covers enabling those rules to allow the test to succeed.

The test uses RPC, specifically with the EventLog Remoting Protocol.

SysVolCheck

This test reads the DCs Netlogon SysvolReady registry key to validate that SYSVOL is being advertised:

HKEY_Local_Machine\System\CurrentControlSet\Services\Netlogon\Parameters
SysvolReady=1

The value name has to exist with a value of 1 to pass the test. This test will work with either FRS or DFSR-replicated SYSVOLs. It doesn’t check if the SYSVOL and NELOGON shares are actually accessible, though (CheckSecurityError does that).

The test uses RPC over SMB (through a named pipe to WinReg).

LocatorCheck

This test validates that DCLocator queries return the five “capabilities” that any DC must know of to operate correctly.

• GC
• PDCE
• Time Server
• Preferred Time Server
• KDC

If not hosting one, the DC will refer to another DC that can satisfy the request; this means that you must carefully examine this under /v to make sure a server you thought was supposed to be holding a capability actually is correctly returned. If no DC answers or if the queries return errors then the test will fail.

The tests use RPC over SMB with the standard DsGetDcName DCLocator queries.

Intersite

This test uses Directory Replication Service (DRS) functions to check for conditions that would prevent inter-site AD replication within a specific site or all sites:

• Locates and connect to the Intersite Topology Generators (ISTG)
• Locates and connect to the bridgehead servers
• Reports back any replication failures after triggering a replication
• Validates that all DCs within sites with inbound connections to this site are available
• Checks the KCC values for “IntersiteFailuresAllowed” and “MaxFailureTimeForIntersiteLink” overrides within the registry key:

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

You must be careful with this test’s command-line arguments and always provide /a or /e. Not providing a site means that the test runs but skips actually testing anything (you can see this under /v).

All tests use RPC over the network to test the replication aspects and will make registry connections (RPC over SMB to WinReg) to check for those NTDS settings override entries. LDAP is also used to locate connection info.

KccEvent

This test queries the Knowledge Consistency Checker on a DC for KCC errors and warnings generated in the Directory Services event log during the last 15 minutes. This 15 minute threshold is irrespective of the Repl topology update period (secs) registry value on the DC.

By default, remote connections to the event log are disabled by the Windows Server 2008/R2 firewall rules so this test will fail. KB2512643 covers enabling those rules to allow the test to succeed.

The test uses RPC, specifically with the EventLog Remoting Protocol.

KnowsOfRoleHolders

This test returns the DC's knowledge of the five Flexible Single Master Operation (FSMO) roles. The test does not inherently check all DCs knowledge for consistency, but using the /e parameter would provide data sufficient to allow comparison.

The test uses RPC to return DSListRoles within the Directory Replication Service (DRS) functions.

MachineAccount

This test checks if:

• The DC's computer account exists in AD
• It’s within the Domain Controllers OU
• It has the correct UserAccountControl flags for DCs
• The correct ServerReference attributes are set
• The minimum Service Principal Names are set. For those paying close attention, this is identical to one test aspect of CheckSecurityError; this is because they use the same internal test

This test also mentions two repair options:

• /RecreateMachineAccount will recreate a missing DC computer object. This is not a recommended fix as it does not recreate any child objects of a DC, such as FRS and DFSR subscriptions. The best practice is to use a valid SystemState backup to authoritatively restore the DC's deleted object and child objects. If you do use this /RecreateMachineAccount option then the DC should then be gracefully demoted and promoted to repair all the missing relationships
• /FixMachineAccount will add the UserAccountControl flags to a DCs computer object for “TRUSTED_FOR_DELEGATION” and “SERVER_TRUST_ACCOUNT”. It’s safe to use as a DC missing those bit flags will not function and it does not remove other bit flags present. Using this repair option is preferred over trying to set these flags yourself through ADSIEDIT or other LDAP editors

This test uses LDAP and RPC over SMB.

NCSecDesc

This test checks permissions on all the naming contexts (such as Schema, Configuration, etc.) on the source DC to validate that replication and connectivity will work between DCs. It makes sure that “Enterprise Domain Controllers” and “Administrators” groups have the correct minimum permissions. This is the same performed test within CheckSecurityError.

The test uses LDAP.

NetLogons

This test is designed to:

• Validate that the user running DCDIAG (and therefore in theory, all other users) can connect to and read the SYSVOL and NETLOGON shares without any security errors. It also checks IPC$, but inability to connect there would have broken many earlier tests
• Verify that the Administrators, Authenticated Users, and Everyone group have the “access this computer from the network” privilege on the DC. If not, you’d see a ton of other errors here though, naturally

Both of these tests are also performed by CheckSecurityError.

The tests use SMB and RPC over SMB (through named pipes).

ObjectsReplicated

This test verifies that replication of a few key objects and attributes has occurred and displays up-to-dateness info if replication is stale. By default the two objects validated are:

• The ”CN=NTDS Settings” object of each DC exists up to date on all other DCs.
• The “CN=<DC name>” object of each DC exists up to date on all other DCs.

This test is not valuable unless run with /e or /a as it just asks the DC about itself when those are not specified. Using /v will give more details on objects thought to be stale based on version.

You can also specify arbitrary objects to test with /objectdn /n, which can be useful after creating a “canary” object to validate replication.

The tests are done using RPC with Directory Replication Service (DRS) functions.

OutboundSecureChannels

This test is designed to check external trusts. It will not run by default and will fail even when provided correct /testdomain parameters, validating the secure channel with NLTEST.EXE, and using a working external trust. It does state that the secure channel is valid but then mistakenly reports that there are no working trust objects. I’ll update this post when I find out more. This test should not be used.

RegisterLocatorDnsCheck

Validates many of the same aspects as the Dcpromo test. It requires the /dnsdomain switch to specify a domain that would be the target of registration; this can be a different domain than the current primary one. It specifically verifies:

• If at least one network adapter has a primary DNS server set.
• If you would have a disjoint namespace based on the DNS suffix
• That the proposed authoritative DNS zone can be contacted
• If dynamic DNS updates are possible for the server’s A record. It checks both the setting on the authoritative DNS zone as well as the client registry configuration of DnsUpdateOnAllAdapters and DisableDynamicUpdate
• If an LDAP DClocator record (i.e. “_ldap ._tcp.dc._msdcs.<domain>”) is returned when querying for existing forests
• That the authoritative DNS zone can be contacted

The test uses DNS on the network.

Replications

This test checks all AD replication connection objects for all naming contexts on specified DC(s) to see:

• If the last replication attempted was successful or returned an error
• If replication is disabled
• If replication latency is more than 12 hours

The tests are done with LDAP and RPC using DsReplicaGetInfo.

RidManager

This test validates that the RID Master FSMO role holder:

• Can be located and contacted through a DsBind
• Has valid RID pool values

This role must be online and accessible for DCs to be able to create security principals (users, computers, and groups) as well as for further DCs to be promoted within a domain.

The test uses LDAP and RPC.

Services

This test validates that various AD-dependent services are running, accessible, and set to specific start types:

• RPCSS - Start Automatically – Runs in Shared Process
• EVENTSYSTEM - Start Automatically - Runs in Shared Process
• DNSCACHE - Start Automatically - Runs in Shared Process
• NTFRS - Start Automatically - Runs in Own Process (if domain functional level is less than Windows Server 2008. Does not trigger on SYSVOL being replicated by FRS)
• ISMSERV - Start Automatically - Runs in Shared Process
• KDC - Start Automatically - Runs in Shared Process
• SAMSS - Start Automatically - Runs in Shared Process
• SERVER - Start Automatically - Runs in Shared Process
• WORKSTATION - Start Automatically - Runs in Shared Process
• W32TIME - Start Manually or Automatically - Runs in Shared Process
• NETLOGON - Start Automatically - Runs in Shared Process

(If target is Windows Server 2008 or later)

• NTDS - Start Automatically - Runs in Shared Process
• DFSR - Start Automatically - Runs in Own Process (if domain functional level is Windows Server 2008 or greater. Does not trigger on SYSVOL being replicated by DFSR)

(If using SMTP-based AD replication)

• IISADMIN - Start Automatically - Runs in Shared Process
• SMTPSVC - Start Automatically - Runs in Shared Process

These are the “real” service names listed in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. If this test is specified when targeting Windows Server 2003 DCs it is expected to fail on RpcSs. See KB2512643.

The test uses RPC and the Service Control Manager remote protocol.

SystemLog

This test validates the System Event Log’s health by reading and printing entries from the past 60 minutes (stopping at computer startup timestamp if less than 60 minutes). Errors and warnings will be printed, with no evaluation done of them being expected or not – this is left to the DCDIAG user.

By default, remote connections to the event log are disabled by the Windows Server 2008/R2 firewall rules so this test will fail. KB2512643 covers enabling those rules to allow the test to succeed.

The test uses RPC, specifically with the EventLog Remoting Protocol.

Topology

This test checks that a server has a fully-connected AD replication topology. This test must be explicitly run. It checks:

• If automatic intra-site topology generation is disabled
• If automatic inter-site topology generation is disabled
• For disconnected topologies (i.e. missing connection objects), both upstream and downstream from each reference DC

The test uses DsReplicaSyncAll with the flag of DS_REPSYNCALL_DO_NOT_SYNC. Meaning that the test analyzes and validates replication topology without actually replicating changes. The test does not validate the availability of replication partners – having a partner offline will not cause failures in this test. This does not test if the schedule is completely closed, preventing replication; to see those active replication results, use tests Replications or CutoffServers.

The test uses RPC and LDAP.

VerifyEnterpriseReferences

This test verifies computer reference attributes for all DCs, including:

• ServerReference attribute correct for a DC on cn=<DC name>,cn=<site>,cn=sites,cn=configuration,dc=<domain>
• ServerReferenceBL attribute correct for a DC site object on a DC on cn=<DC Name>,ou=domain controllers,dc=<domain>
• frsComputerReference attribute correct for a DC site object on cn=domain system volume (sysvol share),cn=ntfrs subscriptions,cn=<DC Name>,ou=domain controllers,DC=<domain>
• frsComputerReferenceBL attribute correct for a DC object on cn=<DC Name>,cn=domain system volume (sysvol share),cn=file replication service,cn=system,dc=<domain>
• hasMasterNCs attribute correct for a DC on cn=ntds settings,cn=<DC Name>,cn=<site>,cn=sites,cn=configuration,dc=<domain>
• nCName attribute correct for a partition at cn=<partition name>,cn=partitions,cn=configuration,dc=<domain>
• msDFSR-ComputerReference attribute correct for a DC DFSR replication object on cn=<DC Name>,cn=topology,cn=domain system volume,cn=dfsr-blobalsettings,cn=system,dc=<domain>
• msDFSR-ComputerReferenceBL attribute correct for a DC site object on a DC on cn=<DC Name>,ou=domain controllers,dc=<domain>

Note that the two DFSR tests are only performed if domain functional level is Windows Server 2008 or higher. This means there will be an expected failure if DFSR has not been migrated to SYSVOL as the test does not actually care if FRS is still in use.

The test uses LDAP. The DCS are not all individually contacted, only the specified DCs are contacted.

VerifyReferences

This test verifies computer reference attributes for a single DC, including:

• ServerReference attribute correct for a DC on cn=<DC name>,cn=<site>,cn=sites,cn=configuration,dc=<domain>
• ServerReferenceBL attribute correct for a DC site object on a DC on cn=<DC Name>,ou=domain controllers,dc=<domain>
• frsComputerReference attribute correct for a DC site object on cn=domain system volume (sysvol share),cn=ntfrs subscriptions,cn=<DC Name>,ou=domain controllers,DC=<domain>
• frsComputerReferenceBL attribute correct for a DC object on cn=<DC Name>,cn=domain system volume (sysvol share),cn=file replication service,cn=system,dc=<domain>
• msDFSR-ComputerReference attribute correct for a DC DFSR replication object on cn=<DC Name>,cn=topology,cn=domain system volume,cn=dfsr-blobalsettings,cn=system,dc=<domain>
• msDFSR-ComputerReferenceBL attribute correct for a DC site object on a DC on cn=<DC Name>,ou=domain controllers,dc=<domain>

This is similar to the VerifyEnterpriseRefrences test except that it does not check partition cross references or all other DC objects.

The test uses LDAP.

VerifyReplicas

This test verifies that the specified server does indeed host the application partitions specified by its crossref attributes in the partitions container. It operates exactly like CheckSDRefDom except that it does not show output data and validates hosting.

This test uses LDAP.

That’s all folks.

- Ned “that was seriously un-fun to write” Pyle

Hey all, Rob Greene here again. We have been getting calls recently on how to use ADFS 2.0 to federate with ADP, so today I explain how.

Disclaimer: If you have problems with connecting to ADP, your first call should be to them. If after talking with ADP you need further assistance you then open a case with Microsoft Support. The AskDS blog cannot troubleshoot connectivity between ADP and ADFS; it requires data and access to your network. This post is a friendly attempt to save you from contacting the support lines as your first option.

Note: The information given is from working with customers setting up a federated trust with ADP and as of this writing it is accurate. This post is not going to discuss how to install ADFS 2.0 or discuss any design decisions around ADFS. If you need this type of information, please visit here.

You need two certificates from a Public Certification Authority (not your internal CA).

• Use with the Service Communications Certificate
• Use for Token-Signing Certificate

You could use one certificate for both purposes; however, the best practice is to use two different certificates, in case one of them is compromised. Once you get the certificates issued, you can review the following WIKI content on the steps that are required so that AD FS 2.0 uses these new certificates.

The next step is to contact ADP. They need the public certificate for your Token-Signing certificate. Follow the below steps to export the public certificate on the ADFS Server:

1. Click on the "Start" button, the select "Run".
2. Type:  "MMC".
3. Click on the menu options:  "File" then select "Add/Remove Snap-in...".
4. Select "Certificates" then click the "Add" button.
5. The Certificate Snap-in Wizard starts. 
6. Select "Computer account" and click the "Next" button.
7. Select "Local computer:  (the computer this console is running on)" then click the "Finish" button.
8. Click the "OK" button.
9. Expand Console Root\Certificates (Local Computer)\Personal\Certificates.
10. Select the certificate in question.
11. Right click on it, and select "All Tasks", and then click on "Export".
12. Click the Next button.
13. Select “No, do not export the private key” and click the Next button.
14. Select “Base-64 encoded x.509(.CER)” and click the Next button.
15. Type in a file path and name then click the Next button.
16. Click the Finish button.
17. In the dialog box “The export was successful.” click the OK button.

Configuring Relying Party Trust information:

ADP uses RelayState information to direct users to their different applications but ADFS 2.0 does not support that protocol binding. Let ADP know that you are using ADFS, and they will modify some settings on their end to get things working.

Now let’s get to the actual configuration steps.

1. Open AD FS 2.0 Management snapin.
2. Navigate to: AD FS 2.0\Trust Relationships\Relying Party Trusts
3. Right click on the “Relying Party Trusts” container and select “Add Relying Party Trust”
4. The “Add Relying Part Trust” wizard starts, click the Start button.
5. Since ADP does not provide metadata information, you will need to select “Enter data about the relying party manually”, and click the Next button.
6. For Display name, you can type what you would like here. For example: ADP Trust
7. Click the Next button.
8. Select “AD FS 2.0 profile” and click the Next button.
9. The Relying Party Trust configuration to ADP does not require a Token Encryption certificate (although I hear that they will give you one if you ask.).
10. Click the Next button.
11. Check “Enable support for SAML 2.0 Web SSO protocol”
12. For the Relying party SAML 2.0 SSO service URL you will type in the Service Provider (SP) URLs. Currently this is: https://fed-stag.adp.com/affwebservices/public/saml2assertionconsumer (when testing) or https://fed.adp.com/affwebservices/public/saml2assertionconsumer (when production).
    
    
13. Click the Next button.
14. In the Relying party trust identifier the ADP SAML endpoint needs to be typed in here. When looking at the ADP Federation Integration Guide.pdf (provided by ADP) this refers to the Audience Attribute, currently this is: https://fed.adp.com
    
    
15. Click the Add button.
16. Click the Next button.
17. Select “Permit all users to access this relying party” and click the Next button.
18. You can review the configuration on this screen. Once you are satisfied with the information click the Next button.
19. Click the Close button.

You should now see a dialog box to add Claim rules to the “ADP Trust” relying party that we just configured. There are two claims that need configuration before sending to ADP: PersonImmutableID, and NameID. The next steps show you how to configure them. Please keep in mind that with any federation configuration, case sensitivity is critical. Please make sure to use the matching case when configuring the claim names.

Configuring PersonImmutableID claim:

1. In the ADP Trust Claim rules click the Add button.
2. Select “Send LDAP attributes as Claims” and click the Next button.
3. The Claim rule name can be anything. We will type in: Send EmployeeID as PersonImmutableID
4. For the “Attribute store” drop down and select “Active Directory”.
5. In “LDAP Attribute” section, drop down and select “Employee-ID”.
6. In “Outgoing Claim Type” section type in: PersonImmutableID
   
   

   

7. Click the Finish button.

Configuring NameID claim:

1. In the ADP Trust Claim rules click the Add button.
2. Select “Send LDAP attributes as Claims” and click the Next button.
3. The Claim rule name can be anything. We will type in: Send UPN as NameID
4. For the “Attribute store” drop down and select “Active Directory”.
5. In “LDAP Attribute” section, drop down and select “User-Principal-Name”.
6. In “Outgoing Claim Type” section, drop down and select “Name ID”.
   
   
7. Click the Finish button.
8. Click the OK button on the Claim rule configuration for ADP Trust.

Since we have configured this as a SAML assertion we can use the LoginToRP feature with the IDPIntitiatedSignon page to get the users signed into ADFS and then redirect them to ADP. Here is an example of this assuming that the ADFS server name is adfs.fabrikam.com. The URL would be:

https://adfs.fabrikam.com/adfs/ls/IDPInitiatedSignon.aspx?LoginToRP=https://fed.adp.com

Now you are ready to begin testing connectivity with ADP. I hope this blog helps making federating with ADP a lot easier.

Rob “Fuzzy” Greene

Hi folks, Ned here again. I mentioned this once in a Friday Mail Sack but today I circle around and explain a well-hidden security feature added in Windows 7 and Windows Server 2008 R2:

Global Object Access Auditing

Oh boy, auditing! I bet you are excited!

What is it and how to enable it

You should be familiar with the security auditing of Windows by now; it’s been around since NT.

Jealous much?!

Beginning in Windows Vista, a new granular auditing system was added by this guy. It meant you could now specify in more (or less!) detail what types of data you wanted to audit. This allowed fancy moves like auditing what AD attributes were changed and even what their new values became.

Garbage in, garbage out

Starting in Windows 7 a new control mechanism called Advanced Audit Policy Configuration was added that let you actually set this stuff easily and not juggle some scripts and auditpol.exe.

Way better than this

Tucked away here in the new policy is a little known section called Global Object Access Auditing (GOAA – an acronym I just invented).

STOP!!!

At this point you want to start clicking and touching. It’s only human. Unless you are using a test computer, resist that urge.

If you start enabling anything in Advanced Audit policy, it will take effect immediately; even if you do not click Apply. Any pre-existing legacy audit policy will be overwritten and this new policy will start being used. If you enable a few things and then disable them, you will turn policy settings off – meaning that you are now auditing nothing. Undoing this is a pain in the neck, so don’t start touching audit policies until you are done testing and ready to roll out to production.

I’ll be writing more about effective auditing settings and dealing with all this in a follow up post very soon.

Effective audit settings are explained here

When you look at the policy, you will see that it has a curious configuration dialog. In your test computer, note the File and Registry nodes, and that they only contain a “configure” option:

Click that button and you will see the usual security dialog where you assign file or registry auditing:

Global auditing lets you create System Access Control Lists (SACL) for the entire computer, based on file and registry. This means that instead of manually altering and maintaining SACLs on 10TB of shared files, you can instead define them implicitly and not actually modify the files at all. You can then troubleshoot an unexplained file deletion, see who keeps changing permissions on a folder, or satisfy an auditor.

This is extremely cool.

LSASS.EXE is the process that handles Windows security auditing. In the usual on-file auditing system it sees when files and registry keys are being opened, notes the SACL attached to that file, and sends the auditing data into the security event log. When the file is opened using GOAA, LSASS also adds to the SACL in memory, then reads it like it had been assigned on the resource directly. Sort of psyches itself out.

So even though I have no auditing configured on these files:

Deleting a file gives me my audit trail:

To be clear here: you must also turn on “Object Access \ Audit File System” or “Object Access \ Audit Registry” in order to have the actual auditing end up in your event log, just like always – GOAA does not enable all auditing, it just adds the magic SACL.

Other Notes

GOAA and the actual on-file audit entries of NTFS can coexist without issues. So if each has different settings, the combined SACL will be used for auditing. There’s no way they could conflict; worst case, they would be redundant. You only get a discrete audit event per action as well – there’s not a “GOAA event” and a regular event.

You can also use AUDITPOL.EXE /RESOURCESACL to view and set these settings outside of group policy; this is an important distinction as the usual auditpol.exe /get /category:* will not show these effective settings. Note that when specifying the /type value that the arguments are - rather disappointingly - case sensitive. So /type:file will not work but /type:File will.

The only reason you’d ever set through this utility would be in an unmanaged environment with no security policy being applied by the domain. And since you can’t manage the computer, odds are you can’t get to the audit logs remotely to see what’s happening, so this is one of those “not very likely” scenarios.

As far as what actions you should audit – that’s up to you. The Book of Fitzgerald states that enabling Failure auditing is usually a bad idea. Auditing “List Folder / Read Data” and their ilk of file access entries are probably not very useful. I recommend you invest in an audit collection product if this is going to be enabled all the time as your logs are only useful if they are retained.

And yes, this works great with DFSR. Since you are not actually changing a file when you use GOAA, you are not going to trigger unnecessary replication with the act of setting up auditing in the first place. For example, here I add a SACL to a replicated file the old fashioned way. Note in the DFSR debug log how this triggers a USN update and the file changes get replicated to all partners via RDC:

20110308 20:08:04.339 2788 USNC  2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:

+      USN_RECORD:

+      RecordLength:        104

+      MajorVersion:        2

+      MinorVersion:        0

+      FileRefNumber:       0xF00000000E19C

+      ParentFileRefNumber: 0x70000000038A3

+      USN:                 0x85c658

+      TimeStamp:           20110308 20:08:04.339 Eastern Standard Time

+      Reason:              Close Security Change

+      SourceInfo:          0x0

+      SecurityId:          0x0

+      FileAttributes:      0x20

+      FileNameLength:      44

+      FileNameOffset:      60

+      FileName:            I am some user goo.rtf

But if I change my GOAA policy, nothing happens. It’s hard to show you a debug log of nothing happening so you’ll just have to take my word for it. :-)

Until next time.

Ned “admit it, you were excited” Pyle

Hiya folks, Ned here with a slightly late Mail Sack coming your way. Today we discuss reading event logs, PowerShell, FSMO, DFSR, DFSN, GCs, virtualization, RDC, LDAP queries, DPM, SYSVOL migration, and Netmon.

Do it.

• LogParser and Win2008 R2 security event logs
• DFS virtualization support
• Cross-forest trusts and the Infrastructure Master
• DFSR file rename and replication
• LDAP query to return only users
• DFSR and DPM compatibility
• DFSR migration in a multi-functional level forest
• NetMon loot

Question

Logparser.exe doesn’t seem to read the message body when run against Security event logs on Windows Server 2008 R2:

logparser -i:EVT -o:CSV -resolveSIDs:ON "SELECT * INTO goo.csv FROM security"

Security,97760,2011-03-09 07:57:23,2011-03-09 07:57:23,4689,8,Success Audit event,13313,The name for category 13313 in S
ource "Microsoft-Windows-Security-Auditing" cannot be found. The local computer may not have the necessary registry info
rmation or message DLL files to display messages from a remote computer,Microsoft-Windows-Security-Auditing,S-1-5-21-336
6683618-1989269118-3947618792-500|administrator|CONTOSO|0x57e6f4|0x0|0xbc8|C:\Windows\System32\mmc.exe,2008r2-01-f.conto
so.com,,A process has exited. Subject: Security ID: S-1-5-21-3366683618-1989269118-3947618792-500 Account Name: administ
rator Account Domain: CONTOSO Logon ID: 0x57e6f4 Process Information: Process ID: 0xbc8 Process Name: C:\Windows\System3
2\mmc.exe Exit Status: 0x0 ,

Answer

I am able to reproduce this issue. I can also see LogParser failing to parse some other ‘modern’ events in other logs, like the Application event log. Considering the tool was written in 2005 and only lists its support as Win2003 and XP, this looks like expected behavior.

You can do pretty much everything LogParser is doing with the event logs using PowerShell 2 on the later OS though, so you may not care to run this all down:

Get-WinEvent
http://technet.microsoft.com/en-us/library/dd367894.aspx

It is crazy powerful and can do Xpath, structured XML queries, and hash-table queries.

Even WEVTUTIL.EXE can do much of this, although not with as much output formatting control like PowerShell. Leave logparser to the older OSes.

Question

We’re thinking about virtualizing DFSR and DFSN. Is it supported? Are a lot of customers virtualizing these workloads?

Answer

Totally supported. Like anything virtual though, expect a slight performance hit.

There is a huge amount of virtualization happening. Enough now that you can just assume anything Windows is being run virtualized a lot. Maybe not many by percentage, but when your OS install base is in the hundreds of millions…

The main concern we have in this scenario is one we see on physical a lot now also (Warren can attest to this): the use of el cheapo iSCSI solutions rather than fiber-channel and other beefier network fabrics, especially combined with cheap SANs that have poor to non-existent support. You absolutely get what you pay for in this environment. The other thing to keep in mind is that - like all multimaster database systems - you absolutely CANNOT use snapshots with it: http://support.microsoft.com/kb/2517913/ 

Question

Do cross-forest trusts figure into Infrastructure Master FSMO role placement? I.e. can the IM run on a GC if the other forests is not all GCs too? I have two single-domain forests with a cross-forest Kerberos trust.

Answer

• In the single domain forest it doesn’t matter where it goes at all, as the IM has no work to do until you have multiple domains in that forest.
• If that single domain forest ever adds a domain, each IM will need to run on a non-GC server unless all DCs in that individual domain are also GCs.
• The IM doesn’t care about the other forest at all. The forest is a boundary of what the IM is tracking, it does not traverse Kerberos trusts to other forests.
• One more bit of recent weirdness that we don’t mention often: Once you enable the AD Recycle Bin, the Infrastructure Master stops mattering as a FSMO role and each DC takes on the role of updating themselves in regards to cross-domain object references (see http://msdn.microsoft.com/en-us/library/cc223753(PROT.13).aspx)

Question

When using DFSR and you rename a file does the whole file get replicated? What about if the same file exists in two different folders folders: will each one replicate when a user makes copies of files between different folders?

Answer

1. Nope: http://blogs.technet.com/b/askds/archive/2009/04/01/understanding-dfsr-debug-logging-part-9-file-is-renamed-on-windows-server-2003-r2.aspx

2. Not if using at least one server with Enterprise Edition in the replication partnership, so that cross-file similarity can be used:

http://blogs.technet.com/b/askds/archive/2010/08/20/friday-mail-sack-scooter-edition.aspx (see Question “The documentation on DFSR's cross-file RDC is pretty unclear – do I need two Enterprise Edition servers or just one? Also, can you provide a bit more detail on what cross-file RDC does?”)

Proof on this one (as I don’t have an article with debug log example):

Two files in two folders, both identically named, data’ed, secured. They have sequential UID version numbers. Below is the inbound debug log from the server replicating the files (heavily edited for clarity and brevity).

20110308 10:26:38.491 2264 INCO  3282 InConnection::ReceiveUpdates Received: uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe session:8 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csId:{C929D10A-601B-41D8-A620-2D161733473B} csName:badseed ß the first file starts replicating inbound

20110308 10:26:38.491 2592 MEET  1342 Meet::Install Retries:0 updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed updateType:remote

20110308 10:26:38.491 2592 MEET  4228 Meet::ProcessUid Uid related not found. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:38.491 2592 MEET  5692 Meet::FindNameRelated Access name conflicting file. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:38.491 2592 MEET  4647 Meet::GetNameRelated Name related not found. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:38.491 2592 MEET  3346 Meet::UidInheritEnabled UidInheritEnabled:0 updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:38.491 2592 MEET  1992 Meet::Download Start Download updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed csId:{C929D10A-601B-41D8-A620-2D161733473B} ß file replicated starts replicating inbound.

20110308 10:26:38.913 2592 RDCX   769 Rdc::SeedFile::Initialize RDC signatureLevels:1, uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe fileSize(approx):737280 csId:{C929D10A-601B-41D8-A620-2D161733473B} enableSim=1 ß added the file’s signature info to the cross-file RDC similarity table

20110308 10:26:39.131 2592 STAG  1215 Staging::LockedFiles::Lock Successfully locked file UID: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 GVSN: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 state: Downloading (refCount==1)

20110308 10:26:39.131 2592 STAG  4107 Staging::OpenForWrite name:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222

20110308 10:26:39.225 2592 INCO  6593 InConnection::LogTransferActivity Received RAWGET uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe connId:{07C54B74-C2FB-4417-8830-3488E368480B} csId:{C929D10A-601B-41D8-A620-2D161733473B} stagedSize:361599 ß file was replicated WITHOUT RDC as we had never seen this file before and had no similar files anywhere

20110308 10:26:39.225 2592 MEET  2163 Meet::Download Done downloading content updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.241 2592 STAG  1215 Staging::LockedFiles::Lock Successfully locked file UID: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 GVSN: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 state: Downloaded (refCount==1)

20110308 10:26:39.241 2592 STAG  1263 Staging::LockedFiles::Unlock Unlocked file UID: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 GVSN: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 state: Downloading (refCount==0) ß done staging file

20110308 10:26:39.241 2592 MEET  2775 Meet::TransferToInstalling Transferring content from staging area into Installing updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  2808 Meet::TransferToInstalling Obtaining fid of the newly installed file updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  2821 Meet::TransferToInstalling Read 733988 bytes, wrote 733988 bytes updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed ß expanded from staging into the Installing folder

20110308 10:26:39.256 2592 MEET  2225 Meet::Download Download Succeeded : true updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed csId:{C929D10A-601B-41D8-A620-2D161733473B}

20110308 10:26:39.256 2592 MEET  4228 Meet::ProcessUid Uid related not found. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  5692 Meet::FindNameRelated Access name conflicting file. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  4647 Meet::GetNameRelated Name related not found. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  3346 Meet::UidInheritEnabled UidInheritEnabled:0 updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  3013 Meet::InstallRename Moving contents from Installing to final destination. Attributes:0x20 updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  3043 Meet::InstallRename File moved. rootVolume:{E6D66386-E6B2-11DF-845F-806E6F6E6963} parentFid:0x2AA00000000E2BD fidInInstalling:0x100000000E2C3 usn:0xb01ec28 updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  3143 Meet::InstallRename Update database with new contents updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  3234 Meet::InstallRename Updating database. updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 MEET  3244 Meet::InstallRename -> DONE Install-rename completed updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed csId:{C929D10A-601B-41D8-A620-2D161733473B} ß moved the file into the replicated folder, done replicating for all intents and purposes

20110308 10:26:39.256 2592 MEET  1804 Meet::InstallStep Done installing file updateName:samefile.exe uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 connId:{07C54B74-C2FB-4417-8830-3488E368480B} csName:badseed

20110308 10:26:39.256 2592 STAG  1263 Staging::LockedFiles::Unlock Unlocked file UID: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 GVSN: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 state: Downloaded (refCount==0)

Now I copy the exact same file into another folder on the upstream server, with same security, attributes, data, and name. Just a different path.

 

20110308 10:26:56.497 2592 RDCX  1311 Rdc::SeedFile::UseSimilar similarrelated (SimMatches=16) uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12223 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12223 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B} (related:

uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B}) ß the server recognizes that the new file it was told about has an identical copy already replicated to another folder.

20110308 10:26:56.497 2592 STAG  1215 Staging::LockedFiles::Lock Successfully locked file UID: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 GVSN: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 state: Downloaded (refCount==1)

20110308 10:26:56.497 2592 RDCX  1510 Rdc::SeedFile::UseRelated "SimilarityRelated" file already staged uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12223 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12223 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B} (related: uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B}) ß even better, the file is still staged, so we don’t have to go stage a copy

20110308 10:26:56.497 2592 RDCX  3742 Rdc::FrsSignatureIndexFile::Open Opening FrsSignatureIndexFile OK for write Levels=1..1 uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222

20110308 10:26:56.497 2592 RDCX   467 StreamToIndex RDC generate begin: (0..1), uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B}

20110308 10:26:56.513 2592 RDCX   509 StreamToIndex RDC generate end: (0..1), uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B}

20110308 10:26:56.513 2592 RDCX  3742 Rdc::FrsSignatureIndexFile::Open Opening FrsSignatureIndexFile OK for read Levels=1..1 uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222

20110308 10:26:56.513 2592 RDCX  2359 Rdc::SeedFile::OpenSeedSigDB Using seed file for uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12223 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12223 fileName:samefile.exe csId:{C929D10A-601B-41D8-A620-2D161733473B} seed(type:SimilarityRelated uid:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 gvsn:{0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 fileName:samefile.exe depth=1) ß we then create a new copy of the file using the signature bytes from the old copy. The actual new file is not copied over the wire.

20110308 10:26:56.653 2592 STAG  1263 Staging::LockedFiles::Unlock Unlocked file UID: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 GVSN: {0F26D474-860E-4A5D-9466-19B11C468E26}-v12222 state: Downloaded (refCount==0)

ß after this it will look just like the first file where it gets expanded to Installing, copied to real RF.

Question

Whenever I use LDIFDE or CSVDE to export just users, I also get computers. How do all these other LDAP apps do it? 

There should only be 14 users in this test domain but I get 33 entries that include computers.

Answer

There are a number of ways to skin this cat.

Give this LDAP filter a try:

ldifde -f foo.txt -r "(&(!objectclass=computer)(objectclass=user))"

See the difference? It is including any objects who have a class of ‘user’ but excluding (with the “!”) any that are also class of ‘computer’. This is necessary because computers are users. :) See the first few lines of one of the computers returned by the original query:

dn: CN=XP-05,CN=Computers,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: XP-05
distinguishedName: CN=XP-05,CN=Computers,DC=contoso,DC=com
instanceType: 4
whenCreated: 20101201143854.0Z
<snip>

A good alternative from the Comments: (&(objectCategory=person)(objectClass=user))

And another good one: (sAMAccountType=805306368)

(You guys think about this a lot don't you? :P) 

Question

Are DFSR and DPM compatible?

Answer

Yes, as long as your DFSR servers have this KB977381 version (or newer) of DFSR.EXE/DFSRS.EXE installed, they are compatible. The article doesn’t state it, but the filter driver I/O requests that DFSR didn’t understand were DPMs.

Question

Is it ok to migrate SYSVOL to DFSR before you have all domains in the forest at a Windows Server 2008 domain functional level, or the whole forest at Windows Server 2008 forest functional level? Do I need to be concerned about site-based policies that might be accessed through out the forest?

Answer

Per-domain is fine, the individual domains don’t matter to each other at all in regards to SYSVOL migration. GP is completely unaware of the replication type, so site-based policies don’t matter either. The main effect will be that once you have DFSR being used, you will hopefully have fewer GP problems due to replication latency and FRS’ general instability.

Regardless: make sure you are using our latest DFSRS, DFSRMIG and ROBOCOPY hotfixes.

KB972105 All files are conflicted on all domain controllers except the PDC Emulator when a DFSR migration of the SYSVOL share reaches the Redirected state in Windows Server 2008 or in Windows Server 2008 R2 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;972105

KB968429  List of currently available hotfixes for Distributed File System (DFS) technologies in Windows Server 2008 and in Windows Server 2008 R2 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;968429

Netmon Loot

If you use NetMon, make sure you check out all of the sweet experts and parsers that keep coming out of various teams. We don’t advertise these well, but there are some really useful ones these days:

• Office and SharePoint Products Network Monitor Parsers
• Office Communications Server Netmon Parsers
• Absolute latest Netmon built-in parsers
• NmDecrypt
• Top Users
• Top Protocols
• Simple Search
• NetWiz

- Ned “Tired” Pyle

Hi everyone, David Beach here today.

Here’s a fun AD Replication error from Windows Server 2003:

 Sitename\DCName via RPC
    DC object GUID: abc12345-6789-0123-4567-890abcdefabc
    Last attempt @ 2011-03-15 12:15:15 failed, result 1127 (0x467):
      While accessing the hard disk, a disk operation failed even after retries.
      8 consecutive failure(s).
      Last success @ (never).

If you’ve seen that in a repadmin.exe output, your first reaction was probably along the lines of: “Wait, what?” Especially when it only happens for one partition.

It turns out that this error code doesn’t really mean what it appears to mean. What’s happening here is that the JET database engine is returning an error code to Active Directory like -1206 (JET_errDatabaseCorrupted). AD then tries to map that Jet error to a Win32 error code, and the result is what you see above.

Note: To find out what the underlying JET error code means use NTDS diagnostic logging which you can turn on via the registry. Be very careful if you do this – it will flood your event logs, and you may find yourself in a needle-in-a-haystack situation trying to parse useful data out of them afterwards. If you’ve ever wondered what all the different JET error codes mean, you can look here.

Fixing this error is a very easy process, but your change control folks may hate you for it in the end:

First, find the DC that’s the source of all the problems. To do this, I recommend running repadmin /showrepl * /csv >somefile.csv – look and see who everyone else is having trouble replicating FROM with the error above (remember, AD replication connections are always pull operations, so when you look at repadmin output on a server, what you’re seeing is the status of the last attempted pull). That’s your bad DC.

The /CSV above goes and gets this kind of data for every DC that it can contact and then dumps it in a format you can import into Excel to manipulate (this makes it much easier to compare between DCs). For blog readability, here’s a screenshot of what one DC looks like in .txt format:

You can see from the above that this DC is complaining about the problems with one partition in the database, which is usually how this failure will come up.

Once you’ve found the DC that’s causing all the problems (it will usually be one domain controller that everyone is having trouble replicating from), then you can take some steps to try and recover the database. I should mention here that in the vast majority of these cases we’ve seen, the database was unrecoverable and the DC had to be demoted. Here’s what to do:

1. Boot to Directory Services Restore Mode using F8.

2. Run ntdsutil and type “files integrity” at the main prompt.

This will execute an integrity check on the database files. It will very likely come back and tell you that errors were found (if it doesn’t, make sure you have the right DC).

3. If the integrity check found errors, execute a semantic database analysis. To do that, at the main ntdsutil prompt, type “semantic database analysis”. Then, at the next prompt, type “Go”

When you do this, ntdsutil does a low-level formatting check on the structure of the database. It looks for structural problems that can cause queries to fail. This will take a short time depending on the size of your database, and then will tell you what it found.

4. To tell the semantic checker to try and fix things that it found, run it again, but this time type “Go Fixup”. This will execute the checker again in Fixup mode, meaning that it will try to correct errors as it encounters them. This is what we call a safe repair – it won’t delete data, and if it encounters a record that it can’t reconstruct properly, it will skip that record and move on to the next rather than damage the database further.

When the check above finishes, ntdsutil will try to tell you if there are any errors remaining in the database. As mentioned above, in most of these cases, the database was too far gone to be recovered, so we saw errors even after the semantic checker was done (or in some cases it was forced to abort). You can reboot to normal mode if you want to see how things perform. At this point you should get a current backup of the DC with systemstate and all files, as the next steps may cause you to lose data and your forensic trail. You can also trying restoring an older systemstate backup from before the failure.

If replication is still failing with the same error, then you only have one option left to you – demote the domain controller. To do this, use dcpromo /forceremoval. The /forceremoval option tells dcpromo to ignore errors and proceed with demotion. This is necessary because in order to demote gracefully, a domain controller has to do one final replication cycle with its peers. Since replication is irrevocably broken in this case, you’ll need to override that to proceed.

The dcpromo process will locally remove the information in AD and DNS that designates this machine as a domain controller, but make sure you run through this metadata cleanup article afterwards on a surviving DC; the other domain controllers won’t know this server has been demoted. Once this is done, your former domain controller will now be a member server, and you can take whatever recovery steps seem appropriate. We usually recommend formatting the hard drive and reinstalling the OS, as well as making sure drivers, bios, and firmware are all updated before you promote the machine to be a domain controller again.

Regardless of whether you end up rebuilding your DC or not, you want to think about root cause here. Most of the time, JET database corruption happens because of a hardware issue – a flaky hard disk controller, a bad memory chip, or even just a hard drive that decides to drop some sectors suddenly. It can also happen because of problems with installed third-party file system filter drivers. The bottom line is that if you see this happen to a server, you want to make sure there’s not another issue happening under the hood before you go and make it a DC again, so get whatever tools your hardware vendor provides to check it out and make sure it’s all in good shape.

This might be a good time to mention that you should have multiple DCs so that your enterprise has some resilience if you encounter this kind of unexpected failure. You do have multiple DCs in each domain you’re running, right?

--David “there’s only one way to be sure” Beach

Hello again everyone.  Last week we had one new KB article for DFSR replication:

Also, be sure to check out our TechNet Wiki site for new content as well:

Cheers!