If they hit cancel it will create the report.  I have used this when
trying to help a user with Microsoft patches


todd

Todd Joyce
Network Services
Radford University - The Smart Choice
[log in to unmask]
(540) 831-7777
 
Keep your boots and ChapStick and ice hotels.
Give me shorts and sandals and a thirty-blocker.

Temperance Brennan - Monday Mourning

-----Original Message-----
From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Lanstein, Alex C
Sent: Monday, August 28, 2006 11:03 AM
To: [log in to unmask]
Subject: Re: CCA gripes

Hm, well, that'll do it for #6 and #1.  So theres no way to get the
report until they log out?
 
We have an issue where the clients, once they are authenticated (read:
are switched off the authentication/remediation vlan) cannot access the
server, so they aren't getting logged out until they time out, and thus
the report doesnt get generated for a while.  
 
For some reason, by default, there is no route back to the
trusted/protected side of the network on the cas.  You guys didn't set
that statically did you?  
 
They are untrusted, they can access the server fine, and we can ping
them.  They become trusted, vlan changes, and they can no longer access
the cas.  
 
Our routing table looks like this:
 

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface
10.255.255.0    0.0.0.0         255.255.255.0   U         0 0          0
fake0
10.255.255.0    0.0.0.0         255.255.255.0   U         0 0          0
fake1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0
eth1
0.0.0.0         10.255.255.100  0.0.0.0         UG        0 0          0
fake0

Then I make a change to:
 
10.255.255.100  0.0.0.0         255.255.255.255 UH        0 0          0
eth0
136.244.50.117  10.255.255.100  255.255.255.255 UGH       0 0          0
eth0
10.255.255.0    0.0.0.0         255.255.255.0   U         0 0          0
fake0
10.255.255.0    0.0.0.0         255.255.255.0   U         0 0          0
fake1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0
eth1
0.0.0.0         10.255.255.100  0.0.0.0         UG        0 0          0
fake0

That, of course, was just to prove that the route wasn't getting set to
get back to my test machine (136.244.50.117). once it was "trusted".
Once i add the route like that commication can happen in both
directions.  I'm sure this is not the right way to fix the issue -
anyone know which checkbox this is?  
 
My trusted settings on the cas are 10.255.255.111, mask of
255.255.255.0, default gateway of 10.255.255.100
 
My untrusted settings on the cas are 10.255.255.111, mask of
255.255.255.0, and no default gateway (as per tac).  
 
Now, whats weird, and I know cisco does some weird things with the
routing, but in the original settings, fake0, the default interface, has
a mask of 0.0.0.0, instead of what I would think should be
255.255.255.0.
 
Anyone else have a similiar situation with VG OOB?
Regards,

Alex Lanstein
Senior Software Engineer, Transitional Data Services Help Desk/Network
Junkie, Connecticut College Chief Coffee Drinker, LBCCHosting
860-625-4277
[log in to unmask]

________________________________

From: Perfigo SecureSmart and CleanMachines Discussion List on behalf of
Joyce, Todd N
Sent: Mon 8/28/2006 7:42 AM
To: [log in to unmask]
Subject: Re: CCA gripes



On number 6 once you put in the criteria you have to click view not
press the enter key. 

Todd Joyce
Network Services
Radford University - The Smart Choice
[log in to unmask]
(540) 831-7777

Keep your boots and ChapStick and ice hotels.
Give me shorts and sandals and a thirty-blocker.

Temperance Brennan - Monday Mourning
-----Original Message-----
From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Alex Lanstein
Sent: Monday, August 28, 2006 1:07 AM
To: [log in to unmask]
Subject: CCA gripes

Well, we recently updated our inband cca to be a VG OOB and have been
pleased with the results.  There have been a few issues that are on the
annoying side, though.

1) when users log into cca and fail, there is a weird delay before they
show up on the "reports" view for the agent.  Sometimes it helps if they
log in twice, then we'll see the first login on the page

2) cca detecting patches that windows update does not.  sure enough,
when a user fails, that patch is not installed - but windows update says
there are no critical updates available. we've begun maintaining a list
of the most commonly seen failures, which you are more than welcome to
leech off: http://helpdesk.conncoll.edu/cca/

3) the hub/switch/AP support leaves something to be desired.  After
spec-ing it out with our netops I realize why things are the way that
they are, but it doesnt make the situation better

4) On the reports view it should show the switch and port they logged in
from.  We also had a sucker walk around with a laptop and label every
single switchport as the dorm room it goes to - showing the port
description would be nice.

5) on the agent, it should show them by default what they failed on, so
that they can attempt to perform self-remediation.

6) The "certified device search", just doesnt work.  you can search all
you want, but it doesnt search, it just refreshes the page.


we're running 4.0.2.  overall pleased with results - problems we see are

frequently due in part to messed up computers, but the bit where CCA
thinks a patch isn't installed but WU does is a bit sketchy.  I do
realize that you dont want to become a SUS/SMS server, but a little help

for the users would be nice.  we're lucky to have a few knowledgable
guys at the help desk that I feel comfortable with to give them access
to making changes to the role policies, but if that were not the case,
I'm pretty sure it would be hellish.

props to raj, alok, and prem for a great product all the way around - my

gripes are merely nusinces.

Alex