Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

Archive for the ‘Core Networking Services’ Category

(2013-11-17) Time Sync Recommendations For Virtual DCs On Hyper-V – Change In Recommendations (AGAIN)

Posted by Jorge on 2013-11-17


The default time synchronization hierarchy within any AD forest is shown in the picture below.

image_thumb7

Figure 1: Default Time Synchronization Hierarchy Within Any AD Forest

As displayed in figure 1, DCs have their own time synchronization mechanism. When virtualizing DCs the time synchronization mechanism between the virtual DC (the VM guest) and the VM host must be disabled and it must be ensured the time synchronization mechanism natively used by the DCs is NOT disturbed. Reasoning for this is the high dependency that other processes (e.g. replication, authentication, etc.) have with accurate time.

OLD RECOMMENDATIONS:

  • Disable “Time Synchronization” within the Hyper-V Integration Services for each virtual DC VM (VM must be OFFLINE for this!)

image14

Figure 2: Hyper-V Time Synchronization Services In DISABLED State

  • Disable the “VM IC Time Provider” on every virtual DC through the registry or through a custom GPO setting
    • Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider
    • Name: Enabled
    • Type: REG_DWORD
    • Data: 0x00000000

PREVIOUS RECOMMENDATIONS:

  • Leave “Time Synchronization” within the Hyper-V Integration Services ENABLED (DO NOT DISABLE!) for each virtual DC VM (VM must be OFFLINE for this!)
    REMARK: Microsoft documentation or other blogs may still advise in disabling time sync with the host. That information is incorrect! Leave it enabled!
  • Disable the “VM IC Time Provider” on every virtual DC through the registry or through a custom GPO setting
    • Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider
    • Name: Enabled
    • Type: REG_DWORD
    • Data: 0x00000000

NEW RECOMMENDATIONS:

  • Disable “Time Synchronization” within the Hyper-V Integration Services for each virtual DC VM (VM must be OFFLINE for this!)

image14

Figure 3: Hyper-V Time Synchronization Services In DISABLED State

UPDATE (2013-12-14): make sure to have the following hotfix (KB2902014) if the Hyper-V host is running WIN8 or W2K12

Additional information about configuring Time Sync for DCs can be found through the following links:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Core Networking Services, NTP, Virtualization | 6 Comments »

(2011-09-14) Time Sync Recommendations For Virtual DCs On Hyper-V – Change In Recommendations

Posted by Jorge on 2011-09-14


UPDATED: (2013-11-17) Time Sync Recommendations For Virtual DCs On Hyper-V – Change In Recommendations (AGAIN)

The time synchronization hierarchy within any AD forest is shown in the picture below.

image

Figure 1: Default Time Synchronization Hierarchy Within Any AD Forest

As displayed in figure 1, DCs have their own time synchronization mechanism. When virtualizing DCs the time synchronization mechanism between the virtual DC (the VM guest) and the VM host must be disabled and it must be ensured the time synchronization mechanism natively used by the DCs is NOT disturbed. Reasoning for this is the high dependency that other processes (e.g. replication, authentication, etc.) have with accurate time.

PREVIOUS RECOMMENDATIONS:

  • Disable “Time Synchronization” within the Hyper-V Integration Services for each virtual DC VM (VM must be OFFLINE for this!)

image

Figure 2: Hyper-V Time Synchronization Services In DISABLED State

  • Disable the “VM IC Time Provider” on every virtual DC through the registry or through a custom GPO setting
    • Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider
    • Name: Enabled
    • Type: REG_DWORD
    • Data: 0x00000000

NEW RECOMMENDATIONS:

  • Leave “Time Synchronization” within the Hyper-V Integration Services ENABLED (DO NOT DISABLE!) for each virtual DC VM (VM must be OFFLINE for this!)
    REMARK: Microsoft documentation or other blogs may still advise in disabling time sync with the host. That information is incorrect! Leave it enabled!
  • Disable the “VM IC Time Provider” on every virtual DC through the registry or through a custom GPO setting
    • Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider
    • Name: Enabled
    • Type: REG_DWORD
    • Data: 0x00000000

Additional information about configuring Time Sync for DCs can be found through the following links:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), NTP, Virtualization | 3 Comments »

(2011-09-11) Service (SRV) Locator Records Registered By Windows Domain Controllers

Posted by Jorge on 2011-09-11


Windows DCs register a set of service locator records in DNS to be able to service both windows and non-clients. The complete list of service (SRV) records is specified below with an explanation of the service that’s represented, including which clients used it. By default. Windows DCs register all available service records. This is OK for datacenter located RWDCs. For RWDCs not located in datacenters, the RWDCs need to be told not to register the domain-wide SRV records. This can be achieved through the registry or through a GPO. The latter of course is preferred and a best practice. For more information about how to configure RWDCs NOT to register specific mnemonics see this blog post. RODCs by default only register site-wide SRV records, so no need to use a GPO to tell the RODC not to register domain-wide SRV records.

The NetLogon service on a DC, during boot and regularly (every hour, and previously that was every 24 hours), is responsible to registering the correct service records. The service records that will be registered are listed in the “netlogon.dns” file in the “C:\Windows\System32\config” folder. An example of this file is shown below.

image

 

It is also possible to force the registration and deregistration of the service records that should be registered/deregistered. The commands are:

  • Forced manual registration: NLTEST /DSREGDNS
  • Forced manual deregistration: NLTEST /DSDEREGDNS:<FQDN DC>

The following RFC provide detailed information about this: “A DNS RR for specifying the location of services (DNS SRV)

The SRV record is used to map the name of a service (in this case, the LDAP service) to the DNS computer name of a server that offers that service. In a Windows Server network, an LDAP resource record locates a domain controller. A workstation that is logging on to a Windows domain queries DNS for SRV records in the general form:

_Service._Protocol.DnsDomainName

Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server by querying DNS for a record of the form:

_ldap._tcp.DnsDomainName

_msdcs Subdomain

There are possible implementations of LDAP servers other than Windows based domain controllers. There are also possible implementations of LDAP directory services that employ Global Catalog servers but are not servers that are running Windows Server. To facilitate locating Windows Server–based domain controllers, in addition to the standard _Service._Protocol.DnsDomainName format, the NetLogon service registers SRV records that identify the well-known server-type pseudonyms "dc" (domain controller), "gc" (Global Catalog), "pdc" (primary domain controller), and "domains" (globally unique identifier, or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain allows location of domain controllers that have Windows Server–specific roles in the AD domain or AD forest, as well as the location by GUID when an AD domain has been renamed (more info about domain rename can be found here). To accommodate locating domain controllers by server type or by GUID (abbreviated "dctype"), Windows Server–based domain controllers register SRV records in the following form:

_Service._Protocol.DcType._msdcs.DnsDomainName

The addition of the _msdcs subdomain means that two sets of DNS names can be used to find an LDAP server: DnsDomainName is used to find an LDAP server or Kerberos server that is running TCP (or, in the case of a Kerberos server, either TCP or the User Datagram Protocol [UDP]), and the subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP and also functioning in a particular Windows Server role. The name "_msdcs" is reserved for locating WIndows domain controllers. The single keyword "_msdcs" was chosen to avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc, dc, and gc) were kept short to avoid exceeding the maximum length of DnsDomainName.

