Windows Management and Scripting

A wealth of tutorials Windows Operating Systems SQL Server and Azure

Posts Tagged ‘PKI’

Troubleshoot Edge Subscriptions

Posted by Alin D on February 3, 2011

While there are other options for connecting Exchange to the Internet, most companies will probably go with placing an Exchange server in the DMZ and deploying the Edge Transport role. When you do this, you typically will subscribe this server to your internal Exchange infrastructure using an edge subscription. While this is an excellent way to maintain a bastion host in the DMZ while still managing it through your internal Exchange Management Console (or Exchange Management Shell,) edge subscriptions can be very tricky to troubleshoot when things go bump in the night.

Microsoft has published a very useful, if somewhat complex, flow chart that administrators can follow if they find themselves needing to troubleshoot edge subscription problems. Found here, it presents a methodical, and step by step process, for starting at the edge transport server, and working your way through the required connections to get to the hub transport server. The flow chart also takes into account that you will have a Microsoft TMG server infrastructure in place between the edge and hub transport roles.

flowchart-300x201

There are also supporting instructions on the five major areas that require more than casual investigation. These are

How to check if Edge Subscription is configuredHow to enable connectivity for EdgeSync trafficHow to check system policy rulesHow to create and import an Edge Subscription fileHow to verify that all Forefront TMG Managed Control Service services are running

Verifying the services is a very important area to look at, as most TMG admins will assume that the services tab in TMG would show you all the running services. For Microsoft TMG, this is not actually the case. The following table shows the services that are managed in TMG or Computer Management, though all can be managed at the command line as well.

Managed on the Services tab in Forefront TMG Management

Microsoft Forefront TMG Job SchedulerMicrosoft Forefront TMG ControlMicrosoft Forefront TMG StorageSQL Server (ISARS). The reporting instance of SQL Server Express 2008SQL Server (MSFW). The logging instance of SQL Server Express 2008SQL Server Reporting Services (ISARS). Manages, executes, renders, schedules and delivers reports.Microsoft Forefront TMG Managed Control. Controls Forefront Threat Management Gateway managed services.

There are two areas in this troubleshooting that I cannot stress enough. First, ensure that your DNS and NetBIOS name resolution are working correctly in both directions. The Edge Transport server, not belonging to your domain, and being in a DMZ, may not be able to directly register its A and PTR records in your DNS. If you are scavenging, those records could be deleted and that will bring things to a screeching halt very quickly. And there is plenty of NetBIOS still going on between Windows systems even today. It’s worth the extra effort to implement a WINS infrastructure, and add static records for any DMZ hosts that cannot register themselves.

Second, make sure your certificates are correctly set up, and trusted by all systems. If you use an Active Directory integrated CA, then your internal servers will trust any certificates issued by the PKI automatically, but you will have to manually import the root CA certificate onto the Edge Transport server. You may also want to make sure that all the certificates in use cover all the service names required. See this post on how to easily create CSRs for all your Exchange needs.

About these ads

Posted in Exchange | Tagged: , , , , , , | Leave a Comment »

Windows Server 2008 R2 DNSSEC–Secure DNS Connections

Posted by Alin D on November 26, 2010

Introduction

With the upcoming insurgence of IPv6, accessing computers through DNS names will be more important than ever. While those of us who have been working with IPv4 for many years have found it fairly easy to remember a great number of IPv4 addresses using the dotted quad system of IP network numbering, the fact is that the IPv6 address space is so large, and the hexadecimal format is so complex, that it is likely that only a handful of very dedicated nerds will be able to remember the IP addresses of more than a few computers on their networks. After all, each IPv6 address is 128 bits long – four times as long as an IPv4 address. This is what provides for the much larger address space to accommodate the growing number of hosts on the Internet, but it also makes it more difficult for us to remember addresses.45008_attack_on_resolver

The Problem: Non-secure Nature of the DNS Database

Given the increasing reliance on DNS that is sure to result, we are going to need a way to make sure that the entries in the DNS database are always accurate and reliable – and one of the most effective ways for us to ensure this is to make sure that our DNS databases are secure. Up until recently, DNS had been a relatively non-secure system, with a large number of assumptions made to provide a basic level of trust.

