\u2022 Plan a security group strategy
\u2022 Plan a user authentication strategy
\u2022 Plan an organizational unit (OU) structure
\u2022 Implement an OU structure
\u2022 Plan an administrative delegation strategy
Once you\u2019ve learned about the components of Active Directory\u2014the physical compo- nents that participate in directory replication, and the logical components that define how the organization defines its administrative structure\u2014it\u2019s time to start populating the Active Directory database with user accounts so users can start using the domain.
In this chapter, you\u2019ll learn to add and manage accounts. You\u2019ll organize your user and even computer accounts to simplify the administration when assigning permis- sions or delegating administration.
Every user participating in a Windows 2003 Active Directory domain needs a user ac- count and password. Further, user accounts are sometimes used as service accounts when accessing Back Office applications such as Exchange Server and SQL Server. And even if you are not using an Active Directory domain for access to network resources, you still need an account to use the local Windows Server 2003 machine. In this case, you will be using a local account.
Users will be created, and then they will log on to begin accessing domain resources. But just howthe users present their logon credentials is yet another area where adminis- trators can exert discretion. Most networks use user names and passwords to access the
After adding accounts and creating security groups, you\u2019ll learn more about the orga- nizational unit creation process and how you can use OUs to divide up administrative responsibilities throughout the domain.
Once you\u2019ve decided how best to implement the Windows Server 2003 operating system, including if andhowto deploy the Active Directory environment, the next essential task is creating accounts. Only once an account has beenpresented and authenticated will a user be able to access a Windows Server 2003 domain\u2019s resources.
As first explored in Chapter 18, a user account allows a user to log on to the local computer, or, in the case of a Windows 2003 Active Directory environment, one of the domains in your forest. The user account\u2019s credentials are validated against the directory database to which they are submitted, and if authenticated, the user account is granted anaccess token at logon time. Included in this access token is the user account security identifier (SID), along with the SIDs for any group account of which the user is a mem- ber. This access token is presented against access control lists (ACLs) to determine a level of access to a resource.
Most of the accounts you\u2019ll create in a Windows Server 2003 environment will be do- main accounts\u2014they will be created in the Active Directory database. But before we dis- cuss the creation of Active Directory accounts, to set the foundation, we\u2019ll examine a local account in some detail.
When you create alocal account, you create a new security identifier in a directory data- base. That directory database is local to that particular machine; that is, it\u2019s stored in a folder on the machine\u2019s local hard disk. You can create a local account on any computer that\u2019s a part of a workgroup, or on any member computers of an Active Directory do- main, as long as the computer is not also a domain controller.
Windows NT 4.0, Windows 2000 Professional, Windows XP Professional, and Windows Server 2003. Other operating systems, such as Windows 98 and XP Home, do not create computer accounts in the domain; therefore,
With a local account, a user has the ability to log on locally to the machine where the account resides. However, when using a local account, he or she is restricted to using only the resources on that computer. If the user wants toaccess a resource on a computer
This caveat becomes a disadvantage as the network starts to grow, because users need multiple accounts defined to access resources that are stored on multiple computers. Figure 20-1 shows the principles of local accounts in a workgroup environment.
How do you know you\u2019re using a local account when logging on? You specify where the account will be submitted in the Log On To section of the Log On To Windows dia- log box. If the selection in the drop-down menu sayscomputername (This Computer), then you are trying to submit a local account for logon.
Adomain user account, conversely, is created on a domain controller, and is stored in the Active Directory database. The domain controller stores a replica of this database, keeps it up to date with the latest changes by synchronizing with other domain controllers, and checks the database when validating the user logon attempt.
Because the account credentials are submitted to a central location, they can be sub- mitted from any computer in the domain. (Unless, that is, you\u2019ve restricted which com- puters the user can log on from, which is your prerogative as the Windows Server 2003 Active Directory administrator. There are exceptions to just about everything, depend- ing on the instructions you\u2019ve given the computer.)
And because account credentials are stored and authenticated against a single en- tity\u2014the Active Directory database\u2014it\u2019s not wise to create two Brian accounts for logon, one for the domain and one for the local computer. All the user needs is the single do- main account. The domain account still gives Brian the right to use every computer in the domain (except the domain controllers themselves, which by default restrict who is able to log on at those machines). As shown in Figure 20-2, a domain account needs to be defined only once per user.
perform administrative tasks. The domain account will do just fine, unless the default group memberships have been tempered with. We\u2019ll discuss some of the default group memberships, especially the Administrators groups memberships, in the next section.
This action might not be possible to undo. Are you sure you want to continue?