SRV Records Registered by NetLogon

The list that follows provides the definitions of the names associated with registered SRV records. It also describes the lookup criteria supported by each record and the checks performed by Net Logon as each record is registered. Text in bold type denotes constant record components; text in italic type denotes variable names.

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name that is used during creation of the first domain controller when the AD domain tree is joined or created (that is, while the computer is running the Active Directory Installation Wizard). DnsForestName refers to the DNS domain name of the forest root AD domain.

The following is a list of the owner names of the SRV records that are registered by NetLogon. An owner name is the name of the DNS node to which the resource record pertains.

_ldap._tcp.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the AD domain named by DnsDomainName. The server is not necessarily a domain controller — that is, the only assumption that can be made about the server is that it supports the LDAP application programming interface (API). All Windows Server–based domain controllers register this SRV record (for example, _ldap._tcp.adcorp.lab.).

_ldap._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the AD domain named in DnsDomainName in the AD site named by SiteName. SiteName is the relative distinguished name of the site object that is stored in the Configuration container in Active Directory. The server is not necessarily a domain controller. All Windows Server–based domain controllers register this SRV record (for example, _ldap._tcp.amsterdam._sites.adcorp.lab.).

_ldap._tcp.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller (dc) of the AD domain named by DnsDomainName. All Windows Server–based domain controllers register this SRV record.

_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller for the AD domain named by DnsDomainName and in the AD site named by SiteName. All Windows Server–based domain controllers register this SRV record.

_ldap._tcp.pdc._msdcs.DnsDomainName.

Allows a client to locate the server that is acting as the primary domain controller (also known as a "PDC") in the AD domain named in DnsDomainName. Only the PDC emulator FSMO of the AD domain (the Windows Server–based domain controller that advertises itself as the primary domain controller to computers that need a primary domain controller) registers this SRV record.

_ldap._tcp.gc._msdcs.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD forest. Only domain controllers that are functioning as Global Catalog servers for the AD forest named in DnsForestName register this SRV record (for example, _ldap._tcp.gc._msdcs.adcorp.lab.).

_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD forest in the AD site named in SiteName. Only domain controllers that are serving as Global Catalog servers for the AD forest named in DnsForestName register this SRV record (for example, _ldap._tcp.amsterdam._sites.gc._msdcs.adcorp.lab.).

_gc._tcp.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD domain. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the AD forest named in DnsForestName registers this SRV record (for example, _gc._tcp.adcorp.lab.).

REMARK: In Windows Server, a Global Catalog server is a domain controller. Other non-Windows 2000 implementations of directory services can also register servers as Global Catalog servers.

_gc._tcp.SiteName._sites.DnsForestName.

Allows a client to locate a Global Catalog (gc) server for this AD forest in the AD site named in SiteName. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the AD forest named in DnsForestName registers this SRV record (for example, _gc._tcp.amsterdam._sites.adcorp.lab.).

_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName.

Allows a client to locate a domain controller in an AD domain on the basis of its GUID. A GUID is a 128-bit number that is automatically generated for referencing objects in Active Directory – in this case, the AD domain object. This operation is expected to be infrequent; it occurs only when the DnsDomainName of the AD domain has changed, the DnsForestName is known, and DnsForestName has not also been renamed (for example, _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.adcorp.lab.). All domain controllers register this SRV record.

_kerberos._tcp.DnsDomainName.

Allows a client to locate a server that is running the Kerberos KDC service for the AD domain that is named in DnsDomainName. The server is not necessarily a domain controller. All Windows Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._udp.DnsDomainName.

Same as _kerberos._tcp.DnsDomainName, except that UDP is implied.

_kerberos._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the Kerberos KDC service for the AD domain that is named in DnsDomainName and is also in the AD site named in SiteName. The server is not necessarily a domain controller. All Windows Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._tcp.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller that is running the Windows Server implementation of the Kerberos KDC service for the AD domain named in DnsDomainName. All Windows Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos v5 protocol Authentication Service Exchange subprotocol) register this SRV record.

_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName.

Allows a client to locate a domain controller that is running the Windows Server implementation of the Kerberos KDC service for the AD domain that is named in DnsDomainName and that is also in the AD site named in SiteName. All Windows Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos protocol Authentication Service Exchange subprotocol) register this SRV record.

_kpasswd._tcp.DnsDomainName.

Allows a client to locate a Kerberos Password Change server for the AD domain. All servers that provide the Kerberos Password Change service (which includes all Windows Server–based domain controllers) register this name. This server at least conforms to "Kerberos Change Password Protocol”. The server is not necessarily a domain controller. All Windows Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kpasswd._udp.DnsDomainName.

Same as _kpasswd._tcp.DnsDomainName, except that UDP is implied.

If multiple domain controllers have the same criteria, multiple records exist with the same owner name. A client that is looking for a domain controller with specific criteria would receive all the applicable records from the DNS server. The client would pick one of the returned records to select a domain controller, as described in the RFC "A DNS RR for specifying the location of services (DNS SRV)."

For information about the Kerberos v5 authentication protocol see:

Host Records for Non-SRV-Record-Aware Clients

NetLogon registers the following DNS A records for the use of LDAP clients that do not support DNS SRV records (that is, that are "non-SRV-aware"). The Locator does not use these records.

The following owner names of A (host) records are registered by NetLogon:

DnsDomainName.

Allows a non-SRV-aware client to locate any domain controller in the AD domain by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up the name; an SRV-aware client looks up the appropriate SRV resource record.

gc._msdcs.DnsForestName.

Allows a non-SRV-aware client to locate any Global Catalog server in the AD forest by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up this name; an SRV-aware client looks up the appropriate SRV resource record.

NetLogon also registers a DNS CNAME (alias) record for use by Active Directory replication. The Locator does not use this record. The owner name of the CNAME record is:

DsaGuid._msdcs.DnsForestName.

Allows a client to locate any domain controller in the AD forest by looking up an A record. The only information that is known about the domain controller is the GUID (“objectGUID” attribute) of the directory system agent (also known as the "DSA") object (“NTDS Settings” object) for the domain controller and the name of the AD forest in which the domain controller is located. This record is used to facilitate renaming a domain controller.

Other SRV Record Content

The following information is also included in an SRV record:

  • Priority – The priority of the server. Clients attempt to contact the server with the lowest priority (a.k.a. lowest (cost)value).
  • Weight – A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight
  • Port Number – The port where the server is listening for this service.
  • Target – The fully qualified domain name of the host computer.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

 

