SoH.txt   [plain text]

== Intro ==

This release adds support for Microsoft Statement-of-Health (SoH), which is
a form of network access protection.

Client supprot is present in Windows XP SP3, Vista and 7.

SoH data can come in from several places:

 * inside EAP-PEAP packets for 802.1x wireless/wired connections
 * inside a radius packet (Microsoft VSA #55, MS-Quarantine-SOH) - VPN and
   terminal services gateways can act as the radius client
 * inside a DHCP request, in vendor-specific options

FreeRadius supports all three types. The SoH statement is decoded into
radius-style attributes, and you can write a policy in "unlang" to act
on them, and permit, restrict or deny network access.

== PEAP support ==

SoH support in peap is enabled in eap.conf using config like so:

 eap {
  peap {
   soh = yes
   soh_virtual_server = "soh-server"

When SoH is enabled, an EAP-PEAP client will be challenged to provide an
SoH statement after providing it's identity (or resuming a PEAP session via
SSL session resumption). Clients which do not support PEAP will NAK the
request, and clients which do will answer it.

The client reply will be written into a fake radius request and sent to the
virtual server specified above; it will either look like:

 SoH-Supported = no

...or (from a Vista machine):

 SoH-Supported = yes
 SoH-MS-Machine-OS-vendor = Microsoft
 SoH-MS-Machine-OS-version = 6
 SoH-MS-Machine-OS-release = 0
 SoH-MS-Machine-OS-build = 6001
 SoH-MS-Machine-SP-version = 1
 SoH-MS-Machine-SP-release = 0
 SoH-MS-Machine-Processor = x86_64
 SoH-MS-Machine-Name = ""
 SoH-MS-Correlation-Id = 0x54468936cb494374b127a6a3cc3bb11c01ca78d858ee1ef0
 SoH-MS-Machine-Role = client
 SoH-MS-Windows-Health-Status = "firewall ok snoozed=0 microsoft=1 up2date=1 enabled=1"
 SoH-MS-Windows-Health-Status = "antivirus error not-installed"
 SoH-MS-Windows-Health-Status = "antispyware ok snoozed=0 microsoft=1 up2date=1 enabled=1"
 SoH-MS-Windows-Health-Status = "auto-updates ok action=install"
 SoH-MS-Windows-Health-Status = "security-updates warn some-missing"

If you have "copy_request_to_tunnel = yes" set on the peap module, the
request variables like NAS-IP-Address and so on will be copied to the fake
request as well.

Clients without SoH seem to just NAK the SoH request and continue with the inner
EAP auth. This has been tested as working with Windows XP SP2 and lower, Linux
clients using NetworkManager & wpa_supplicant, MacOS 10.5, Nokia/Symbian S60 and
iPhone OS 3.x. It should therefore be safe to deploy.

== Radius support ==

If you are running a Microsoft VPN or Terminal Services Gateway, these can
be configured to send the SoH data to an upstream radius server, in this
case presumably FreeRadius. To take advantage of this you will need to add
the "soh" module to the "authorize" section of your virtual server, like so:

server tsgateway {
  if () {
    ... policy goes here

The SoH module simply looks for the Microsoft VSA #55 and decodes the SoH
data, adding the SoH attributes to the request - see above for an example
of the available attributes.

The SoH module also does dynamic expansions - see below for more info.

== DHCP support ==

If you compile FreeRadius with DHCP support, the "soh" module can challenge
a DHCP client for SoH data in the DHCPOFFER packet. As with normal radius,
the SoH attributes are added to the request. You would use like so:

server dhcp {
  dhcp DHCP-Discover {
    # note - no SoH attributes are added here, the client hasn't sent them yet

    # other DHCP config

  dhcp DHCP-Request {
    if () {
      # SoH policy
    # other DHCP config

== soh module ==

The "soh" module decodes the radius & DHCP payloads. It also makes some dynamic
variables available, for example:

authorize {
  update request {
    Tmp-String-0 = "%{soh:OS}"

...will give you a string like "Windows Vista 6.1.100 sp 1.0" or "Windows XP 5.x.x sp 3.0"

At the moment, this is the only dynamic expansion; in future, we will make
various bits of info available, for example non-Microsoft SoH records (see below)

== Non-microsoft SoH data ==

The Windows SoH structure is extensible and, in principle, clients can be
extended with .dll plugins to add vendor-specific info to the SoH, which
can then be checked on the server.

At the present time, few plugins are known and I have seen none, so can't
add support for them.

== Client configuration ==

The code works fine with Win XP SP3 & Vista on both wired & wireless. However
contrary to what some sites claim, the NAP service is disabled by default, as
are the many NAP remediation agents. These can be enabled from the command prompt
with (for XP; instructions may differ for other windows versions):

 sc config napagent start= auto
 sc start napagent

 # optionally for wired 802.1x; the dot3svc should usually be made dependent
 # on the napagent service, else the machine might attempt 802.1x before NAP
 # has started...

 sc config dot3svc start= auto depend= napagent
 sc start dot3svc

 # enable the EAP agent
 netsh nap client show config

 # get the "ID" value for the "EAP Quarantine Enforcement Client"
 netsh nap client set enforce id=$ID admin=enable

 # repeat for DHCP, VPN or Terminal Services agents

This can be automated via Group Policy.

You then need to enable EAP, PEAP, Quarantine Checks & the relevant auth method
on the relevant adapters. This can be done with "netsh xml profiles" or Group
Policy - google for the relevant terms, or see the MS article:

...and related links.

== TODO ==

Currently the code does not support sending the final SoH reply. This
is because the SoH reply (see section 2.2.9 of MS-SOH version
v20091104) needs various fields formatted in a manner which is not
obvious to me, and I don't currently have access to a windows NAP
server to look at a working example. The clients I have access don't
seem to mind.

 Phil Mayers <>
 December 2009