Due to this non-secure nature, there are many high profile instances where the basic trust has been violated and DNS servers have been hijacked (redirecting the resolution of DNS names to rogue DNS servers), DNS records spoofed, and DNS caches poisoned, leading users to believe they are connecting to legitimate sites when in fact they have been led to a web site that contains malicious content or collects their information by pharming. Pharming is similar to phishing, except that instead of following a link in email, users visit the site on their own, using the correct URL of the legitimate site, so they think they’re safe. But the DNS records have been changed to redirect the legitimate URL to the fake, pharming site.

The Solution: Windows Server 2008 R2 DNSSEC

One solution you can use on your intranet to secure your DNS environment is to use the Windows Server 2008 R2 DNSSEC. DNSSEC is a collection of extensions that improve the security of the DNS protocols. These extensions add origin authority, data integrity and authenticated denial of existence to DNS. The solution also adds several new records to DNS, including DNSKEY, RRSIGN, NSEC and DS.

How DNSSEC works

What DNSSEC does is allow all the records in the DNS database to be signed, with a method similar to that used for other digitally signed electronic communications, such as email. When a DNS client issues a query to the DNS server, it returns the digital signatures of the records that it returns. The client, which has the public key of the CA that signed the DNS records, is then able to decrypt the hashed value (signature) and validate the responses. In order to do this, the DNS client and server are configured to use the same trust anchor. A trust anchor is a preconfigured public key associated with a particular DNS zone.

DNS database signing is available for both file based (non-Active Directory integrated) and Active Directory integrated zones, and replication is available to other DNS servers that are authoritative for the zones in question.

The Windows 2008 R2 and Windows 7 DNS clients are configured, by default, as non-validating, security-aware, stub resolvers. When this is the case, the DNS client allows the DNS server to perform validation on its behalf, but the DNS client is able to accept the DNSSEC responses returned from the DNSSEC enabled DNS server. The DNS client itself is configured to use the Name Resolution Policy Table (NRPT) to determine how it should interact with the DNS server. For example, if the NRPT indicates that the DNS client should secure the connection between the DNS client and server, then certificate authentication can be enforced on the query. If security negotiations fail, it is a strong indication that there is a trust issue in the name resolution process, and the name query attempt will fail. By default, when the client returns to the DNS query response to the application that made the request, it will only return this information if the DNS server has validated the information.

Ensuring Valid Results

So there are really two methods that are used to ensure that the results of your DNS queries are valid. First, you need to ensure that the DNS servers that your DNS clients connect to are actually the DNS servers you want the DNS clients to connect to – and that they are not rogue or attacker DNS servers that are sending spoofed responses. IPsec is an effective way to ensure the identity of the DNS server. DNSSEC uses SSL to confirm that the connection is secure. The DNS server authenticates itself via a certificate that is signed by a trusted issuer (such as your private PKI).

Keep in mind that if you have IPsec enforced server and domain isolation in force, you must exempt TCP and UDP ports 53 from the policy. Otherwise, IPsec policy will be used instead of certificate based authentication. This will cause the client to fail certificate validation from the DNS server and the secure connection will not be established.

Signed zones

DNSSEC also signs zones, using offline signing with the dnscmd.exe tool. This results in a signed zone file. The signed zone file contains the RRSIG, DNSKEY, DNS and NSEC resource records for that zone. After the zone is signed, it has to be reloaded using the dnscmd.exe tool or the DNS manager console.

One limitation of signing zones is that dynamic updates are disabled. Windows Server 2008 R2 enables DNSSEC for static zones only. The zone must be resigned each time a change is made to the zone, which may severely limit the utility of DNSSEC in many environments.

The Role of Trust Anchors

Trust anchors were mentioned earlier. DNSKEY resource records are used to support trust anchors. A validating DNS server must include at least one trust anchor. Trust anchors also apply only to the zone that they are assigned. If the DNS server hosts several zones, then multiple trust anchors are used.

The DNSSEC enabled DNS server performs validation for a name in a client query as long as the trust anchor is in place for that zone. The client doesn’t need to be DNSSEC aware for the validation to take place, so that non-DNSSEC aware DNS clients can still use this DNS server to resolve names on the intranet.

NSEC/NSEC3

NSEC and NSEC3 are methods that can be used to provide authenticated denial of existence for DNS records. NSEC3 is an improvement on the original NSEC specification that allows you to prevent “zone walking”, which allows an attacker to retrieve all the names in the DNS zone. This is a powerful tool that attackers can use to reconnoiter your network. This capability is not available in Windows Server 2008 R2, as only support for NSEC is included.