Posted in Active Directory Domain Services (ADDS), Core Networking Services, DC Locator | 1 Comment »

(2011-06-17) HOTFIX For "The Size Of The AD Increases Rapidly On A W2K8R2 DC That Hosts The DNS Server Role"

Posted by Jorge on 2011-06-17


SOURCE: The size of the Active Directory increases rapidly on a Windows Server 2008 R2-based domain controller that hosts the DNS Server role

SYMPTOMS:

Consider the following scenario:

  • You install the Active Directory Domain Services role and the DNS Server role on a computer that is running Windows Server 2008 R2.
  • The computer hosts one or more Active Directory-Integrated DNS zones.
  • The Dynamic Updates setting on the General tab of the Properties page of locally held Active Directory-integrated DNS zones is set to Secure only.
  • The same DNS records are registered and deregistered frequently. For example, the same DNS records are registered and deregistered several hundred times per day.

In this scenario, the size of Active Directory database directory information tree (.dit) files increases significantly over time. If you track the change by using the repadmin /showchanges command, you see that most of the growth in file size is contributed by deleted DNS objects.

Note An increase in size of the NTDS.dit file in the Active Directory database path is exacerbated by the following factors:

  • Large values for the Tombstone Lifetime setting
  • Large volume of dynamic update record registration that is caused by large populations of Windows and third-party DNS clients, short DHCP lease durations, or code defects that cause third-party devices to register records too often
  • The enabling of the Active Directory Recycle Bin feature

CAUSE:

The issue occurs because of incorrect Active Directory tombstoning of DNS objects.

DNS clients should reuse the existing DNS objects that are marked to be deleted when they register DNS records. The existing DNS objects are usually referred to as "reanimating objects." However, currently the DNS server service creates a new object for these DNS clients and moves the existing DNS object to the deleted objects container. Over time, this behavior causes the Active Directory DIT file size to increase significantly.

Soooo…..

If you think your AD NTDS.DIT is behaving like a rabbit and you do not like that, then get the hotfix here. (Applies to both W2K8R2 RTM and W2K8R2 SP1)

For more info see: The size of the Active Directory increases rapidly on a Windows Server 2008 R2-based domain controller that hosts the DNS Server role

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Core Networking Services | 1 Comment »

(2011-01-01) DHCP And Name Protection In Windows Server 2008 R2

Posted by Jorge on 2011-01-01


For a project at a customer I wanted to implement Name Protection through DHCP in W2K8R2. With regards to DHCP and related technologies the requirements were as follows:

  • One or more RODCs are the only computers that can have contact with one or more RWDCs;
  • A firewall separates RODCs and AD member clients from RWDCs;
  • AD member clients should not register ‘A’ DNS record and the ‘PTR’ DNS record;
  • Implement DHCP on an RODC to perform DNS record registration/updates on behalf of the AD member clients;
  • Implement Name Protection through DHCP;
  • AD member clients are Windows Server and non-Windows computers (e.g. Unix).

Based on these requirements I wanted to implement and configure DHCP as follows:

  • Use specific credentials to perform all DDNS registrations and updates;
  • DHCP always registers and updates both ‘A’ DNS records and ‘PTR’ DNS records for both Windows and non-Windows AD member clients;
  • DHCP Reservation for every AD member client;
  • DHCP distributes the following configuration to AD member clients:
    • IP Address and Subnet Mask;
    • Lease Period (Option 051 – ‘Standard’ Vendor)
    • Router IP Address (Option 003 – ‘Standard’ Vendor);
    • DNS IP Addresses (Option 006 – ‘Standard’ Vendor);
    • DNS Domain Name (Option 015 – ‘Standard’ Vendor);
    • NetBIOS State (Option 001 – ‘Microsoft Windows 2000 Options’ Vendor);

Based on these requirements I wanted to implement and configure AD member clients as follows:

  • Windows AD member clients request DHCP to register both the ‘A’ DNS record and the ‘PTR’ DNS record on behalf of the AD member client

Because I wanted to implement Name Protection for the first I decided to perform tests in a staged manner, just to see what happens and what the differences are between the different scenarios

One thing that’s certain, is the behavior of the Windows AD member client:

  • [‘A’] Windows AD member client with static IP address configured: AD member client registers/updates both the ‘A’ DNS record and the ‘PTR’ DNS record;
  • [‘B’] Windows AD member client with dynamic IP address (through DHCP) configured: AD member client registers/updates the ‘A’ DNS record and requests DHCP to register/update the ‘PTR’ DNS record on behalf of it;

REMARK: In lots of document I see the following: "The DHCP server updates both the ‘A’ DNS record and the ‘PTR’ DNS record if requested by clients using option 81". I have never found a way to configure a Windows AD member client to request the DHCP server to register/update BOTH the ‘A’ DNS record and the ‘PTR’ DNS record! In other words, the Windows AD member client already knows how to request DHCP to register/update the ‘PTR’ DNS record, but how the heck do you configure the Windows AD member client to also request DHCP to register/update the the ‘A’ DNS record? Anyone knows this? If you do, then please place a comment!
According to the information in
RFC 4702, page 8 paragraph 3.3, such as request must be possible. However, I wonder if this has been implemented in the Microsoft’s DHCP.

REMARK: For more detailed information with regards to the DHCP protocol and especially in Windows, please see:

 

[‘Scenario 1’]

DHCP was configured as shown in the picture below. The Windows AD member client was configured as a DHCP client (dynamic IP address allocation) and in that case behavior [‘B’] will be experienced.

With this configuration the DHCP server will register a DNS record on behalf of the DHCP client only when that DHCP client actually requests it. In this case you will see that after the DDNS registration/update the ‘A’ DNS record is owned by the computer account of the AD member client and the ‘PTR’ DNS record is owned by the user account specified as DDNS credentials in DHCP.

image

image

image

image

image

image

In both the "DHCP Request" and the "DHCP Ack" messages you can see the DHCP client is registering the ‘A’ DNS record and the DHCP is NOT overriding it.

[‘Scenario 2’]

DHCP was configured as shown in the picture below. The Windows AD member client was configured as a DHCP client (dynamic IP address allocation) and in that case behavior [‘B’] will be experienced.

With this configuration the DHCP server will always register a DNS record on behalf of the DHCP client whether or not that DHCP client actually requests it. In this case you will see that after the DDNS registration/update both the ‘A’ DNS record and the ‘PTR’ DNS record are owned by the user account specified as DDNS credentials in DHCP.

image

image

image

image

image

image

In the "DHCP Request" message you can see the DHCP client is requesting to self-register the ‘A’ DNS record. Because of the DHCP server configuration, the DHCP server is overriding that request and is telling that to the DHCP client in the "DHCP Ack" message. The DHCP server is overriding the DHCP client’s request and the registration of the ‘A’ DNS record will be done by the DHCP server.

[‘Scenario 3’]

