Implementing Network Infrastructure – 11/30/2009

Today’s class discussed Windows Software Update Services, and why it’s so useful to us as network admins.

Bascially, it boils down to saving administrators time, which I’ve said again and again, is a beautiful thing (the more time you can spend playing golf, or WoW, or reading or whatever it is you people do out there, the better).  What WSUS does for us is automate the process of getting our OS’s updated without the hassle of sucking up loads of bandwidth.

Automatic updates, by themselves, are nothing new.  Windows 98 could and would connect to Microsoft servers automatically and suck down updates to the OS automatically.  (By the way, this is a good idea — go home and turn on Automatic Updates if you’ve disabled it, you won’t be sorry.)  The problem that Automatic Updates gave us was that it was too easy, and could make things very hard for our administrators.  Why harder, you ask?  Well, for one thing, sometimes updates from Microsoft break things.  Even if Microsoft tested the updates extensively, there is no real way to test every possible hardware and software configuration combination in the world before deploying it.  There have been horror stories of an update breaking a mission-critical application and effectively putting a company out of business.  Since no admin wants to have to recover from that, early Windows network admins (late 90s) would simply disable automatic updates and this automatic installation simply wouldn’t occur.  Instead, the admin would test the update themselves, and then manually install the update later.  Ha.

Even if no one in the company was using any software that would be deemed uncommon (everyone crunches in Excel all day long), administrators also had another reason to disable automatic updates: bandwidth.  If I have a network with 500 computers, and there is a 1MB update issued, I eat up 500 MB of bandwidth just from each of my machines downloading that update.  That’s not a huge amount, but when you start adding multiple updates of bigger sizes and more computers, then the bandwidth issue quickly becomes out of control.

What WSUS does for us is serve as an in-house Windows Update Server.  Administrators will set up a WSUS machine, and it will download updates from Microsoft.  Then, it will corral them in a place where an administrator can test the update.  Once the administrator signs off on it, it becomes “Approved” and will then filter down to the client machines — which have been configured to use the local WSUS server (NOT the Microsoft servers!) as an update server.  Since that filtering is all done theoretically in-house, bandwidth cost is no longer an issue.

So, today, we set up our own WSUS server and played around with it.

Homework:

• Take Home Test #7 – download it here.
• Continue work on MS E-Learning modules.

 

Implementing Network Infrastructure – 11/16/2009

Back in the 60s and 70s, when what we now know as the Internet was in its most infant-est stages, we were mostly concerned with *how* to get packets from one computer to another.  Rarely were we concerned about securing those packets — the mere fact that we could take them from one computing device and “magically” transport them to another computational device seemed miraculous, and frankly, there wasn’t a large need to secure the data at that time — getting your hands on equipment to do that sort of thing was very expensive in those days, and therefore our data seemed to subscribe to a “Security by Obscurity” security model.  We developed network transport models that didn’t take today’s seemingly obvious security needs into consideration.

Nowadays, when any teenager with a couple hundred  bucks can grab our data and exploit it, we need ways of securing that data and protecting ourselves (and our jobs!).  The problem is is that we are still using those same old protocols with no security mechanisms.  The best solution would be to create and use brand new protocols with security built in, but we know for compatibility reasons, this is generally not possible.  So, what we can do instead is employ a technique that will “wrap” our insecure packets with a level of security.

The specific technology I’m talking about is IPSec.  IPSec is used in conjunction with insecure technologies, like FTP, to encode those packets and make them secure.  What’s cool about IPSec is that it only needs the two communicating nodes in order to work.  All of the infrastructure in between can just forward the packets as normal.

IPSec runs in one of two modes: transport mode and tunnel mode.  Transport mode secures the traffic between two computer nodes; tunnel mode secures the traffic between two routers.  Most of the time we will configure IPSec to run in transport mode, especially if we are sending traffic across Internet infrastructure we don’t control.

Next, we looked at deploying IPSec.  The easiest way to do so is to simply set up a GPO requiring it.

