For the Windows 2000 Server exam you are required to be familiar with the essentials of IIS 5.0,which is installed by default on a new Windows2000 Server installation, and upgrades systems with IIS 4.0. The two main features of IIS remain its functionality as both a web and ftp server,which we’ll concentrate on here. Note that many other services do exist under IIS, including the ability to act as an SMTP (mail), NNTP (news), or streaming media server.
After IIS 5.0 is installed, two new user accounts are created by default, and placed in the Users container. One, called IUSR_computername, is provided for the purpose of allowing anonymous access to the IIS-based system. The other is called IWAM_computername, and is the account under which IIS runs. This is used to start scripting applications, for example.
IIS will also create a folder called Inetpub on the IIS system, and subdirectories of this folder provide the working roots for installed services.For example, wwwroot is the location of the default website, while ftproot houses the root directory for ftp connections. While these directories are used by default, others can be created and placed in different folders or partitions if this better meets your needs. It is usually best, however, to keep everything situated in a single location in order to simplify the administrative process.
IIS services are managed using the Internet Services Manager tool. You can access the master property sheet for a server by right-clicking the server and choosing properties. Settings set on the master property sheets for the WWW or FTP services will be inherited by all new sites you create. The master properties allow you to control settings such as the amount of bandwidth dedicated to each server, registered MIME file types, and server extensions, which includes server usage optimization.
Windows 2000 Server includes terminal services for the purpose of remote administration of servers as well as the ability to provide centralized access to software and the Windows 2000 desktop. Not installed by default, terminal services provides an environment that is often referred to as‘thin client’. In this environment (also provided by third-party products such as Citrix Metaframe), only screen-shots, keyboard strokes,and mouse movements are passed between the server and the client. All processing actually takes place on the server, which greatly reduces the computing requirements on the client side. Assuch, even Intel 386 running Windows 3.11 can provide users with access to the Windows 2000environment and associated applications. Terminal services uses the Remote Desktop Protocol (RDP) to pass data between the terminal service client and server.
Terminal services is installed via the Windows Components Wizard. After choosing to install terminal services, you will be prompted to choose between the two possible install modes.
Remote administration mode allows 2 simultaneous terminal services connections for the purpose of remote administration and requires no additional licensing. Application server mode is provided for the purpose of allowing regular users to run applications in Windows 2000. In this mode, a terminal services licensing server much also exist(a 90-day grace period is provided), since every terminal client connection will require a terminal service CAL. Note that Windows 2000 Professional systems do not require an additional CAL to access the terminal server, but other operating systems do.
A Window 2000 environment running Active Directory provides the ability to use group policy to distribute software to users and computers. This allows for the distribution of software at the site, domain, and organizational unit levels (the 3 levels within Active Directory to which group policy can be applied). Note that software can only be distributed to client systems running Windows 2000.
In a group policy object, the distribution of software is handled as part of both the computer and user sections.
When distributing software, two options exist –assigning and publishing. Software can be assigned to both users and computers, but software can only be published to users. The difference between the distribution types is outlined below.
Assigning software to users: Doing this will distribute software to users, but will not actually install it on their system. When software is assigned to a user, it ‘follows’ them, or appears to be installed on every machine they logon to. In reality, only shortcuts appear on the programs menu. If they user clicks on the shortcut, then the application is actually installed on that system. Assigning software tousers gives that user access to the applications they need, even if the system doesn’t have the software already installed.
Assigning software to computers: This method actually installs the software assigned to the computer the next time the system is restarted, making it available to all users of the system.
Publishing software to users: This method adds the application to the Add/Remove programs section of control panel, allowing the user to install the application if necessary. It does not appear to be installed as software assigned to a user does. A published application can also beinstalled via document invocation. For example, if a user clicked on a zip file, WinZip would install if it had been published to the user.
DFS, or the distrbuted file system, was a feature originally found in the NT 4 product but underutilized. The distributed file system allows you to organize shared folders on the network into a single logical hierarchy, while maintaining data on different physical servers. To the user, data which is actually distributed appears to fall under an organized, structured hierarchy. This allows you to not only manipulate how users see the data (you can use different share names for existing folders), but also how they access it (you can create whatever hierarchy will best suit the needs of the users). For example, data might be physically distributed, as outlined below:
Sales data files \\server13\salesdata
Sales quota files \\server2\s-quotainfo
Sales report files \\server1\rpt
Using DFS, we could create a DFS root called Sales using an empty shared folder on Server1 called Sales, and create a the following hierarchy:
We would simply map a drive for users to the Sales folder on Server1, and they would automatically be redirected to the appropriate folder of the appropriate server as they accessed the subfolders. Note that DFS maintains and does not change any of the permissions associated with the actual folders. Whatever level of access users had to the folders before DFS will be the same level of access after DFS has been configured.
In Windows 2000, two types of DFS structures exist – standalone DFS, and domain-based DFS. Note that while a domain can host multiple DFS roots, any server can host only a single DFS root, regardless of type (stand-alone or domain-based).
Much like in NT 4, a user profile defines a user’s desktop environment and settings. This can include things like the placement of desktop icons, drive and printer mappings, and mouse-related properties. In Windows 2000, two types of profiles still exist – local and roaming.
A local profile is the most simple. By default, every time a user logs onto a system for the first time, the default profile is opened for that user, and is ultimately saved on that system in a folder bearing the user’s name, under the Documents and Settings folder. Any changes made by the user are saved at logoff. When the user logs on to that system again, they receive the environment they left off with. The nature of a local profile is that it does not ‘follow’ the user. That is, if the user were to log on to another computer, they would receive the default profile, and another local profile would be created.
A roaming profile is one where the user’s environment ‘follows’ them as they move to different systems on the network. These profiles are stored on a server, and are copied back and forth as the user logs on or off. In order for a user to have a roaming profile, the location of the profile must be stored in the properties of the user’s account, in the User Profile section of the ‘Profile’ tab.
As noted earlier, the basic difference between a built-in container and an OU is that OUs can have group policy settings applied to them. Another benefit is the fact that OUs can be nested, which provides benefits in terms of the inheritance of group policy. Note that an OU can be moved within a domain, just like any other domain object. Simple right-click the OU and choose to move it. Be careful about deleting an OU, however, since you will also be deleting all of the objects it contains (at least you get a warning!)
OUs exist primarily for the purpose of organization of resources according to administrative needs. For example, I can delegate control over an OU called Servers to the server support team, and not grant them administrative access to anything else. By the same token, I can apply policies to an OU (such as one containing all bank teller user accounts), which would allow me to lock down the desktop environments of these users specifically. As mentioned in a previous article, group policy can be applied at 4 levels, in the following order:
- OU followed by sub-OUs, if any
The order of application is very important. All group policy settings that apply merge together, unless there is a conflict. In the case of conflicting settings, the settings at the lower level apply. For example, if a setting at the domain level said that users were to have the Run command disabled, and a policy at the OU level specifically enabled it, the user would have access to the Run command. The order followed is the one described above. By the same token, it is possible that conflicting settings would exist in different policies applied to the same OU.
In this case, it is important to note that policies are applied from bottom to top. That is, first Policy A is applied, followed by Policy B, and then Policy C. As such, if there were a conflict between Policy C and Policy A, the settings from Policy C would apply. You can change the order of policies at a given level by using the up and down arrows on this screen.
Active Directory requires that computer accounts be created for both Windows 2000 and Windows NT-based operating systems. Similar to NT 4, Windows 9x-based systems do not require this, on account on the fact that these systems do not have a SID. Computer accounts can be created in the built-in Computers container or other containers in advance. If you create the computer account as part of joining a domain, the account will automatically be placed in the Computers container. Of course, it can be moved at any time, according to your management and administration needs.
Group accounts have also changed in Windows 2000. Unlike NT 4 where we only found Global and Local groups, Windows 2000 includes new group types, scopes and abilities. Before we discuss these however, we need to take a look at something referred to as the ‘mode’ of a domain. By default, all domains are created in something called Mixed Mode. In this mode, NT 4 BDCs can still exist, and many of the rules associated with an NT 4 domain still apply. Once all domain controllers have been switched to Windows 2000, the domain can be switched into what is referred to as Native Mode. This is a one-way process. Note that even if you are not upgrading an NT 4 domain, a Windows 2000 domain is still automatically created in Mixed Mode, and the change to Native mode must be made before many of the new feature with respect to users and groups can be used.
Windows 2000 supports two types of groups. The first are very similar to groups in NT 4, and are referred to as Security groups. Quite simply, a security group has a SID, and as such can be part of a Discretionary Access Control List (DACL), the list of users and groups that have permissions to access a resource. The second type of group is called a Distribution group, and exists for the purposes of sending email messages to a group of users. This functionality largely exists for the purpose of Exchange 2000 integration. Distribution groups have no SID, and as such cannot be added to a DACL. You may be asking why it is necessary to make a distinction. The reason relates to what happens when a user logs on – a security token gets created that lists their SID, and the SIDs of the groups they are part of. The larger the number of security groups, the larger the security token for a user, and the longer it will take to log on. Distribution groups provide an easy and less resource-intensive way to be able to integrate messaging technologies with Active Directory.
Every User that needs to log into the domain will require a user account. Note that the account can be created within any container (built-in, or OU that you create), since these are all still technically ‘domain’ accounts. The user will still only need to supply the domain they wish to log into, not the container in which their account actually exists. Unlike NT 4 where the properties relating to a user account were very limited, in Active Directory user account properties are actually quite extensive. Most of these are not configured during the account creation process, but actually afterwards by accessing the properties of an account. Like NT 4, you can change the properties of multiple accounts simulataneously by selecting many accounts and then accessing their properties collectively. The property tabs found on a domain user account differ based on the services installed. For example, if Exchange 2000 is installed, a user’s mail configuration is done from the property sheets. Note that to view some tabs, you must choose Advanced Features from the View menu. The default tabs and their purposes are listed below:
- General – contains basic information about the user including first name, last name, email address, etc.
- Address – home address of the user
- Account – user account details, including logon name, logon hours, account options, and account expiry.
- Profile – user profile and logon script information, as well as home directory details.
- Telephones – various phone numbers for the user.
- Organization – information on title, department, and manager.
- Environment – Terminal services startup information.
- Sessions – settings relating to Terminal service sessions, such as idle session disconnect.
- Remote Control – settings relating to Terminal service remote control options.
- Terminal Services Profile – information relating to Terminal service profile, home directory, and allowing/disallowing logon to terminal server.
- Published Certificates – listing of user’s X.509 certificates and purposes.
- Member Of – listing of groups the user is a member of.
- Dial-in – Dial-in settings for this user, including items such as callback settings.
- Object – shows fully qualified name of the user object, when it was created.
- Security – show access control list associated with this object.
The administration of Active Directory involves the management of domain objects and their associated properties. The objects managed within a domain include user accounts, group accounts, computer accounts, and organizational units primarily. Unlike NT 4 where we used one tool to manage users and groups (User Manager for Domains) and another to manage computer accounts (Server Manager), in a Windows 2000 domain all management of these objects is handled via a tool called Active Directory Users and Computers, an MMC snap-in. Note that this tool can quickly be accessed from the Run command, by running dsa.msc.
When opened, Active Directory Users and Computers will be focused on a particular domain controller. This will be the domain controller to which updates and additions will be written. It can be changed by right-clicking the domain object and choosing to connect to another domain controller instead. This is actually quite useful – because replication between sites can have associated schedules, you might decide to change a user’s properties on their local domain controller instead of another, and thus not have to wait for the changes to replicate. The AD Users and Computers program displays the domain object, and then a series of containers.
First and foremost, the folders that appear beneath the domain object are actually containers. Two types of containers exist – built-in containers, and OUs. A built-in container appears as a plain folder, while an OU looks like a folder with a book icon on it. Note that OUs can have group policies applied to them, while built-in containers cannot. However, both types of container allow you to delegate administrative control. The containers which are created automatically are described below:
- Built-in: This container houses all built-in user and group accounts created when Active Directory is installed.
- Computers: This container houses any upgraded computer accounts, or any new accounts added as part of joining a domain from a client system.
- Domain Controllers: This OU contains all domain controllers for the domain.
- ForeignSecurityPrincipals: Container for SIDs of user accounts from external trusted domains.
- Users: This container is where upgraded user accounts are stored. You will also find the domain Administrator and Guest accounts here.
These are not the only built-in containers that exist, however. If you choose Advanced Features from the View menu, you will also find the following containers:
- LostAndFound: This container houses orphaned objects. For example, imagine if an OU was deleted on one domain controller, and before replication had completed, a user was created in that OU on another domain controller. This user would be placed into the LostAndFound container, since its container object no longer exists.
- System: This container holds settings relating to domain operational information, including AD-integrated DNS, domain DFS configuration, and so forth.
Within these containers (or the root of the domain) other objects can be created such as users, computers, groups and so forth. Note that there is no requirement to actually create users in the Users container, or computer accounts within the Computers container. You can use these, or create additional OUs according to your organizational needs and place accounts there instead. You can also easily move objects between contains by right-clicking the object and choosing Move. To create a new object within a container, right-click the object and choose New, and then choose the appropriate object type you wish to create.