DHCP was configured as shown in the picture below. The Windows AD member client was configured as a DHCP client (dynamic IP address allocation) and in that case behavior [‘B’] will be experienced.

With this configuration Name Protection is enabled. As soon as Name Protection is enabled, the DHCP server is automatically configured to behave as specified in [‘scenario 1’]. The DHCP server will always register a DNS record on behalf of the DHCP client whether or not that DHCP client actually requests it. In this case you will see that after the DDNS registration/update both the ‘A’ DNS record and the ‘PTR’ DNS record are owned by the user account specified as DDNS credentials in DHCP.

image
image

image

image

image

image

image

In both the "DHCP Request" and the "DHCP Ack" messages you can see the DHCP client is registering the ‘A’ DNS record and the DHCP is NOT overriding it.

SUMMARIZED:

When Name Protection is enabled, I cannot fulfill the requirements I explained at the beginning of this post. So to fulfill my requirements I need to implement [‘scenario 2’] and NOT enable Name Protection.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Core Networking Services, Windows Server | 2 Comments »

(2010-09-26) Configuring And Managing The Windows Time Service (Part 4)

Posted by Jorge on 2010-09-26


In the previous post (part 3) I discussed how to configure the DCs so that these do not accept and therefore do not time jumps that are too large. Also taking the first post (part 1) and the second post (part 2) into account, it is now interesting to know how you can see what the configuration is a certain DC or AD (member) client is using.

To view the time source a DC or an AD (member) client currently is using to synchronize the time from, use the following command:

W32TM /QUERY /SOURCE

image

To view the Windows Time Service configuration a DC or an AD (member) client currently has, use the following command:

W32TM /QUERY /CONFIGURATION

image

(this picture shows the configuration of the DC with the PDC FSMO role)

The Windows Time Service can be configured to log information into the System event log. The two settings that are available for this are:

  • GPO Node: "Computer Configuration\Policies\Administrative Templates\System\Windows Time Service"
    • GPO Setting: "Global Configuration Settings" = Enabled
      • GPO Setting Item: "EventLogFlags" = 2 (default value)
  • GPO Node: "Computer Configuration\Policies\Administrative Templates\System\Windows Time Service\Time Providers"
    • GPO Setting: "Configure Windows NTP Client" = Enabled
      • GPO Setting Item: "EventLogFlags" = 1 (default value) (The GPO shows "0", but in reality the default value is "1"!)

The first "EventLogFlags" option configures the Windows Time Service to log (or not) an event when it is not able to reach the time server from which it synchronizes the time.

The second "EventLogFlags" option configures the Windows Time Service to log (or not) an event when a time jump is made and/or a new time server is being used to synchronize the time from.

In addition to the information in the System event log, it is possible to enable debug logging for the Windows Time Service. When debugging logging is enabled it is possible to see what is happening under the hood by the Windows Time Service.

To enable debug logging for the Windows Time Service, execute the following command:

W32TM /DEBUG /ENABLE /FILE:<Full Path To Log File> /SIZE:<Log File Size In KB> /ENTRIES:<Type Of Entries To Log>

W32TM /CONFIG /UPDATE

‘<Full Path To Log File>’ is the full path to the log file used for denug logging. For example: "C:WindowsDebugW32Time.log"

‘<Log File Size In KB>’ specifies the maximum size of the log file in KB. For example ‘10000000’ means ’10MB’

‘<Type Of Entries To Log>’ is a numerical mask of the entries you wish to log in the log file. Each number in the range between 1 and 300 represents a specific log entry type you would like to log. Just specifying 0-300 is the easiest way to use this as it will log everything.

A sample of the log file is shown below

image

To disable debug logging for the Windows Time Service, execute the following command:

W32TM /DEBUG /DISABLE

W32TM /CONFIG /UPDATE

For more information about configuring the Windows Time Service debug log see the link: ‘Configuring the Time Service: Enabling the Debug Log‘.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Blog Post Series, Core Networking Services, NTP | 6 Comments »

(2010-09-26) Configuring And Managing The Windows Time Service (Part 3)

Posted by Jorge on 2010-09-26


In the previous post (part 2) I discussed how to configure the DC in the forest root AD domain with PDC FSMO role by using GPOs and a WMI filter. After configuring the DC in the forest root AD domain with an external time source, you want or need to make sure no excessive time jumps occur back or forward on any DC in the AD forest. When excessive time jumps occur you will experience issues with AD replication, Kerberos authentication, object recovery, etc.

The configuration on DCs that prevents such an excessive time jump can either be achieved through local registry configurations or through GPOs. The GPO settings can be configured in the GPOs mentioned earlier and there GPO settings are:

  • GPO Setting Item: "MaxNegPhaseCorrection" = XYZ (default value = 172800 seconds = 48 hours)
  • GPO Setting Item: "MaxPosPhaseCorrection" = XYZ (default value = 172800 seconds = 48 hours)

image

image

By default, the OS (W2K3 and higher) implements a period of 48 hours before the current time and 48 hours after the current time. If the time jump falls within the defined intervals, the time jump is accepted and processed. If the time jump falls outside the defined intervals, the time jump is not accepted and therefore also not processed. This is very good to prevent serious damage to your AD forest. What I do not understand is why Microsoft has chosen a default value of 48 hours. Personnally I still find that interval too big. I would choose an interval that’s more close to 10 or 15 minutes as an acceptable time jump. Taking an interval of 15 minutes into account, the XYZ would be 900 seconds.

For more information about protecting DCs from processing a time jump that’s too large see the links ‘Configuring the Time Service: Max[Pos/Neg]PhaseCorrection‘, ‘Preventing large time offset problems‘ and ‘How to configure the Windows Time service against a large time offset‘.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Blog Post Series, Core Networking Services, NTP | 6 Comments »

(2010-09-26) Configuring And Managing The Windows Time Service (Part 2)

Posted by Jorge on 2010-09-26


In the previous post (part 1) I discussed how to configure the DC in the forest root AD domain with PDC FSMO role manually. The commands mentioned in that post must be executed on DC in the forest root AD domain hosting the PDC FSMO role. To prevent these manual actions, it is also possible to achieve the same result after a one-time configuration in AD through GPOs and a WMI filter. Perform the following tasks.

[Task 1] – Create a WMI filter to only target the DC with the PDC FSMO role.

image

In the GPMC create a WMI filter with the following configuration (without the single quotes):

  • WMI Filter Name: "RWDC With The PDC FSMO role" (can be something else of course)
  • WMI Filter Description: ‘This WMI filter targets the DC with the PDC FSMO Role’ (can be something else of course)
  • WMI Filter Namespace: ‘rootCIMv2’
  • WMI Filter Query: ‘Select * from Win32_ComputerSystem where DomainRole = 5’

[Task 2] – Create a GPO and link it to the Domain Controllers OU to target all DCs. Make sure it is applied after the GPO called "Default Domain Controllers Policy".

image

image