However, there is limited support for NSEC3:

  • Windows Server 2008 R2 can host a zone with NSEC that has NSEC3 delegations. However, the NSEC3 child zones are not hosted on Windows DNS servers
  • Windows Server 2008 R2 can be a non-authoritative DNS server configured with a trust anchor for a zone that is signed with NSEC and has NSEC3 child zones.
  • Windows 7 clients can use a non-Microsoft DNS server for DNS name resolution when that server is NSEC3 aware
  • When a zone is signed with NSEC, you can configure the Name Resolution Policy Table to not require validation for the zone. When you do this, the DNS server will not perform validation and will return the response with the Active Directory bit clear

Deploying DNSSEC

To deploy DNSSEC, you will need to do the following:

  • Understand the key concepts of DNSSEC
  • Upgrade your DNS servers to Windows Server 2008 R2
  • Review zone signing requirements, choose a key rollover mechanism, and identify the secure computers and DNSSEC protected zones
  • Generate and backup the keys that sign your zones. Confirm that DNS is still working and answering queries after signing the zones
  • Distribute your trust anchors to all non-authoritative servers that will perform DNS validation using DNSSEC
  • Deploy certificates and IPsec policy to your DNS server
  • Configure the NRPT settings and deploy IPsec policy to client computers

For more information on deploying a secure DNS designing using Windows Server 2008 R2, go here.

Summary

In this article, we provided a high level overview of DNSSEC and discussed the reasons that securing your DNS infrastructure is important to your organization. Windows Server 2008 R2 introduces new features that help make your DNS infrastructure more secure than ever, through the combined used of signed DNS zones, SSL secured connections to trusted DNS servers, and IPsec authentication and encryption. In a future article, we’ll take apart the DNSSEC solution in more detail and look at the specifics of the new resource records, the signing process, and the client/server interactions that take place between a DNSSEC client and server

Posted in Windows 2008 | Tagged: , , , , , , , , , , , , , , , , , | Leave a Comment »

PKI Made Easy – Exchange Certificate Wizard

Posted by Alin D on October 27, 2010

One of the challenges with securing Exchange is managing its security. Exchange offers secure ways to connect to every mail protocol it offers, including SMTP/TLS, POPS, IMAPS, and HTTPS access for OWA, ActiveSync, and OWA. All of these, of course, require certificates, and that is where some admins run into problems. Exchange can generate its own, self-signed, certificates, and it will, but of course these are not trusted by clients. Admins can use certificates.msc, or certutil.exe to generate certificate signing requests, but here the challenge is generating a CSR that includes all the names and extensions required to secure all the services.

Exchange includes a wizard that you can run, which will generate a CSR with all the required properties needed for all services to run properly. Whether you submit this to your Enterprise Certificate Authority or a public CA, you can rest assured that your certificate will work for all your services. If this could be useful to you too, here is how to use the Exchange Certificate Wizard.

  1. Here is how to use the Exchange Certificate Wizard.
  2. Launch the Exchange Management Console.
  3. Browse down to Server Configuration.
  4. Select the server you are going to configure.
  5. From the Actions pane, click the New Exchange Certificate… to launch the wizard.
  6. In the first step, give the certificate a friendly name which will help you to identify it whenyou go to assign it to services, then click Next >.
  7. You are then prompted to enable a wildcard certificate. If you want to purchase a wildcardcertificate from a public CA, this is a great way to leverage one certificate for several purposes, especially when you are using a load balancer or securely publishing sites through TMG 2010. Just make sure you are purchasing the proper number of licenses based on the agreement with your CA. If you are not going to use a wildcard certificate, just click Next >. In this example, that’s what we’re going todo.
  8. In the next step, you can select each of the services you want to use with your Exchange server. The first choice, Federated Sharing, indicates that you must use a Public certificate, on the basis that your Federation partner will not trust your internally issued certificates. You can also enable Client Access server for OWA and ActiveSync, Web Services, Outlook Anywhere, and Autodiscover, Client Access for POP and IMAP, and Unified Messaging. There are also options for your Hub Transport server and Legacy Exchange server. Where relevant, you can enter both your intranet and Internet names, so that your one certificate can be used both internally, and on the web. Since certificates cost money, but they cost the same no matter which services you enable the names for, I recommend that you go ahead and activate all the ones you might possibly use. That way, you are covered as you enable more services later. After you enable the desired services and enter your intranet and Internet names, click Next >.
  9. Pick the name from the list that you want to populate in the certificate as the CN= property. Usually, this will be the NetBIOS name of your server, then click Next >.
  10. Fill out your Organisation, Organisational Unit, Country from the drop down list, your City, and your State (remember to spell it out, no abbreviations here.)
  11. Browse to the location you want to save your CSR to, and give it a name. I usually use my Desktop so it is easy to find. Click Next >.
  12. Verify the information in the last page, and click New. You will see the CSR listed under Exchange Certificates. Note that an incomplete CSR will not show a checkbox.
  13. Now, submit this CSR to your CA of choice, and when the certificate is issued, use the Complete Pending Request wizard to enroll the certificate. Launch that by right-clicking the pending certificate, and clicking Complete Pending Request…
  14. Follow the steps in this wizard, browsing to the issued certificate. When completed, this certificate will now show a check box under Exchange Certificates.
  15. Right-click it again, and launch the Assign Services to Certificate… wizard. Make sure only to assign it to those services you selected when you created the CSR.