Homework:

• Take Home Test #6 – download it here.
• Continue work on MS E-Learning modules.  They’re due in a few weeks!!!

Implementing NI – 11/9/2009

Today’s topic is one of those quintessential networking topics — security.  Today was our first real discussion about the various security methodologies that are out there, but we definitely have brushed over them before.

As you’ll remember, there are several approaches we can take when looking to secure our intellectual property, and we should choose several in order to protect it.  We can choose authorization methods, which have the network require that people prove they are who they say they are (usually by way of username and password) before being allowed access to network assets — as well as setting up user rights and permissions to go along with their accounts.

We looked at the built-in groups that  come with Windows’ initial installation and discussed some of the things users in those groups can do.  For instance, we talked about two common local groups — the administrators and power users groups.  We talked about how the groups are similar in that they have elevated rights, but how the administrator account is able to accomplish so much more (driver installation and most “system” tasks).

We also talked about setting security templates — collections of security settings that we can apply to our machines so that we aren’t spending an inordinate amount of time tweaking mundane settings.  We discussed how Windows comes with its own security templates and how we can come up with our own and apply them to our computers.

The EFS (Encrypted File System) was also discussed — how the file system itself can encrypt files that are only open-able by the user that created them.  In order to do this, you must have the NTFS file system in place.

Finally, we discussed the Microsoft Baseline Security Analyzer (MBSA), which will comb through your system and compare it to the current state your server should be (regarding updates) and known security implementations (requiring compelx passwords, etc.).  It will then show you a report you can use to harden your network, which is a good idea, all around.

Homework:

• Take Home Test #5 – download it here.
• Continue work on MS E-Learning Modules!!!

Implementing Network Infrastructure – 11/2/2009

Welcome to November!

If you remembered, two weeks ago, we discussed DNS — what it does and how it does it.  This week, we return to the concept of DNS and, perhaps more importantly, how to manage it in an organization.  We looked at a number of ways of keeping your thumb on DNS.

The first way we looked at was simply the Monitor tab of your DNS server properties dialog box.  The main use of this tab is to perform some queries against your DNS servers.  You can perform either recursive or iterative queries against your servers (remember those?)

The next tool we looked at was NSLOOKUP.  NSLOOKUP is a command line tool and uses reverse lookup zones (remember those?) to lookup your name servers, hence the name.  We discussed the various things you can do with NSLOOKUP, and instead of rehashing them here, check out this link to get more information.

The next tool we looked at was a powerful DNS tool called DNSLint.  This tool is available from the Windows Support Tools and is used to do some advanced DNS troubleshooting.  Depending in which options we use with the command, we can do various things.  For example, running dnslint /d boston.contoso.com will test the boston.contoso.com domain to ensure that it has proper DNS connectivity.  Again, TechNet has more information here.

Next up, we looked at the DNSCMD command, which can be used to directly manipulate the DNS database.  If, for example, I want to insert a Host (A) record pointing traffic aimed at mailserver.contoso.com to 10.1.5.1 I would type in this from the command prompt:

dnscmd dnsserver.contoso.com /recordadd mailserver A 10.1.5.1

The last thing we discussed was Replication Monitor, which is launched simply by issuing the replmon command from the command prompt.  This command allows us to ahem, monitor replication to discover any errors that might be happening.

Homework:

• Take Home Test #4 – download it here.
• Continue working on MS E-Learning Modules.

Implementing Network Infrastructure – 10/26/2009

Nothing but the midterm exam today.  See you guys next week!

Homework:

• No Homework!

Implementing Network Infrastructure – 10/19/2009

We’ve discussed DNS in the past before, and today we begin deep-dive day 1 on the topic, where you learn everything you wanted to know about DNS (and probably some stuff you didn’t want to kn0w).  Next week, we’ll look at some DNS commands we can use to manage DNS from a day to day point of view.  Today’s purpose is to get a good feel for what DNS is and how it works. 