In the GPMC create a GPO with following configuration (without the single quotes):

  • GPO Name: "GPO_C_All-Domain-Controllers" (can be something else of course)
    • GPO Node: "Computer Configuration\Policies\Administrative Templates\System\Windows Time Service"
      • GPO Setting: "Global Configuration Settings" = Enabled
        • GPO Setting Item: "FrequencyCorrectRate" = 4 (default value)
        • GPO Setting Item: "HoldPeriod" = 5 (default value)
        • GPO Setting Item: "LargePhaseOffset" = 50000000 (default value)
        • GPO Setting Item: "MaxAllowedPhaseOffset" = 300 (default value)
        • GPO Setting Item: "MaxNegPhaseCorrection" = XYZ (default value = 172800 seconds = 48 hours) (more about this item later in this blogpost!)
        • GPO Setting Item: "MaxPosPhaseCorrection" = XYZ (default value = 172800 seconds = 48 hours) (more about this item later in this blogpost!)
        • GPO Setting Item: "PhaseCorrectRate" = 7 (default value) (The GPO shows "1", but in reality the default value is "7"!)
        • GPO Setting Item: "PollAdjustFactor" = 5 (default value)
        • GPO Setting Item: "SpikeWatchPeriod" = 900 (default value)
        • GPO Setting Item: "UpdateInterval" = 100 (default value)
        • GPO Setting Item: "AnnounceFlags" = 10 (default value)
        • GPO Setting Item: "EventLogFlags" = 2 (default value)
        • GPO Setting Item: "LocalClockDispersion" = 10 (default value)
        • GPO Setting Item: "MaxPollInterval" = 10 (default value)
        • GPO Setting Item: "MinPollInterval" = 6 (default value)
        • GPO Setting Item: "ChainEntryTimeout" = 16 (default value)
        • GPO Setting Item: "ChainMaxEntries" = 128 (default value)
        • GPO Setting Item: "ChainMaxHostEntries" = 4 (default value)
        • GPO Setting Item: "ChainDisable" = 0 (default value)
        • GPO Setting Item: "ChainLoggingRate" = 30 (default value)

REMARK: You must define all GPO configuration items with default or custom values because all part of the same GPO setting.

[Task 3] – Create a GPO and link it to the Domain Controllers OU to target only the DC with the PDC FSMO role. Make sure it is applied after the GPO called "GPO_C_All-Domain-Controllers".

image

image

In the GPMC create a GPO following configuration (without the single quotes):

  • GPO Name: "GPO_C_RWDC-With-PDC-FSMO-Role" (can be something else of course)
    • GPO Node: "Computer Configuration\Policies\Administrative Templates\System\Windows Time Service"
      • GPO Setting: "Global Configuration Settings" = Enabled
        • GPO Setting Item: "FrequencyCorrectRate" = 4 (default value)
        • GPO Setting Item: "HoldPeriod" = 5 (default value)
        • GPO Setting Item: "LargePhaseOffset" = 50000000 (default value)
        • GPO Setting Item: "MaxAllowedPhaseOffset" = 300 (default value)
        • GPO Setting Item: "MaxNegPhaseCorrection" = XYZ (default value = 172800 seconds = 48 hours) (more about this item later in this blogpost!)
        • GPO Setting Item: "MaxPosPhaseCorrection" = XYZ (default value = 172800 seconds = 48 hours) (more about this item later in this blogpost!)
        • GPO Setting Item: "PhaseCorrectRate" = 7 (default value) (The GPO shows "1", but in reality the default value is "7"!)
        • GPO Setting Item: "PollAdjustFactor" = 5 (default value)
        • GPO Setting Item: "SpikeWatchPeriod" = 900 (default value)
        • GPO Setting Item: "UpdateInterval" = 100 (default value)
        • GPO Setting Item: "AnnounceFlags" = 5 (default value = 10)
        • GPO Setting Item: "EventLogFlags" = 2 (default value)
        • GPO Setting Item: "LocalClockDispersion" = 10 (default value)
        • GPO Setting Item: "MaxPollInterval" = 10 (default value)
        • GPO Setting Item: "MinPollInterval" = 6 (default value)
        • GPO Setting Item: "ChainEntryTimeout" = 16 (default value)
        • GPO Setting Item: "ChainMaxEntries" = 128 (default value)
        • GPO Setting Item: "ChainMaxHostEntries" = 4 (default value)
        • GPO Setting Item: "ChainDisable" = 0 (default value)
        • GPO Setting Item: "ChainLoggingRate" = 30 (default value)

REMARK: You must define all GPO configuration items with default or custom values because all part of the same GPO setting.

  • GPO Node: "Computer Configuration\Policies\Administrative Templates\System\Windows Time Service\Time Providers"
    • GPO Setting: "Configure Windows NTP Client" = Enabled
      • GPO Setting Item: "NtpServer" = <NTPSRV1>,<flag> <NTPSRV2>,<flag> <NTPSRVx>,<flag> (default value = time.windows.com,0x9)
      • GPO Setting Item: "Type" = NTP (default value = NT5DS)
      • GPO Setting Item: "CrossSiteSyncFlags" = 2 (default value)
      • GPO Setting Item: "ResolvePeerBackoffMinutes" = 15 (default value)
      • GPO Setting Item: "ResolvePeerBackoffMaxTimes" = 7 (default value)
      • GPO Setting Item: "SpecialPollInterval" = 3600 (default value)
      • GPO Setting Item: "EventLogFlags" = 1 (default value) (The GPO shows "0", but in reality the default value is "1"!)

REMARK: You must define all GPO configuration items with default or custom values because all part of the same GPO setting.

For more information about configuring the DC in the forest root AD domain with the PDC FSMO through a GPO and WMI Filter see the link ‘Configuring an Authoritative Time Server with Group Policy Using WMI Filtering‘.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Blog Post Series, Core Networking Services, NTP | 7 Comments »

(2010-09-26) Configuring And Managing The Windows Time Service (Part 1)

Posted by Jorge on 2010-09-26


One of the important configurations required in your AD forest is the configuration of the Windows Time Service. Processes within AD, such as for example ‘Kerberos authentication’ and ‘AD replication’ depend on the correct time on systems. A great explanation on how the windows time service works with an AD forest can be found at the following links ‘Keeping the Domain On Time‘, ‘Windows Time Service Technical Reference‘ and ‘How the Windows Time Service Works‘.

The time synchronization hierarchy within an AD forest is shown in the picture below.

image

As you can see in the picture above, all systems within an AD forest use certain logic on which other system can be contacted to synchronize the time with. There is not much reason to change this and my suggestion is not to change this. Even in a virtualized environment I still suggest the virtualized systems to synchronize their time using the default configuration and not to synchronize with the host. At the top of the picture above you can see the PDC FSMO of the forest root AD domain needs to be configured with a (trusted) external time source. For a list of time servers available on the internet please see the link ‘A list of the Simple Network Time Protocol (SNTP) time servers that are available on the Internet‘.

