|
|
| Home | Active Directory | Admin Tools | Security | Resources |
Implementing Active Directory at UGA
What is AD?
Microsoft’s Active Directory (AD) is an LDAP-based directory service released in January of 2000. It allows Microsoft administrators to manage and share network resources and to manage users and network security centrally. You can also use AD to manage other directories. It is an essential part of the Windows 2000 and 2003 architecture, enabling many of the newer features found in those versions of Microsoft's network operating system. AD is integrated with the Domain Name System (DNS) for service location.
A First Look
When departmental administrators on campus began showing an interest in running AD within the University environment, we spent some time looking into what would need to be done in order to accomodate that need. What we found was that, since Microsoft had integrated their Active Directory Service with the Domain Naming System (DNS) namespace for service location, our DNS infrastructure which was in place at that time would not support AD*. Our original Active Directory goal was simply to enable DNS to support AD on campus. The departments would then, at least, be able to create their own discontiguous AD Forests.
As we learned more about Active Directory and showed EITS how important (and complex) the initial planning stages are, the goals began to shift. While looking at Active Directory's potential, its worldwide popularity and it's integration with current and future Microsoft operating systems, we decided that we needed to plan for the possibility that at some point the University would require a campus-wide Active Directory. And, as we began to understand AD's integration with Exchange, we concluded that we should also plan for the possibility that UGA's current enterprise mail implementation (ARCHES) could one day be run in an Exchange environment. A lot of planning would be required in order to ensure that the Active Directory architecture on campus could support this potential growth.
Currently, departments are able to employ Active Directory by building their own Active Directory Forests, with the understanding that built-in technology does not currently exist which will enable the discontiguous forests to merge into the campus forest. This is supported by our central DNS service. In addition, in the near future we will offer a UGA AD Forest for those who wish to participate in a centrally run Active Directory. The central forest is in it's final phases of testing at this time. The central forest will enable departmental administrators to have an Organizational Unit (OU) within UGA's central forest, without the responsibility of managing a schema of their own and still maintaining administrative rights within their own Organizational Unit's hierarchy. This will also enable long term growth with respect to the Active Directory infrastructure and synchronization with the other campus directories including the Novell Directory Services (NDS) implementation.
At this time, we have two departments who are involved in our final phases of testing for the central UGA Active Directory Forest. We have integrated security into this forest at the various levels, including domain level Group Policies and OU level Group Policies. In order to maintain an adequate level of security, we have structured the forest so that certain services (like IIS and FTP) are separated from the rest of the tree. We hope to finalize the security settings over the course of the next couple of months and, once completed we can allow more departments to add their resources to the structure. We will be having orientation sessions for those administrators who will be migrating their departments into the central forest. More information will be added to cover the details of the central forest soon.
DNS
Originally, EITS decided to modify our non-dynamic BIND environment to accomodate Active Directory on campus. We created scripts to modify the zones which needed to run Active Directory, allowing dynamic entries to be made by named domain controllers and only allowing the specific zones required by Microsoft to be updated dynamically. In the beginning, this seemed like the easiest solution, considering the fact that creating an additional DNS environment, specifically for Windows, was yet another service that EITS would have to maintain and support on an already tight budget. The were also security concerns about modifying the entire BIND environment and making it dynamic. We did have success with our solution, but as new versions of Windows are released, we realized that the scripts and the way that we deal with both environments would have to be adjusted every time a new release that changes DNS happens. Because of this, we have decided to break off the AD environment from our originally naming structure (uga.edu) and have created a new namespece for the central AD (ad.uga.edu). We have set up Windows DNS servers to handle the DNS for this zone and created pointer records for it in the uga.edu zone. This will enable us to provide both secure and dynamic updates for the members of the central Active Dirctory without the constant maintainence of our BIND solution.
*For more information, see RFCs 2136, 2137, and 2782 which cover the requirements of Active Directory.