Windows Server Customer Engineering : Longhorn

Using the FREE network security tools you get in Windows (and who doesn't love free tools?)

pfetty — Fri, 20 Feb 2009 01:42:00 GMT

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!

The Definitive Guide to NAP Logging

morello — Mon, 29 Oct 2007 15:39:00 GMT

Pete Rivera is the Windows Team Lead on one of our DoD support teams and we've been working together on a NAP project. In addition to being a master of style and male fashion, Pete also puts together some great guidance for his customers. Recently, he wrote a detailed description of all the various logging capabilities that you might ever need to use to debug a NAP problem. Thanks, Pete!

NPS has various places where it does logging and/or creates a log… First off we do accounting IAS logging of the NPS status and network connection process data in %windir%\system32\LogFiles, but it can be configured to an alternative location. The log is:

IN<date>.log

2. Secondly we also can do SQL logging to a SQL 2k or SQL 2k5 database. This is used for logging user authentication and accounting requests: Logs user authentication and accounting requests in a stored procedure in a SQL Server 2000 or SQL Server2005 database. Request logging is used primarily for connection analysis and billing purposes. It is also useful as a security investigation tool, providing a method of tracking down the activity an attacker.

3. Likewise you can enable debug trace logging via netsh and this can be used to help provide detailed information about the Network Policy Server operation when NAP policies are configured: Netsh ras set tr * en

%windir%\Tracing\IASNAP.log

4. In addition this enabled a slew of other IAS/RAS related logs in the same folder (i.e.: IASSAM.LOG, IPSEC etc ):

%windir%\Tracing\*.log

5. You also have Event Logs. These provide a lot of info about the operation of NAP and connecting clients but is used primarily for auditing and troubleshooting connection attempts. Depending upon your build they are either in the SYSTEM (B3) log and/or the security log (RC0). There is also the Network Access Protection event log which you'd find on NAP clients.

6. On the client side we can enable NAP client Debug Tracing logs as well. This is enabled either via netsh or via the NAP client Configuration snap-in. It's an ETL file which is generated only by using logman… so you'll need to do a logman start QAgentRt -p {b0278a28-76f1-4e15-b1df-14b209a12613} 0xFFFFFFFF 9 -o %systemroot%\tracing\nap\QAgentRt.etl –ets in order to turn start .etl generation.

7. likewise we can also do WHSA tracing for NAP also… the trace GUID is 789e8f15-0cbf-4402-b0ed-0e22f90fdc8d

8. DHCP QEC tracing…

Netsh dhcpclient trace enable. This command enabled QEC tracing and the trace files will be generated at %WINDIR%\System32\LogFiles\WMI\DHCP*.*

9. EAPHost Tracing for 802.1x

Trace logs containing debugging information can assist users in finding the root causes of issues that occur during the EAP authentication process. The debugging information can include API calls performed, internal function calls performed, and state transitions performed. Tracing can be enabled on both the client side and the authenticator side.

When EAPHost tracing is enabled, logging information is stored in an .etl file in a user-specified location. Tracing generates an .etl file.

10. EAPHost Tracing for 802.1x (client side)

To enable tracing on the client side:

Run the following command: logman start trace EapHostPeer -o .\EapHostPeer.etl -p {5F31090B-D990-4e91-B16D-46121D0255AA} 0x4000ffff 0 -ets

Run the following command: logman stop EapHostPeer -ets

Convert the etl file into text using the following command: tracerptEapHostPeer.etl –pdb <pdbpath> -tp <tracemessagefilesdirectorypath> -o EapHostPeer.txt

11. EAPHost Tracing for 802.1x (Authenticator side)

To enable tracing on the authenticator side:

Run the following command: logman start trace EapHostAuthr -o .\EapHostAuthr.etl -p {F6578502-DF4E-4a67-9661-E3A2F05D1D9B} 0x4000ffff 0 -ets

Run the following command: logman stop EapHostAuthr -ets

Convert the etl file into text using the following command: tracerptEapHostAuthr.etl –pdb <pdbpath> -tp <tracemessagefilesdirectorypath> -o EapHostAuthr.txt

12. The we have the SCCM related logging specific to the SCCM SHA and shv. The Configuration Manager 2007 client computer log files are found, by default, in %windir%\CCM\Logs. For client computers that are also management points, the log files are found in %ProgramFiles%\SMS_CCM\Logs.

13. Ccmcca.log

This file logs the processing of compliance evaluation based on Configuration Manager NAP policy processing. It also contains the processing of remediation for each software update required for compliance.

14. locationservices.log

This log is used by other Configuration Manager features (for example, information about the client's assigned site), but it also contains information specific to Network Access Protection when the client is in remediation. It records the required remediation servers (management point, software update point, and distribution points that host content required for compliance), which are also sent in the client statement of health.

15. SMSSha.log

This is the main log file for the Configuration Manager Network Access Protection client, and it contains a merged statement of health information from the two Configuration Manager components: location services (LS) and the configuration compliance agent (CCA).

This log file also contains information about the interactions between the Configuration Manager System Health Agent and the operating system NAP agent, and also between the Configuration Manager System Health Agent and both the computer compliance agent and location services. It provides information about whether the NAP agent successfully initialized, the statement of health data, and the statement of health response.

16. CIAgent.log

This tracks the process of remediation and compliance. However, the software updates log file, Updateshandler.log provides more informative details on installing the software updates required for compliance.

17. SDMAgent.log

This log file is shared with the Configuration Manager feature desired configuration management, and it also contains the tracking process of remediation and compliance. However, the software updates log file, Updateshandler.log provides more informative details about installing the software updates required for compliance.

On the server side for the System Health Validator point, you should first check the Windows Application event log on the Windows Network Policy Server computer. This log will record any failure categories and errors with the source being SMS_SYSTEM_HEALTH_VALIDATOR. These are also raised as Configuration Manager status messages. Otherwise More detailed logging information can be found in the Configuration Manager logs and the System Health Validator point log files are located in %systemdrive%\SMSSHV\SMS_SHV\Logs.

19. Ccmperf.log

This log contains information about the initialization of the System Health Validator point performance counters.

20. SmsSHV.log

This is the main log file for the System Health Validator point. It logs the basic operations of the System Health Validator service, such as the initialization progress.

21. SmsSHVADCacheClient.log

This log file contains information about retrieving Configuration Manager health state references from Active Directory Domain Services.

22. SmsSHVCacheStore.log

This log file contains information about the cache store used to hold the Configuration Manager NAP health state references retrieved from Active Directory Domain Services, such as reading from the store and purging entries from the local cache store file.

23. SmsSHVRegistrySettings.log

This log is used to record any dynamic changes to the System Health Validator component configuration while the service is running.

24. SmsSHVQuarValidator.log

This log file records client statement of health information and processing operations. To obtain full information, change the registry key LogLevel from 1 to 0 in the following location:

HKLM\SOFTWARE\Microsoft\SMSSHV\Logging\@GLOBAL

25. <InstallationPath>\Logs\SMSSHVSetup.log

This log file records the success or failure (with failure reason) of installing the System Health Validator point.

Longhorn Beta3 Ships!

ram — Fri, 27 Apr 2007 02:54:26 GMT

Little late on this post, nevertheless, it is great news for the Server Division and our customers. The highly anticipated release of Longhorn Server Beta3 is available as of yesterday. Beta3 is a big deal, it is a public release and is feature complete! Beta3 enables some of the coolest scenarios purely based on our customer feedback. The 60 second pitch is:

PowerShell – play around for five minutes, you will wonder how you lived without this awesome scripting functionality.
Server Manager – one stop shop to provisioning and managing server roles.
Internet Information Services (IIS) 7.0 – next gen web and app platform
Server Core – more roles, low footprint, no GUI!
Terminal Services Gateway – access your apps with TS web gateway.
Failover Clustering – improved cluster management, security, and stability.
Network Access Protection – keep your network safe from un-healthy clients.
Read-Only Domain Controller – ideal for branch offices.

Below are download links for the available ISOs:

We hope you can take the new scenarios for a spin and provide us feedback using the "Customer Scenario Voting" tool. In this tool you can "vote" on the scenario, tell us your experience, importance, etc. Trust me, we are actively monitoring your feedback. Get started, get the product, give it a spin, keep the feedback coming.

There are few webcasts coming up that will cover various topics in Longhorn Server. Be sure to check out the calendar.