One of the main reasons, not to use the AD infrastructure for time synchronization and rather implement/use a custom time synchronization solution/configuration, is when you have systems or applications that require a very high accuracy in time synchronization. For more information about this see the link ‘High Accuracy W32time Requirements‘.

With regards to manually configuring DC in the forest root AD domain with the PDC FSMO role, the following commands can be used. On the DC in the forest root AD domain with the PDC FSMO role execute the following command:

W32TM /CONFIG /MANUALPEERLIST:"<NTPSRV1>,<flag> <NTPSRV2>,<flag> <NTPSRVx>,<flag>" /SYNCFROMFLAGS:MANUAL /RELIABLE:YES /UPDATE

‘<NTPSRV>’ is the actual NTP Server from which the time should be synchronized and can be noted by FQDN or IP Address.

‘<flag>’ can be any of the following values or combinations of values:

  • 0x1 — use special poll interval SpecialInterval
  • 0x2 — UseAsFallbackOnly
  • 0x4 — send request as SymmatricActive mode (the host configured in "symmatric active mode" uses another NTP hosts to sync time, but also gives those other NTP hotes to sync time with the local host)
  • 0x8 — send request as Client mode (the loca host configured in "client mode" uses the other remote NTP host to sync time)

When you seize or transfer the FSMO role to a new DC in the forest root AD domain, you have to execute the previous command on the new target DC. If you are performing a transfer, then you also have to reconfigure the old target DC to use the default windows time service configuration, i.e. the domain hierarchy. For that execute the following command on the old target DC:

W32TM /CONFIG /SYNCFROMFLAGS:DOMHIER /RELIABLE:NO /UPDATE

For more information about configuring the DC in the forest root AD domain with the PDC FSMO role see the link ‘Configure the Windows Time service on the PDC emulator in the Forest Root Domain‘ and ‘Configuring the Time Service: NtpServer and SpecialPollInterval‘.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Blog Post Series, Core Networking Services, NTP | 7 Comments »

(2008-03-19) Windows Time Service

Posted by Jorge on 2008-03-19


In addition to a previous post a did, I would like to point you to a Microsoft blog about the Windows Time Service (W32TIME). That blog contains interesting information. My favorite posts on that blog are:

You can use the links above, but you can also read the information below which was copied from that Microsoft blog about the Windows Time Service (W32TIME) . All credits go to the person (Ryan Sizemore) that blogged about this.

Keeping the Domain On Time
(Explaining how Windows Time Service works in an AD forest)

Windows Time Service on a domain (referred to as ‘Domain Synchronization’ or ‘Domain Sync’ for short) is a huge topic. I will do my best to cover all of its aspects in this article, but some concepts won’t be covered until a later date, and others still relate directly to the original RFC for NTP.

Background

As I stated in my previous post, the original reasons for developing w32time stemmed from the requirements imposed by Kerberos. In order for Kerberos to function securely, the time difference between the participating machines needs to be less than five minutes. In time, other components have come to rely on w32time, including Active Directory Replication and Windows Update. In a Windows domain, w32time needs to keep machines synchronized, and it needs to do so in a quick, efficient, and quiet manner.

Beyond NTP

The NTP protocol described in the RFC goes a long way toward designing a robust time synchronization solution. But in the end, what we are really interested in is just that: the solution. Keeping time synchronized between two machines is possible, but the solution needs to be more robust to deal with computers belonging to a domain. In particular, w32time works to answer these questions (just to name a few):

  • How do we ensure that in a large network of computers, an efficient chain of time sources is picked?
  • How do we auto-configure so that an administrator has to do a minimal amount of work to set it up?
  • How do we keep it secure and still auto-configurable?
  • How do we allow administrators to get a look at what is happening?
  • How do we alert the administrators when something goes wrong?

These questions are important, specifically in the domain scenario (as opposed to the home user scenario), since the needs of the home user and the needs of the domain user are quite different.

Designing Inside the Box

Because many components within Windows depend on w32time to keep the clock synchronized, w32time cannot take (hardly) any dependencies itself. If w32time relied on component X to do something fancy, and component X relied on Kerberos, then we would have a problem, since Kerberos relies on w32time. This would create a circular dependency and, well, that’s a bad thing.

For this reason, w32time has a simplified mechanism to authenticate time syncs. More information on the authentication mechanism will be covered in a future post.

Intelligent Design

The first issue to address is finding someone to synchronize with. Each machine needs to sync with another machine to get its time. To do this efficiently and automatically, w32time uses the domain hierarchy created with the domain itself. In the simplest frame of mind, a domain consists of the following distinct entities (aka computers):

  • Exactly one primary domain controller (or PDC-emulator)
  • Zero or more replica domain controllers (DCs)
  • Zero or more member computer (either server or workstations)

image

The inner working of what a domain is and how it operates is beyond the scope of this post, but this should be enough to provide the groundwork for our discussion.

Time Source Selection

Each member of the domain follows a different set of requirements, based on its role. Lets take a look at those roles:

  • Primary Domain Controller – This machine is the authoritative time source for a domain. It will have the most accurate time available in the domain, and must sync with a DC in the parent domain (except in special cases).
  • Replica Domain Controller – This machine will act as a time source for clients and member servers in the domain. A DC can sync with the PDC of its own domain, or a DC or PDC in the parent domain.
  • Clients/Member Servers – This machine can sync with any DC or PDC of its own domain, or a DC or PDC in the parent domain

These are the default rules of where a machine can go looking for a time source. Keep in mind that there are corner cases where the rules can be bent a little. A few additional rules:

  • A machine can only look for a time source in its own domain or the parent domain. A machine will never go to a domain on a parallel level, or a "skip-level" parent domain.
  • Within a domain, a machine cannot sync with its own kind. A DC cannot sync with another DC. A client cannot sync with another client.

Also, you may have noticed that a PDC can only sync from a DC or PDC in the parent domain. Well, what if you are in the parent domain already? This is a special case, which is detailed below in the section "Special Case: The Root PDC".

The time source selection mechanism works great to enumerate the possible machines to sync from. The problem is that this usually leaves more than one machine as a possible partner. We need a way to pick the "best" one of the group, and that is what scoring does for us.

Score!

Each possible machine is given a score, based on certain criteria. Once all of the candidates have a score, w32time simply chooses the machine with the highest score. Here is what the scoring looks like:

  • 8 points if the machine is in-site
  • 4 points if the machine is "reliable"
  • 2 points if the machine is in the parent domain
  • 1 point if the machine is a PDC (or PDC emulator)