And once the certificate is assigned, you should be good to go. I usually restart the services just to be on the safe side, but you should not have to reboot unless you want to take the easy way out. Of course, if you run your updates at the same time (and since this is maintenance window work, that’s probably a good idea) then a reboot will be needed any way, and it’s less work overall.

As you can see, Microsoft has come a long way in making PKI work easier for admins. While some folks really dig getting into the nitty-gritty of PowerShell commands, the rest of us can use the time saved to do other things, like sleep.

Posted in Exchange | Tagged: , , , , , , , , | Leave a Comment »

Reasons to Upgrade Your DNS Server to Windows Server 2008 R

Posted by Alin D on October 7, 2010

Introduction

DNS is the backbone of network communications. Without DNS you would be forced to memorize the IP addresses of all the clients and servers on your network. That might have been something you could have done in 1985, but it’s really not realistic as we enter into the second decade of the 21st century. And DNS is going to be even more important as we slowly transition from IPv4 to IPv6. While some talented administrators could realistically remember the dotted quad addresses for dozens or maybe even hundreds of servers, that just isn’t going to happen with IPv6; where the IP addresses are 128bit hexadecimal numbers. IPv6 is going to bring DNS back to the forefront of your awareness.

Because DNS is going to be ever more important, you’re going to need to be sure that your DNS server solution is secure. Historically, there was a large amount of implicit trust in DNS deployments. There was an implicit trust that the DNS client could trust the DNS server, and there was implicit trust that the records returned from the DNS server to the DNS client were valid. While this “gentleman’s agreement” has worked reasonably well for the last few decades, the time has come when we need to be able to guarantee that the information provided by the DNS server is valid and that client/server DNS communications are secure.

This has me thinking about the Windows Server 2008 R2 DNS server. There are several new features in the Windows Server 2008 R2 DNS server that you can use to improve the overall security of your DNS infrastructure. These include:

  • DNS Security Extensions (DNSSEC)
  • Control over DNS devolution behavior
  • DNS cache locking
  • DNS Socket Pool

In this article, I’m going to provide you a brief overview of each of these features and how you can use them to create a more secure DNS for your network.

DNS Security Extensions (DNSSEC)

DNSSEC is a group of specifications from the Internet Engineering Task Force (IETF) that provide for origin authentication of DNS data, authenticated denial of existence and data integrity (not data confidentiality). The purpose of DNSSEC is to protect against forged DNS information (for example, DNS cache poisoning), by using digital signatures.DNSSEC is actually a collection of new features added to the DNS client/server interaction that help increase the security of the basic DNS protocols. The core DNSSEC features are specified in:

  • RFC 4033
  • RFC 4034
  • RFC 4035

DNSSEC introduces several new terms and technologies on both the client and server side. For example, DNSSEC adds four new DNS resource records:

  • DNSKEY
  • RRSIG
  • NSEC
  • DS

Windows Server 2008 R2 Implementation

