Sunday, January 20, 2008

Debian Experience

I'm now involved in a very interesting situation here in my home. My brother and I are going to redesign our network, and have a joint operation domain. So, for the time being, my domain controller plans are on hold until those commence. However, the reason for this came about when a friend of mine asked me to host a game server for his game. He asked me to do this for a variety of reasons:

1) I have the(sic:his) hardware.
2) I have the time.
3) I'd like the experience.

So, using his hardware, we're going to build a Debian Linux box. I've never used Debian before. This is going to be fun.

My configuration:
Abit IC7 motherboard, 2 gigs of PC2700 DDR, and 2x80gb SATA drives to be configured in RAID1 format.

I've spent a good portion of the day installing Debian, trying out some things, screwing up the file system or the partitions, when I finally came across this:

This is a very handy guide for creating a software RAID1 on the drives. It varied a bit from my configuration, but, it's not hard to modify. If anyone's ever looking to do what I've done, this is very handy.

I e-mailed Paul and thanked him.

Wednesday, January 16, 2008

Server 2008 Firewall

Interesting problem discovered today.

Windows Server 2003 used the Firewall Service as a layer of software all network traffic used to pass through it. When you disabled the service, you disabled the firewall.

However, Server 2008 does this differently. The Firewall service is no longer an abstraction layer, but more similar to IPTables in Linux. The firewall service actually controls the settings of the firewall, it does not control the firewall itself. So, if you want the firewall turned off, you actually have to tell the firewall to turn off. Nice feature.

Thursday, January 10, 2008

Windows Server 2008: Backups

There's an old adage in IT: It's not the backups that are the problem, it's restoring them.. Whoever said that is entirely correct. Today was spent wrestling with the built-in functionality of Windows Server 2008 and backing itself up. Prior to 2008 was the NTBackup system. Now, as much of a pain in the ass NTBackup was, it still worked. My test network had the domain controllers built from the NTBackup commands, and it worked rather well when you knew what you were doing.

I suppose the same can be said for 2008, however, I've yet to figure out what the problem is. My goal: Full restore. I want to be able to load a system from scratch onto a blank machine from that backup. Windows Server 2008 allows for a full system backup, as well as system state.

Fantastic!, I think to myself. If I get this working in the short timespan I've got, I now have zero problems with loading it as the primary file servers! And we'll also know that the backup systems work!

Microsoft, you tease.

I'm tempted to call out 2008 and say that it sucks, yet, I'm sure that there's something I'm screwing up with the procedure. Only time will tell. So far:

+ I ran a full backup with system state and saved it to a remote share located on a Windows Server 2003 machine. Just for the hell of it, I shared every folder that was created. Every Folder. Booting a machine to a DVD and requesting to repair via the network location yields that the shared location contains no backups.
+ Using the same backup, I installed Server 2008 on the previously attempted server, and attempted the same thing, yielding the same results.

At first, I might've blamed drives. RAID controllers can be a pain in the ass, sometimes the Ethernet driver says it's connected when it's actually having difficulty, things like that. But even after that is all bypassed, it still couldn't do it.

If I can't get something working in the name of backups and recovery, I'm going to seriously doubt putting 2k8 into production. My next test for a situation like this is with the Veritas software and recovery of system state.

Tuesday, January 8, 2008

Windows Server 2008

Over the past few days I've had the opportunity to test Windows Server 2008 in my environment. I'm looking at placing it on my primary file servers, as they're due up for replacement/migration/cleanup. So, I opted to write out some of the more interesting features I've noticed, those especially emphasizing benefit to our network.

Distributed File Shares
Think symbolic links. Instead of mounting a \\server\share\folder\folder\folder, instead, you mount a \\namespace\folder. This, however, does not work with MacOS clients right out of the box. Doing some research, you can download some apps that will allow you to mount a virtual DFS share, but to load an application to every single Mac on our campus is too much of a pain in th ass. So, essentially, DFS goes off of the priority list.

File Quotas
Windows Server 2003 maintained file quotas per user per partition. So, if Guy A was a member of five AD groups that have access to 15 folders, he could save up to the quota limit--regardless of where he saved them. The owner of the file was also important: If Guy B creates a file and gives it to Guy A, to which he places it on the file server--the file counts against Guy B. In essence, the file quota system sucked.