DNS stands for Domain Naming System, and is a mechanism for assigning human-readable words to network addresses.  For us, this means assigning English names to IP addresses — after all, remembering computer01.spidermonkey.com is a lot easier to remember than 172.20.240.9.  At least for me.

It would follow that one of the first things we discuss about DNS is its installation.  It, like many other Windows services, is installed via Add/Remove Programs under the Windows components portion.  It’s also automatically installed with Active Directory if AD doesn’t detect DNS on the network.

DNS operates on the concept of zones.  Don’t stress too much about nailing down zones — they’re simply places where DNS data lives.  Zones can contain information about a single domain, or domains in a parent-child relationship.  We have a few different types of zones, named after the way that they receive new DNS records: primary, secondary and Active-Directory integrated.  Primary zones can be updated manually by an administrator and that’s a big benefit — many common networking problems can be traced back to DNS, and its extremely helpful to be able to fire off a DNS command (which we’ll look at next week) and add the particular network node to DNS.  Secondary zones are read-only zones, and are only updated by pulling information from another DNS server (typically a primary one).  This adds the added benefit of security, but it is a hassle since any updated records must be entered on a primary server and then transferred over to a secondary zone.  When might you use a secondary DNS zone you might ask?  Good question, I’m glad you asked it.  You would most likely use a secondary zone in situations where you need DNS but don’t have the local staff available to administer it.  You definitely don’t want someone who has “lots of computer experience” monkeying with the DNS server without IT’s knowledge and/or permission.  Lastly, you have Active Directory-integrated zones which, as it’s name suggests, integrates directly into Active Directory and new records are replicated with all of the other information that populates when it replicates.  Oh, and technically, I forgot about another zone type: the stub zone.  No one really knows why these are around, but here’s what they’re good for.  Let’s say that you need to be able to find a computer in an entirely different DNS zone than what exists on your local DNS server.  Instead of traversing the network and through DNS queries find the node you’re looking for, you can store just a piece of the other zone on your own DNS server.  “Just a piece” refers to the “stub” in the name Stub Zone.  The benefit for your users is that they don’t have to wait on foreign DNS servers to serve up the information they need — they simply get the associated IP address they need and go to straight to the resource.

So, we’ve mentioned DNS record updates, and if you’ve inferred that DNS must then be a database, you’re correct!  As with any good database, DNS is made up of records, and has several different types of records you can use for different scenarios.  The most common ones you’ll use are the Host (A) records (fully qualified domain name (FQDN) to IP address, used in Forward Lookup Zones) and PTR records (IP address to FQDN, used in Reverse Lookup Zones) and arguably MX records (MX stands for Mail Exchange, which points to the e-mail servers in a domain).  We looked at the other types too, and it will be helpful, useful, necessary, etc. to know what each of these are.

