Domain authentication can be achieved relatively simply, by using either Winbind (part of the Samba project) or the new kid on the block, Likewise. Likewise-Open offers a simple procedure for joining domains, and the new version comes packaged with it's own version of Kerberos. It also hashes the Windows SID into a UNIX UID in a consistent manner - so the UIDs are always the same across your entire environment. Sounds perfect, right? Well, no. Not quite. The problem with Likewise-Open, is that it's difficult to integrate with Samba. Though it does ship with a "compatibility module" called lwi_compat, which allows Samba to hook into Likewise's authentication module, I found this quite difficult to get working, and I only achieved partial success through guesswork - as the documentation didn't actually help much, given they only officially support Samba 3.0.x (while Ubuntu now uses 3.3.x). When I did get it going, however, it only recognised the Windows users' primary group, not any of the other groups they were members of. This meant that my (possibly overly) complex system of ACLs and user directories just didn't work at all. So, on to Plan B...

When I read through the short (but sweet) Ubuntu Wiki article entitled ActiveDirectoryWinbindHowto, I felt like somewhat of a fool after reading a small, illusive section called Adding more than one Linux machine to a Windows network. Bingo! This section described a problem whereby the traditional Winbind domain authentication method would lead to inconsistent UIDs across the network, and thus cause headaches when trying to achieve anything like what I was aiming for. It suggested using a method of mapping SIDs to UIDs called RID. I assume this stands for Relative ID, which is another kind of ID Active Directory uses to track users within a domain. These can possibly clash from domain to domain, so it is advised not to use this method when your network contains a trust between multiple Windows domains, but for the simpler setup (like my own) it's a godsend.

This meant that I could use RID mapping within Winbind, which is part of Samba itself (so no troubles integrating those two), and achieve a consistent SID-UID mapping scheme across the network, allowing me to finally enable access to the file shares via. NFS. Amazingly, NFS "Just Worked" straight away, and I've written some nice wrapper programs around chown, getfacl and setfacl to set the correct owner and permissions on entire directory trees, which saves a lot of time when your UIDs are changing as often as mine were! I'm also using autofs to automatically map user's home directories on the Linux machines, which has proven itself to be very useful. I just used static fstab entries to map the other "general" file shares, like software and media - as I couldn't seem to get autofs direct maps working (apparently they are only partially working in Ubuntu anyway, but it seems as though they are completely broken to me).

On a side note, I've also just finished developing a Python-based rsync backup program, which allows me to write a _very_ small script to backup remote servers using rsync over SSH, and tar up the contents of all the servers into one archive. This is really useful, as I have a lot of disparate locations on different servers that all need to be pulled onto the backup drive every night. Now though, I should really concentrate on some revision for the exams I have after Christmas!