So why are these points given? Let’s look at the rules individually. Machines that are in the same site as the one in question have the best chance of providing us with good time.

  • Machines that are out of site probably are disconnected physically in one way or another, and would likely introduce delay.
  • A machine that is "reliable" is pre-configured to be directly connected to a reliable time source, such as a GPS or atomic clock. These devices provide very accurate, very stable time samples. If a machine is configured to sync directly with one of these devices, a registry value can be changed to indicate that this machine will be a source of reliable time.
  • A machine higher in the forest will be closer to the root, and hence will have more accurate time than a machine in the current domain.
  • A PDC (or PDC-emulator) will be more accurate than a DC in the same domain because it is guaranteed to sync with a machine in the parent domain.

From this, we can derive a score for each machine, and then choose the machine with the highest score.

Examples

When a machine boots up, it will go looking for a time source. Depending on its role, it will be required to choose from a subset of possible machines to sync with. But how do we prioritize between the available choices? Lets take a look at the following example:

Example 1:

This example utilized the graphic above. The domains will be referred to as the "Left Domain", the "Right Domain", and the "Parent Domain".

Computer foo has just been joined to the Left Domain as a regular client (not a DC), and it booting up for the first time on a domain. First, we need to enumerate which machines are possible as partners to sync with. We will look at each machine to see if it is a possible sync partner.

  • "Domain Controller" [Left Domain]  is a DC in the same domain, so it is a valid choice
  • "PDC Emulator" [Left Domain] is a PDC in the same domain, so it is a valid choice
  • "Domain Controller" [Parent Domain] is a DC in the parent domain, so it is a valid choice
  • "PDC Emulator" [Parent Domain] is a PDC in the parent domain, so it is a valid choice

Which machines aren’t valid? Let’s take a look (and find out why)

  • "Workstation" [Left Domain] is not a DC, so it is not a valid choice
  • "Server" [Left Domain] is not a DC, so it is not a valid choice
  • "Workstation" [Parent Domain] is not a DC, so it is not a valid choice
  • "Server" [Parent Domain] is not a DC, so it is not a valid choice
  • Anything in the [Right Domain] is not in the same domain, and not in the parent domain, so it is not a valid choice

Ok, so we have our possible choices, but now we need to prioritize them to pick the best one. To do this, we will utilize the scoring system. Assuming that our entire forest is in one site, and we don’t have any machines configured as "reliable":

  • "Domain Controller" [Left Domain]  Score = 8
  • "PDC Emulator" [Left Domain] Score = 8 + 1 = 9
  • "Domain Controller" [Parent Domain] Score = 8 + 2 = 10
  • "PDC Emulator" [Parent Domain] Score = 8 + 2 + 1 = 11

So there we have it. The PDC in the parent domain will be our time source. But what if the [Left Domain] was put into a separate site?

Example 2:

Assume the same scenario as the above example, except that [Left Domain] exists in a different site from the rest of the forest. We will use the same logic applied above to determine a time source.

So the [Left Domain] is in a different site. Since the first part of time source selection does not take site location into consideration, we will get the same possible machines to sync with. However, the scoring system will provide us with a different machine when all is said and done. Lets look at how the scoring would now occur:

  • "Domain Controller" [Left Domain]  Score = 8
  • "PDC Emulator" [Left Domain] Score = 8 + 1 = 9
  • "Domain Controller" [Parent Domain] Score = 2 = 2
  • "PDC Emulator" [Parent Domain] Score = 2 + 1 = 3

Because the DC and PDC in the [Parent Domain] are in a different site, they don’t get the +8 to their score. This leaves us with the PDC of the current domain, with a score of 9. But what about the PDC of the [Left Domain]?

Example 3:

Assume the same scenario as Example 2, Again, we will use the same logic applied above to determine a time source.

With the left domain in a different site from the rest of the forest, and with the PDC of the [Left Domain] being the authoritative time source for the [Left Domain], we will need to go out of site for a time source – we have no other choice. So we will look at the scores for the various eligible time sources:

  • "Domain Controller" [Parent Domain] Score = 2 = 2
  • "PDC Emulator" [Parent Domain] Score = 2 + 1 = 3

We cannot sync with any time sources in our own domain, so we only have the time sources from the [Parent Domain]. The scoring will give us the PDC of the [Parent Domain].

Plan B: Fail over

So what happens when things don’t go as planned? Windows Time Service has been built to handle fail over situations from the beginning. For a generic example, assume that a client is currently synchronizing with a time source. If the time source goes away for one reason or another, the client will need to go looking for another time source.

For this reason, we use the scoring system illustrated above. The client will reassess the available time sources, score each of them, and choose the best one. Since the previous time source (which was probably the best first choice) has gone away, w32time will pick the next highest scoring time source.

Special Case: The Root PDC

The PDC for the domain at the root of the forest (the root PDC) poses a problem. Since it has no time sources that are more authoritative than it, it cannot choose a time source automatically. Thus, the administrator will need to set one up manually, or the domain will operate in a "standalone" mode. In the case of a standalone domain, the root PDC will still be the authoritative time source, but its time will come from its own clock.

Wrap Up

We have taken a look at how w32time operates in a domain at a very high level. Future posts will dive deeper into specific areas of w32time, and this will provide a groundwork for those other articles. If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Windows Vista Applications section of the Microsoft Technet forums. One way or another, questions posted there should make their way to my inbox, and I will do my very best to answer them.

References

  1. http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true

Configuring the Time Service: NtpServer and SpecialPollInterval
(Explaining specific W32TIME configurations)

One of the most talked about configuration options for W32Time has to be the list of time sources that W32Time connects to for synchronization. It is important to note that W32Time will only actively synchronize with one time source at a time, even though you are able to list more than one time source. The reason for this is simple: If your favorite time source goes down, it would be good to have a backup, or possibly a list of backups.

W32Time configures the list of time sources through the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

The NtpServer key is a space-delimited list of time servers, either as DNS address or as IP addresses. Each server in the list can optionally have a set of flags, which are denoted as a hex value at the end of the address, separated by a comma. We will get to the flags in a moment. Here are a few examples of NtpServer values:

time.windows.com,0x01

time.windows.com,0x01 time.nist.gov,0x01 my.time.server.com,0x02

In the first example, we are specifying a time source of time.windows.com, with the 0x01 and 0x08 flags. In the second example, we are specifying 3 time sources, each with a different set of flags (0x01 & 0x08; 0x01; 0x02 respectively).

Now lets take a look at the flags. We have 4 possible flags:



0x01 SpecialInterval

0x02 UseAsFallbackOnly

0x04 SymmatricActive

0x08 Client

For 99% of cases, we only care about the first two options, so that is where we will focus. If you use the SpecialInterval flag, then you need to also set the "SpecialPollInterval" key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClientSpecialPollInterval

Normally, W32Time will poll (make a time request) on a floating interval, based on the quality of the time samples being returned by the time source. You can however specify a static interval that the time service will syncronize on. This value is in seconds. For example, if you set a of 3600, the time service will syncronize every hour (60 minutes * 60 seconds).

The second flag is the UseAsFallbackOnly option. Setting this flag will tell the time service that you want to try every other time server specified before trying this one.

That wraps up this one. As usual, If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Directory Services section of the Microsoft Technet forums.