However, in Server 2008, this has been rectified, which was one of the primary reasons I wanted to wait for 2k8. File Quotas can now be managed multiple ways: Per folder, user/AD Group, or share. (I'm not entirely sure if the AD Group portion is true, to which I'll double check tomorrow. ) So, if I have Department A, Department B, and Department C, with the three departments sharing members, I no longer have to worry about who is saving what to which folder. Fantastic.

TCP/IP Printing
Today was also an experiment on network printing. Our Lead Tech spent several months putting into place an easy-to-use networkable printer system. Well, let me clarify that: It's easy to use if you understand how networks work. You know, DNS translation and DHCP. In short, I give a website a MAC Address and a hostname, the website feeds both to a DHCP scope, and viola'. When you plug the printer in, it has the IP Address. Configure the queue to the network information, and you're in. Now it's simpler. Sort of.

Server 2008 will automatically detect any printer on the network based on hostname or IP address. Put it online, done. The website he designed won't change much, but now detection is drastically simpler: It knows what model printer it is and loads the necessary driver.

IIS 7.0
Another change was IIS. Since I'm not a web programmer, nor did I have any websites to port over to the test environment, I don't have a proper evaluation for it. However, from the new features (comparing 6.0 to 7.0), I did like some of the newer authentication procedures.

Read Only Domain Controllers
This is something I'd love to implement strictly because it's new. Unfortunately, we don't have a need for it. Basically, you have a domain controller that has only has the capability to read active directory--it cannot change a thing. This is perfect for offsite locations outside of the primary IT center, somewhere that doesn't have the constant security an Operations room would(might/should) have.

Access Enumeration Lists
This one was slick. One of Microsoft's "mottos" for security is Security through Obscurity; in short: If you don't know its there, you can't hurt it--much like the Ostrich. Well, this took a new turn. File Enumeration basically controls what you can and cannot see based on permissions. If you have the capability of opening the file/folder, you can see it. If you can't, then you got nothing. The one thing that I was impressed was that it works with Mac as well. I loaded up my Mac with 10.4 and mounted the fileshare, lo and behold I could only see the share the account had access to. Unfortunately, I haven't perfected it yet, but, this is roughly what I've come up with:

The Share$ gets Authenticated Users. Example: Filestore$
The Initial Folder gets Authenticated Users. Example: A (Usernames that start with A)
The Sub Folders get Domain\Administrators, and Domain\%Username%.

By doing it this way, the user can see the path up to the share, but only that. This is inclusive to Mac users. And by combining this with Directory File Share, I can set their login scripts to load \\domain\username$, which points to \\server\share$\folder\folder\. And since the initial share is hidden ($), just browsing the hard drive won't reveal it's location on the file server. I have to play with this more, of course.

However, it doesn't eradicate the problem entirely. Browsing the server still shows all root folders up until the share. This could be corrected by creating AD Groups that only have specific access to those shares, however, this would clutter AD to the point where I'd need a separate OU just to keep it straight. Well, maybe. Let's think about this.

ALL_USERS has access to the entire share. It's membership is "Authenticated Users." In all reality, this isn't necessary, since you can just go for "Authenticated Users."
FILE_STORE_A has access to only the folders under folder named A. It's membership is all users whose username begins with A.
Under folder A is a separate folder for each user. The membership is based on %Username%.

If it needed to go deeper, reverse the order of the AD Groups, adding A to FILE_STORE_A, which is a member of FILE_GROUP, which is a member of ALL_USERS. Might get confusing, but, if you had a treespan of it, it doesn't look that bad. I might just pass it by my coworkers for the sake of security.

Overall, Windows Vista may be a huge flop, but, Windows Server 2008 looks to be very promising. I look forward to promoting it to Domain Controller level and have it start controlling DHCP/DNS on the test network, just for the sake of testing purposes.

Sunday, January 6, 2008

File Shares

Now that I've created a series of accounts, and added another account to the Domain Admins AD Group (default group set by Windows that allows almost as much domain control as Administrator does), it's time to set up another basic premise in a domain:

File shares.

Since I don't have a dedicated server for file shares, I'll have to impose another huge security risk by placing the fileshares on the Domain Controller itself. When available, I'll move them to another server, but for the current time--here they be.

I created a folder in the Root of C:\ called "Fileshares", and shared it out, adding the $ to the share, hiding it. I also modified security permissions on it, saying that the Authenticated Users AD Group has full control, but removing Everyone. This gives control to anyone who authenticates as a user within my domain to access this folder, and only them.

