Phantom DHCP servers

I recently came across this issue when working with the DHCP servers on the domain at work. Instead of 41 DHCP servers, one for each remote location, the DHCP administration snap-in was showing we had 93! That’s just a few too many.

In order to clean up the DHCP server list, I first opened Active Directory Sites & Services. You have to click View and then Show services node in order to see the available AD services. Then, I expanded Services and clicked on NetServices to see what DHCP servers (dHCPClass records) were listed. I removed all of the invalid records (but not the DhcpRoot record) and then checked the DHCP admin utility. All of the invalid servers were still listed.

The next step was to use ADSI Edit in order to edit the DhcpRoot record found in the NetServices container. Using ADSI Edit, I browsed to the CN=NetServices,CN=Services,CN=Configuration,DC=Domain,DC=Domain container, substitute your domain name after DC=, right clicked on DhcpRoot and chose Properties. I found another list of invalid DHCP servers when I opened the dhcpServers property of the DhcpRoot record. Once I deleted the invalid servers there, the DHCP admin utility only listed the valid DHCP servers.

It was odd that the list was wrong to begin with. Any time a DHCP server is taken off line it is unauthorized first. Only one or two of the invalid servers were servers that had been replaced due to a server crash that resulted in reloading Windows Server 2003. I may need to set up a DHCP server, authorize on the domain and then decommission it to see if AD is removing them properly. I hope it was just a minor glitch carried over from when the domain controllers were Windows 2000 based.

Patience is something you admire in the driver behind you and scorn in the one ahead. – Mac McCleary

23.Nov.09 Active Directory, DHCP, Networking, Server 2003, Windows Comments (0)

Finding the cause of the problem

Since implementing the Cisco NAC, I’ve had a few fun calls that could have been avoided with a little more troubleshooting.  The calls always start with, “Hey, we’re having some NAC issues here.” and go down hill from there.  Here are a few issues initially blamed on the NAC with the true cause of the issue in parentheses.

• User shared drives are not mapping at login. (Network cable was unplugged.  User was being authenticated with cached credentials.)
• No one can log on to the domain when using X computer in Y room. (There was no computer account on the domain.  Joined the computer to the domain and logins started working.)
• User cannot log on, no matter what computer they try.  (User account had been disabled due to administrative request.)
• Clicking noise when computer is turned on.  (Seriously?  A technician actually asked if the recent agent install had caused the issue.  A cookie to the correct answer in the comments.)
• A projector connected to the computer did not show the shared screen.  (It helps if the projector is actually turned on.)

There are a few more in the ever growing compilation list to be posted later.  I get at least two calls a weeks that are very face-palm worthy.  I’m thinking about setting up a wall-o’-shame at work.  Let the guilty party step forth.

Sometimes it’s more important to be human, than to have good taste. – Brecht

09.Dec.08 Humor, Networking, Security Comments (2)

It’s working? Holy crap! It’s working!

The Cisco NAC is finally working!  Here are the two main things that made it start working:

• A rule was needed to allow pings to all domain controllers. The Active Directory logon process involves pinging all known domain controllers to see if they are online. The pings were being blocked for Unauthenticated users. The blocked pings caused erratic logons, some would authenticate while others didn’t, and it all started working once the pings were allowed.
• Cisco is full of crap when it comes to setting up their NAC to work with their Wireless LAN Controllers. Their directions said to set up WLCs as VPN concentrators. I had it set up like they directed but wireless users still had problems logging on. When I removed all of the settings, in order to try setting it back up from scratch, I happened to see that wireless users were authenticating properly.

I have four remote locations set up with the site Cisco Clean Access Server (CAS) reporting back to a centralized Clean Access Manager (CAM). All four sites had zero issues with users being able to log on, install the agent and get authenticated. Even logon scripts are running properly thanks to a loop that pings a specific set of IPs. Those IPs are blocked by default and can only be reached once the user is dropped into their appropriate user role. Successful ping = logon script execution.

I’ve still got about 20 locations left. Right now, the NAC is only performing authentication and assessing whether or not Windows updates are installed. Once I have all of the locations up, I’m going to implement a few more checks (i.e. antivirus software running and updated). I tested the AV check on a couple of users and it worked properly so I don’t expect any big issues when I role the check out for all locations.

Consider the postage stamp: its usefulness consists in the ability to stick to one thing till it gets there. – Josh Billings

16.Oct.08 Networking, Security Comments (0)

Shut it down

After three weeks of random errors, I had to shut down the Cisco NAC installation.  I hated to do it but it had to be done.  The errors were so inconsistent that it made fixing them almost impossible.  Here’s a quick run down of some of the problems:

• Users that worked fine one day would stop having access the next day even though the Clean Access Agent showed them logged on and in the proper role.
• Printers would randomly drop off the network but still show up in their role/VLAN.
• Moving a laptop from a docked, wired network, connection to undocked, wireless connection, was hit or miss. If the user just undocked, they definitely would lose network connection. If the user clicked Start and then Undock Computer, they would get network connection about 60% of the time.
• Logon scripts would randomly fail to run.

The last issue was (somewhat) fixed by doing two things. One, changing the script so that it would ping multiple servers and only initiate the script when a ping was successful (i.e. the user was placed into the proper user role). Two, pushing out a registry change for Windows XP that would introduce a group policy timeout (GpNetworkStartTimeoutPolicyValue). The timeout made it so that the group policy would keep trying to run the logon script for up to 60 seconds, trying to contact the server every two seconds, before failing.

The company we purchased the equipment from is supposed to send some of their technicians out next week in order to try and fix the problems. They are also supposed to send out a Cisco technician. I hope they can get it to work. If they don’t, this is going to look really bad on the IT department because of all of the issues the users are having to deal with during the installation.

There is no failure except in no longer trying. – Elbert Hubbard

18.Sep.08 Networking, Security Comments (0)

Do not buy the Cisco NAC

Short story: It sucks.  I have been struggling for over two weeks to just get ONE location up and running.  Every thing I’ve done is being done according to how the Cisco documentation says it needs to be done.  I’m having to get a Cisco representative on the phone at least every other day in order to fix a problem with the setup.

Long story: Coming soon.

16.Aug.08 Networking, Security Comments (3)