Friday, August 31, 2018

Active Directory - DCDIAG 2 - specific tests and DNS

In my previous blog post, I presented the default tests performed when we run DCDIAG. We can concentrate on specific components with the switch /test: followed by the specific test we want to run, for example:

dcdiag /test:Sysvol

In the following lines, I'll demonstrate how to run these specific tests and in particular the tests for DNS that are not run by default (and must be run separately).


***


When we run a specific test, without additional switches, we have the output shown in the screenshot below. I use the example of the "advertising" test (note that DCDIAG is not case-sensitive). Remember that the test "Connectivity" is always peformed, regardless of the specific tests that we run.

dcdiag /test:Advertising



All we see if that the domain controller "passed test Advertising (and Connectivity)". If we want to see more details, we can add the verbose switch /v as we did for the default tests in my previous post. We then see something like this (with the Topology test as the example):



Remark: since much of the output consists in the mention of "Test omitted by user request", my screenshot concentrates on the output concerning the test that interests us.


For DNS, we can run six different tests, individually or in combination:

/DnsBasic
/DnsForwarders
/DnsDelegation
/DnsDynamicUpdate
/DnsRecordRegistration
/DnsResolveExtName

Some of the test names are self-explanatory but additional details can be found in this article:

DCDIAG

If we want to run all tests, we do not have to type each switch one after the other. This switch is enough:

/DnsAll


Without the verbose switch, output looks exactly like that for other individual tests, other than the message that DNS tests are running and that we should be patient:



In verbose mode, we can see the test details which would be especially useful in case of errors. This is the verbose output for the /DnsBasic test (once again, the screenshot focuses on the relevant section):



At the end, there is a summary of the test results:


Only the tests run have a PASS or FAIL status. The status of the others is n/a.


We can test DNS forwarders with dcdiag /test:DnsForwarders. The forwarders will be shown (OpenDNS in my case) and then the result:



We can test our delegations with /DnsDelgations. In my case, there is simply the delegation to the zone _msdcs.mynet.lan:



The registration test will verify the many SRV records in DNS. The output is so long, I only show a small portion below:






If we use the switch /DnsAll, the summary would look like this if all tests are successful:




Monday, August 27, 2018

Active Directory - DCDIAG 1 - presentation of the default tests

I use this tool quite often (among others) to verify the health of the domain controllers that I manage. In the lines that follow, I want to review what each test accomplishes which in itself is not very original. There are already a number of sources available on the subject, this article by Ned Pyle for example:

What does DCDIAG actually… do?

For some originality, I intend to add my own comments on a couple errors that appear, if they can safely be ignored and if not, what measures can be taken. This will not be exhaustive: I'll only concentrate on some errors I have seen, in a rather simple scenario with a single forest, domain and even site.

The first thing to point out is that errors are quite common when we execute DCDIAG shortly after a reboot. Some Active Directory related services may attempt to interact with others that have not finished starting. Observing errors in DCDIAG, and in the Event Viewer for that matter, do not necessarily indicate a serious problem.


***

Some preliminary remarks...

We can obtain help on DCDIAG (and see options) with either of these switches:

  • dcdiag /?
  • dcdiag /h

