Neal from SnC asked me to take a look at some software he's thinking about using for intrusion detection.

It's called "OSSec" and you'll find more about it at http://www.ossec.net/

He's also talking about setting up a syslog server that we can use to collect authentication traps and possibly other information.

Here's a summary of where I think we stand with differences between the ACSAD domain controllers serving DNS and the QIP "NCSU-Legacy" DNS

Matched 926 of 1013 records (2 SOA, 5 NS records and 10 others can never match).
830 of 901 total matched 'A' records.
89 of 360 total matched 'SRV' records.

When I tried to do reverse (IP to name) lookups against ns60, ir looka like our PTR records were a complete mess, but I haven't dived in to gather specifics.

Kevin and I figured this out last week, but I hadn't found the time to post it until now.

We've found another wrinkle in the ACSAD DNS migration to QIP.  The existing ACSAD DNS is configured for "dynamic" registration for both DHCP and DNS services.  When a new host comes up, it's name (as set in the Windows control panel) is automatically registered in DNS.  QIP uses "static" registration, in that you must key in DNS info to get the name server to acknoledge you.

We had the next to the last "File System Team" meeting this morning.  I wasn't taking good notes, so the particulars I record here may not be correct.  Eric is doing our "official" write-up, so anything differenet between that write up and this one means that this one is in error.

Eric and I have just confirmed that the issues previously thought to be DNS problems using ns60 were in fact a firewall problem.

Eric is going to identify a bunch of test vms and provisioning servers, and I'm going to look for admin vms and servers at Monday's WAL meeting to set to use ns60 using a GPO.  The idea is that we eat our own dogfood while the CAB deliberates on pushing ns60 out wholesale to all ACSAD workstations.

Once there is a WolfTech Remedy queue created, I'll put in a formal request for the ilo extensions, and confirm a date when we can install in WolfTest.

Rather then try to paraphrase, here's a hacked up e-mail response to give some background:

We had the answer all along

http://xteams.oit.ncsu.edu/iso/node/273

Everette has semi-tested and can therefore semi-confirm that in the WolfTest Domain, before the group reading restrictions were applied, he was seeing better results.  We're planning to do a more formal test in WolfTest RSN.

Rough notes on features we want to see in the New Nagios, given the assumption that we have a rush deployment. It's a little light on details regarding the Sun and HPSIM integration. Feel free to edit!

Version "1.0"

Main goal is to provide existing function and look and feel for operations. No major changes to the "field of green" or the host detailed status. No changes to paging.

I've created two more groups in the WolfTech AD, "ISO_SHS-Server-Admins" and "OIT_SHS-Server-OnCall".

I've populated ISO_SHS-Server-Admins and set a group policy so that any servers installed under the OU=OIT_SHS,OU=Computers container will have this group in the local Administrators' group.

I've done some changes to the ISO_SHS container in the WolfTech active directory.

First off, I've created a manged group named "WT-ISO-Infrastructure Systems Operations Staff" that contains all of the ISO staff according to GuardDog.  This group should get updated nightly, so as staff changes it will automatically update itself.

The Wolftech managed group tool is at https://www.wolftech.ncsu.edu/wtmg/index.php

Secondly, I've added this group to the "ISO_Users" and "ISO_SHS_Users" group.