[unisog] NAC Policy questions

Cal Frye cjf at calfrye.com
Fri Feb 9 20:44:02 GMT 2007

Aaron Gee-Clough wrote:
> So, my questions to those of you that have deployed NAC: What policy
> issues came up due to the NAC deployment?  Were there policy issues with
> setting requirements for machines that you don't own?  How did you
> handle the exemptions for non-Windows machines (Mac and Linux boxes, for
> example)?
I'll take a whack, as a purely subjective and anecdotal account. Sorry
it turned out so long-winded. Some history:

At the time we chose a product, there were really two that still stand,
Perfigo (now Cisco NAC) and Bradford Campus Manager. Bradford relied
more heavily on VLAN structures, which we were not prepared to create at
the time, so we chose Perfigo. One of the attractive features was, and
continues to be, that the client/agent is optional. We do not require
our users install the NAC client software at this time, although a Mac
client has just been released.

In lieu of client installation, Cisco NAC performs a Nessus scan against
new systems upon authentication, looking for vulnerabilities we choose
to mark significant. Systems failing the scan can be presented with a
scan report indicating the vulnerabilities found and the remediation
steps, including web links, needed for a do-it-yourself fix.

Policy issues:
Guest access needed to be an option. Cisco NAC has guest access, but in
an unidentified form (every user appears as "guest"). We are working on
an account provisioning application that would permit an existing user
(faculty, staff, or student) to create a temporary account for a guest
to use to authenticate to the network; we can link these guest accounts
back to the person creating the temp account should there be a problem.

Not everyone permits CIT to control their computers, and we don't own
every computer on our network. A non-invasive option needs to be
present. The Nessus scan CNAC provides is acceptable to us as a
compromise, and offers a limited check of vulnerabilities to which Macs
and Linux systems could be susceptible. We're not too anal about
checking if they have an antivirus scanner in place, although we have a
site license to supply one to everyone but guests. If a system has a
firewall preventing us from scanning it, we figure that's a good sign,
and let them on the network.

The role-based structure CNAC uses provides us the ability to manually
place a system (by Ethernet address) into a restricted role should they
subsequently become infected, with a web page redirect to indicate to
them why their network stopped working. We also have directory-based
roles that can be assigned to different classes of users, prohibiting
access to critical systems from non-privileged users.

Exceptions need to be made for all devices which cannot install the
client or open a web browser. Nintendo, XBoxes, printers, IP data
loggers, security cameras, all need to be manually entered into the
system by Ethernet address and assigned a role to control the access the
device needs. This could be painful, depending on how good your
documentation already is ;-) But it's doable, and helps you gain a good
picture of what devices are already there without your knowledge.

Some of our implementation described above represents less-than-absolute
control over systems attached to our network. That accurately describes
the real status of our network. We have decided, for now, that's
sufficient for us. It has reduced the problem from meltdown to easily
manageable once again. Your situation may easily require more. Hope this

-- Cal Frye, Network Administrator, Oberlin College
   www.calfrye.com,  www.pitalabs.com

"We need a kind of feminism that aims not just to assimilate into the
institutions that men have created over the centuries, but to infiltrate
and subvert them." -- Barbara Ehrenreich.

More information about the unisog mailing list