Happy holidays, everyone! (That's Merry Christmas and a happy new year, but just between you and me).

The basic idea is that Firefox has a file called profiles.ini, which takes care of all the configured profiles, and where they are stored. I used this file to change the default profile location to within the user's home directory on the file server. I had to use a home drive, mapped to the root of my users' folder redirection directory on the server, as I presumed UNC paths were unsupported in the .ini file. I did this with a GP Preference drive map using the %USERNAME% variable, and an amazing feature of GP Preferences - parsing and even altering ini files. You can specify which section of the ini file you are interested in, and which key you want changing. How useful! My policy looks like this:

You can probably work out what's going on here, but I'll give a quick overview. Basically, you specify the ini file to edit - in this case it's %APPDATA%\Mozilla\Firefox\profiles.ini. Using the %APPDATA% variable means that it will always resolve to the correct location in the user's local profile, whether they are on XP or Vista. Then we specify the section of the ini file - I'm interested in Profile0. This is the only profile present by default, but allows users to have multiple profiles if they wish without overwiting their settings when they log off. Finally, you specify the key to change, and what to change it to. I rename the default profile to Firefox, and change it's location to H:\Firefox. Also, this path is not relative, so I have to change IsRelative to 0.

OK, so now we have the Firefox profile location sorted, we need to make sure that folder exists - or Firefox will just overwrite our changes and make it's own folder in the default location. It's easy to use GP Preferences for this as well - as there's a Folders preference category. So I just made a new folders preference for \\zeus\UserData\%USERNAME%\Firefox, with the action of create (zeus is my main DC and File Server). I used the UNC path to be sure that the folder is created, even if the drive map hadn't come into effect when this preference was applied. Also, a little trick I had to pull here was ticking the checkbox titled Run in logged-on user's security context on the common tab. This is because only the user has permissions on their home directory, so this preference needed to run in the context of that user for it to work successfully (without access denied errors).

Once this was finished, the system started to work flawlessly. I copied the contents of existing Firefox profiles to the newly created directories, and they were picked up by Firefox with no problems. New users get blank profiles as expected, but they are stored on the file server instead of the local machine. One little issue I have encountered is that a user can't logon at more than one machine, and start Firefox - as the program can't lock particular files in the profile. This just results in a message saying this Firefox is already running though, which is pretty much correct (and I can't see why this would ever cause problems for the user).

The last trick I employed, to make things a little speedier and to reduce uneccesary file server traffic, was to disable disk caching on the roaming Firefox profiles. To do this, I used a file policy in GP Preferences to copy a tiny user.js (Firefox's preference file override) which contained only one line:

user_pref("browser.cache.disk.enable", false);

This turns off disk caching completely, which will not only save space on the file server, but should speed things up as well. I hosted this file elsewhere on the file server, and told the file policy to simply copy it into place, within the user's Firefox profile. Here's the preference:

So there you have it, my technique for enabling roaming Firefox profiles. If you've achieved the same through a different method, or have any ideas on this this could be improved, then I'd love to hear how - feel free to comment on this post.

Thanks to the MSDNAA program, I'm able to try out the latest version of Windows Server in the lab. I opted to migrate my domain accross to a new machine, instead of performing an in-place upgrade. Personally I feel this is a much safer bet, and tend to migrate domain controllers whenever I'm doing something pretty major to a DC.

So far everything looks good, I've upped the forest and domain functional level to Server 2008, so I can now take advantage of some of the new features - though I'm yet to find out what they all are! The best thing so far (by a mile I'd like to add) is the addition of Group Policy Preferences. Although it's annoying having to install the Client-Side Extensions on every machine in the domain (that is if WSUS isn't in use), the gains faw outweigh this bit of pain. I only wish an MSI could have been released, so that it could easily be pushed out using the existing Group Policy infrastructure. Never mind, eh?

Anyway, on with the good! The new GP Preferences allow an administrator to define, amongst others, drive maps for client machines, printer connections and power options. As you may be thinking, this just about does away with the need for logon scripts! Most, if not all of the common tasks that are performed with logon scripts can now be done from a group policy object.

There are also a lot of changes to the way Active Directory works. In Server 2008, Active Directory Domain Services can be installed on a machine, without actually making it a DC. What this means is that a standard server build can be 'sysprepped' with the files required for promoting the server to a DC, without actually doing the promotion. Also, Read-Only Domain Controllers (RODCs) have been introduced as a new feature. Essentially, an RODC just caches queries from a normal DC, usually located at another site - apparently allowing for faster logon times at remote sites with slow links. After discussion with a colleague, however, the benefits of such a system are maybe not quite as advertised. For example, only one RODC can be installed per site - so larger sites can't benefit from the redundancy and load balancing offered by multiple DCs, if RODCs are used. Also, the much-touted security advantages of using an RODC aren't as they seem either, as the database can be just as easily written to, just through another "normal" DC.

More on this later!

If you have ever reconfigured said DNS server, and recreated the DNS zones from scratch, you'll know that the neat zone that keeps all the SRV records separate from the oh-so-important A records, disappears - and gets put in a folder under the usual domain root.

Well, I have a solution to the ever so pressing issue. Obviously the only way anyone is going to risk breaking their whole Active Directory network will be if, like me, they are so _totally_ OCD about this kind of thing.

So, if you're interested, I've written a short article on how to restore this behaviour, and published it as always on maxms.net. If you think it might help you out, then here's the link:

http://maxms.net/article/Restoring-the-Separate-_msdcs-Zone-in-DNS

But remember, follow that article at your own risk!

Firstly, I install DNS on the Domain Controller to-be. I don't do any configuration on the service, just install it. Then, running DCPromo, I allow the wizard to configure the DNS Service for me. This makes sure that the two separate zones will be present - _msdcs.domain.name, and domain.name. This seems much neater to me, and I like to see this result - so I allow the wizard to take care of it.

When the domain is installed, the first thing I usually do is open up the default domain policy and remove all the password complexity options. These are usually just an annoyance - and unless the network has any particular security needs, I disable them all. Maybe leaving the length value at 6 if it's inappropriate to turn it off completely. I like managing GPO's from the Group Policy Management Console (GPMC), so that usually gets installed straight away.

In regard to the structure of the domain, I make an OU with the domain's Netbios name in the root, and under that I create some OU's as follows:

• Computers
• Distribution Groups (If Exchange will be installed)
• Security Groups
• Servers
  • Exchange Servers (for a special shutdown script)
• System Users
• Users

As for an explanation for that Exchange Servers OU, I make a shutdown script to stop all the exchange servers when it shuts down, to make the process a hundred times faster. I am so impressed by this technique, it works flawlessly every time. This OU allows me to assign the shutdown script via GPO to all Exchange Servers in the domain. Note that the DC stays in its own Domain Controllers OU that is created by the system automatically.

I guess at this point I'm feeling like I should do a backup of the DC. DHCP servers need authorizing, and Remote Desktop needs configuring. When that's done, we're basically there. Get the clients joined to the domain and we're off!

I have no idea whether my procedure is similar to anyone elses, or in any way superior (or indeed inferior) to others. Give me some opinions anyway, it will be interesting to hear from the rest of the community.

Up until recently, the network was running with just one physical server at each site, we shall call them Site A and Site B, each with VMware Server installed. Both servers were configured almost identically, with the host machine running AD (Active Directory) and Exchange 2003, and a VM running ISA Server 2006 for the firewall/VPN. Another VM was used for hosting some websites in the Perimeter network.

The redesign saw one new server in at Site A and two new servers at Site B – although the main server at Site A has been upgraded significantly. The new servers were installed to take the firewall away from the Virtual Machine to a physical one – as this is much more secure. Also, the second new server at Site B hosts Exchange, while this is now on a VM at Site A.

This network doesn’t support many clients or users, but it used mostly for educational purposes. For that it is perfect. We have a multi-tree forest AD configuration, with one domain for each site (or each house!), and one Exchange organisation spans the entire forest, with one Exchange server at each site. This also helps if one server/network is down, as the other will pick up the email for both sites – so we have a failsafe if one network is having problems.

I have published a “public” version of the network diagram, with external IP addresses/names removed, just in case anyone might find it interesting. Just click the thumbnail for a fullsize version.

As you may have noticed, I've used the names of gods from Greek and Roman mythology for the servers. The web servers are the oldest ones there so they haven't been renamed yet. Maybe an exiting project for the future!

Both networks now have a 20mb/784kb internet connection (up/down), so the VPN link is essentialy 784kb/sec both ways. That's pretty good for things like AD replication, but not brilliant for sharing files and photos.

The active directory is the aspect of the network I am most proud of. Since the rebuild it has been working flawlessly, although I am forever looking at ways to expand the directory. The DC at each site hosts a DNS zone for both domains, which provides redundancy for DNS if one DC is down, and both servers hold a copy of the Global Catalog. This allows for fast directory searches from both sites, and gives each Exchange server a GC to look to.

The forest is split logically, as well as physically, into sites. This allowed me to easily alter the replication schedule for the Domain Controllers, although I decided to leave this at hourly intervals, as I saw no reason to alter this value.

Hopefully the AD forest and network infrastructure will provide a solid base to expand on, and I will post about any major additions to the network. At present the clients consist of XP and Vista machines, but we are soon to aquire a new desktop, which will be running Vista, that will make a nice addition to AD.

Background: I manage a multi-tree forest, with two trees, one in each of two sites. They are connected by a slow site-to-site VPN link, over which all AD replication takes place.

The domain controller at the forest-root-domain needed rebuilding, as the operating system was installed on a flaky single disk, and was due to be moved to a RAID1 array. So I thought it best to promote another DC, transfer all FSMO roles, rebuild the first, and transfer the roles back. This process went swimmingly, and the first DC was back online in no time.

However, when it came to the second site, it seemed that no replication whatsoever was taking place. After delving into AD with tools such as adsiedit and replmon, I discovered that the second DC had not "heard" about the rebuild of the first. This meant that the GUID had not been updated to hold the value of the newly installed server. The fact that I had used the same name as before didn't help the situation at all.

In the end, it was clear that I would have to either restore the original DC from a System State backup, or rebuild the second domain from scratch. I chose the latter, as it was a small domain, and wouldn't take very long. Now the process is complete, and we have a fully functioning forest again (after lots of metadata cleanup and /forceremoval's!).

I won't forget this one in a hurry - allow time for big changes to replicate before making more big changes!