Configuring the Time Service: Enabling the Debug Log
(Explaining how to use the debug log for W32TIME)

The debug log is a powerful tool in the W32Time bag of tricks when you need to figure out why something isn’t working. The debug log tell you (for better or worse) what the Time Service is doing under the hood. Where it is connecting to, how long it is waiting between polls, etc.

In Windows Vista/Server 2008, we added the /debug option to the w32tm.exe command. This is the quickest and easiest way to configure the time service, and should be used if possible. A secondary option (if you are running XP/W2k3) is to edit the settings in the registry. Both will have the same effect, but using the w32tm command will keep you from having to get your hands dirty with registry editing. We will take a look at the w32tm command first:

Using the w32tm.exe command

To enable the w32time debug logging:

w32tm /debug /enable /file:C:windowstempw32time.log /size:10000000 /entries:0-300

The command uses the following options:

  • /debug – This tells w32tm that you will be changing the debug log settings
  • /enable – We are turning on the debug log (as opposed to turning it off)
  • /file – Here we are specifying the full path of where the log file will be created; in this case: "C:windowstempw32time.log"
  • /size: The maximum size of the log file, in bytes; in this case, it is 10 Mb. When the log is full, the w32time service will wrap to the top of the log file
  • /entries: This field is a mask, where you can mask off certain types of entries. More about this later.

Turning off the debug log is just as easy:

w32tm /debug /disable

Using the registry

In essence, the w32tm.exe command shown above does exactly what we are about to do here. The only real difference is that when you use w32tm, it handles the reloading of the config, which will actually apply the values found in the registry. Since we will now be making the changes ourselves, we will need to reload the config ourselves.

Note: If you just want a quick .reg file that you can modify and merge, skip to the bottom of this post.

To get started, fire up the Windows registry editor:

Start -> Run -> Regedit.exe

Next, browse to the w32time config key, where we keep all of the w32time configuration:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Here, you will be creating the following three keys (if they do not exist):

  • FileLogName (REG_SZ)
  • FileLogSize (REG_DWORD)
  • FileLogEntries (REG_SZ)

Once they are created, go ahead and add the values that you want.

  • FileLogName should point to the full path where you want to store the log file. C:windowstemp is the preferred location. Just ensure that a service running as LOCAL_SYSTEM has write access to the directory.
  • FileLogSize should be the maximum size of the log file, in bytes. Remember to convert to hex as needed 10Mb in hex would be 0x989680.
  • FileLogEntries is a numerical mask of the entries that you want to have logged in the log file. Each number in the range 1 – 300 represents a particular logging entry, such as polling intervals, packets received, etc. For the sake of simplicity, you should enable all logging. This is really only useful if you need to track a particular entry over a long period of time, and you don’t want all of the other logging to clobber your file. Using 0-300 will guarantee that everything possible will be logged.

Once you apply the changes to the registry, you need to tell the w32time service that it needs to re-read the configuration information. To do this, you can use the following command:

w32tm /config /update

Example .reg file

Here is an example .reg file you can modify to simplify the process:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"FileLogName"="C:\windows\temp\w32time.log"
"FileLogEntries"="0-300"
"FileLogSize"=dword:00989680

As usual, If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Directory Services section of the Microsoft Technet forums.

Configuring the Time Service: Max[Pos/Neg]PhaseCorrection
(Explaining how to protect yourself if your external/internal clock goes crazy by jumping back/forward in time)

In the last few months of the Windows Server 2008 development, a good friend of mine was discussing a problem they have been seeing with customers. The problem, lovingly titled as the "Large Time Jump" issue involves a machine in the domain (usually the PDC) making a large jump in time, either forward or backwards. Regardless of the direction of the jump, the results are equally catastrophic.

How it all happens

Lets look at how this can happen. Some of the causes are more likely than you think. Here is a quick list:

  • Hardware changes. It is quite common for a company to have a hardware failure for a DC, even the PDC. Assume a situation where the motherboard in the PDC fails. After the hardware is all installed, the technician boots the machine back up. As hoped, the machine looks to be running just fine. However, the part that the manufacturer shipped out is considered an "after market" part, so the BIOS isn’t configured correctly. By default, the BIOS date is set to the manufacture date of the motherboard – sometime in the past. Of course, when the technician gets the new part, he sees that everything looks to be in order, but he neglects to notice that the date it wrong.
  • Bad external time source. Sometimes, the time source that you are syncing the PDC with (such as a network device, like a high-end router) can get a wild hair and jump to an invalid time.
  • Bad CMOS battery. Every once in a while, a BIOS battery in a computer will fails. After all, they don’t last forever. If the PDC isn’t configured to sync with an external time source, it will by default use its own internal clock, which is based on the BIOS clock. A computer cannot maintain it’s time across a reboot, so it stores the current time in the BIOS. If the CMOS battery has failed, the time after the reboot will be incorrect.
  • User error. It is not outside of the realm of possibility for someone to log onto the root PDC and change the clock. It sounds unlikely, but it is still possible.

Fixing the glitch

The real problem here is that in a domain environment, domain controller completely and utterly trust the time that they get from another DC. The root PDC is a special case, but it still counts.

The solution is to do a "sanity check" on the time that any domain controller gets from anywhere. In this way, you are ensuring that if a domain controller gets out of whack, it will not spread that time to other DCs. This is done by setting the MaxPosPhaseCorrection and MaxNegPhaseCorrection values.

MaxPosPhaseCorrection and MaxNegPhaseCorrection limit the allowable offset taken from a time sample. When any instance of w32time polls another machine for the time, it will determine the offset between the time source and itself. This value is known as the "Sample Offset". Before the samples is used by the time service, it will be compared to the phase correction limits. If the sample offset is greater than the phase correction limit, then sample will be thrown out and a "TOO BIG" event will be generated. The event contains all of the information about the time sample, including who sent it. The purpose of doing this is to isolate domain controllers in the network who get into a bad time state. In this way, the other DCs will log and error about the time samples being too big rather than blindly accepting it.

Knowing your limits

The next question is: What is an acceptable limit of phase correction? After much analysis and debate, we are advising a value of 48 hours. If a domain controller receives a sample that says it is more than 48 hours off, either in the future or in the past, the domain controller will throw it out. However, every customer should evaluate their own situation to be sure.

This is advised for both limits, both forward and backwards.

A packaged solution

Here is an example of a registry entry that you can merge on-demand to apply a 48 hour limit to the phase correction:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"MaxNegPhaseCorrection"=dword:0002a300
"MaxPosPhaseCorrection"=dword:0002a300

As usual, If you have specific thoughts or questions about this post, please feel free to leave a comment. For general questions about w32time, especially if you have problems with your w32time setup, I encourage you to ask them on Directory Services section of the Microsoft Technet forums

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Core Networking Services, Windows Client, Windows Server | Leave a Comment »

 
%d bloggers like this: