Adventures in home working

A few of the longhorn technologies seem great for branch offices which we can assume to lack physical security and the high levels of management required for enterprise class service integrity.  if we string together Secure Startup (lack of security), read-only Domain Controllers (lack of service integrity, but resiliance to network outages) and Lonhorn Core (minimum attack surface and maximum up-time) we start to see the beginings of a good solution.

Here is a bit more on read-only domain controllers:

Read-only

An RODC holds all the Active Directory® directory service objects and attributes that a full domain controller holds, but clients are not able to write changes directly to the RODC. This means that changes that are made at branch locations cannot pollute or corrupt the forest. Local applications requesting Read access to the directory are satisfied, while Lightweight Directory Application Protocol (LDAP) applications requesting Write access are referred to a full domain controller at a hub location.

Unidirectional Replication

Because no changes are written directly to the RODC and therefore do not originate locally, full domain controller replication partners do not have to pull changes from the RODC. This reduces bridgehead load in the hub as well as the effort it takes to monitor replication.

RODC unidirectional replication applies to both Active Directory and File Replication service (FRS) replication. The RODC performs normal inbound replication for Active Directory and FRS changes.

Credential Caching

Credential caching is the storage of user or computer credentials. Credentials consist of a small, well-defined set of approximately 10 encryption keys that are associated with each user or principal.

By default an RODC will not store user or computer credentials except for its own computer account and a special krbtgt account. The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different krbtgt account and password than the KDC on a full domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests. This makes it possible for the RODC to identify authentication requests and forward them to a full, writable domain controller.

When the RODC processes a successful authentication request, it attempts to contact and pull the user’s credentials from a full domain controller at the hub location. The full domain controller acknowledges the request based on the special krbtgt account of the RODC. The credential-caching policy that is enforced at the full domain controller determines if a user’s or computer’s credentials can be replicated from the full domain controller to the RODC. If the credential-caching policy allows it, the full domain controller replicates down the credentials. After a user’s credentials are cached on the RODC, the RODC can service that user’s logon requests directly until the credentials change.

Credential caching limits the potential exposure of users’ credentials in the branch office because typically only a small subset of the user base will have their credentials cached on any given RODC. Thus, in the event that the RODC is stolen, only those credentials that are cached can potentially be cracked.

I have promoted the concept of standard corporate PC builds for over a decade,  in fact my first standard PC’s were in fact Unix workstations back in the late 1980’s.  However I have become increasingly unsure of the approach as we find more and more uncontrolled devices connecting to the network (customers, partners, contractors etc), more home devices being used and more IT literate users who want to take on the burden of management in return for flexibility.

In all of these senarios it’s not standard builds that are important but policy compliance and enforcement. Enter NAP, I first came across NAP in SSL VPN’s but now I see it being much more universally used on corporate networks, and heralding improved security and greater freedom and flexibility, especially for innovators, developers and other creative professionals.   Here’s how Microsoft describes their Longhorn implementation:

NAP, a set of components in the Microsoft® Windows® Code Name “Longhorn” client operating system and in the Microsoft Windows Server™ Code Name “Longhorn” operating system, helps protect access to a private network by enforcing health policies. System administrators establish health policies, which can include such things as software requirements, security update requirements, and required configuration settings. NAP enforces health policies by inspecting and assessing the health of client computers, restricting network access when client computers are deemed unhealthy, and remediating unhealthy client computers for full network access. NAP enforces health policies on client computers that are attempting to connect to a network; NAP also provides ongoing health compliance enforcement while a client is connected to a network.

To help protect network access, NAP relies on four key processes.

Policy Validation

NAP uses health policies to determine whether a client computer is allowed access to a network. The system administrator defines health policies, which include such things as virus signature requirements, security update requirements, and firewall configuration settings. NAP deems a client computer as healthy if it complies with current health policies and unhealthy if it does not comply.

Network Restriction