Windows Server 2008 R2 and Windows 7 are the first Microsoft operating systems to support DNSSEC. You can now sign and host DNSSEC signed zones to increase the level of security for your DNS infrastructure. The following DNSSEC related features are introduced in Windows Server 2008 R2:

  • The ability to sign a zone (that is, to provide the zone a digital signature)
  • The ability to host signed zones
  • New support for the DNSSEC protocol
  • New support for DNSKEY, RRSIG, NSEC, and DS resource records.

DNSSEC can add origin authority (confirmation and validation of the original of the DNS information presented to the DNS client), data integrity (provide assurance that the data has not been changed), and authenticated denial of existence to DNS (a signed response confirming that the record does not exist).

Windows 7/Server 2008 R2 DNS Client Improvements

In addition to the DNS server updates in Windows Server 2008 R2, there are some improvements in the Windows 7 DNS client (which also includes the DNS client service in Windows Server 2008 R2):

  • The ability to communicate awareness of DNSSEC in DNS queries (which is required if you decide to used signed zones)
  • The ability to process the DNSKEY, RRSIG, NSEC, and DS resource records.
  • The ability to determine if the DNS server with to which it had sent a DNS query has performed validation for the client.

DNSSEC and the NRPT

If you’re acquainted with DirectAccess, you might be interested in the fact that DNSSEC leverages the Name Resolution Policy Table (NRPT). The DNS client DNSSEC related behavior is set by the NRPT. The NRPT enables you to create a type of policy based routing for DNS queries. For example, you can configure the NRPT to send queries for contoso.com to DNS server 1, while queries for all other domains are sent to the DNS server address configured on the DNS client’s network interface card. You configure the NRPT in Group Policy. The NRPT is also used to enable DNSSEC for defined namespaces, as seen in Figure 1 below.


Figure 1

Understanding how DNSSEC works

A key feature of DNSSEC is that it enables you to sign a DNS zone – which means that all the records for that zone are also signed.The DNS client can take advantage of the digital signature added to the resource records to confirm that they are valid. This is typical of what you see in other areas where you have deployed services that depend on PKI. The DNS client can validate that the response hasn’t been changed using the public/private key pair. In order to do this, the DNS client has to be configured to trust the signer of the signed zone.

The new Windows Server 2008 R2 DNSSEC support enables you to sign file-based and Active Directory integrated zones through an offline zone signing tool. I know it would have been easier to have a GUI interface for this, but I guess Microsoft ran out of time or figured that not enough people would actually use this feature to make it worthwhile to make the effort to create a convenient graphical interface for signing a zone. The signing process is also done off-line. After the zone is signed, it can be hosted by other DNS servers using typical zone transfer methodologies.

When configured with a trust anchor, a DNS server is able to validate DNSSEC responses received on behalf of the client. However, in order to prove that a DNS answer is correct, you need to know at least one key or DS record that is correct from sources other than the DNS. These starting points are called trust anchors.

Another change in the Windows 7 and Windows Server 2008 R2 DNS client is that it acts as a security-aware stub resolver. This means that the DNS client will let the DNS server handle the security validation tasks, but it will consume the results of the security validation efforts performed by the DNS server. The DNS clients take advantage of the NRPT to determine when they should check for validation results. After the client confirms that the response is valid, it will return the results of the DNS query to the application that triggered the initial DNS query.

Using IPsec with DNSSEC

In general, it’s a good idea to use IPsec to secure communications between all machines that participate on your managed network. The reason for this is that it’s very easy for an intruder to put network analysis software on your network and intercept and read any non-encrypted content that moves over the wire. However, if you use DNSSEC, you’ll need to be aware of the following when crafting your IPsec policies:

  • DNSSEC uses SSL to secure the connection between the DNS client and server. There are two advantages of using SSL: first, it encrypts the DNS query traffic between the DNS client and DNS server, and second, it allows the DNS client to authenticate the identity of the DNS server, which helps ensure that the DNS server is a trusted machine and not a rogue.
  • You need to exempt both TCP port 53 and UDP port 53 from your domain IPsec policy. The reason for this is that the domain IPsec policy will be used and DNSSEC certificate-based authentication will not be performed. The end result is that the client will fail the EKU validation and end up not trusting the DNS server.

Control Over DNS Devolution

DNS devolution has been available for a long time in Windows DNS clients. No, it doesn’t mean that the operating systems are less evolved. Devolution allows your client computers that are members of a subdomain to access resources in the parent domain without the need to provide the exact FQDN for the resource.

