Mike's IFAS AD Progress notes

ICC Home  /  AD Home / Members  /  Meetings  /  Peer Support  /  Documentation  /  Projects

7-3-03

Sorry I haven't updated everyone in a while...

We are making noteable progress in the lab. Just yesterday we set up a Cross Realm Trust to UFL.EDU (GatorLink) and setup a SQL Server connection to the Campus DB2 database.

Here are a few noteable observations:

• Win95B will authenticate to a Windows Server 2003 native domain IF you install the DSClient
• GatorLink usernames and the domain are CASE SENSITIVE so the correct format to log on to AD using a GLID is mikekano@UFL.EDU (I tried all of the other combinations, this is the only syntax that will work)

What we are going to focus on next is hardening the DC's acording to the Windows Server 2003 Security Guide

This will entail setting up IPSEC filters, tunnels, etc on the DC's to limit their exposure.

The design of the lab is in flux too, the diagram I created is already out of date. We will be getting a larger block of IP addresses next week so we can add more systems to the lab.

Here is a real quick summary of the basic structure of the lab:

• Two DCs
• UFDC01
• all FSMO roles
• GC
• DNS
• WINS
• UFDC11-GNV
• just a DC
• Exchange Server 2003
• Exchange
• Exchage OWA
• www.ad.ufl.edu website
• SQL Server 2000
• RRAS Server
• Multiboot system with:
• Win95B
• NT4 Workstation SP6a
• Windows 2000 Pro SP4

As we get things a little more solidified we will be asking for some help testing authentication methods from remote sites.

6-20-03

Here's where we are in the lab:

• Two Windows Server 2003 DCs
• One Windows Server 2003 (currently just another member server, this will be DCPROMO'd to a DC _after_ we populate our Test AD with lots of entries to test initial replication/sync time)
• One Exchange Server 2003
• One SQL 2000 SP3 server
• Two MIT Kerberos KDCs (installed on RedHat9) these are strictly for testing. we will plug into the Campus KDC soon.
• One Windows98se workstation to test downlevel clients (I need to build a Win95 box too though)
• One Windows2000 Pro workstation (we use this to get to the Internet and check our mail!)

Over the next few weeks we plan on building a VPN server and may start placing these systems on Public IP addresses for further testing, including WAN testing.

Also the phone numbers for the lab is 846-0226 in case you want to call me while I'm there (usually 10-5 during the week). Also, if you want to drop by and see the lab and our progress it is located in 3104 in the Journalism Building (Weimer Hall).

I'll try and update the Visio diagram once we get things a little more solidified.

5-23-03

Current Test Environment

Note that this is only a preliminary test environment and is apt to start changing rapidly. We are in the process of  securing a more permanent lab space, possibly with Journalism or at ERP headquarters.

So far we have made some progress in testing, which seems to have answered some questions but given us many more.

We have tested:

Kerberos Cross Realm Authentication with a TwoWay transitive trust from Windows 2003 AD to the MIT Kerberos Realm. 
(This will have to be retested in a One Way trust setup to replicate what will eventually be in place at UF)

We tested and saw that logon scripts assigned to a user account worked both when logging on via Kerberos or Windows AD account from a Windows 2000 Pro workstation.

We will need to investigate usage of a GPO to add the KDC information to workstations. There is a tool that was developed by MIT to create the REG_MULTI_SZ registry key directly since it is in a binary format. (more to come later...)

What did not work is Cached credentials using the Kerberos logon. Also, Kerberos username are Case Sensitive, therefore mikekano and MIKEKANO are completely different, so this might cause some user "frustration".

We also began some preliminary testing of using the Active Directory Connector (ADC) to migrate Exchange 5.5 into the Active Directory. This tool has some limitations in that since the Exchange server is in a separate Domain and also a separate Exchange Organization and Site it cannot actually move the accounts or data over. The ADC is merely a connector and is not intended for permanent usage. 

We plan on looking much closer at the Aelita tools and other scenarios for Exchange upgrade / migration strategies.

Some of the next stages will be to place the test environment on public IP addresses (or behind a vlan or VPN) to start testing across the network.

I'll know more next week.

 Last updated 04/14/2005 by
Mike Kanofsky