1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
== Intro ==
This release adds support for Microsoft Statement-of-Health (SoH), which is
a form of network access protection.
Client support 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 = "netbios.example.com"
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 {
preprocess
soh
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 {
soh
# note - no SoH attributes are added here, the client hasn't sent them yet
# other DHCP config
}
dhcp DHCP-Request {
soh
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 {
soh
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:
http://technet.microsoft.com/en-us/library/bb726965.aspx
...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 <p.mayers@imperial.ac.uk>
December 2009
|
