Certificate templates can't be issued after an implace upgrade ofWindows 2008 to the enterprise edition

Published on Saturday, February 14, 2009 in

Months ago I had a Windows 2008 (standard edition) server which had to be upgraded to Windows 2008 enterprise. The enterprise edition of Windows allows templates to be duplicated and changed so that custom validity periods can be chosen or that a smaller key size can be set.

After the upgrade the duplicated templates couldn't be issued. Always keep in mind that these templates are stored in AD so they might take some time to replicate. Nevertheless, I seemed unable to issue those templates. Then I stumbled upon this post: Windows PKI blog

Which provided the following solution:

certutil -setreg ca\setupstatus +512
net stop certsvc
net start certsvc

And now Microsoft issued KB967332 5 months after that post.


W2008 Failover Cluster: resource name fails to come online after afailover

Published on Thursday, February 12, 2009 in , ,

In the project I'm currently involved in, the network team had a planned upgrade of the cisco 4500 switches located in both datacenters. These switches are used to connect the new server hardware to the current environment. This new hardware consist of a print, file and mail cluster among other service. The print and file clusters have their SAN disks in the first datacenter (A), the mail in the other datacenter (B). During the upgrade, for some reason a complete shutdown of the switch in the first datacenter was required. It was a planned intervention and the environment is still in build phase so this was not an issue. We, the ones responsible for the server setup, didn't stay to check the health of the clusters. We just expected a fail-over to happen to the other datacenter for the file and print services. Not!

As the switch in datacenter A was powered off at 18.00, the clusternodes for file and print lost their network in datacenter A. Hence they stopped their services, disks, networknames so the nodes in the other datacenter B could start them. I intended to provide a small network diagram, but I have no time for this.

As the cisco 4500 was powered off in datacenter A, the cisco 4500 in datacenter B had to learn new networkroutes to other LAN segments such as the one containing the DNS servers. The process of learning this new routes approximately takes up to 6 minutes. This is because the RIP protocol is currently in use. During this crucial 6 minutes the clusternodes in the B datacenter try to start the resources. Bringing the disks online is no issue, same for the IP's. Bringing the CAP (Client Access Points) online failed. So basically no services where available. The proces of bringing the network names online failed because Active Directory couldn't be contacted... The domain controllers themselves where available as these are located on VLANs which are routeable by the cisco 4500. But for the clusternodes be able to contact AD they required DNS, which they didn't had because they lacked a networkroute to that specific subnet for 6 minutes....

So when we arrived the morning after, we found our file and print cluster to be offline. At first we wondered why the clusters didn't tried to bring their networknames online at a later interval.  Afterall the network was "healthy" all night. This KB947172 explains why. Shortly: if a resources fails once on the first node, followed by a failure on the other node, a manual interaction is required.

Below is a copy paste of the clusterlog when the check succeeds:

INFO  [RES] Network Name <vdmprinters>: Initiating the Network Name operation : 'Verifying computer object associated with network name resource printcluster'
INFO  [RES] Network Name <vdmprinters>: Trying to find computer account printcluster object GUID(b4a849281d4b47d30af3681b8590a20e) on any available domain controller.
INFO  [RES] Network Name <vdmprinters>: Found computer account printcluster on domain controller \dc1.domain.local.

So the point in this story: allthough the cluster service no longer requires an Active Directory user account, you still need AD AND DNS to be around at all time, especially during a cluster failover.


DC Locator process

Published on Thursday, February 5, 2009 in , ,

Just a very interesting series of posts by Jorge on how the Active Directory clients determine which domain controller servers their logon request and which domain controller sends the GPO files over.

DC Locator process part 1
DC Locator process part 2
DC Locator process part 3

A small add-on: using start - run - cmd and execute "set" you can easily determine your logon server. Determining which DC sent the GPO's can be determined by running "gpresult /R" (Windows 2008) or "gpresult" (Vista)

The following Technet article is also a nice source of information: How DNS Support for Active Directory Works


Active Directory and Firewalls

Published on Wednesday, February 4, 2009 in , ,

[Update:] added NTP as said by Brent in the comments

The following post will explain how to let basic Active Directory related network traffic such as logon requests or replication traffic, be it either sysvol items or AD objects, happen through firewalls. This doesn't mean I'm totally in favour of implementing a firewall between every possible environment. But you might encounter projects where firewalls are used between different sites or just internally between clients and servers.  In that case you might find the following interesting:

The following list is an overview of the AD related services with their required ports:

  • NetBIOS name service (137/tcp, 137/udp)

  • NetBIOS datagram service (138/udp)

  • NetBIOS session service (139/tcp)

  • SMB over IP (Microsoft-DS)(445/tcp, 445/udp)

  • LDAP (389/tcp)

  • LDAP ping (389/udp)

  • LDAP over SSL (636/tcp)

  • Global catalog LDAP (3268/tcp)

  • Global catalog LDAP over SSL (3269/tcp)

  • Kerberos (88/tcp, 88/udp)

  • DNS (53/tcp, 53/udp)

  • WINS resolution (if required) (1512/tcp, 1512/udp)

  • WINS replication (if required) (42/tcp, 42/udp)

  • RPC endpoint mapper (135/tcp, 135/udp)

  • AD replication (TCP 1024 - 65535*)

  • FRS replication (TCP 1024 - 65535*)

  • Netlogon (TCP 1024 - 65535*)

  • NTP (123/udp)

It all seems fine but those last 3 entries are quit funny. If you ask your security guy to implement those, he might aswell just throw his firewall out of the window. Microsoft describes this situation as turning your firewall into swiss cheese (Technet: Active Directory Replication over Firewalls).  A second solution is to set up an IPsec tunnel. Something in between is the option to restrict certain RPC services to a specific port. There are a lot of services which use RPC to determine the port they are listening on. Domain replication, file replicaton, netlogon, remote eventviewer, remote computermanagement are all examples. Whenever such a service is started the "RPC end-point mapper", a service which listens on port 135, decides which port the service will actually listen on (between 1024 and 65535). This behaviour is nicely explained in the following posts over at the (Microsoft Networking Team: RPC Endpoint Mapper in a network trace and RPC to Go v.1)

By choosing those ports ourselves and fixing the services to listen on those port we can actually limit the required ports to be opened to 3 single ports:
  • AD replication:
value: port1
  • Sysvol replicaton
DWORD: "RPC TCP/IP Port Assignment"
value: port2
  • Netlogon traffic
DWORD: "DCTcpipPort"
value: port3

Don't forget: A reboot is required

Note: actually only sysvol and ad replication traffic is required for two domain controllers to talk across a firewall. The netlogon service is only required when you want to handle logon requests or domain joins accross a firewall. This might be the case when you're setting up a new site and at first you don't have that Domain Controller available to handle your requests.

Microsoft KB's which explain the given registry keys:

KB224196 and KB319553