Finally we discussed what happens when your local DNS server can’t resolve the query you send it: you get sent to another DNS server — either or directly, or indirectly as it asks for you.  You can have either an iterative query, or a recursive query.  Iterative queries puts the client in the driver’s seat of resolving the DNS query.  If one DNS server doesn’t have the information the client needs, it simply reports back that it doesn’t have the information and the client then is responsible for finding another server and getting the information from it.  On the other side of the coin, recursive queries puts the local DNS server in the driver’s seat.  The client will send a request, and then the DNS server will handle the query resolution, by asking all of the other servers on behalf of the client.  Once it finds an answer, it will return that to the client.  (The client will likely store the answer in its own DNS cache, and not even have to ask the DNS server the next time it needs to resolve that particular query.

Finally, we discussed what happens when DNS servers get together and update each other with updated records.  We call this get-together zone transferring, and there are two basic kinds: full and incremental (think backups).  The full zone transfer (aka AXFR) transfers the entire database each time a zone transfer occurs.  This results in a large amount of traffic, but is the most compatible with older DNS servers.  The incremental transfer (IXFR) only sends the changes to teh database to other servers.  As you might infer, incremental zone transfers aren’t compatible with all DNS servers.

Homework:

• Take Home Test #3 – download it here.
• Continue work on MS E-Learning modules!
  

Implementing Network Infrastructure – 10/5/2009

Ok, so last week we talked about setting up DHCP and looked at how it works.  Hopefully you remember the eight types of DHCP packets that are sent during client configuration and how they all work together.  This week we took a look at the day-to-day management of the DHCP service in a network.

One of the tasks we will perform when managing DHCP is setting up the server to update DNS automatically.  We call this DNS Dynamic Updates, and basically what happens is that, when enabled, DHCP will automatically generate the appropriate Host (A) and if necessary, PTR records that go along with the host.  What this accomplishes is allowing the other clients in the network to contact the newly connected client by its DNS name very soon after the client is connected to the network.  This is very convenient, and in most cases is very desirable.  If you want to make sure you computer is registered in DNS, (good if you’ve set up a computer with a static IP address), issue the ipconfig /registerdns command.

Next up, we talked about the management of the DHCP database.  DHCP is stored as a hierarchical database, and when clients’ leases come and go, they leave “holes” in the database file.  Those holes add up to a large, fragmented database, which affects DHCP (and therefore, server) performance.  The way around this, of course, is to periodically clean up database and compress it to a lean, mean fighting weight.  The database is stored a simple Access file, and we use the jetpack tool to compress it down:

net stop dhcpserver <– stops DHCP.  Necessary to prevent “sharing violations!”
jetpack dhcp.mdb tmp.mdb <– compresses the database.  tmp.mdb is a temporary location for files to land while the main database is cleaned up.

Finally, we looked at some best practices in regards to monitoring the performance of DHCP.

Homework:

• Take Home Test #2 – download it here.
• Continue working on Microsoft E-Learning modules.

Implementing Network Infrastructure – 9/28/2009

Welcome back!  I hope you’ve enjoyed your last couple of weeks off — I know I have (if, by enjoy, you mean lots of meetings and late-night lab rebuilds).

This particular class is about the procedures beyond the day-in and day-out of server administration (like last class).  In this class we will be learning the intricacies of the mechanisms that allow our networks to work.  Be prepared to discuss things such as DNS, security (including IPSec), WSUS, etc.

In today’s class, we discussed DHCP.  If you reach way back to the Network+ class, you’ll remember that DHCP stands for Dynamic Host Configuation Protocol.  What that means is that this particular protocol will automatically configure our computers with IP addresses, subnet masks, gateways, DNS servers and more.  This becomes nicer and nicer the larger our networks become — imagine having to manually configure 500 different computers — the time alone to complete this task would be phenomenal and that’s assuming that we wouldn’t make ANY mistakes on any of those 500 computers.  Ha!

Just for review, recall that the configurations that clients receive are called leases, and are temporary in nature.  In Windows networks, they last for eight days, and the clients try renewing the leases starting at day four.  Typically, the client is allowed to keep getting the same IP address, although it’s not guaranteed.

We discussed some of the requirements of the DHCP server.  For Windows networks, this means NT4+, a server with a static IP address (irony?  no, not really) and a valid range of addresses at your disposal. For a computer to use DHCP as a client, basically any modern or semi-modern operating system will do.  For example, Windows 3.11 will receive a dynamically assigned IP address.

Now, back in Net+, I promised we would get into DHCP much deeper, and I plan on keeping that promise.

We’ve discussed how DHCP works in general terms.  The DHCP client comes alive, broadcasts out on the network looking for a server.  If one’s available, it responds back and configures the client, if one’s not, the DHCP client self configures with an APIPA address.  But, let’s really look at how the DCHP process works.

There are up to eight different types of packets that get thrown around on the network during typical DHCP conversations.  The four most common:

• DHCPDISCOVER – This packet is sent out by the client machine.  It’s by definition a broadcast packet, and its sole purpose is to dig up a DHCP server somewhere.
• DHCPOFFER – This packet is sent out by the server to a client machine in response to a DHCPDISCOVER packet.  No configuration is happening yet, the server is just introducing itself and offering IP address configuration.  We do this in case there are more than one DHCP server in the subnet, the client can then turn away “late” DHCPOFFER packets (more on this in a moment).
• DHCPREQUEST – This is a client packet, and it’s sent out to the first DHCP server to send out a DHCPOFFER packet.  It’s the formal request for configuration, and basically tells the server, “Hey, thanks for the configuration, I’ll take it.”
• DHCPACK – This packet, sent out by the server, acknowledges (hence the ACK) that the client has accepted its configuration and logs its presence in the server.  That particular IP address will not be given to another client unless the client gives it up later.

There are, of course, other types of DHCP packets:

• DHCPDECLINE – This packet is sent by the client to the server declining its offer.  This packet would be sent to DHCP servers who respond the clients after the inital DHCP server responds (remember our example above?)
• DHCPNACK – Sometimes, when a client tries to renew it’s lease, the server says no.  Usually the reason is that the client machine is now in a different subnet, but sometimes we just want to deny network access to a client, and this is one way of doing it.
• DHCPRELEASE – This type of packet releases the client’s IP address.  To accomplish this in a Windows system, we issue the ipconfig /release command.
• DHCPINFORM – This packet is used by clients in order to obtain additional IP addresses.

Clear?  Good.  Now, here’s a wrench: the DHCPDISCOVER packet is a broadcast packet right?  What happens when the DHCP client is on one subnet and the DHCP server is on another subnet on the other side of a router?  If the router is like most, the client won’t be able to find the DHCP server — routers block broadcast packets.  This can present some problems.  It’s not exactly cheap buy lots of servers simply for running DHCP servers.

We have two possible solutions to this problem.  First, we could purchase a RFC1542-compliant router, which is a fancy way of saying “Buy a router that DOES let broadcast packets through!”.  This would certainly work, but may defeat the benefit of the router by combining broadcast domains.  Another solution we could do is set one server up as a DHCP Relay Agent.  I like this solution — with it, we name some random server as an informant of sorts.  This particular server listens for DHCPDISCOVER packets, and then wraps them up as non-broadcast packets and smuggles them across the router, destined for the DHCP Server on the other side.  The DHCP server then takes over and configuration happens as normal.

So what happens when a client can’t find a server with whom to connect?  After a period of trying to locate a server, the client will self-configure with an older dynamic configuration protocol called Automatic Private IP Addressing (APIPA).  An APIPA address starts out with the octets 169.254 and has random entries in the last two octets.  Once the client receives an APIPA address, it continues to try to contact a DHCP server every five minutes.  The reason is because an APIPA address cannot be routed, which means you will NOT be able to access the Internet, or any other network on the other side of a router.

Ok, theory aside, we jumped into the actual DHCP server configuration and looked around at some things.  One thing to point out, if your DHCP server is running inside Active Directory, it must be authorized by an administrator.  This is to prevent rouge servers from popping up on the network and handing out phony addresses.

We discussed the concepts of Reservations and Exclusions.  Oftentimes, students will confuse the two, and it’s important that you recognize the differences between the two.  To configure a Reservation, you will need the MAC address of a client, and the server will reserve a specific IP address for that MAC address.  No other host will receive it, but the host will still receive its configuration dynamically.  When you configure an exclusion, on the other hand, it is in effect telling the DHCP server not to even hand out a particular address or range of addresses.  This is useful if you have servers or specialized clients that need static IP addresses right in the middle of your IP address range.  For example, I might have a configured scope of 192.168.1.0 – 192.168.1.255, but have some servers that live on 192.168.1.50-55.  Those servers would be statically configured with their IP addresses, and then I would configure exclusions in the DHCP server to not hand out those IP addresses to clients.

Homework:

• Take Home Test #1 – download it here.
• Work on Microsoft E-Learning modules.