• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Domain Design Strategies

    In Active Directory, as with classic NT, a domain defines a discrete security and administrative unit. It also defines a replication boundary, as each domain forms a separate naming context within the Active Directory database.

    As you doodle your initial designs, start by looking for ways to use a single Active Directory domain. Do this even if you have a strong feeling that a single domain will not be feasible in your organization due to political turmoil. A single domain has several advantages:

    • Easier navigation. Users look at network structures with all the fear and suspicion of medieval serfs gaping up at a comet. The simpler you make it for them to find resources, the more likely your design has of being successfully implemented.

    • Simpler DNS configuration. If you have multiple domains in complex parent/child configurations, the resulting DNS zone referrals get a little tricky to configure. DNS causes the majority of Active Directory problems, so it makes sense to avoid complexity when possible.

    • Simpler replication topology. Managing replication is much more straight-forward in a single domain because you are not mixing different domain naming contexts and Global Catalog servers into your replication topology.

    Name Lengths

    When deciding what to name your domains, keep the names short and simple. Abbreviate where possible. Users will get irritated if their UPN is user@Albuquerque.NewMexico.UnitedStates.NorthAmerica.Company.com.

    Keep Organizational Unit names short, as well. A distinguished name cannot be longer than 255 characters. This includes the typeful designators such as DC=, CN=, and OU=.

    • Eliminate separate Global Catalog servers. With a single domain, you eliminate the reliance on separate Global Catalog servers because you can enable the Global Catalog on every domain controller.

    • Simpler security implementation. It's true that transitive Kerberos trusts make it possible to seamlessly access resources in other domains, but just because a feature is transparent doesn't mean it's simple to manage. An administrator's worst nightmare is trying to resolve a problem with file and directory access permissions by sifting through the membership list for hundreds of groups in separate domains.

    Reasons for Using Multiple Domains

    You may also encounter sizeable resistance to a single domain on the part of administrators who want an autonomous domain no matter what. I group these objections under political restrictions. This is not because I think they are any less important than the technical reasons. They aren't. The stability and performance of an information system has a lot more to do with people than it does with technology. It's just that political design restrictions tend to change considerably during the approval process, so you may be able to apply them less rigorously than the technical restrictions.

    There are only a few technical restrictions in Active Directory that may require you to use multiple domains. These include database size, performance restrictions, the need to have unique password policies, and the presence of sites that require Simple Mail Transport Protocol (SMTP) replication.

    Database Size Restrictions

    The more objects you pack into a single domain, the larger you make the Active Directory database, Ntds.dit, and the more changes you have to replicate between domain controllers. Active Directory can accommodate one billion objects, so you have lots of overhead to play with, but an extremely large database needs more powerful servers to handle authentications and LDAP requests. There comes a point, such as with the Roman Empire, where size affects durability.

    An Active Directory database for 100,000 users, their computers, and the groups necessary to manage them would be about 1.5GB. If you add in the additional directory overhead of Exchange 2000, you might touch 2GB. Extrapolating upward, an organization with half a million users would have an Ntds.dit file of 10GB, which is certainly within the capability of an average mirrored or RAID 5 array.

    These aren't huge databases by today's standards, so the decision to split into separate domains doesn't really boil down to the number of users and computers and groups. You should be more concerned with replication traffic and acceptable authentication performance.

    The vast majority of Windows domains contain fewer than 10,000 users, not enough to make Active Directory breathe hard. The toughest job for the designer of such a system is convincing management not to put additional services on the domain controllers such as messaging or database management. In general, domain controllers work fine when given DNS, DHCP (Dynamic Host Configuration Protocol), and WINS (Windows Internet Name Service) duties, but resist the urge to ladle on other chores. You don't want an application failure to force you into restarting or rebuilding a domain controller.

    Only truly gargantuan organizations with many hundreds of thousands of users and computers need to consider dividing their operations into separate domains. Microsoft has not published hard and fast rules about maximum practical database size, so if you are in one of those super-sized organizations, you'll need to work closely with Microsoft Consulting Services to structure your domain.

    Performance Restrictions

    Most companies deploying Active Directory opt to use separate domains for their overseas operations to reduce the need to replicate across expensive WAN links. This generally means having a Europe domain, a Pacific Rim domain, a South America domain (unless a solid link is available), an Asia domain for China and India, and an Africa domain.

    To get acceptable authentication performance, you'll need to size your domain controllers based on the user population in a particular site. If you have a few hundred users in a site who all log on at about the same time in the morning, you can easily get by with a 1U rackmount server with a single Xeon processor, 256MB of memory, a 100Mbps network card, and mirrored drives to hold the Active Directory files. Such a server costs less than $4,000 from top-tier vendors.

    If you have several thousand users authenticating in the morning at the same site, you can spread out the load by installing several smaller domain controllers or beef up a few domain controllers with dual processors, multiple network adapters, and separate mirrored spindles for the Active Directory and Sysvol files.

    Password Policy Restrictions

    Three sets of policies affect attributes of the Domain object in Active Directory and cannot be modified by group policies in subordinate containers like OUs. They are as follows:

    • Password policies. These include maximum and minimum password age, minimum password length, password history, complexity requirements, and reversible password storage.

    • Account lockout policies. These include the number of bad attempts that trigger a lockout, lockout duration, and reset interval.

    • Kerberos policies. These include service and user ticket lifetimes, ticket renewal interval, and permissible clock skew.

    If these policies must have different settings within the same organization, you'll need to create separate domains. This might happen if you are working on a contract and the client wants you to have certain security restrictions that are different than those in your organization.

    SMTP Replication Restrictions

    You may have a site or sites in remote, forsaken corners of the world like Tierra del Fuego or Hobbs, New Mexico. The network links to these sites might not be able to maintain stable data communications. If you attempt to construct a standard inter-site low-speed RPC connection over these links, the connections may fail often enough to prompt the bridgeheads to give up.

    If this happens, you can use Simple Mail Transport Protocol (SMTP) as the transport for replication to the remote site.

    SMTP is well suited for transporting replication packets over unreliable connections, but it has limitations when it comes to security. The RPCs used for inter- and intra-site replication encrypt traffic, but SMTP traffic is transferred in the clear. To avoid potential compromise of secure Active Directory information, the messages are encrypted using a form of secure messaging. This requires a Domain Controller certificate at the bridgehead servers on either side of the connection. To get this certificate, you'll need a Microsoft Certification Authority.

    Another limitation when using SMTP lies with the File Replication Service, or FRS. This service replicates the content of Sysvol, which contains group policy template files and the files used for classic system policies and scripting. FRS cannot use SMTP. This means that group policy container objects in Active Directory will not stay in sync with group policy files in Sysvol. For this reason, you cannot use SMTP to connect bridgeheads in the same domain.

    Political Restrictions

    A single domain should work for all but the largest and most geographically diverse organizations. As we get further into the operation of authentication, rights delegation, group management, and group policies, you'll see that it is entirely possible to build a single domain with Organizational Units to define management and administrative boundaries.

    Still, a good single-domain design can fracture during the approval process, usually because of balkanization rather than any engineering limitations. System administrators and their managers may view domain consolidation with suspicion. Depending on your personal force of will and your backing from management, you may end up with more domains than you really need.

    Try not to let local administrators carry their independence too far at the expense of reliability and performance. Large numbers of domains, especially when they each comprise a separate tree in the forest, complicate replication and domain controller placement.

    If you are a local administrator facing an initiative by central IT to consolidate domains, try to rein in your suspicions. You can get wide operational latitude in an OU and still share the benefits of a single Active Directory structure.

    Figure 8.4 shows an example of a forest where global regions have been compartmentalized into separate domains and large offices have been made into domains rather than OUs. The company has separate business units that also insisted on being in separate domains.

    Figure 8.4. Upper directory containers using multiple domains.


    Administratively, this structure becomes unwieldy because it forces you to manage many different Domain naming contexts with many possible variations of OUs and group policies. If your organization has no central IT staff whatsoever, this structure might work for you. Otherwise, you should try to avoid proliferating separate domains below major geographical areas.

    Multiple Domains and Groups

    If you decide that you must have multiple domains, you need to consider the impact of security groups very early in your design cycle. Chapter 12, "Managing Group Policies," takes a detailed look at security group functionality, but let's take a sneak preview right here to find out what we need to know for domain design. Here are the important elements to watch out for:

    • There are three different group types in Active Directory and their membership and application scopes differ. You must be in Native to get maximum flexibility.

    • The security subsystem uses groups to determine access authorization. If you do not plan correctly, users might be unable to reach certain resources, or you might be unable to lock them out.

    • Membership lists for the various group types are stored differently in the Global Catalog. This makes access to a GC a highly important element of your Active Directory design.

    Group Classifications

    Active Directory recognizes three classes of security groups: Domain Local, Global, and Universal. A fourth type, Machine Local, is only present in the local SAM of a member computer.

    Groups are differentiated by their scope of membership and scope of use:

    • Domain Local. This group type can have members from any domain in the forest. It can only be assigned to access control lists (ACLs) within its own domain.

    • Global. This group type can have members only from its own domain. It can be assigned to ACLs anywhere in the forest.

    • Universal. This group type can have members from any domain in the forest. It can be assigned to ACLs anywhere in the forest.

    Group Nesting

    Groups can be nested in other groups—that is, one group can be a member of another group. Nesting rules restrict which group type can be a member of another group type. The nesting rules vary depending on whether the domain is Mixed or Native. Here are the nesting rules:

    • In Mixed, Domain Local groups cannot nest within other groups. In Native, Domain Local groups can nest in other Domain Local groups in the same domain but not in any another group type. Domain Local groups can never nest in groups in other domains.

    • In Mixed and Native, Global groups can nest in Domain Local groups. In Native, Global groups can nest in other Global groups and Universal groups.

    • Universal groups can only be created and used in Native. They can nest into Domain Local, Global, and other Universal groups. If you have users from several domains in a Universal group, you can still nest the Universal group into a Global group as long as the two are in the same domain.

    A user's group membership helps determine which resources the user is authorized to touch. The group nesting rules determine how hard a user's logon server has to work to determine the user's group membership.

    Groups and Authorization

    When a user logs on, the Local Security Authority Subsystem (LSASS) at the logon server constructs a Privilege Access Certificate, or PAC, for the user. The PAC contains the user's Security ID (SID), a batch of security policies (password length, password history, logon time restrictions, and so forth), the SID of every group to which the user belongs, and the SID of any groups to which those groups belong.

    I emphasized the last part of that sentence because the way groups nest together has an impact on how you design your domains and lay out your security structures. Here's an example.

    Let's say that the security descriptor for a particular folder has an access control list (ACL) containing entries for two groups. Group A has Deny All permissions. This means that every member of group A is denied access. Group B has Full Control permissions. This means that every member of group B can create, read, write, modify, and change the security descriptor of files in the folder.

    If you nest group B into group A, all members of group B are suddenly denied access. The most restrictive permission has precedence.

    To make this nesting trick work, LSASS must chase down all cascading group memberships so that the user's PAC contains every applicable SID. This brings us to the final distinction between security groups.

    A Group object has an attribute called Member. This attribute contains the distinguished name (DN) of each group member. When you add a user or another group to the membership list of a group, you add the user or group's DN to the Member attribute. The Active Directory stores the Member attribute for a group differently depending on the group type:

    • A standard domain controller holds the Member attribute for all Group objects in its domain: Domain Local, Global, and Universal.

    • The Global Catalog stores the Member attribute for Universal groups from all domains in a forest.

    • The Global Catalog does not store the Member attribute for Domain Local and Global groups.

    Microsoft chose to exclude Domain Local and Global group membership from the GC to conserve replication bandwidth. The reasoning goes like this:

    • Universal groups can be nested into groups in other domains. Those groups can be placed on ACLs in any domain. For this reason, the LSASS must chase down cascading group memberships for Universal groups. To avoid walking the tree each time a domain controller performs this search, the Universal group Member attribute is included in the Global Catalog.

    • Domain Local groups cannot be nested into groups in other domains. When the LSASS assembles a PAC, it does not need to chase down any cascading group memberships in other domains because there cannot be any. It can get all the information it needs from the local Domain naming context. Therefore, it is not necessary to store Domain Local group membership in the Global Catalog.

    • Global groups can be nested into Domain Local and Universal groups in other domains. Domain Local groups cannot be placed on ACLs outside their own domain, so there is no need to chase down those cascading memberships. Universal group membership is already included in the Global Catalog. So, for Global groups, the LSASS can get all the information it needs from searching the local Domain naming context. It is not necessary to store Global group membership in the Global Catalog.

    Summary of Groups and Active Directory Design

    As you can see, group interaction in a multi-domain forest can get complex. The complexity grows if you decide to use Exchange 2000 as your messaging platform because security groups control access to public folders. Also, Exchange makes use of a second group type called the Distribution group to create email distribution lists without security credentials.

    Here are key points to keep in mind regarding groups when you lay out your Active Directory design:

    • Changing the membership of a Universal group results in a replication event to every Global Catalog server in the forest. If you define different domains for large geographical areas such as North America, Europe, Pac-Rim and so forth, you will incur additional communication traffic if the Universal group members change frequently. For this reason, Microsoft recommends putting users in Global groups and nesting Global groups into Universal groups.

    • Universal groups and the advanced nesting rules for Global groups are only available in Native, so your design should make the transition from classic NT as simple and quick as possible.

    • The user's logon server must be able to determine the user's Universal group membership to properly construct the user's Privilege Access Certificate. To prepare for a potential loss of a GC server, you should either configure multiple GC servers in a site or configure a standard DC to cache the GC contents.

    If you use multiple domains, it's imperative that you develop a set of standards for your operations and administration staff to define the group types to create for various situations. Otherwise, you'll soon have a mishmash of group types that makes chasing down resource access permissions very difficult.

    Designing Trusts in Multiple Domain Forests

    If you must have more than one domain, you need to decide how you will structure the trusts between the domains. You have several choices depending on how you plan on doing business over the next few years:

    • Tree. You'll get the most straightforward structure by confining your domains to a contiguous namespace, forming a tree. Individual domains in the tree trust each other using a Parent/Child trust. This simplifies your LDAP searches and makes scripting more straightforward, as well. It also simplifies user management, because individual objects can be quickly and easily moved between OUs.

    • Forest. If you cannot configure your DNS namespace to accommodate a single, contiguous tree, your next most effective solution is a forest of trees. Conglomerates and universities often select this structure because they have a diverse, decentralized IT organization. Each business unit or college gets its own top-level domain with its own DNS root. The root domains trust each other using a Tree Root trust. The child domains participate in the trust thanks to transitive, two-way Kerberos authentication.

    • Federation. If you cannot convince your colleagues to merge their separate domains into a single forest, you can achieve something approaching a single security entity using a Forest trust between the root domains in each forest. This trust type supports transitive two-way Kerberos authentication, which simplifies user access to resources. A Forest trust is not a replacement for a true Tree Root trust. The two forests represent completely separate administrative entities and you cannot easily move objects between them. You also cannot write simple scripts to manage the two forests. The Forest trust is most advantageous in situations where you must quickly build a security structure then wait a while before consolidating the objects into a single forest.

    • Mixed Domains. If you have downlevel NT domains, Samba domains, or MIT Kerberos v5 realms that you want to integrate into your Active Directory architecture, you can form External trusts or Realm trusts. You can also form External trusts to Active Directory forests with which you cannot form a Forest trust. Realm trusts can be two-way and transitive. External trusts are always one-way and intransitive.

    Configuring Logons for Multiple Domains

    If you have a single global domain, users can travel from Phoenix to Seoul, sit down at a workstation, press Ctrl-Alt-Del, and log on with their standard credentials. The local domain controller in Seoul has a replica of the same Domain naming context as the domain controller in Phoenix.

    If you have multiple domains, though, you need to train your traveling users to use one of two approaches:

    • Select their home domain from the Winlogon pick list. This requires users to remember their home domains, which might be something of a feat for a user who scarcely remembers a password. Also, the standard Winlogon window doesn't show the domain pick list by default. You have to click the Options button.

    • Log on using their UPN (User Principal Name). An example would be tjones@company.com. As soon as the Winlogon window sees an @ sign in the user name, the Domain pick list is dimmed.

    The system behaves exactly the same whether the user logs on using a UPN or a flat name with a domain. The user authenticates using Kerberos in an Active Directory domain and NTLM Challenge-Response in an NT domain. Using the UPN does not cause a client to "seek out" an Active Directory domain controller in a mixed-mode domain. The only difference is that the UPN logon requires a lookup at a Global Catalog server to "crack" the string into its component parts of username and domain. When you create a Parent/Child domain trust using a contiguous DNS namespace, the child domain is automatically configured to use the UPN of the root domain in the tree. The same is not true for forests where the domains or domain trees occupy a discontiguous DNS namespace.

    You can use a UPN logon to your advantage in a Discontiguous forest by assigning a custom UPN Suffix that all users in a forest can use so they don't need to know their home domain. If you select flat names that correspond to the users' email mailboxes, the logon names and email names would be the same. This is nowhere near a single sign-on solution, but it simplifies the user experience with two of the major systems that require authentication.

    By assigning a custom UPN Suffix, you can have a universal logon structure to simplify training. However, you must be sure to keep the flat names unique in the various domains. If you attempt to assign a flat name that already exists in another domain, the domain controller will query a Global Catalog server to verify that the name is unique. If a GC server is not available, you will not be permitted to create the potentially non-unique name. Assign a custom UPN Suffix using the AD Domains and Trusts console as described in Procedure 8.1.

    Resetting UPNs with Scripts

    If you look at the Account tab in a user's properties, you'll see a User Logon Name field that combines the user's flat logon name and the UPN Suffix. For any new users you create, you can select the new UPN Suffix from a pick list in the New User window.

    For existing users, though, you'll need to change the UPN to use the new suffix. This can be done quickly using Active Directory Services Interface (ADSI) in a script. Here is an example script that resets the UPN suffix to @BigCompany.com for users in an OU called Phoenix in the Company domain. A production script would include error checking and possibly a check to see if the current UPN were already correct to avoid unnecessary updates:

    set OU = GetObject("LDAP://ou=Phoenix,dc=Company,dc=com")
    OU.filter = Array("User")
    NewUPNSuffix = "@BigCompany.com"
    For Each User in OU
         Wscript.echo "Current UPN: " & User.UserPrincipalName
         Wscript.echo "Current logon name: " & User.SamAccountName
         User.UserPrincipalName = user.SamAccountName & NewUPNSuffix
         Wscript.echo "New UPN: " & User.UserPrincipalName

    Procedure 8.1 Assigning Custom UPN Suffixes

    1. Right-click the AD Domains and Trusts icon and select PROPERTIES from the flyout menu. The Properties window opens as shown in Figure 8.5.

      Figure 8.5. AD Domains and Trusts Properties window showing UPN Suffixes tab.


    2. There is only one tab in the Properties window, UPN Suffixes. Enter the suffix in the Alternative UPN Suffixes field and click Add.

    3. Click OK to save the change and close the window.

      Previous Section Next Section