For example, if the client uses the primary DNS suffix corp.contoso.com and devolution is enabled with a devolution level of two, an application attempting to query the host name server1 will attempt to resolve:

  • server1.corp.contoso.com and
  • server1.corp.com

Notice that when the devolution level is set to two, the devolution process stops when there are two labels for the domain name (in this case, corp.com).

Now, if the devolution level were set to three, the devolution process would stop with server1.corp.contoso.com, since server1.contoso.com only has two labels in the domain name (contoso.com).

However, devolution is not enabled in Active Directory domains when:

  1. There is a global suffix search list assigned by Group Policy.
  2. The DNS client does not have the Append parent suffixes of the primary DNS suffix check box selected on the DNS tab in the Advanced TCP/IP Settings for IPv4 or IPv6 Internet Protocol (TCP/IP) Properties of a client computer’s network connection, as shown in Figure 2. Parent suffixes are obtained by devolution.


Figure 2

Previous versions of Windows had an effective devolution level of two. What’s new in Windows Server 2008 R2 is that you can now define your own devolution level, which gives you more control over the organizational boundaries in an Active Directory domain when clients try to resolve names in the domain. You can set the devolution level using Group Policy, as seen in Figure 3 below (Computer ConfigurationPoliciesAdministrative TemplatesNetworkDNS Client).


Figure 3

DNS Cache Locking

Cache locking in Windows Server 2008 R2 enables you to control the ability to overwrite information contained in the DNS cache. When DNS cache locking is turned on, the DNS server will not allow cached records to be overwritten for the duration of the time to live (TTL) value. This helps protect your DNS server from cache poisoning. You can also customize the settings used for cache locking.

When a DNS server configured to perform recursion receives a DNS request, it caches the results of the DNS query before returning the information to the machine that sent the request. Like all caching solutions, the goal is to enable the DNS server to provide information from the cache with subsequent requests, so that it won’t have to take the time to repeat the query. The DNS server keeps the information in the DNS server cache for a period of time defined by the TTL on the resource record. However, it is possible for information in the cache to be overwritten if new information about that resource record is received by the DNS server. One scenario where this might happen is when an attacker attempts to poison your DNS cache. If the attacker is successful, the poisoned cache might return false information to DNS clients and send the clients to servers owned by the attacker.

Cache locking is configured as a percentage of the TTL. For example, if the cache locking value is set to 25, then the DNS server will not overwrite a cached entry until 25% of the time defined by the TTL for the resource record has passed. The default value is 100, which means that the entire TTL must pass before the cached record can be updated. The cache locking value is stored in theCacheLockingPercent registry key. If the registry key is not present, then the DNS server will use the default cache locking value of 100. The preferred method of configuring the cache locking value is through the dnscmd command line tool.

An example of how to configure cache locking is seen in Figure 4 below. The percent value can range from 0 to 100.


Figure 4

Swimming in the Windows Server 2008 R2 DNS Socket Pool

OK, so you can’t swim in a socket pool. But what you can do with the Windows Server 2008 R2 DNS socket pool is enable the DNS server to use source port randomization when issuing DNS queries. Why would you want to do this? Because the source port randomization provides protection against some types of cache poisoning attacks, such as those described over here.

The initial fix included some default settings, but with Windows Server 2008 R2 you can customize socket pool settings.

Source port randomization protects against DNS cache poisoning attacks. With source port randomization, the DNS server will randomly pick a source port from a pool of available sockets that it opens when the service starts. This helps prevent an unauthenticated remote attacker from sending specially crafted responses to DNS requests in order to poison the DNS cache and forward traffic to locations that are under the control of an attacker.

Previous versions of the Windows DNS server used a predictable collection of source ports when issuing DNS query requests. With the new DNS socket pool, the DNS server will use a random port number selected from the socket pool. This makes it much more difficult for an attacker to guess the source port of a DNS query. To further thwart  the attacker, a random transaction ID is added to the mix, making it even more difficult to execute the cache poisoning attack.

The socket pool starts with a default of 2500 sockets. However, if you want to make things even tougher for attackers, you can increase it up to a value of 10,000. The more sockets you have available in the pool, the harder it’s going to be to guess which socket is going to be used, thus frustrating the cache poisoning attacker. On the other hand, you can configure the pool value to be zero. In that case, you’ll end up with a single socket value that will be used for DNS queries, something you really don’t want to do. You can even configure certain ports to be excluded from the pool.

