Introducing Windows Server 2008 R2 - Free eBook
Fantastic new book hot off of Microsoft Press covering Windows Server 2008 R2.
Excerpt from the book:
“This book is targeted primarily at Windows server administrators who are responsible for hands-on deployment and day-to-day management of Windows-based servers for large organizations.”
Chapter breakdown is as follows:
Chapter 1, “What’s New in Windows Server R2”
Chapter 2, “Installation and Configuration: Adding R2 to Your World”
Chapter 3, “Hyper-V: Scaling and Migrating Virtual Machines”
Chapter 4, “Remote Desktop Services and VDI: Centralizing Desktop and Application Management”
Chapter 5, “Active Directory: Improving and Automating Identity and Access”
Chapter 6, “The File Services Role”
Chapter 7, “IIS 7.5: Improving the Web Application Platform”
Chapter 8, “DirectAccess and Network Policy Server”
Chapter 9, “Other Features and Enhancements”
And best of all a free electronic version is available here:
I have been to a lot of sessions and attended two keynote sessions this is my third VMworld and this year was really more about the Cloud message. Really while the term Private Cloud is new the concepts are the same thing customers wanted 5-7 years ago when embarking on the server consolidation journey. When service utilities, just in time infrastructure, service oriented infrastructure was all the rage. At Microsoft during that same time we announced our Dynamic Datacenter initiative which was focused on modeling, operations and developer knowledge coming together and rich application knowledge deployed into the management infrastructure. This allowed the applications to be managed automatically when they were deploying into the infrastructure. So what is the difference today you ask, well of course machine virtualization is the key enabler that provides the decoupling of the virtual machine from physical hardware and the movement of virtual machines without downtime takes what we can do to new levels. That being said it was clear to Microsoft years ago that rich information about the applications was key to a great management platform and building that information at application development time was key. This week I watched as the VMware message was directed at management and deep understanding of the applications running in the virtual machine all goodness but something we understood years before (It is about the applications). We are taking different approaches to get to the same end instead of depending on a tool to listen to application calls on the network and gather information about application knowledge; we provide the infrastructure for application developers with the best expertise of their application to provide us this information in the form of a comprehensive management pack. How many applications provide this knowledge you ask well take a look here:
http://technet.microsoft.com/en-us/systemcenter/cc462790.aspx there are hundreds of examples including a management pack for ESX as well. Also Dell just released an updated to their management pack that gives you deep hardware information at:
http://support.us.dell.com/support/downloads/format.aspx?releaseid=R237719. So providing the infrastructure to unify physical, virtual and application management is something that Microsoft does well today and will continue to innovate on. Sometimes in the software industry a lot of weight is placed on code maturity clearly Microsoft has a much more mature Systems Management toolset with System Center and a head start in unified management across physical, virtual and applications. I plan to spend the next few blogs on this topic.
Allen Stewart – PM Lead Windows Server
This week, we've been in the Enterprise Engineering Center (EEC) doing our scale testing on a project to help build the world's largest PKI. When fully implemented over the next couple of years, this PKI will be the world's largest, issuing 100s of millions of certificates from 100s of CAs to devices around the world. The entire design is built on WS08R2 Hyper-V and WS08/WS08R2 CAs. Management is done using SCVMM.
In the EEC, we were able to simulate a portion of the hosting environment and drive load against it to find bottlenecks and optimize around them. To simulate one of the Hyper-V hosts, we used a similar machine to the ones being used the hosting facilities: a 2.4GHz, 4 socket, quad core machine with 64GB. We took a sysprep'd copy of the actual CA VM image used in the customer environment and loaded our host with 10 VMs, each assigned a single VCPU and 6GB. All 10 of these VMs were connected to an nCipher netHSM 2000. To generate load, each CA VM was paired with a single DC and 5 client machines, each assigned a single VCPU and 2GB and separated from the CA by a WAN simulator that added latency and throughput constraints based on the customer's actual network topology. We used an internal PKI test tool to have each client machine open 4 request sessions and requests 1000000 2K key certs per session.
After <24 hours, we'd issued >20 million certificates from this single physical chassis. During these tests, we found that:
Overall, this testing was a great validation of the performance of ADCS. Our software ran as fast as the HSM would allow and we gracefully handled response delays introduced by it. Also, the fact that we're able to run this configuration entirely on Hyper-V and get ~30 CAs per physical host provides an efficient scale story for even the very largest and most complex environments around.
Security events are different than other Windows events because they require a special level of authentication/credentials in order to read or forward these events. Different configurations are required depending on which Windows platform is the client. The event collector functionality is only implemented in Windows Vista or Server 2003 R2 (or later).
The following table illustrates the special configurations required for each platform:
|
Platform |
Configuration Requirement |
|
XP SP2+ |
The “Windows Remote Management” Service needs to run as “Local System” (make sure you're okay with this elevation - it does have potential security ramifications) |
|
Server 2003 |
The following “CustomSD” key needs to be set within “HKLM/SYSTEM/CCS/Services/EventLog/Security” to “O:BAG:SYD:(A;;CC;;;NS)” |
|
Vista, Server 2008, and beyond |
Add “Network Service” to the “Event Log Readers” Local Security Group |
Note: A popular scenario includes forwarding Security Events from a Domain Controller in order to get an enterprise view for auditing and security monitoring. Due to the large number of Security Events that tend to be generated on Domain Controllers, the Event Forwarding subscription should not request that Forwarded Events be "Rendered". Event rendering for a large number of events will consume a large amount of processing resources on the client. The "ContentFormat" of the subscription needs to be set to "Events" rather than the default "RenderedText". This change can be made via "WECUTIL.EXE".
<ContentFormat>Events</ContentFormat>
Note: In addition, Security events are typically considered time sensitive and it's desirable to forward them immediately, rather than at a set interval. The following "MaxItems" setting for the subscription insures that events are forwarded as they occur (only valid for "Push" subscriptions).
wecutil ss <subscription name> /cm:Custom /dmi:1
More details can be found below:
We recently released the DirectAccess Step by Step Guide and many customers are using it to start understanding and testing DirectAccess in their labs, which is great. However, if you're planning to virtualize your lab environment on Hyper-V, you should ensure you're using Legacy Network Adapters for the child partition where you're running the DAS. Using the default synthetic NICs is OK for all the other resources in the test lab, but for the DAS itself, it's important to have both the Internet and Corpnet NICs as legacy ones, to ensure proper passing of traffic between both sides of the DAS. If you use the default synthetic adapters, you may end up in a situation where traffic doesn't properly flow from the outside to the inside, even though all your IPsec, 6to4, Teredo, and IP-HTTPS settings are correct. Basically, you'll be in a situation where connectivity will fail at a basic level, with you not even being to successfully ping the internal DNS server using its ISATAP address.
If you've already built your lab on Hyper-V using the synthetic adapters, the fix is pretty simple. Just replace them with legacy ones, reconfigure the IP addressing as specified in the guide and rerun the DirectAccess wizard, again supplying all the information specified in the guide. After doing so, all your traffic should flow properly.
In my last post I talked extensively about the use of 802.1x for network authentication (wired or wireless) and talked about the benefits of the 2 common approaches to controlling machine access (VLAN vs. Port ACL). While 802.1x remains a very popular mechanism for controlling port based access for machines coming onto the network, it also has some significant requirements associated with it, primarily, having 802.1x capable switches and/or access points in place today. You would be surprised how many people think that their devices support this capability, but in reality, they may find that this is not the case. What this means is that if your hardware vendor tells you that what you have isn't 802.1x capable, be prepared for some sticker shock when you find out how much it will cost for an upgrade!
Given the state of IT budgets today, doing a massive hardware upgrade is probably not something you are prepared to do now, or any time in the near future. That being said, you still have the requirement of securing the endpoints that are on your network and ensuring that they are kept up to date with patches, AV signatures, Anti-Malware Definitions etc. These 2 efforts may seem to conflict, but they certainly don't have to.
Let me introduce you to Server and Domain Isolation (SDI) with IPsec, all built into Windows, all free of charge!
Now, as to not sound like a late night infomercial peddler of dodgy wares, I will explain what I mean by "free of charge". What this means is that if you have purchased Windows Server (any SKU or version) and a Windows Desktop OS (Windows 2000 or later) and an associated Client Access License (CAL) (you usually purchase a CAL when you buy a server from Microsoft), these technologies do not have any additional licensing requirements whatsoever.
Now that we have the cost definition out of the way, let's talk about what these technologies can do for you.
Server and Domain Isolation (SDI)
Simply put, SDI utilizes the IPsec (Internet Protocol Security) technologies that have existed in Windows ever since the days of Windows 2000. What SDI allows you to do is to create access policies based on Active Directory groupings that can require authentication between any set of machines in the network (or all machines). The tools for creating and distributing these policies are also built into Windows and policies are distributed via the Group Policy mechanism, meaning that yes, a machine must be joined to the domain to easily take advantage of SDI. Since we are talking machine and/or user authentication here, there are 2 options for credential use in SDI, they are X509 certificates, or a Kerberos ticket. There are advantages and disadvantages to the use of each of these credentials which I won't go into here, but the message is that there is flexibility here with both credentials being secure (i.e no passwords.)
Now, let's talk about one big option that 802.1x cannot offer you, and that is data encryption.
Many customers have never really ever considered doing any kind of encryption on their network because they probably never understood how easy it is to implement. Many think that there is some hardware requirement, or that their machines will come to a crawl performance wise, when in reality, neither are true. Granted, you have the option to create very stringent policies that require stronger encryption, but in many cases you simply won't need to do something like this, or may choose to bypass encryption all together.
Example
Here's a real world example of how SDI can be used:
The Microsoft network uses SDI technologies to protect our assets. Pat Fetty (aka me) is a known and trusted employee and is allowed to access the network from his office, or remotely every day. However, since Pat is not a Windows developer, pat is unable to access or even see or ping our source code servers. Pat is also unable to see things like our HR server, financial servers etc. How is that you ask, well, Pat is not in the proper security groups in AD to have the proper policy applied to him, or his machines, that allow this type of access.
Using this simple example, think of some of the other scenarios that you, or your customers may be faced with that you may be able to solve. Here are some others I have come across in my job in the WinCAT team:
- Allow only doctors to see patient records, and encrypt all traffic going to and from those servers
- Allow only attorneys to be able to see servers X, Y and Z
- Encrypt all traffic to and from an ATM machine to the banks home offices
- Encrypt all Active Directory synchronizations between servers where traffic is going over the Internet
- Authenticate all traffic from my Windows machines, but exempt traffic from my main frame machines and all Macintosh machines (we'll talk a bit more about this)
This is just a small sample list of real business problems that are out there that SDI can help to solve.
Now, getting back to the last item regarding mainframes (let's just say all *ix) and Macs. There are Ipsec stack implementations available for these platforms, but I have personally not seem them work. As previously mentioned, the Microsoft SDI set of technologies are based 100% on public RFC's so there is no reason to expect that any implementation that is RFC compliant wouldn't work with any Windows machine.
Another reason why this is important is because the tools to build and manage SDI policies allow you to create very simply policies to address this scenario. For instance, you can have a policy that looks like this:
If you are a machine in group A, and you are capable of negotiating IPsec, then negotiate IPsec with a (Kerb ticket or cert)
else
Allow traffic to flow in the clear
You may be asking yourself "what kind of security policy is that" and the answer is that it is one that doesn't disrupt the flow of traffic on the network, and yet will negotiate the security you dictate when possible. This is a very important concept since the reality is that your machines today are most likely not doing any kind of SDI today, so by having your policies based on AD group membership, and by having a "best effort" type of policy like this you can ease this type of technology into your network with little or no disruption!
SDI versus 802.1x
We talked about this at the beginning and I think that SDI is the hands down winner here given that if you are a Windows environment
Deployment
To do 802.1x means you will have to touch all the switches and AP's in your network and configure them to do 1x on their ports, and to then send all traffic to a back end authentication server. In many cases, the group that manages desktops and servers in your company is not the same group that manages the infrastructure, so you now are getting more people involved in the effort.
SDI utilizes Group Policy and other built in tools to distribute policies and credentials, and the best part about this whole thing, is that SDI will work across whatever hardware you have in place today!
Management
This is a bit of a toss up, but I'd give SDI an edge since you can use a variety of methods to manage who is on the network accessing resources. 802.1x usually requires an enterprise ready SNMP (Simple Network Management Protocol) solution either from our hardware vendor or from a third party
Security
This is the one that gets the networking guys feathers ruffled, but I give SDI the advantage here for a couple of reasons. First, SDI offers you the ability to encrypt traffic which is something that 1x cannot offer. Second, in 802.1x, once you get passed the switch you are on the network doing what you please until you either reboot, or the switch kicks you off the port. SDI allows you to control the credential that is given to that client so that if for some reason you need to remove the client from the network, you can more quickly do so via SDI than 1x.
Overall I feel that both technologies here offer up some nice benefits (we didn't even touch on Guest Access which I feel is better done with 802.1x than SDI), but in the end, you should evaluate what your business needs are and make your technology decision on that. Usually the second phase of that decision process is cost, and that is where using the tools we have built into Windows can save you loads of money down the road assuming you plan on running Windows for the foreseeable future (which we hope that you are of course!)
With budgets shrinking and/or disappearing I would encourage everyone to take a look at what you have purchased in the Windows platform and ask Microsoft how to best utilize it because we are definitely here to help you get the most out of Windows!
One of the technologies that I've been working on is DirectAccess, a new feature in Windows 7 and Windows Server 2008 R2 that provides seamless connectivity to your enterprise network from wherever you are. I've been dogfooding DirectAccess for months now and I think it's going to be a real customer delighter. It's hard for me to imagine going back to traditional VPN.
That said, one of the first questions I always get from customers when I talk about DA is how does it fit into our overall remote access strategy? This is usually followed up with a joke about whether we have any strategy at all. That's a fair question because while we have a lot of great technologies, we often don't do a great job of articulating what to use when. For example, customer hear us use terms like L2TP, IAG, RDP, SSTP, and DirectAccess, but it can be difficult to understand if these are competitive or complementary technologies not to mention which ones fit which usage scenarios. So, I wrote this post to try to clarify how all the pieces fit together and hopefully encourage customers to see all these technologies as different tools in the same box, all of which share a common goal of enabling secure remote productivity.
I often use the following diagram to illustrate this relationship:
The foundation of the remote access strategy is Windows Server. Windows is where we ship the base protocols (e.g. L2TP, SSTP, RDP, etc.) that users connect with as well as the APIs that partners (both internal and external) build other products on top of. Above the basic protocols and APIs in the operating system, we also ship more complete solutions in the form of server roles and features. In the above example, you can see that Remote Desktop Services (formerly known as Terminal Services) and Network Access Protection are both roles and features that build on the base protocols.
Above the operating system layer, you can see the Forefront remote access technologies that provide further value on top of the protocols and server roles. Forefront TMG is the next version of ISA Server and implements an enterprise class firewall with reverse proxy capabilities. On top of Forefront TMG, Forefront UAG implements an advanced web based portal and SSL VPN, integrating various connection protocols like RDP and SSTP into a single easy to use interface and management control point. At the very top of the pyramid are the remote users connecting through these products.
If this seems like a lot of different pieces, it definitely is, but the net result is actually much simpler for customers. Basically, it's this: for Windows 7 clients, have them configured for DirectAccess. DA provides the best, most transparent end user experience and unparalleled levels of remote administration and control. For all other scenarios, use UAG. UAG integrates all the other pieces together into a single package, providing users with access to all their apps from wherever they are in a policy driven manner, simply by typing in a URL. For example, an administrator might say that a user connecting through UAG from a home computer with up to date anti-virus can access OWA normally, upload files to SharePoint, use Remote Desktop Services RemoteApps to run SAP, and create a full VPN with SSTP. However, that same user connecting from an untrusted kiosk machine might not be able to send attachments in OWA, only download files in SharePoint, and not be able to access SAP or create an SSTP tunnel at all. UAG also has the benefit of providing a single packaged solution where a customer can get an appliance, ready to run VHD, or traditional installer that sets up everything they need in one place.
So, when you're thinking about the Microsoft remote access strategy, you really just need to think about 2 things. DirectAccess is the premium experience for Windows 7 systems and UAG provides a single solution for managing it and all other forms of access.
With the introduction of IIS 7.0 in Windows Server 2008 the game has changed. IIS 7.0 is built using a modular architecture from the ground up. This means two very important things. The first is you only have to install/enable the core set of features YOU want to use, gone are the days of a monolithic design where you had "stuff" running/installed that you simply did not need or use. The same can be said of Windows Server 2008 but that is a post for another time. The second part which is key and brings the most benefit is the module/extension based architecture of IIS 7.0. Currently on IIS 7.0 we ship a handful of in-box modules on top of the core web server engine.
· HTTP Modules (Static Content, Default Document, Directory Browsing and HTTP errors)
· Security Modules (Request Filtering)
· Compression/Performance (Static Content Compression)
· Diagnostics and Health (HTTP logging and Request Monitoring)
· Management (IIS Management Console)
· Windows Process Activation
In addition to the in-box modules that come with IIS 7.0 on Windows Server 2008, the IIS team has teed up, out of box modules that will add new functionality and extend current functionality. All of these modules are available from IIS.NET. These modules fall under the following categories: Content Publishing, Deployment and Migration, Media Serving, Application Hosting, Request Handling, Server Management and Security. These extensions are built upon a new public Integrated Pipeline API which allows modules to be plugged anywhere into the request processing pipeline. The beauty of this design is that we no longer have to wait to ship new features or extend current ones between versions of the core Operating System platform. So in other words gone are the days of old where you the customer had to wait for new version of Windows Server/Client for new functionality in IIS. This makes the IIS 7.0 Web Platform adaptable and nimble to industry trends, empowers us to deliver new functionality for you at greater velocity and allows our customers to build their own modules further extending the platform.
Now that was the history part. Not everyone is going to build their own extensions/modules from scratch and for those that want to there are lots of online resources discussing in greater detail this scenario. A lot of customers use our shipping extensions in their production environments to solve some of their current technology problems or build platforms on top of our platforms. In this post I want to briefly discuss three extensions available today from IIS.NET that are extremely powerful individually but can be leveraged together to build a fairly complex solution for your environment. I will keep this conversation at a high level because I want these examples to stimulate conversation with you our customers as to how you are using these extensions today, where you plan on taking them tomorrow and where do you think we can move them forward.
The three extensions are:
· URL Rewrite
· Application Request Routing
· Web Deployment Tool
At the time of this writing Web Deployment Tool (WDT) is at Beta 2, Application Request Routing (ARR) is at RC (Release Candidate) and URL Rewrite is RTW (Released To Web - Final - Production Ready). They are available in x86 and x64 flavors. I won't go into the specifics or the command sets for each module as they are covered in great detail by the IIS team on IIS.NET, but I will briefly summarize each module's core feature sets.
URL Rewrite is an extension to IIS 7 that provides a rules based engine that uses regular expression pattern matching and wildcard analysis against URLs, server side variables and HTTP headers and can generate back to the requestor custom URLs, Redirects, HTTP Responses or stop HTTP requests based on these patterns.
· Rules-based URL rewriting engine.
· Regular expression pattern matching.
· Wildcard pattern matching.
· Global and distributed rewrite rules.
· Access to server variables and HTTP headers.
· Various rule actions including redirect and request abort.
· Support for IIS kernel mode and user mode output caching.
· Lower case conversion function.
· Rewrite maps to generate the substitution URL during rewriting.
· Failed Request Tracing support.
· Built-in rule templates.
· Integrated user interface for testing regular expression and wildcard patterns.
· Integrated user interface for managing rewrite rules and rewrite maps.
· Integrated user interface for importing of Apache mod_rewrite rules.
Application Request Routing (ARR) is also an extension for IIS 7.0 that leverages the engine in URL Rewrite to provide rules-based routing and load balancing of HTTP/HTTPS requests.
· HTTP based routing decisions built using rules that examine HTTP request information.
· Sophisticated load balancing algorithms to determine appropriate servers to service the HTTP requests.
· Health monitoring for live traffic and specific URLs to determine the health of servers with a set of configuration parameters provided to calibrate baseline server health.
· Client affinity to direct all requests from a client to a specific server by using cookies.
· Host name affinity to streamline administration for Web servers and to create additional business opportunities.
· Management of multiple server farms to enable pilot management and A/B testing scenarios.
· Management and monitoring of all configuration settings and aggregated runtime statistics through IIS Manager interface.
· Support for Failed Request Tracing Rules.
Web Deployment Tool (WDT) is an extension that can be installed on either IIS 6.0 (Windows Server 2003) or IIS 7.0 (Windows Server 2008) and provides simplified migration, management and deployment of Web Servers, Web sites and Web applications.
· Seamless integration into the IIS 7.0 Manager and Visual Studio 10 interface.
· Web server migration and synchronization:
· Ability to synchronize or migrate the entire Web server, a Web site or application.
· Synchronizes only the data that has changed.
· Ability to detect missing dependencies during synchronization.
· Automatically gathers content, IIS Configuration, Certificates and ASP.NET configuration when you sync a Web site.
· Web application packaging:
· Packages a Web application or an entire site, including the associated SQL database.
· Automatically packages ACLs, COM, GAC and Registry settings.
· Supports both live servers and zipped packages as a source or destination.
· Web application deployment:
· Administrative privileges are not required in order to deploy Web applications.
· Integration with the IIS 7.0 Web Management Service (WMSVC) for remote deployment by non-administrators.
· Server administrators have granular control over the operations that can be performed and can delegate tasks to non-administrators.
· In addition to the IIS Manager and Visual Studio 10, tasks can be performed using the command-line, PowerShell cmdlets or public APIs.
Now as I previously mentioned above each of these extensions are fully functional as standalone products within the IIS 7.0 Web Platform. Now imagine that you are an enterprise customer, hoster or even a developer managing a web farm of any scale. As a previous enterprise customer when faced with the age old question do I "Buy vs. Build", I would leverage these extensions to do the heavy lifting for me in the creation of an automated web deployment platform. How you say? There are public APIs that are and will be made available to interact with the extensions so you can glue them together to build your solution for a seamless user experience.
Without getting into the details of what the master console would look like, the base functionality I would want is to deploy content (server, site, application), pull content (server, site, application), and control the flow of traffic (remember we are keeping this basic and leveraging just three extensions for this solution). I would use WDT as the deployment/backup/synchronization engine for my Web Servers, Sites and Applications. It runs as a remote service so I can include WDT as part of my Operating System base build or image. One might even store the packages in SQL so you have a central store for all published content and site/server settings with some versioning control. Depending on the size of the farm I can also have SQL replicas around the globe serving as the package content distribution store. Out of the box WDT provides delegation so you can control what users can deploy and where they can deploy to (they do not have to be an administrator to deploy Web Applications). From my console I can control traffic flow and reroute traffic using ARR and URL Rewrite. I can do rolling upgrades of content using this system and redirect traffic to other servers while content is being refreshed or populated. My users can even use it to move web applications through their lifecycle from DEV/TEST to QA and then Production, whether that be by migrating web applications via WDT to the various server farms or routing some production traffic via ARR and URL Rewrite to DEV/QA staging servers. If I suffer from seasonal effects and need to quickly provision capacity I can leverage my OS deployment system (SCCM, WDS, In-House, 3rd party) or virtual machine management system (SCVMM) to bring nodes online whether that be new physical host deployments or quickly provisioning virtual machines from library and the web deployment system will populate my server settings, site content and/or web applications and start directing traffic to these new nodes. The possibilities are endless.
I would encourage anyone who is not using any of these modules to hop on over to IIS.NET and take a look at what the team has to offer. I would encourage anyone who is using any of the modules today, not just the three I discussed in this blog to leave feedback on the forums. I would personally ask anyone using the three modules above to provide feedback either in the comments section or on the IIS.NET forums.
As for me...well I am a fairly new member of the team. Having recently come to Microsoft back in July 2008 after spending the better part of 14+ years working in the financial services industry in IT. This was my first post on the team site and it won't be my last. I look forward to future constructive two-way dialogue that hopefully come out of these posts.
-eric
Given that the NAC (Network Access Control) market is one of the hottest segments in the industry (I think virtualization has that distinction at the moment) it is fitting to take a look at the variety of options available from Microsoft's Network Access Protection (NAP). NAP supports a variety of what we call enforcement methods. In the NAP space, and enforcement method is simply a term that defines the way a machine connects to a network. In NAP, these are DHCP, 802.1x (wired or wireless), VPN, IPsec, or via a Terminal Services Gateway.
The most common method of the list is 802.1x for a variety of reasons. First, the industry has been selling 802.1x network authentication for the last 10 years. 1x gained tremendous popularity as wireless networking became prevalent in the late 90's and early 2000's and has been proven to be a viable solution to identifying assets and users on your network. For customers that have invested in 802.1x capable switches and access points, NAP can very easily be implemented to complement what is already in place. The Network Policy Server (NPS) role Windows Server 2008 has been dramatically improved to make 802.1x policy creation much simpler to do, however, what many people don't realize is that there really are 2 rather distinct ways to deploy 802.1x based NAP, and this is what we will be discussing today. These 2 methods are commonly referred to as the use of VLAN's or Port ACL's.
VLAN
Since we are talking about this in the context of NAP, this would be a good time to introduce the fact that taking the VLAN approach essentially requires that you involve the folks that own your switching infrastructure in your NAP plans. Why you ask, because you will now be asking them to touch all the switches and AP's on the network to create the VLAN structure that you will need for your NAP deployment. At a minimum, you would want to create 3 different VLAN's. One for 'healthy' or compliant computers, one for 'unhealthy' or non-compliant computers, and a third VLAN for guests, or unknown devices that cannot pass the ports requirement to do 802.1x authentication.
In the VLAN scenario, on your RADIUS server (i.e. our NPS server) you would create a policy that had a set of attributes with values that matched the VLAN you have created on the switch. The most common attributes used are Tunnel-Private-Group-ID, Tunnel-Tag and Filter-ID. The values for these attributes usually would match the VLAN name, or number you created on the switch.
As an example, let's say on your switch VLAN 100 is the compliant VLAN and VLAN 200 is the non-compliant VLAN.
To make this work when you walk through the wizard in NPS to create 802.1x policies you will create a compliant and non-compliant policy. When prompted to insert values for these attributes you will enter "100" for your compliant policy (i.e. Tunnel-Private-Group-ID = 100) and "200" for the non-compliant policy. Our wizard based configuration makes this very easy.
Once completed, when a machine comes onto your network and meets the criteria of one of the policies you created, the NPS will send back this tunnel information to the switch to instruct the switch to put that machine in the proper VLAN. Pretty simple and straight forward.
Port ACLs
There are 2 approaches here.
- You send the switch a 'reference' to an ACL you have already created on the switch
- You send the switch vendor specific attributes with values that tell the switch how to ACL the port
In scenario 1, you would do the heavy configuration on the switch by creating the ACLs you would want for compliant and non-compliant machines. Most likely those ACL's would restrict protocols and ports and access to only certain IP addresses. For this example let's say you have named your ACL's "compliant" and "non-compliant".
In your RADIUS server you would use something like the Filter-ID attribute (this is the most commonly supported attribute) with a string value of "compliant" or "non-compliant". When received the switch will then know what ACL to apply to that port.
In scenario 2, instead of configuring and sending the Filter-ID attribute, you would create Vendor Specific Attributes (VSAs) (this is a common concept in the RADIUS protocol) that tell the switch explicitly what ACL's to apply to that port. For example, the HP ProCurve line of switches will accept the following Vendor Specific Attribute (VSA)
permit in udp from any to 10.10.10.2 53
This essentially says 'allow any DNS traffic on this port to IP address 10.10.10.2'. The assumption is that 10.10.10.2 is your DNS server.
The pros and cons of the 2 port ACL approaches are fairly similar as well.
- Pros, simplified RADIUS server configuration, less prone to mistakes in the RADIUS server configuration; Cons, required to touch your entire switching infrastructure, ACL configuration isn't centralized
- Pros, doesn't require you to touch your entire switching infrastructure, configuration can be centralized on your RADIUS servers; Cons, more complex RADIUS server configuration, prone to mistakes in ACL configuration on the RADIUS server
Comparing the 2 approaches
Now that everyone understands what is required for each approach, let's take a look at some of the pro's and con's of each.
VLAN
+ The concept of VLAN's is one that is easy to explain that even a manager can figure out!
+ Doesn't require extensive knowledge of the RADIUS protocol to set up and anyone who's anyone at a switch CLI could get this set up pretty easily
+ Makes helpdesk troubleshooting a bit simpler by being able to quickly find out why a machine can't connect to (insert your answer here). It would go something like "Oh, you can't get to your mail because you're in VLAN 200!"
- The user experience can be very poor if the machine is being dynamically moved from VLAN to VLAN (which is what NAP does essentially). The reason why is because when a machine changes VLAN's the interface on the machine is torn down and essentially does an ipconfig /release /renew
- If not properly designed, this can be a real helpdesk nightmare. A common mistake here is to ACL down the non-compliant VLAN to not have any corporate access, which is a mistake since that machine may need to re-authenticate itself with the network after NAP has remediated it
- Requires you to touch all of your switches and AP's to do the VLAN creation and management.
- For NAP, your AP's and switches will need to support the ability to do dynamic VLAN assignment and not all switches and AP's support this concept. In fact, not all firmware versions from the same manufacturer support this, so an upgrade may be required.
Port ACL
+ Can possibly be implemented without having to touch all your switches and AP's since the configuration would reside on the NPS Server. This can also be seen as a political positive as well since infrastructure folks and server folks are commonly separate teams with separate objectives that rarely overlap.
+ The actual enforcement of the ACL is done at the switch or AP and thus offers the user a more pleasant experience since even if the machine is moving from a compliant to a non-compliant state (or vice versa) it is handled at the switch and not on the client machine (no ipconfig /release /renew)
+ The attributes and values required in your NPS policy to make this scenario work are commonly supported and have been for some time, so the chance of having to do a hardware upgrade in this scenario are less likely
- To really make this work effectively in an enterprise you really need to know the ins and outs of your switches and what is and is not supported, not to mention you must be a pretty good RADIUS geek as well to get this working (we are a dying breed these days… J)
- Troubleshooting and helpdesk support in this scenario is a bit more complicated since your NPS policy for this could have multiple ACL's in it that look like this (permit in udp from any to 10.10.10.2 53). It would not be
uncommon to have 10-12 lines like this in your policy and trying to figure out why a machine can't connect to a resource on the network
- Finding accurate documentation on exactly what attributes and values are supported for your device(s) can be a challenge
In conclusion
Hopefully now you have a better understanding of what 802.1x authentication support in NAP can offer you. 1x is a very powerful means of maintaining and safe and healthy network, but it's not the ultimate solution by any means. Network security and health is an ongoing exercise that may require multiple solutions to achieve your business goals (like using 1x and IPsec together for instance).
NAP is a very compelling feature with a lot of moving parts, so in future posts we will be visiting more topics around NAP. In the mean time, please visit the NAP development team's blog at http://blogs.technet.com/nap
One of the most compelling capabilities being added in IAG SP2 (which will also be available in UAG) is the 'virtual appliance' installation option. A virtual appliance is a preconfigured, ready to use Virtual Machine that already has Windows Server and IAG / UAG installed. Microsoft will build the VHD and make it available for customers to download. Customers will then take the Virtual Hard Drive (VHD) and drop it into a child partition on a Hyper-V host. At this point, the VM would function like a classic IAG installation, with all the normal features and capabilities customers have come to expect. The reason we've added this capability in IAG is to give customers options for how they want to deploy IAG in their networks. For many customers, the pre-tuned, dedicated hardware appliances available from our partners are a great option that fit in well with their overall management methodology. For other customers, they prefer a more standardized hardware platform in their datacenters and thus the virtual appliance on Hyper-V is preferred. Note that it's not a question of which is 'better'; the two options allow customers to chose the solution that best fits their environment.
For customers looking at deploying the virtual appliance, a common question is what is the best way to provide a secure virtualization environment for the IAG/UAG VM? There are three primary design options to choose from. Again, it's not a question of what option is best; rather, customers should look at each model and decide which best aligns with their management approach.
Option 1: Classic Physical Appliance
It may seem strange to list a physical appliance as an option here, but arguably the dedicated physical appliance is the most hardened configuration out of the box. The reason for this is that the OEM appliance vendors take Windows Server and IAG and really mold the entire hardware platform around them. In doing so, they reduce the attack surface of the machine by disabling services not critical to IAG, ensure necessary updates are installed, and then put that image on top of a hardware platform designed for them. Because IAG is built on top of Windows Server, it's possible for a customer to take many of the same software steps the OEMs do, but the benefit of the appliance is that it's all been done and tested for you. For customers looking for the most secure out of the box experience with IAG, physical appliances provide some unique benefits.
Pros: minimal configuration; pre-hardened operating system; hardware designed specifically for remote access gateway
Cons: limited hardware choice; potentially non-standard device and software configuration in an otherwise rationalized datacenter
Option 2: VM on Dedicated Hardware
While one of the key benefits of virtualization is the ability to run multiple operating systems simultaneously on the same physical hardware, it's by no means a requirement that a Hyper-V machine have more than 1 child partition. In other words, it's fully supported to run a Hyper-V system with only a single child. Why would you do this? If you want to have the manageability benefits of virtualization, but have workloads that can scale up and maximize an entire physical server, this approach is an effective model for getting the best of both worlds. Particularly when you use the Server Core option of Windows Server 2008 to run the parent partition, you have very minimal overhead incurred by doing so. In fact, key Microsoft web sites like TechNet and MSDN use this exact model in their production environments. When you think about this model for hosting IAG, the benefits are that you don't have concerns about resource contention between VMs (though Hyper-V has resource management controls available) and you don't have to worry about sharing the remote access gateway physical platform with any other workloads. Because Hyper-V supports the same huge catalog of server hardware that Windows Server 2008 does, you have great flexibility in what the physical layer looks like. Whether you prefer 1U, 2U, blades, and regardless of OEM, you'll be able to easily integrate the Hyper-V host and its IAG child partition into your existing datacenter. Finally, because you can use whatever hardware you prefer, it's easy to place the server wherever it needs to go within your network. For example, it is often easier to provision a new blade into the DMZ network to host IAG than it is to securely route traffic from the DMZ to a larger virtualization system in the internal network.
Pros: great choice in hardware; can use existing organization standards for hardware and operating system images; with Server Core, very low overhead for parent partition; great flexibility in network placement
Cons: may require greater setup effort to configure hardware and parent partition operating system
Option 3: VM on Existing Virtualization Environment
For customers that already have a Hyper-V environment, they may wish to simply add the IAG VM to the existing hosts. This is particularly true if a customer has already invested in building a highly reliable, well tuned hosting environment, using tools like Failover Clustering. In these cases, there's no problem with running IAG in a child partition on an existing physical server already running other VMs. So long as the traffic is properly routed to the VM, IAG can function perfectly well in such a configuration. However, when sharing physical resources with other child partitions, it's particularly important to allocate sufficient capability to the IAG VM. This should be done both by allocating enough memory and CPU capability to VM, as well as ensuring that Hyper-V prioritizes requests through the IAG VM appropriately. Additionally, there are significant performance and security benefits to dedicating physical network adapters solely to the IAG VM, rather than sharing them with other VMs. Having dedicated NICs ensures that IAG will not need to compete for network IO and simplifies the routing of remote access traffic to and from the VM.
Pros: efficiency of reusing existing investments in Hyper-V physical platform, such as Failover Clustering
Cons: more planning required to ensure sufficient resources for IAG child partition; potentially more complex network routing needs if the existing environment does not already receive traffic from internet hosts
Virtual appliances are all about customer choice; providing you with the right options for security and placement while allowing you to chose your own hardware platform or reuse one you already have. There's no right choice that applies to all situations, so think about your environment and goals, and chose the option that fits your network best.
One of the least known yet most powerful management features to ship with Windows Vista and Windows Server 2008 is built-in Event Forwarding which enables large scale health and state monitoring of a Windows environment (assuming health and state can be determined from Windows Events - which they usually can). Not only is this feature built into the latest versions of Windows, but it's also available for down-level OSs like Windows XP SP2+ and Windows Server 2003 SP1+ (here).
Note: True enterprise class Windows eventing is included with enterprise monitoring solutions like System Center Operations Manager.
This new Windows Event Forwarding (also known as Windows Eventing 6.0) is exceptional for the following reasons:
- Standards Based: No really! It leverages the DMTF WS-Eventing standard which allows it to interoperate with other WS-Man implementations (see OpenWSMAN at SourceForge).
- Agentless: Event Forwarding and Event Collection are included in the OS by default
- Down-Level Support: Event Forwarding is available for Windows XP SP2+ and Windows Server 2003 SP1+
- Multi-Tier: Forwarding architecture is very scalable where a "Source Computer" may forward to a large number of collectors and collectors may forward to collectors
- Scalable: Event Collection is very scalable (available in Windows Vista as well) where the collector can maintain subscriptions with a large number of "Source Computers" as well as process a large number of events per second
- Group Policy Aware: The entire model is configurable by Group Policy
- Schematized Events: Windows Events are now schematized and rendered in XML which enables many scripting and export scenarios
- Pre-Rendering: Forwarded Windows Events can now be pre-rendered on the Source Computer negating the need for local applications to render Windows Events
- Resiliency: Designed to enable mobile scenarios where laptops may be disconnected from the collector for extended periods of time without event loss (except when logs wrap) as well as leveraging TCP for guaranteed delivery
- Security: Certificate based encryption via Kerberos or HTTPS
This implementation will walk through the following example design where via Group Policy a domain computer group will be configured to forwared Windows Events to a single collector:
Implementation steps are as follows:
-
Step 1: Create Event Forwarding Subscription
-
Step 2: Configure WinRM Group Policy
-
Step 3: Configure Event Forward Group Policy
-
Step 4: Test
Step 1: Create the Event Forwarding Subscription on the Event Collector
In the Windows Event Forwarding architecture, the subscription definition is held and maintained on the Collector in order to reduce the number of touch-points in case a subscription needs to be created or modified. Creating the subscription is accomplished through the new Event Viewer user interface by selecting the 'Create Subscription' action when the 'Subscriptions' branch is highlighted. The Subscription may also be created via the "WECUTIL" command-line utility.
Note: Both Windows Vista and Windows Server 2008 can be event collectors (this feature is not supported for down-level). Although there are no built-in limitations when Vista is a collector, Server 2008 will scale much better in high volume scenarios.
Although the above subscription is configured to leverage Group Policy, the subscription can be configured in a stand-alone mode (see the "Collector Initiated" option). In addition, this subscription is designed to gather all events from the "Application" and "System" logs that have a level of "Critical", "Error", or "Warning". This event scope can be expanded to gather all events from these logs or even add additional logs (like the "Security" log).
Lastly, the subscription is configured to forward events as quickly as possible with the advanced settings delivery option of "Minimize Latency". The default setting of "Normal" would only forward events every 15 minutes (which may be more desirable depending the the Collector and Source Computer resources).
If Group Policy is not being used, configure the "Subscription type" to be "Collector Initiated". In this case Source Computers will need to be manually added to the Subscription either through the Subscription configuration or the "WECUTIL" command-line utility (which can also be scripted using PowerShell, but that's another topic).
Note: In cases where there Source Computer is generating a large volume of forwarded events (e.g. Security events from a Domain Controller), use WECUTIL on the collector to disable event rendering for the subscription. The task of pre-rendering an event on the source computer can be CPU intensive for a large number of events.
Step 2: Configure Group Policy to enable Windows Remote Management on the Source Computers (clients)
Group Policy can be used to enable and configure Windows Remote Management (WinRM or WS-Man) on the Source Computers. WinRM is required by Windows Event Forwarding as WS-Man is the protocol used by WS-Eventing. The following shows the Group Policy branch locations for configuring both WinRM and Event Forwarding:
The following GP setting will enable WinRM on the client as well as configure a Listener that will accept packets from ANY source.
Note: This Listener configuration should only be used in a trusted network environment. If the environment is not trusted (like the Internet), then configure only specific IP Addresses or ranges in the IPv4 and IPv6 filters.
To configure WinRM outside of Group Policy, run the following command on the Source Computer (also see the above Note):
winrm quickconfig
Step 3: Configure Group Policy to enable Windows Event Forwarding on the Source Computers
As with WinRM, Group Policy can be used to configure Source Computers (Clients) to forward events to a collector (or set of collectors). The policy is very simple. It merely tells the Source Computer to contact a specific FQDN (Fully Qualified Domain Name) or IP Address and request subscription specifics. All of the other subscription details are held on the Collector.
If Group Policy is not being used, then there is nothing to do here as the "Collector Initiated" Subscription will proactively reach out to the Source Computer.
Step 4: Test Event Forwarding
If all of the Event Forwarding components are functioning (and there's minimal network latency), a test event created on the Source Computer should arrive in the Collector's "Forwarded Events" log within 60 seconds. Create a test event with the following command:
eventcreate /id 999 /t error /l application /d "Test event."
This event should appear on the Collector as follows:
If the event doesn't appear, perform the following troubleshooting steps:
Troubleshooting Step 1: Has Policy Been Applied to the Source Computer?
This can be forced by running the following command on the Source Computer:
gpupdate /force
Troubleshooting Step 2: Can the Collector Reach The Source Computer via WinRM?
Run the following command on the Collector
winrm id /r:<Source Computer> /a:none
Troubleshooting Step 3: Is the Collector Using the Right Credentials?
Run the following command on the Collector
winrm id /r:<Source Computer> /u:<username> /p:<password>
Note: These are the credentials defined in the Subscription on the Collector. The credentials don't need to be in the local Administrators group on the Source Computer, they just need to be in the "Event Log Readers" group on the Source Computer (local Administrators will also work).
Troubleshooting Step 4: Has the Source Computer Registered with the Collector?
Run the following command on the Collector
wecutil gr <subscription name>
This will list all the registered Source Computers (note if the Subscription is "Collector Initiated" then this will list all configured Source Computers), their state (from the Collector's perspective), and their last heartbeat time.
Enjoy!
My name is Allen Stewart Team Lead of the Windows Server Customer Advisory Team in the Windows Server Division. We are a team of Program Managers that are experts in specific workloads/technologies. We work in the Windows Server Engineering organization and our main goal is helping to ship Windows Server that incorporates requirements/scenario based feedback directly from customers via Engineering focused customer councils and direct technical projects that my team engages in specifically focused on early, new complex scenarios. My team looks forward to working with the technical community and sharing best practices from our learning's across a range of topics for specific server workloads. Our blog will be the main way we communicate some of the interesting things we discover. Each month we will communicate a new topic (see John Morello's blog post: on Clustering CA'S) http://blogs.technet.com/wincat/archive/2008/07/21/to-cluster-or-not-to-cluster-cas.aspx
I would like to introduce the members of my team and their focus areas:
Allen Stewart | System, Management & Application Virtualization |
Xavier Pillons | High Performance Computing |
John Morello | Windows Security, Anywhere Access |
Otto Helweg | Windows Management, Datacenter Automation, Sysinternals |
Pat Fetty | Network Health and Policy, Forefront Suite |
Robert DeLuca | Identity |
Allen Stewart - Principal Program Manager Lead
One of the many enhancements in Active Directory Certificate Services in Windows Server 2008 is support for 2 node active / passive clustering. We have a great whitepaper, Configuring and Troubleshooting Certification Authority Clustering in Windows Server 2008, which walks you through the setup process. Because we just leverage the Failover Clustering already in Windows, the supported hardware and software configurations for running a highly available CA are the same for running other applications on a cluster. Many of the customers I work with have recently asked about whether or not they should implement clustered CAs and the answer really depends on what you're trying to achieve.
The first thing to understand is that having a highly available CA does not mean the same thing as having a highly available PKI. While it performs a critical role, the CA itself is only one part of the overall PKI and it could be argued that other components, such as CRL Distribution Points, are actually more sensitive to outages. In most PKIs, end entities will only talk directly to a CA to enroll for / renew certificates. If a computer enrolls for a certificate with a 2 year validity period, that computer will talk to the CA once to get the initial certificate and then not again until 98 weeks later (assuming a 6 week re-enrollment window). During that long interval, the client doesn't know or care if the CA is online, only that it can find and download a fresh revocation list. Thus, clustering CAs solely to support continuous enrollment services in the case of an outage is often inefficient; it would likely be cheaper and more simplistic to have 2 separate issuing CAs instead.
During an outage, the most critical capability to restore is that of the Certificate Revocation List (CRL). CRLs are used to ensure that certificates used by end entities are still valid and, depending on the application, the inability to retrieve a CRL with a current validity period can cause significant problems. For example, CRL retrieval issues are by far the most common root cause of smart card logon issues. Fortunately, there is no need to rely on clustering to keep CRLs fresh during an outage. So long as you have access to the CA's private key material, you can manually sign and publish CRLs while your CA is offline and ensure service continuity to your users.
None of this is meant to dissuade customers from deploying ADCS clusters, but rather intended to provide some context about what are the right scenarios to use them. The two primary needs for which I recommend clusters are for autonomous failover or geo-dispersal. While manual CRL signing and multiple issuing CAs can ensure that your PKI continues to work during the outage of a CA, some customers prefer failover to be an autonomous activity. In other words, rather than having to manually resign and republish the CRLs, they'd prefer for one CA to just take over for the other with no administrator interaction required. This is a great use case for Failover Clustering and many customers find that autonomous recovery to be worth the investment.
The other major use case is geo-dispersion of CAs to increase survivability in the case of a major disaster. Consider an organization that has multiple datacenters around the world. They may be pursuing a strategy such that one of these datacenters is able to take over for another in the case of a major disaster. Or, the organization may have a dedicated 'hot site' whose sole purpose is to take over operations in the case of the loss of the primary site. In both of these cases, CA clustering provides a great way to ensure that a failure of one site will not interrupt enrollment or CRL signing services for the clustered CA. Typically this style of clustering, known as Multi-Site Clustering, leverages partner solutions to replicate the data between sites.
In most if not all enterprise customers most technology areas are driven by various teams responsible for a technology area. Some enterprise customers have more integrated technology teams then others. So how does this affect the common approach today of infusing virtualization into datacenters and building out a virtualization utility/service? To date this task has been assigned to a virtualization team or a virtualization expert in most companies folks that understand the virtualization technology well. This is reflective of the disruptive nature of the virtualization technology initially and companies reacted by creating teams to work on Virtualization. The virtualization projects started out small with Test/Development environments and expanded into production then into full blown virtualized datacenter projects.
So of course the datacenter existed long before the project to create a virtualization utility/service with various technology and process areas. Some will say the datacenter was lumbering along (no offense to present datacenter operations managers) with various issues and challenges and that virtualization is going to cure all the ills of the datacenters. I am a virtualization person and I love the virtualization technology and I happen to believe that virtualization capabilities have the potential to change how we build and use capabilities in the datacenter and beyond. Ok with that said without reference architecture of these new datacenters where virtualization is a key pillar we may miss some opportunities to completely realize all of the potential across datacenter service areas.
A Virtualization datacenter project should seek to review present datacenter capabilities determine gaps, leverage existing capabilities and redesign others that do not fully leverage or hinder the virtualization effort. What are some of the areas that have to be taken into account when embarking on this journey to build a virtualized datacenter? Well let's look at some of the services that a present day datacenter offers:
- Power and Cooling
- Systems/Service Management
- Backup services
- Disaster Recovery services
- Security Services
- Capacity services
- Storage services
Equipment Provisioning
- Servers
- Network devices
- Storage
- Backup devices
- Compliance services
So it is pretty clear that today's datacenters offer a range of complex services and you thought all it did was keep servers from being homeless. So a project to infuse virtualization as a core pillar has to seek to understand how virtualization impacts the various datacenters areas. I know what people are thinking, I already have virtual machines in production so this is a mute point. There is some production virtualization but very few projects that have truly looked at all of the datacenter areas and designed the area to fully leverage virtualization. This is an opportunity for datacenter architects and datacenter service owners to think and rethink how virtualization can affect some of the service areas in the datacenter. This exercise will help unlock potential that relooking at some of the services with virtualization capability in mind will provide. Some core areas to start are Storage and Business continuity areas that receive a lot of interest especially from the Virtualization community but have very little architecture patterns and practices. I look forward to your comments on this and experiences' looking deeper at datacenter services that Virtualization affects.
Allen Stewart
Principal Program Manager
Windows Server Group
Hopefully you get better presents than this, but if not, here are a couple of web casts I just did that you might be interested in:
Certificate Services Updates |
Amesh Mansukhani, Senior Product Manager, speaks with John Morello, Program Manager, Windows Server Division, about Windows Server 2008 and what's new with Certificate Services. John lists the four major pillars of Server 2008 for cryptography and certificate services, and they continue their conversation around the two biggest features—manageability and revocation—that will be impactful for customers. |
http://www.virtualteched.com/pages/videos.aspx
TechNet Webcast: Windows Server 2008 Terminal Services Security and Authentication (Level 300)
Are you looking to extend remote access to users on the road or at home? Learn how Windows Server 2008 Terminal Services can provide a solution. Join Microsoft Program Manager John Morello in this webcast as he provides an overview of Terminal Services Gateway and Terminal Services Authentication, and shows you how they can help take your business to the next level. Additionally, he demonstrates anywhere access to remote programs using single sign on (SSO).
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032355426&CountryCode=US