These are some of the more common options:

  • /s: use the indicated server, for example: dcdiag /s:DC1
  • /a: test all servers in the site
  • /e: test all servers in the enterprise (overrides /a)
  • /c: runs comprehensive tests (default tests and more but not "dcpromo" and "RegisterDNS".
  • /v: provides verbose output (more details)
  • /q: Quiet - opposite of verbose, only error messages
  • /f: direct output to a text file (can be easier to read), for example: dcdiag /f:C:\TS_AD\dcdiag1.txt
  • /fix: this can fix certain problems and is sometimes run in conjonction with "net stop netlogon & net start netlogon". In particular, it can re-register domain controller SRV records.

In forums, we often see helpers request the out of DCDIAG with a combination of the switches above, for example:

dcdiag /e /c /v /f:C:\Folder\dcdiag1.txt

Sometimes the output of the following is requested as well:

repadmin /replsum
repadmin /showrepl
ipconfig /all - for each domain controller


Remark: it is useful to execute DCDIAG "as administrator" if UAC is enabled. In the past, I have encountered errors when not running it as administrator.

Remark: not all possible DCDIAG tests are run by default. In particular, DNS tests must be run separately.


***

I will list and comment the tests as they appear in my output ("default" dcdiag without the /v or the /c switch).


Connectivity

This test evaluates the following points:

  • Is the server registered in DNS?
  • Is the server pingable?
  • Verification of LDAP/RPC connectivity

Remark: Active Directory replication uses RPC.



Advertising

Can the domain controller advertise all the roles that it holds?

The roles here are not the single master operation roles (the "FSMO" roles) since only one domain controller can hold these at a given time. Instead, these would be the roles that we see with the nltest command...

nltest /dsgetdc:NameOfDomain

Note: looks at the "flags".

This is also very clear if we look at the verbose output (/v switch).

Remark: possible cause of problem? Netlogon service not started.



FRSEvent

DFS-R (see the next test) is used more and more often so the indication that this test passed can be puzzling. In fact, it is skipped if we have migrated to DFS-R. This is explicitly stated in the verbose output of DCDIAG (with the /v switch).



DFSREvent

This looks for "operation errors" in DFS (last 24 hours). I often see a failure here (notably after a reboot). This is probably referencing the  DFS Replication log where there is often an entry with EventID 1202: "The DFS Replication service failed to contact (a) domain controller [...]. Replication is stopped". This can be ignored if followed by an EventID 1206 and 1210: "The DFS Replication service successfully contacted domain controller "DC1" to acess configuration information" and "The DFS Replication service successfully set up a RPC listener for incoming replication requests".

Remark: the replication mentioned here is that of the content of the SYSVOL and NETLOGON shares holding components of Group Policy and scripts.

Otherwise, if we have DFSRDIAG installed...

Install DFSRDIAG On Windows 2012 R2 and Windows 2016

We could run this command to verify DFSR:

dfsrdiag pollad /verbose


Sysvol

This verifies that SYSVOL is being advertised (dependent on a registry key - see the link to Ned Pyle's article). Other tests verifiy if the SYSVOL (and NETLOGON) share is accessible.


KccEvent

This checks for KCC errors in the "Directory Service" Event Log in the last 15 minutes.



KnowsOfRoleHolders

Does the domain controller know which domain controller holds the operation master (or "FSMO") roles? In verbose mode, we can see which server the domain controller (on which we run the test) shows as the role holder.



MachineAccount

This verifies that the domain controller's computer account exists in Active Directory and is located in the domain controllers OU. It also verifies a number of SPNs (visible in verbose mode). If there is a problem with the machine account, there are repair options but they should be used with caution. The recreation of the computer account does not recreate necessary domain controller child objects. See the link above to Ned Pyle's article for more information.



NCSecDesc

Checks the security (permissions) on each of the Active Directory naming contexts (partitions): domain, configuration, schema, and NDNC DomainDNSZone and ForestDNSZone.

On Windows 2008 R2 domain controllers, I will see this error:

"Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes In Filtered Set"

If you do not use read-only domain controllers (RODC), it can be ignored. I do not see this with Windows 2016 domain controllers.

Dcdiag fails for NCSecDesc test on Windows 2008 Domain Controllers



NetLogons

Checks "logon privileges" for not only the NETLOGON share (as the name of the test suggests) but also the SYSVOL share. This is evident in verbose mode. In other words:  are NETLOGON and SYSVOL accessible? The test "CheckSecurityError" also validates this (see below). As mentioned earlier, the Sysvol test does not validate accessibility but rather advertisment of the SYSVOL share.



ObjectsReplicated

Checks if the machine account object in Active Directory and the DSA object are up-to-date on other domain controllers. Apparently, this test is only effective if dcdiag is run with either the /a or /e parameter. Yet in verbose mode (with no other switches), I see that the two objects verified (CN=DC1 and CN=NTDS Settings) are supposedly "up-to-date on all servers".



Replications

Checks for timely replication between domain controllers for all five naming contexts (partitions). I have not attempted to create errors but there would be some warning if replication was disabled, failing or delayed.



RidManager

Is the RidManager accessible? Does it hold proper information? This test verifies that. In verbose mode, we can see details about the RID pool.

Note: Ned Pyle specifies that this role must be online (and accessible) for domain controllers to create security principals and other domain controllers to be promoted.



Services

This test verifies that all essential Active Directory services are running and correctly configured for startup (almost all are - and should be - set to "automatic"). In verbose mode, each service is listed with the test result.

These are the services listed in verbose mode:

- EventSystem
- RpcSs
- NTDS
- DnsCache
- DFSR
- IsmServ
- kdc
- SamSs
- LanmanServer
- LanmanWorkstation
- w32time
- NETLOGON



SystemLog

This test lists errors and warnings from the last 60 minutes in the System log.

It is the role of the administrator to determine if the errors and warnings require further attention or can be safely ignored.

This test usually fails after reboot because there are almost always some errors or warnings immediately afterwards.



VerifyReferences

This checks various object references that can be seen in verbose mode, for example serverReference, serverReferenceBL, msDFSR-ComputerReferenceBL).



CheckSDRefDom and CrossRefValidation

At the end of the default output (if we run DCDIAG without additional switches), DCDIAG verifies a number of elements in each of the naming contexts, including:

  • The presence of at least one KDC in the domain (Key Distribution Center - for Kerberos)
  • The presence of a computer account for the domain controller in Active Directory and in particular, in the domain controllers OU. This seems to duplicate elements of the MachineAccount test presented above.
  • Replication of the computer account to other domain controllers.


If we add the /replsource switch (not the case by default), a number of other elements are validated:

  • Time skew (under 300 seconds or 5 minutes - important for Kerberos).
  • Permissions on the naming contexts (so replication is possible: no access = no replication).
  • Permissions on the SYSVOL and NETLOGON shares (for proper replication of group policy objects and scripts).
  • Is the "Access this computer from the network" right granted to Administrators but also Authenticated users and Everyone?

Ned Pyle's article provides some more details. It sounds like it would be very rare to see errors for the CheckSDRefDom check.


***


That's a brief (or not so brief) presentation of the basic DCDIAG tests. But we can do more - and less - with DCDIAG. On one hand, we can run a number of tests that verify DNS. On the other, we can choose to run only specific tests, rather than all the tests presented above. That will be the subject of my next blog post.








Tuesday, August 21, 2018

Active Directory - PowerShell: Move-ADDirectoryServerOperationMasterRole

Before PowerShell, we could move the so called "FSMO" roles in the Windows GUI or with the ntdsutil tool. This required multiple steps in either case. With PowerShell, we can move one, some, or all of the roles with a single command - or cmdlet:

Move-ADDirectoryServerOperationMasterRole

The cmdlet is somewhat long but we only need to type...

Move-ADD

And then tab twice for the entire cmdlet (the first tab gives us "Move-ADDirectoryServer").

After the cmdlet itself, we designate the domain controller to which we want to move the role or roles.

For example:

Move-ADDirectoryServerOperationMasterRole DC1

-

Optionally, we can add the -identity parameter although it is not necessary since it is a positional parameter.

Move-ADDirectoryServerOperationMasterRole -identity DC1

-

After that, we indicate the roles to be moved, separated by a comma:

  • SchemaMaster
  • DomainNamingMaster
  • PDCEmulator
  • RIDMaster
  • InfrastructureMaster


Once again, we could (and should, when writing scripts) specify all parameters but here again, we can simply indicate the role to move:

Move-ADDirectoryServerOperationMasterRole DC1 InfrastructureMaster

-

If we indicate the parameter, we would have this:

Move-ADDirectoryServerOperationMasterRole DC1 -OperationMasterRole InfrastructureMaster

-

Better yet, we can be even more concise, indicating only the first letter of each role:

  • S
  • D
  • P
  • R
  • I

So we can do this:

Move-ADDirectoryServerOperationMasterRole DC1 I

Or this, since the roles are not case sensitive:

Move-ADDirectoryServerOperationMasterRole dc1 i

Or this, for multiple roles, separated by commas:

Move-ADDirectoryServerOperationMasterRole DC1 S,D,P,R,I


We have one more option. Each of the roles can be represented by a number. Following the same order as above:

3 - SchemaMaster
4 - DomainNamingMaster
0 - PDCEmulator
1 - RIDMaster
2 - InfrastructureMaster

With numbers, the cmdlet would look like this:

Move-ADDirectoryServerOperationMasterRole DC1 0,1,2,3,4



How can we verify the current holder of the roles with PowerShell? With the following cmdlets:

- Get-ADForest (for the forest wide roles: Schema Master and Domain Naming Master)
- Get-ADDomain (for the others)

There is a lot of information in the output so we can target the operation master roles using the words "master" and "emulator" as shown below:



Of course, we can still always use the following netdom command:



Now I'll move the roles from domain controller "DC2" to domain controller "DC1, designating the roles by number:


In the screenshot above, I confirmed the move for each role separately. If we enter "A" (for all) instead of "Y", we only need to confirm once.

After the move, we can confirm with the same cmdlets used before the move (or with netdom):


Thursday, August 16, 2018

Windows Server 2016 - configuration - IPv6 and Windows Defender

In this blog post, I'm aiming to add a Windows 2016 domain controller to my test environment that currently has a single 2008 R2 domain controller. First of all, since this is a simple test environment, I accept the risk of a single domain controller. Secondly, when building the server, I have to decide how to manage IPv6 and Windows Defender. Some organizations choose to disable IPv6 for various reasons and there are many discussions on this subject on forums, including the Microsoft Technet forums. I won't summarize the different arguments here but will remind the reader that Microsoft does not test Windows Server with IPv6 disabled (which could possibly complicate troubleshooting a problem with Microsoft technical support if it is disabled).  Microsoft recommends that instead of disabling IPv6, we should make Ipv4 the default IP protocol (since Windows 2008, IPv6 is the default). As for Windows Defender, I want to see if automatic exclusions for certain Active Directory components are added automatically when the Active Directory Domain Services role is installed.


***


IPv6

Some administrators disable IPv6 in TCP/IP properties. Once again, I have adopted another approach but want to observe the effect of making IPv4 the default. I would not expect any of the parameters shown below to become unchecked:




I'm going to scroll down and provide another screenshot so we can see all the IPv6 related items:



Here are the "Network Connection Details", comparable to what we would see at the command line with ipconfig /all. Although IPv6 is enabled, it is configured to "obtain an address (and DNS server) automatically". Since we have no DHCP server distributing IPv6 addresses, none of the IPv6 parameters have values, except for the link-local IPv6 addresss (which is auto-configured):





There is a multitude of articles online that present methods to disable IPv6 and its related components - or to make IPv4 the default IP protocol. Rather than simply unchecking IPv6 in the TCP/IP properties, the recommended method is to add a registry key named "DisabledComponents" and enter a hexadecimal value appropriate for our objectives. I used this Microsoft article as a reference:



The value for making IPv4 the preferred IP protocol is:

0x20

We can add the key manually, with the REG.exe tool, or with PowerShell. I opted for PowerShell and used this command:

New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\” -Name “DisabledComponents” -Value 0x20 -PropertyType “DWord”



We must restart the server for changes to take effect.

Here is a before and after comparison in regedit:







As expected, there is no effect on the TCP/IP settings:




***


Windows Defender


This section will be short. Windows Defender exclusions are added automatically, for a given server role, when that role is installed.

"If you are using Windows Defender Antivirus to protect Windows Server 2016 machines, you are automatically enrolled in certain exclusions, as defined by your specified Windows Server Role."


I thought (without reading further at the time) that I might be able to see the exclusions here (in the Windows Defender properties):



In fact, the automatic role-based exclusions are not displayed here:

"These exclusions will not appear in the standard exclusion lists shown in the Windows Defender Security Center app."

I was not able to find a method to display what automatic exclusions are in place.