Thanks to a lot of work by Phil Mayers, the server now has support for Microsoft SoH in PEAP, normal RADIUS (MS VPN gateway), and in DHCP. The code is in the "v2.1.x" branch, and in the "stable" branch. It will be in 2.1.11, and all later versions of the server. The documentation is in doc/SoH.txt, and in raddb/sites-available/soh. The EAP configuration in eap.conf can also be updated to enable SoH on the server side. See http://git.freeradius.org/ for information on git. Alan DeKok.
Garber, Neal wrote:
Thanks to a lot of work by Phil Mayers, the server now has support for Microsoft SoH in PEAP, normal RADIUS (MS VPN gateway), and in DHCP.
Wow! That *must* have been a lot of work! Thank you Phil.
~1400 lines, including documentation.
Does this mean FreeRADIUS can now act as a Health Policy Server?
I presume so. See raddb/sites-available/soh Alan DeKok.
On 09/10/10 15:01, Garber, Neal wrote:
Thanks to a lot of work by Phil Mayers, the server now has support for Microsoft SoH in PEAP, normal RADIUS (MS VPN gateway), and in DHCP.
Wow! That *must* have been a lot of work! Thank you Phil.
Does this mean FreeRADIUS can now act as a Health Policy Server?
Yes, though it's not 100%. Specifically the code can challenge clients for an SoH, and the client will submit it and FreeRadius decode it. There is not (yet) support for FreeRadius generating and emitting an SoHR, because I don't have a working example of such, and decoding the MS-SOH spec is REALLY REALLY hard without at least some working data to compare to the awful spec language! It's fairly useful though - you can enable it, and SoH-enabled clients will submit info like: [peap] Processing SoH request SoH-Supported = yes SoH-MS-Machine-OS-vendor = Microsoft SoH-MS-Machine-OS-version = 5 SoH-MS-Machine-OS-release = 1 SoH-MS-Machine-OS-build = 2600 SoH-MS-Machine-SP-version = 3 SoH-MS-Machine-SP-release = 0 SoH-MS-Machine-Processor = x86 SoH-MS-Machine-Name = "machine.test.ic.ac.uk" SoH-MS-Correlation-Id = 0x... SoH-MS-Machine-Role = client SoH-MS-Windows-Health-Status = "firewall error down" SoH-MS-Windows-Health-Status = "antivirus error down" SoH-MS-Windows-Health-Status = "auto-updates warn service-down" SoH-MS-Windows-Health-Status = "security-updates ok all-installed" FreeRADIUS-Proxied-To = 127.0.0.1 User-Name = "host/machine.test.ic.ac.uk" This can be punted to a virtual server, and you can assign a vlan or reject authentication etc. I've tested it with WinXP SP3, Vista and Win7. There is one compile fix needed which must have snuck through (attached)
Phil Mayers wrote:
I've tested it with WinXP SP3, Vista and Win7. There is one compile fix needed which must have snuck through (attached)
I deleted all references to the REQUEST structure from src/lib/soh.c. The library functions are for clients, not just the server. The code in "git" should now be up to date, and should compile. Alan DeKok.
On 11/10/10 13:24, Alan DeKok wrote:
Phil Mayers wrote:
I've tested it with WinXP SP3, Vista and Win7. There is one compile fix needed which must have snuck through (attached)
I deleted all references to the REQUEST structure from src/lib/soh.c. The library functions are for clients, not just the server.
Indeed. Is there a good way besides the DEBUG macro to emit debugging output in lib/*.c code? I imagine there will be SoH type/value or type/len/value stuff that we'll want to log (but others that we won't - it's probably too noisy as-is) Also I guess the "right" thing to do is use the RDEBUG macros where possible so that the per-request / radmin conditional debugging works? Perhaps lib/soh.c should move to main/, given it's not much use for the clients?
Phil Mayers wrote:
Indeed. Is there a good way besides the DEBUG macro to emit debugging output in lib/*.c code?
Nope.
I imagine there will be SoH type/value or type/len/value stuff that we'll want to log (but others that we won't - it's probably too noisy as-is)
OK.
Also I guess the "right" thing to do is use the RDEBUG macros where possible so that the per-request / radmin conditional debugging works?
Yes.
Perhaps lib/soh.c should move to main/, given it's not much use for the clients?
Hmm... that would work, too. I can always "git mv" the file if that would be best, then re-add the RDEBUG macros. Alan DeKok.
--On Monday, October 11, 2010 14:24:07 +0200 Alan DeKok <aland@deployingradius.com> wrote:
Phil Mayers wrote:
I've tested it with WinXP SP3, Vista and Win7. There is one compile fix needed which must have snuck through (attached)
I deleted all references to the REQUEST structure from src/lib/soh.c. The library functions are for clients, not just the server.
The code in "git" should now be up to date, and should compile.
[I know it's work in progress, just FYI...] There are two unprotected fprintf in peap.c which appear to block the server if you run it daemonized [i.e. not -X]: $ grep -A 5 -B 5 JJJ ./src/modules/rlm_eap/types/rlm_eap_peap/peap.c rad_assert(t->soh_virtual_server != NULL); fake->server = t->soh_virtual_server; RDEBUG("Processing SoH request"); debug_pair_list(fake->packet->vps); //JJJ fprintf(fr_log_fp, "server %s {\n", fake->server); rad_authenticate(fake); //JJJ fprintf(fr_log_fp, "} # server %s\n", fake->server); RDEBUG("Got SoH reply"); debug_pair_list(fake->reply->vps); if (fake->reply->code != PW_AUTHENTICATION_ACK) { RDEBUG2("SoH was rejected"); -James -- James J J Hooper Network Specialist Information Services University of Bristol http://www.wireless.bristol.ac.uk http://www.jamesjj.net --
On 11/10/10 15:37, James J J Hooper wrote:
--On Monday, October 11, 2010 14:24:07 +0200 Alan DeKok <aland@deployingradius.com> wrote:
Phil Mayers wrote:
I've tested it with WinXP SP3, Vista and Win7. There is one compile fix needed which must have snuck through (attached)
I deleted all references to the REQUEST structure from src/lib/soh.c. The library functions are for clients, not just the server.
The code in "git" should now be up to date, and should compile.
[I know it's work in progress, just FYI...]
*Now* people spot this! ;o)
There are two unprotected fprintf in peap.c which appear to block the server if you run it daemonized [i.e. not -X]:
Ok, the attached should be more sane
On 11/10/10 16:23, Alan DeKok wrote:
Phil Mayers wrote:
Ok, the attached should be more sane
Debug messages shouldn't have "\n". The log function adds the "\n" itself.
Yeah - that's in 0004-*.patch (I noticed it when using the excellent raddebug to test that the SoH stuff appeared)
Phil Mayers wrote:
Yeah - that's in 0004-*.patch (I noticed it when using the excellent raddebug to test that the SoH stuff appeared)
OK... the patch doesn't apply, and adding/deleting the "\n" is awkward. I'll make a few simple changes today, and push them to git.freeradius.org. Please double-check them for sanity. Alan DeKok.
On 12/10/10 11:11, Alan DeKok wrote:
Phil Mayers wrote:
Yeah - that's in 0004-*.patch (I noticed it when using the excellent raddebug to test that the SoH stuff appeared)
OK... the patch doesn't apply, and adding/deleting the "\n" is
Rats. Sorry about that.
awkward. I'll make a few simple changes today, and push them to git.freeradius.org.
Please double-check them for sanity.
Will do.
OK... see "git". I've moved src/lib/soh.c -> src/main/soh.c, and done minimal updates to get it to compile. If you can redo the debug patches, I'll put them in. Or maybe I should just give you direct "git" access... Alan DeKok.
On 12/10/10 15:29, Alan DeKok wrote:
OK... see "git". I've moved src/lib/soh.c -> src/main/soh.c, and done minimal updates to get it to compile.
Ok, "aefe73e885198b5735fad6fbd59d63a9116912b7" looks good; patch against that attached - it's nothing complex, but seems to work for me. (Is there an equivalent of "debug_pair_list" outputting via request->radlog?)
If you can redo the debug patches, I'll put them in. Or maybe I should just give you direct "git" access...
Gulp!
Hi, you know...some sicko side of me things it'd be great if stats on SoH could be output via access with radmin or the Server-Status packet... alan
Alan Buxey wrote:
Hi,
you know...some sicko side of me things it'd be great if stats on SoH could be output via access with radmin or the Server-Status packet...
That's the kind of information which belongs in a DB, I think. It's not RADIUS related (packets sent / received), and it's about long-term network state. Alan DeKok.
Phil Mayers wrote:
Ok, "aefe73e885198b5735fad6fbd59d63a9116912b7" looks good; patch against that attached - it's nothing complex, but seems to work for me.
Pushed, thanks.
(Is there an equivalent of "debug_pair_list" outputting via request->radlog?)
No, sorry. Alan DeKok.
Hi,
It's fairly useful though - you can enable it, and SoH-enabled clients will submit info like:
<snip>
This can be punted to a virtual server, and you can assign a vlan or reject authentication etc.
I've tested it with WinXP SP3, Vista and Win7. There is one compile fix needed which must have snuck through (attached)
just to report that we've been using this for a little while (via its old direct GIT) and I'm happy to see it starting to go into the main tree... we are not using it YET for direct policy decisions (ie putting people onto different VLANs) - we are just starting to record the status of our clients health and security posture. it will hopefully give us interesting client metrics.... alan
On 11/10/2010 12:37, Phil Mayers wrote:
On 09/10/10 15:01, Garber, Neal wrote:
Thanks to a lot of work by Phil Mayers, the server now has support for Microsoft SoH in PEAP, normal RADIUS (MS VPN gateway), and in DHCP.
Wow! That *must* have been a lot of work! Thank you Phil.
Does this mean FreeRADIUS can now act as a Health Policy Server?
Yes, though it's not 100%. Specifically the code can challenge clients for an SoH, and the client will submit it and FreeRadius decode it. There is not (yet) support for FreeRadius generating and emitting an SoHR, because I don't have a working example of such, and decoding the MS-SOH spec is REALLY REALLY hard without at least some working data to compare to the awful spec language!
Hi Phil, Alan, http://msdn.microsoft.com/en-us/library/cc251376%28v=PROT.10%29.aspx -> Independent of the above states, the last bit of the third byte of the AU ClientStatusCode can take the value of 1 if the AU settings on the client are controlled by policy. [We do a little of http://technet.microsoft.com/en-us/library/cc708449%28WS.10%29.aspx on our clients via our wireless set-up wizard to help them keep up to date with patches] ... Therefore patch attached {"confd-by=" format only a suggestion}. -James -- James J J Hooper Network Specialist Information Services University of Bristol http://www.wireless.bristol.ac.uk http://www.jamesjj.net --
On 11/10/2010 22:14, James J J Hooper wrote:
On 11/10/2010 12:37, Phil Mayers wrote:
On 09/10/10 15:01, Garber, Neal wrote:
Thanks to a lot of work by Phil Mayers, the server now has support for Microsoft SoH in PEAP, normal RADIUS (MS VPN gateway), and in DHCP.
Wow! That *must* have been a lot of work! Thank you Phil.
Does this mean FreeRADIUS can now act as a Health Policy Server?
Yes, though it's not 100%. Specifically the code can challenge clients for an SoH, and the client will submit it and FreeRadius decode it. There is not (yet) support for FreeRadius generating and emitting an SoHR, because I don't have a working example of such, and decoding the MS-SOH spec is REALLY REALLY hard without at least some working data to compare to the awful spec language!
Hi Phil, Alan,
http://msdn.microsoft.com/en-us/library/cc251376%28v=PROT.10%29.aspx
-> Independent of the above states, the last bit of the third byte of the AU ClientStatusCode can take the value of 1 if the AU settings on the client are controlled by policy.
[We do a little of http://technet.microsoft.com/en-us/library/cc708449%28WS.10%29.aspx on our clients via our wireless set-up wizard to help them keep up to date with patches]
... Therefore patch attached {"confd-by=" format only a suggestion}.
...I wonder if MS ever end up with: case 0x00000105: snprintf(vp->vp_strvalue, sizeof(vp->vp_strvalue), "%s warn unconfigured confd-by=policy", s); Oh well, it's in the spec... -James
On 10/11/2010 10:14 PM, James J J Hooper wrote:
Hi Phil, Alan,
http://msdn.microsoft.com/en-us/library/cc251376%28v=PROT.10%29.aspx
-> Independent of the above states, the last bit of the third byte of the AU ClientStatusCode can take the value of 1 if the AU settings on the client are controlled by policy.
Aww man... They really did screw up that result code crap... "It's an enumeration, ORed with a bitfield! We're geniuses"
On 11/10/2010 22:14, James J J Hooper wrote:
On 11/10/2010 12:37, Phil Mayers wrote:
On 09/10/10 15:01, Garber, Neal wrote:
Thanks to a lot of work by Phil Mayers, the server now has support for Microsoft SoH in PEAP, normal RADIUS (MS VPN gateway), and in DHCP.
Wow! That *must* have been a lot of work! Thank you Phil.
Does this mean FreeRADIUS can now act as a Health Policy Server?
Yes, though it's not 100%. Specifically the code can challenge clients for an SoH, and the client will submit it and FreeRadius decode it. There is not (yet) support for FreeRadius generating and emitting an SoHR, because I don't have a working example of such, and decoding the MS-SOH spec is REALLY REALLY hard without at least some working data to compare to the awful spec language!
Hi Phil, Alan,
http://msdn.microsoft.com/en-us/library/cc251376%28v=PROT.10%29.aspx
-> Independent of the above states, the last bit of the third byte of the AU ClientStatusCode can take the value of 1 if the AU settings on the client are controlled by policy.
Hi Guys, I've re-written the patch I originally forwarded to account for the third byte-first bit flag MS stuck in the middle of AU ClientStatusCode. As attached - still not pretty~~ -James
participants (5)
-
Alan Buxey -
Alan DeKok -
Garber, Neal -
James J J Hooper -
Phil Mayers