Like the DNS cache feature, you configure the socket pool using the dnscmd tool. The figure below shows you an example using the default values.


Figure 5

Summary

In this article we went over several new features included in the Windows Server 2008 R2 server and Windows 7 DNS client that increase the security and performance of your DNS infrastructure. The combination of DNSSEC, improvements in control over DNS devolution, security enhancements in the DNS cache and the DNS socket pool all provide compelling reasons to upgrade your DNS servers to Windows Server 2008 R2.

Posted in Windows 2008 | Tagged: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Leave a Comment »

Kerberos Authentication template – Domain Controller Certificates

Posted by Alin D on September 16, 2010

When you install Windows 2008 Certification Authority a new domain controller certificate template named Kerberos Authentication is available. It replaces the Domain Controller Authentication template. If you need more information about the new certificate templates shipped with a Windows 2008 CA you can read this article.

Here is a tab that outlines the specific attributes of the Domain Controller Authentication and Kerberos Authentication templates:

Domain Controller Authentication Kerberos Authentication
Key Usage Client AuthenticationServer Authentication

Smart Card Logon

Client AuthenticationServer Authentication

Smart Card Logon

KDC Authentication.

Subject Alternate Name DNS Name : Domain Controller FQDN. DNS Name : Domain FQDN.DNS Name : Domain NetBios name.

For more information about the KDC Authentication key usage that help assure that smart card users are authenticating against a valid Kerberos domain controller you can read this document: Enabling Strict KDC Validation in Windows Kerberos.

Having the domain name rather than the domain controller name in the Subject Alternate Name of the certificate proves that the computer presenting the certificate is a domain controller for the domain contained in the Subject Alternate Name. Domain name should also be included in the certificate in order to enable Strict KDC Validation.

We will describe how to deploy the Kerberos Authentication template certificates on your domain controllers and how to revoke the old certificates issued with the Domain Controller Authentication template once they are useless. We distribute certificates to domain controllers using autoenrollment , to achieve this you need to configure your template (permissions, settings…) and setup a GPO.

If you want the new Kerberos Authentication template to replace the Domain Controller Authentication template, you need to configure it using certtmpl.msc by setting up the “Superseded Templates” tab. For more information you can have a look at the “Superseding Certificate Templates” chapter of this article.

Once the template is well configured and ready for autoenrollment, the new certificates will be deployed automatically, you can run the certutil -pulse command on the domain controllers, in order to speed up the autoenrollment process.

The new domain controller certificate is replaced in the local computer store, messages with source AutoEnrollment are displayed in the eventlog telling us that the Kerberos Authentication certificate is installed.

With Quest ActiveRoles Management Shell for Active Directory v1.4, you can manage certificates using PowerShell thanks to the Certificate and PKI management CmdLets. First we will check that the Kerberos Authentication certificates are installed on every Domain Controller:
Get-QADComputer -computerRole ‘DomainController’ | Get-QADCertificate -Revoked:$false -template:’*kerberos authentication*’ | format-table template,IssuedTo -autosize
Once all your domain controllers have enrolled the new Kerberos Authentication certificates and you have checked everything is running properly, you can disable the old Domain Controller Authentication template with certsrv.msc in order to avoid installing this kind of certificate on a domain controller.

Then you can revoke the old Domain Controller Authentication certificates which where superseded by the Kerberos Authentication certificates. To achieve that we will combine the Quest CmdLets and the Certutil -revoke command. You just need to retrieve the Domain Controller Authentication certificates serial numbers and specify the reason code for the revocation of these certificates: In our case 4 for Superseded:

Get-QADComputer -computerRole ‘DomainController’ | Get-QADCertificate -Revoked:$false -template:*domain controller authentication* | foreach {certutil -config %SRV_CA_FQDN%%CA_Common_Name% -revoke $_.SerialNumber 4}
You just need to adapt:

  • %SRV_CA_FQDN%: Issuing CA server FQDN.
  • %CA_Common_Name%: Certification Authority Common Name.

By combining the Certutil command line tool and Quest AD CmdLets v1.4, you can make some of your PKI management tasks automatic.

Posted in Windows 2008 | Tagged: , , , , , , , , , | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.

Join 387 other followers

%d bloggers like this: