Month: September 2013

Windows Server 2012 R2 Failover Cluster – Global Update Manager

Pretty interesting new feature is implemented in Windows Server 2012 R2 failover clustering that allows you to manage how cluster database is updated.

Service responsible for this is called Global Update Manager. This service is responsible for updating the cluster database. In Windows Server 2012, you were not able to configure how these updates work, but in Windows Server 2012 R2 it is possible that you  configure the mode of work for Global Update Manager.

Each time the state of cluster changes (for example, when cluster resource is offline) all nodes in the cluster must receive notification about the event, before the change is committed to the cluster database, by Global Update Manager.

In Windows Server 2012, Global Update Manager works in Majority (read and write) mode. In this mode, when change happens to the cluster, majority of cluster nodes must receive and process the update before it is committed to the database. When cluster node wants to read the database, cluster compares the latest timestamp from a majority of the running nodes, and uses the data with the latest timestamp.

In Windows Server 2012 R2, Global Update Manager can also work in All (write) and Local (read) mode. When working in this mode, all nodes in the cluster must receive and process the update before it is committed to the database. However, when the database read request is received, the cluster will read the data from the database copy stored locally. Since all roles received and processed the update, local cluster database copy can be considered as a relevant source of information.

Windows Server 2012 R2 also supports the third mode for Global Update Manager. This mode is Majority (write) and Local (read). In this mode majority of cluster nodes must receive and process the update before it is committed to the database. When the database read request is received, the cluster will read the data from the database copy stored locally.

In Windows Server 2012 R2, default setting for Hyper-V failover clusters is Majority (read and write). All other workloads in the clusters use All (write) and Local (read) mode. Majority (write) and Local (read) is not used by default for any workload.

Using digital signatures in emails

Implementing digital signatures in Exchange/Outlook environment is not a very complex. However, it requires that you understand how this technology work, and also must have some infrastructure background implemented.
Digital signatures actually protect the content integrity. They don’t provide any protection in a meaning that content of the message can’t be intercepted and read by someone else. However, if the content is altered during transport, digital signature will alert you on this.

When an author digitally signs a document or a message, the operating system on his machine creates a message digest which ranges from between a 128-bit and to a 256-bit number. It is generated by running the entire message through a hash algorithm. This number then is then encrypted by using the author’s private key, and then it is added to the end of the document or message.

When the document or message reaches the recipient, it will go through same hash algorithm as when it was digitally signed. Also, the recipient uses the author’s public key to decrypt the digest that is added to the message. After it is decrypted, it is compared to the digest that the recipient has generated. If they are the same, the document or the message was not altered during transport. Also, if the recipient is able to decrypt the digest by using the author’s public key, this means that the digest was encrypted by using author’s private key, and that confirms the author’s identity. At the end, the recipient also verifies the certificate that was used to prove author’s identity. During this check, the validity period, CRL, subject name, and certificate chain trust also are verified. Make sure that certificates that you use for digital signatures have valid CDP and AIA locations defined.

To implement digital signatures in internal communications, you just need to issue certificates based on the User template. This certificate template is present by default on each Windows Server CA. Of course, you can also use a custom template for this, or you can use smart card certificates for digital signature. This is actually pretty common if smart card infrastructure is deployed. You must issue certificates to all users that who use digital signatures, as authors (don’t need to have one just to read digitally signed message). You can issue the certificate without any user intervention if you use autoenrollment. Also, users must use an application that supports content signing. The digital signatures are ready to be used after the certificate is issued and configured in the application. Certificate for digital signature will be mostly automatically configured in Outlook, so the end user will not need to perform any configuration. If you want to use digital signature in OWA, you will need to install latest S/MIME controls. For mobile platforms and digital signatures, things are not so simple. At the moment, most mobile platforms do not support functionality of digital signature in an email (although ActiveSync does support it on protocol level).

However, if you want to send digitally signed content outside of your organization, you can experience CA trust issues. In this scenario, a recipient is not in the same domain as the author, so it does not trust a the CA that issued a the certificate for the digital signature. Although this kind of digital signature will still be valid from the aspect of content protection perspective, an application being used will probably generate a warning on the recipient side.

If you have a need to send digitally signed content to recipients outside of your organization, I recommended that you buy certificates from a public, globally trusted, CA.