After speaking with TAC, it turns out that once the user is logged in
and passes posture assessment(in VG OOB), they can not then interact
with the CAS. This does, in fact, mean that once a user is logged in,
they cannot be logged out (without you bouncing the port or kicking them
off). It does make troubleshooting a bit more difficult, but it's nice
to know that it was set up right and the behavior we were seeing was
expected.
RE: the reports issue - the reports turned out to be generated on either
a) logout from the quarantine role, or b) when they pass posture
assessment. Our issue was that they would log in and fail the checks,
the report wasnt getting generated right away. One of the other list
members here told us that if you hit "cancel" on the quarantine screen,
they will be logged out of the authentication vlan, and the report would
be generated. That was very helpful - thanks!
It would still be useful for us, at least for our users, to see what
they fail on so that they can attempt to install the patches by hand.
We were also having an issue where we wanted to tell the web logon users
(ie mac, linux, etc) that they were "successfully logged on", but alas
that seems not to be possible in VG OOB, as they cannot interact with
the CAS anymore.
Other than that, things are running smoothly
ACL
Rajesh Nair (rajnair) wrote:
>Alex,
>
>The route cannot be the reason. If the user is successfully
>authenticating, then the report is posted to the CAS even before the CAS
>tells the user that they are authenticated and before the CAM switches
>their port VLAN.
>
>-Rajesh.
>
>-----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 8: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
>
>
|
