On 14/07/11 14:30, Palmer J.D.F. wrote:
Hi,
We've started to look at SoH with the intention to implement it for the new academic session in September, but are having an issue.
Cool (I wrote it)
The server is setup using the example soh-server, but find that the condition in the example (below) isn't being satisfied when a client with no AV returns it's SoH status. (SoH Reply below) It appears after some trial that only the first of the "SoH-MS-Windows-Health-Status =" attributes is considered, if I manipulate the condition to check the firewall status which is returned first it works. Is this a bug or something I've done wrong?
Hmm. I thought that the =~ regexp operator tried all attributes on the left-hand side; that is, I thought it looped through until it got first-match. If it doesn't, then the idea of squeezing all the SoH data into a multiple instances of a single text attribute is going to need revisiting (or the "foreach" unlang operator will need backporting!) Can you post a full debug?
Example condition... if (SoH-MS-Windows-Health-Status =~ /antivirus (warn|error) /) {
SoH Status Reply...
SoH-MS-Windows-Health-Status = "firewall ok snoozed=0 microsoft=1 up2date=1 enabled=0" 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=download" SoH-MS-Windows-Health-Status = "security-updates ok all-installed"
Separate to this, an observation from the SoH reply after I'd installed Microsoft Security Essentials; the two hashed lines below show that Microsoft Security Essentials is classed as being non-Microsoft. I presume this the NAP service on the client making this decision, not FreeRADIUS?
Correct. The SoH code just parses the horrible binary payload that the client sends. It's not clear what the "microsoft" bit in that payload means semantically; I suspect it means "built-in windows component"