NAP denies unhealthy client computers access to the network or allows them access only to a special restricted network (sometimes known as a quarantine network or a remediation network). Set up properly, a restricted network provides client computers with access only to servers that can update them to a healthy state.

Remediation

Unhealthy client computers that are put into a restricted network might undergo remediation. Remediation is the process of automatically updating a client computer so that it meets current health policies. For example, a restricted network might contain a File Transfer Protocol (FTP) server that automatically updates the virus signatures of unhealthy client computers that have outdated signatures.

Ongoing Compliance

NAP can enforce health compliance on client computers that are already connected to the network. This functionality is useful for ensuring that a network is protected on an ongoing basis as health policies change and the health of client computers change. For example, NAP will determine that the client computer is in an unhealthy state if a health policy requires that Windows Firewall be turned on and an administrator inadvertently turns it off on a client computer. NAP will then put the client computer into the restricted network until Windows Firewall is turned back on.

NAP enforces health policies for the following network access technologies: Dynamic Host Configuration Protocol (DHCP) address configuration, network connections based on virtual private networking (VPN), and communication based on Internet Protocol security (IPsec). NAP also provides a suite of application programming interfaces (APIs) that allow companies other than Microsoft to integrate their software into the NAP platform. By using the NAP APIs, software vendors can provide end-to-end solutions that validate health and remediate unhealthy clients.

I would add only a little to this description and that is that in many cases the resticted network that non-compliant devices have access to needs to provide access to the internet, this means that visitors who connect to your network then can get “home” without impacting on the integrity of your network.

This is a great example of a feature that needs MDS, MCS, MNS and GISS to work together!

More information is in the attachment.

For years, in fact since the beginning,  Microsoft have been critisised over the complexity of their serviver operating system and recently over the resulting large attack service.  The response is Longhorn Server Core:

Server Core is a new minimal server installation option for Windows Server “Longhorn” Beta 1. Server Core provides an environment for running specific Server Roles, reducing the servicing and management requirements for those Server Roles. Server Core supports the following Server Roles:

·      DHCP server

·      File Server

·      DNS

·      Active Directory®

The Server Core installation option is designed to provide a minimal environment to run the above Server Roles and reduce:

·      Required servicing

·      Required management

·      Attack surface

To accomplish this, the Server Core installation option installs only a subset of the Server binaries, those that are required by the above four server roles. For example, the Explorer Shell is not installed as part of Server Core. Instead, when using a Server Core based server, the default user interface is the command prompt.

I find it difficult to get excited by print management,  however its an essential task.  I am much more interested in Metro which will have a direct impact on the user experience.  That said Longhorn definately looks like it improves on print management in a way that will allow service providers with a way to reduce costs and be more pro-active. In CSC we are just about to launch a manged print service, which will provide many of the same advantages, but with longhorn its built in and will over time work on all printers. Here is a summary of the capabilities, with more in the attachment.

Print Management is a snap-in in Microsoft Management Console (MMC) that enables you to install, view, and manage all of the printers in your organization from any computer running Windows Server 2003 R2 and the “Longhorn” versions of Windows operating systems. Print Management provides up-to-the-minute details about the status of printers and print servers on the network. You can use Print Management to install printer connections to a group of client computers simultaneously. Print Management can help you find printers that have an error condition by using filters. It can also send e-mail notifications or run scripts when a printer or print server needs attention. On printer models that provide a Web page, Print Management has access to more data, such as toner and paper levels, which you can manage from remote locations, if needed.

 

Print Management saves the print administrator a significant amount of time installing printers on client computers, and managing and monitoring printers. Tasks that can require up to 10 steps on individual computers now can be accomplished in 2 or 3 steps on multiple computers simultaneously and remotely.

By using Print Management with Group Policy, you can automatically make printer connections available to users and computers in your organization. In addition, Print Management can automatically search for and install network printers on the local subnet of your local print servers.