For the next several months, I'll discuss users, groups, domains, and permissions. Windows NT Magazine covered some of these topics in earlier issues, but the magazine is constantly acquiring new readers. Thus, I'll present these topics from a novice's perspective. This month I'll look at the different types of user accounts, and I'll explain how the domain accounts database interacts with the local accounts database.
Workgroup Accounts vs. Domain Accounts
Windows NT requires users to log on with a valid username and password. NT compares the username and password the user enters with those in the user accounts database. If the names and passwords match, NT lets the user log on. NT can store the user accounts database locally, on the user's computer. These locally validated accounts are called workgroup accounts, because you can use the accounts to set up multiple NT computers in a workgroup, or peer-to-peer, relationship. In this case, users log on to their workgroup computers. Alternatively, NT can check usernames and passwords against an accounts database on a central domain controller. For NT to use a central domain controller, you must first implement the NT domain model. In this model, NT manages the accounts database from a central point, the Primary Domain Controller (PDC). In the domain model, the accounts are called domain accounts, and users log on to the domain.
Many combinations of workstations, domain controllers, and servers exist. To eliminate confusion, I'll discuss the different user account configurations.
Domain Controllers
On a PDC, you always log on to the domain. In fact, you can't log on locally to the computer. From the Start menu, select Programs, Administrative Tools, User Manager for Domains. You'll see lists of user accounts and groups, as Screen 1, page 226, shows. The icon in the left column under Groups tells you the type of group; a computer icon identifies local group and globe identifies a global group. From the User menu, you can add new user accounts, as Screen 2, page 226, shows. You can then use these accounts anywhere in the domain. You can add new global groups, which you can also use anywhere in the domain. You can add new local groups, but these groups apply only on the domain controllers. The Backup Domain Controllers (BDCs) keep a copy of the database from the PDC because the BDCs don't have their own accounts database. If you define a local group on the PDC, the group appears on all the BDCs in the domain.
When you add permissions to a resource on a domain controller, you can grant access to individual users, global groups from the domain, or local groups from the domain controller. Screen 3, page 226, shows granting permissions.
Member Servers
You can configure a server as a member server. A member server is an NT server that isn't a domain controller. The server is a registered part of an NT domain and is aware of domain accounts, but it has its own accounts database. A member server is typically a computer you use as a database or messaging server and that you don't want to load down with domain controller responsibilities. When you configure a member server, you can log on locally to the computer or to the domain. The logon dialog box controls where you log on. When you supply a username and password, you must specify where they are valid, but you can't type a value in the domain box. You must choose from a drop-down list that contains the server name, the domain to which the server belongs, and the domains you've established trust relationships with for the server.
Open User Manager for Domains to add users. Where you logged on determines what you see when you open this utility. If a user logs on to the domain, User Manager for Domains displays the domain accounts database. Administrators can see all domain accounts and groups and can administer the domain as if they were sitting at the PDC. In fact, changes take place on the accounts database's master copy on the PDC. But if a user logs on to the local accounts database, User Manager for Domains displays only local user accounts and groups. In Screen 4, page 227, User Manager for Domains shows the \\MEMBER computer name to indicate that the user is logged on to the computer accounts database.
After you open User Manager for Domains, you can switch from the domain database to the local database. As domain administrator, you can make this switch because when the computer became a member of the domain, the system automatically added the domain global group Domain Admins to the local group Administrators. To switch from the domain group to the local group, click User, Select Domain. As Screen 5 shows, you'll see only the domain names. To view local computer accounts, you have to type in the name of the computer. You can type
MEMBER
or
\\MEMBER
If you log on locally, you can't switch to the domain group. When you log on locally, you use an account from the local accounts database, which has no administrative privileges on the domain. If you try to switch to the domain group, you'll receive an Access denied message.
Assigning permissions on member servers. NT administrators can use a standard method for granting permissions on resources such as shared folders, files, and printers. First, assign the appropriate permissions on the resource to a local group on the server. Next, place the users who need access to the resource into a global group on the domain controller. Finally, place the domain global group into the local group on the server.
When you go to a permissions menu on a member server, you see the global groups from the domain controller. For example, double-click the My Computer icon and right-click a drive that uses NTFS. Select Properties, Security to see the list of permissions on the drive, and click Add to modify the permissions. The default accounts database you see is the domain accounts database. Before you can assign access permissions on the disk to a local group, you must select the computer name to switch to the local accounts database. To remember the difference between global and local groups, think of global groups as organizing users who have domain accounts, and think of local groups as controlling access to local resources.
Remote Administration of Accounts Databases
Switching accounts databases saves administrators time and energy. Suppose you have several users who are responsible for network backups. To perform a networkwide backup, you add the users to a global group called GL_Netbackops. Next, you need to put the global group in the Backup Operators local group, which NT previously set up for you on each member server. This local group has the permissions to back up and restore files. You can go to each server and add the global group to the local group, or you can connect to the accounts database on the member server and complete the operation remotely. From my domain controller, I can add the Backup Operators global group to the local group on the member server, as Screen 6 shows.
Standalone Servers
You can configure an NT server as a standalone server. A standalone server is not part of a domain, although it can be part of a workgroup. From a standalone server, you can see only the accounts database on that server. The Administrative Tools menu item says User Manager for Domains, but you can't access domain accounts from this item. On the User menu, you can see Add a New Global Group, but you can't select it. You can add users and local groups to the local database, but you can't connect to other accounts databases. The same limitations apply if you want to assign permissions on resources: From the security menus, you can see only the accounts in the local database. NT's standalone server is just that, so only a user who has an account on the server can access it.
If you want your domain users to have access to resources on this server, you need to create accounts for them on the server. As in the workgroup model, users need accounts on every computer they connect to. You can add a standalone server to the domain and make it a member server, or you can let it maintain a separate set of accounts.
If the server maintains separate accounts, a user's username and password can be the same on all accounts. Otherwise users must supply their username and password to connect to the server (an annoyance that NT typically eliminates). But changing passwords then becomes an issue, because the user must change the password in two places.
Administrators' passwords need to be different on the domain controller and the standalone server. Thus, administrators must supply their username and password to connect to the standalone server. If administrators don't maintain separate usernames and passwords, security risks are increased. If the username and password are the same, anyone who hacks into the standalone server can automatically access the domain.
A standalone server doesn't have access to the domain accounts database, so you can't give permissions on resources to a global group or put domain global groups into local groups. To manage resources, you must assign permissions to user accounts on the standalone server and match the user accounts to the domain accounts. Companies rarely use standalone servers unless they need an extremely secure system and have the resources to maintain the server.
NT Workstations
You can configure NT workstation computers to join the domain or to act as standalone workstations. The previous discussion about accounts databases for member servers and standalone servers also applies to workstations. However, you typically do not need to assign access permissions to resources on a workstation.
Recommendations
The domain model in NT is based on the concept of centralized domain administration and a centralized accounts database. The model focuses attention on the domain accounts database on the domain controllers, often overlooking the local accounts database. However, the domain and local databases work together, and you can administer them from a central location. On a workstation, which shares no resources and always logs on to the domain, the local accounts database is unimportant. But on a server, the local accounts database might contain information about which domain accounts should have local access. Thus, when you back up these servers, you also need to back up the Registry. You'll want to periodically rebuild the Emergency Repair Disk (ERD). These preventive measures will save you from having to reconstruct a server after a crash.