Going back to Active Directory Users and Computers, modify the properties on each object (in this case, the user accounts). Under the Profile tab, opt to use the Connect: option, mapping a drive letter to a folder located somewhere on the domain. Using the absolute folder structure, \\servername\sharename$\foldername is the naming convention. Since they're only mapping one drive, a logon script won't be necessary, however, with the addendum of a webserver coming later, I'll explore that option in the future.

I've opted to name the shares based on the username, keeping it simple; This is the user's personal share. After all the shares were created, I wanted to modify permissions on each folder, so that they couldn't access the contents of one another's drives. Whats the point of having separate folders when you can view them all? So, modify the folder, and under the Security tab, click Advanced. Still under Permissions, I've removed the check box for "Allow inheritable permissions from the parent to propage tot his object and all child objects. Include these with entries explicitly defined here." When prompted to copy or remove the permissions, I chose remove. I'll define the permissions thank you very much. Now we're left with only two permissions: Domain\Administrators, and the user account. Perfect. Only the admins and the user can access the folder. Everyone can see it, which is a danger, but for right now it'll do.

Initial Setup

Alright. So now that I have some free time, it's the first technical post: Initial Setup.

My Setup:
Currently under my control are three working computers:
Rescate - A computer given to me by a friend of mine.
SweikataServ1 - My Domain Controller
Leviathan - My computer.

Outside of my current workspace is a laptop, Glitch, and two as of yet unnamed unassembled computers. These two currently have no plans, and aren't powerful enough to really handle anything I have in mind for the future.

When I obtained Rescate, I knew I finally had the opportunity (and reason) to build my domain. So, let's begin with what I've accomplished so far:

SweikataServ1 is the primary domain controller. Windows Server 2003 requires at least 512mb of RAM to run, so make sure your hardware meets this requirement.

Installation of Server 2003 was marked as complete when the computer was updated to all available Microsoft Updates. To actually create a domain, under 'Run' type the command "dcpromo". This begins the Domain Controller Promotion, crafty eh?

Since this is my first domain creation, after reading some documents on how it should be done, I know I've done a lot of things incorrectly. So, to properly do it, I'm linking you to this.

Since I didn't follow these steps, my system is currently flawed. However, my situation is flawed: I'm not in control of my network, nor do I own the domain name So, in essence, I've created just an internal domain. There isn't anything particularly wrong with this mind you, I'll just have to reconfigure some things when I do have control of the network (network referring to the physical topology, DHCP, etc.).

With my domain's inception, the first step I went for was creating a user account--not everything can be run as Administrator. Under Administrative Tools, you'll find Active Directory Users and Computers. From here, as long as you have Domain Privileges, you can control any objects in the domain.

Since my domain isn't that expansive, I'll keep everything under the root of, however if I learn of more security procedures that dictate otherwise, I'll move it. I created an Organizational Unit (or OU for short) called User Accounts. From here, I've created all the accounts I feel necessary. Depending on your mindset on creating accounts, I opted for standard naming conventions for user names: lastname+first_initial+number. This guarantees standardization as well as keeping objects straight. I absolutely cannot stand user accounts like "smithj", proceeded by "smithjo", then by "smithjoe". It looks abhorrent.

So, the first account: Michael Sweikata (account name sweikatam1). And here I run into my first error: "Windows cannot set the password for (username) because: The password does not meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements."

Well shit. I haven't set those yet. So, before creating the account, we must first define the parameters of the account. This is done under the Group Policy Editor. Back under Administrative Tools, I've altered the Default Domain Controller Security Settings. As we define and edit them further, we'll revist them. Each option explains what it's purpose is, and gives you a default value. Set them accordingly as you like, I left the maximum password age to be 42 days, with the minimum to be 1 day. The password length is to be 7 characters, and 0 passwords are remembered under the Enforce password history. The final step is to enable the option for complexity requirements. After this is complete, I can now create accounts.

Aside from standard naming accounts, I also created a test account that will not be a member of any AD Groups. It's meant for testing security.

Initial Creation

I decided to create a blog on blogspot to document my developments as I encounter them. This way, in case someone else decides to do what I have done on their own, this might answer some questions for them.

What am I doing?

In short: Creating a domain.

In long: Creating a domain inside my home with the basis of exploring Active Directory, File & Print Sharing, User Account creation and control, eventually an e-mail and web server, as well as looking at the possibilities for binding not only Windows computers, but Linux and Mac operating systems, and the trials that will ensue.

This may also document some of the more interesting finds I've come across at my own place of work. I'm a System Administrator for a University.

This ends the original post.