|Last modified: 14-11-2012|
by Jeffrey R. Shapiro and Jim Boyce
Microsoft Management Console : In Windows 2003, the MMC is used systemwide for managing just about everything on Windows Server 2003. A management module, known as a snap-in, exists or is created for each service. Each snap-in offers peculiar features and options, depending on the service targeted for configuration.
The IntelliMirror is a group of technologies that enables a user’s settings, preferences, applications, and security to follow that user to other computers on the network. IntelliMirror is really an umbrella term that refers to the following technologies and features:
A lot of overlap does, of course, exist between the IntelliMirror-cum-Active Directory servicesand System Management Server (SMS). SMS manages the deployment of software over multiple sites as part of its complex change-control and change-management services.
Managing Windows Networks and Windows Server 2003 just got a lot easier with the new Group Policy technology. Group Policy is used to manage user settings, security, domain administration settings, desktop configurations, and more. In short, most of the workspace is managed through Group Policy.
Group Policy is applied at all levels of the enterprise in Active Directory, from domains down to organizational units and so on. The tool used for the job is the Group Policy Editor (GPE). The GPE enables you to create objects that are associated or referenced to organizational units (OUs) in Active Directory. Group Policy Objects (GPOs) can be secured with NTFS permissions in the same fashion as files and folders.
Thanks to the long-awaited Windows Driver Model (WDM) initiative, all device drivers created for Windows 98 and its successor that conform to the WDM can support hardware in both operating systems because they are the same drivers.
The DFS Namespaces (formerly known as Distributed File System) enables administrators to group shared folders located on different servers and present them to users as a virtual tree of folders known as a namespace. DFS Replication, the successor to File Replication Service (FRS), is a new state-based, multimaster replication engine that supports scheduling and bandwidth throttling.
Without Active Directory, you cannot log in to a Windows Server 2003 domain, period. Active Directory stores information about objects and enables administrators or users to easily access information. This information is stored in a datastore (also known as a directory) that provides a logical and hierarchical organization of information.
A forest consists of a database, whereby the database partitions are defined by the domains. This database is made up of many small databases spread across computers. Each of these databases contains security principal objects, such as computers, users, and groups. These objects can grant or deny access to resources in your structure, and must be authenticated by the domain controller for the particular domain in which the object resides.
Group Policy is associated with that domain and does not automatically propagate to other domains in the forest. For the domains and the Group Policy to be associated, they must be explicitly linked, so security policy for a domain user account must be set on a per-domain basis.
A domain is identified by its DNS name, which provides a method for you to locate the domain controller for the given domain. This name indicates the domain’s position within the forest hierarchy.
In creating your DNS hierarchy, you can divide your domains into trees, because a tree is a set of one or more contiguous named domains. (The names are contiguous because the names are different by only one label.)
The site topology is layered on top of the physical network that reflects the underlying network topology. The domain structure sits above the site topology, but below the network layer. Domains contain objects, whereas sites reflect user groups. The domain is mapped to the site by placing a replica of the domain in the site, so the site contains the entire domain. The site topology routes query and replication traffic efficiently, and helps you determine where to place domain controllers within your structure. The site is known as a set of IP subnets; these subnets usually have LAN speed or better. Site links are used in the plan to model the available bandwidth between the sites.
After the user starts his or her computer, the computer communicates with the domain controller of the user’s member domain. The user’s site is then determined by the domain controller, based on the computer’s IP address, which returns the name of the site to the user’s computer.
LDAP consists of the following components, which in some shape or form are the foundations of all modern directories, including Active Directory:
AD uses LDAP as the access protocol, which opens it to everyone and everything. Active Directory also relies on DNS as its locator service, enabling clients to transparently locate domain controllers (Active Directory hosts) by merely connecting to a DNS server and looking up the IP addresses for the closest domain controller.
You can still use the registry to store configuration data, and you would still use the registry on a standalone workstation or server, even a domain controller. Active Directory is not meant to replace the registry. The registry still plays an important role in Windows Server 2003. In fact, even Active Directory uses the registry to store some configuration-related information.
RFC822 is the naming convention most of us are familiar with, by virtue of our using e-mail and surfing the World Wide Web. These names are also known as user principal names (UPN) in the form of somename@somedomain. The UPN is also the login name or user ID to a Windows Server 2003 domain. Windows users can now log in to a Windows Server 2003 network by simply entering their user ID and password, like this: User: email@example.com.
The LDAP and X.500 naming conventions are known scientifically as attributed naming, which consists of the server name holding the directory (which we refer to as the directory host), username, OU, and so on, as shown in the following example:
LDAP names are used to query the Active Directory.
All the replicas of Active Directory are synchronized (which itself is quite an administration feat, as you will soon see). All copies of an organization’s Active Directory system propagate changes to one another, similar to how DNS servers propagate domain records.
The key to the scalability of Active Directory is the domain tree. In Active Directory, a single domain is a complete partition of the directory. Domains are then subdivided or partitioned into organizational units, enabling administrators to model the domain after their physical organization structure or relevant business models. A single domain can start very small and grow to contain tens of millions of objects; thus, objects can be defined at the smallest corporate atomic structure without the fear of overpopulation, as was the case with Windows NT 4.0, and NetWare 3.x and 4.x.
Objects contain attributes or properties—they hold information about resources they represent. Objects that are not container objects, such as user objects, are known as leaf objects, or end node objects. Objects contain attributes. Some are essential to the object’s existence, such as a password for a user object. Some are not essential, such as a middle initial.
The schema is the Magna Carta of Active Directory. When you create an object in Active Directory, you have to also comply with the rules of the schema. In other words, you have to supply all the compulsory attributes required by the objects, or the object cannot be created. The schema governs data types, syntax rules, naming conventions, and more.
In Active Directory, the full pathname to an object is known as the distinguished name (DN) of the object. The name of the final object itself, apart from the path, is known as the relative distinguished name (RDN).
Each section of the DN is an attribute of an object expressed as attribute_type=value. When we talk about the object name itself or the RDN, we refer to the canonical or common name of the object, expressed in LDAP lingo as cn=. If we are talking about a user, the common name takes the format cn=jchang.
Active Directory supports both LDAP v2 and LDAP v3 naming styles, which comply with the Internet’s RFC 1779 and 2247 naming styles. This style takes the following form:
However, Active Directory drops the c=country and replaces o=organization with the dc=domain component, as shown in the following example: cn=jchang,ou=marketing,dc=mcity,dc=us. In dot notation, this would read jchang.marketing.mcity.us.
By complying with the LDAP naming convention, any LDAP client can query Active Directory via an LDAP Uniform Resource Locator (URL) as follows: LDAP://ldapserver.mcity.us/cn=jchang,ou=marketing,dc=mcity,dc=us
Objects in Active Directory are stored and tracked according to an attribute consisting of the object’s globally unique identifier, or GUID (pronounced gwid by some and gooeyID or gooID by others). The attribute is called the objectGUID. The object can thus be moved around and changed, even renamed, but its identity will always remain the same. An object cannot exist in Active Directory without a GUID; it is one of the compulsory attributes that are automatically assigned when the object is created.
Objects are protected in Active Directory via the SAM access control mechanisms, and security is achieved through the functionality of access control lists (ACLs).
When you set up Active Directory for an enterprise, your first exercise will be to create your root domain, or, in Active Directory terms, the root domain object. If this root domain will also be your Internet root domain, you should register it with an Internet domain administration authority (such as Network Solutions, Inc.) as soon as possible. This root domain in fact becomes the first container object you create in your chain of objects that represent the “expanse” of your local network logon domain in Active Directory. Under this domain, you create more container objects that represent the organizational units within your enterprise.
you can have only a single domain parent in Active Directory. It is entirely feasible, and good practice, to create subdomains under the domain root that reflect the subdivision of resources, departments, politically and geographically diverse divisions of an enterprise, acquisitions, resource entities, and more.
Active Directory refers to a domain structure as domain trees. Everything from the bottom of the object path is considered part of the domain tree—leading from the bottom up, all the way to the single domain parent at the top. The domain tree is unique in Active Directory because no two parent domains can be the same.
It is possible to create another parent domain in Active Directory and create objects under it that may appear identical to objects in adjacent domain trees. These collections of domain trees are called forests. Active Directory refers to a single domain tree as a forest of one tree.
You can also set up trust relationships between these trees, and allow users of one tree in the forest to access the resources in another tree. You would find yourself adding trees to your forest, for example, when you acquire another IT department in a corporate takeover or merger, or when migrating objects from one domain to another, or integrating with legacy NT domains.
Active Directory supports directory deep queries by means of a Global Catalog that is created as soon as the first domain root is created. It contains the attributes of all objects in Active Directory that are, by their nature, searchable. The global catalog (GC) contains every object in all domains in the forest, although it can see only a select set of object attributes, enabling fast, efficient fullforest searches. The GC also provides a seamless presentation to end-users.
If you create a single forest, all users can see a single directory in the GC; they are, therefore, oblivious to the structure of the forest. The trust is automatically created for you, and configuration changes need to be applied only once. They flow through all forests.
At least one domain controller in the forest domain must be the GC.
The forest root domain is special; it is the root of the Active Directory namespace. You need at least two forest root domain controllers in the hub site, pointing to each other as primary DNS servers.
Five operation master roles exist in the root domain: the schema master, the domain naming master, the primary domain controller (PDC) emulator, the infrastructure master, and the relative ID (RID) master.
The root domain is usually a small domain, keeping the load to a minimum. On a small domain, you should try to keep all roles on one server so that whenever you take the server down, transferring the roles to a different domain is easy. On a larger network comprising several hub sites that service large centers of the employee population, such as our example Millennium City, you will need to install root domain controllers in each of the central hub sites.
OUs are the smallest scope or unit to which you can assign Group Policy or delegate administration, thereby enabling you to manage resources based on your organizational model and to give administrators the capability to delegate administration on all OUs or a single OU.
Active Directory provides several APIs you can use to access its data for such custom needs:
When a user (human or service) logs into a domain, NT authentication and security management grants the user access to the network and resources it is permitted to use. This is done in the form of ACLs and access tokens. NT also provides the user (login) with an access token, which the user wears as it browses the network. Windows NT domains and Windows 2003 domains both control access using ACLs.
In Active Directory, the SAM ACLs (in the directory) control who has access to objects and the scope of that access. All Windows Server 2003 services are referred to as objects. These objects are either stored in the local Security Account Manager (SAM), which is a registry tree, or Active Directory which is controlled by the ACLs. Each ACL contains permissions information, detailing which user can access the object and the type of access allowed (such as read-only or read/write). ACLs are domain-object-bound; they are not transient entities.
Trust is automatically established between domains that are part of a contiguous namespace (an Active Directory tree).
Backing up your Active Directory on a regular basis is critical. The Backup tool provides several features that keep this process simple. The Backup tool enables you to back up the domain controller while it is still online, causing no user interruption.
Kerberos is based on a system of tickets, which are packets of encrypted data issued by a Key Distribution Center (KDC)—the security officer just mentioned. This ticket is your “passport,” and carries with it a myriad of security information. Each KDC is responsible for a realm, and in Windows 2003 every domain is also a Kerberos realm. In addition, every Active Directory domain controller (DC) is a KDC.
When you log on to Windows, WinLogon and LSA kick in to first authenticate you to the KDC, which provides you with an initial ticket called the Ticket-Granting Ticket (TGT), which is akin to a right-of-way coupon at the fairgrounds, or a passport. Then, when you need to access resources on the network, you present the TGT to the DC and request a ticket for a resource. This resource ticket is known as a Service Ticket (ST). When you need access to a resource, your processing environment presents the ST to the resource. You are then granted access in accordance with the ACL protecting the resource.
In Windows 2003, the default authentication and security protocol between Windows 2003 machines is Kerberos. The NT LAN Manager (NTLM) is a legacy protocol that Microsoft has included in Windows 2003 to support legacy Windows clients and servers.
When a user or machine logs onto a domain, he, she, or it interacts with a collection of functions that make up the Windows Logon service, better known in development circles as WinLogon. WinLogon is now fully integrated with Kerberos, which provides the initial Single Sign-On architecture now part of Windows 2003. After the logon, the user continues to be attached to the security protocol its client software best understands, which could be Kerberos, NTLM, or Secure Sockets Layer/Transport Layer Security. These protocols transparently move the user’s identity around the network.
After a user or device account is authenticated to the domain, it is given permission, through certain default privileges, to network objects. In Windows 2003, these objects are stored in the Active Directory and “point” to the actual network location (in Windows NT, they are stored in the SAM portion of the registry). To gain access to an object, the object has an Access Control List (ACL) associated with it. This access control list is also stored in the directory. The items on the ACL are known as access control entries. You can view the ACL by opening the Security tab on an object’s property sheet.
The property sheet lists the users and groups that have access to the object, and the level of access they have, such as Read, Write, or Execute. ACLs apply only to security principals— that is, user accounts, computer accounts, and security groups (as opposed to distribution groups).
Auditing leaves a trail that you can follow to see what was done or attempted by network objects. If the network object has a username attached to it, your audit trail will then be a history of what was attempted by whom.
Different types of W2003 Servers:
Licensing Mode. You can choose to select licensing on a per-server, per-seat, or per-device basis. If you choose to license per seat, you must enter the number of client access licenses (CALs) purchased. If you are going to provide application services by using the Terminal Services in Application Mode, choose the CAL option (Understanding Client Access Licenses).
More information: You can choose between two licensing modes: per user or device, or per server. With the per server option, you specify the number of concurrent connections for the server or application. When that number of concurrent connections is reached, additional connections are refused. You then can use the Licensing applet to add licenses for the product (assuming that you’ve purchased the licenses in question).
You can also choose per user or device mode (also called per-seat mode), which does not track concurrent connections. Instead, per-seat mode assumes that you’ve purchased a CAL for each computer that will access the server or application.
Terminal Services. You are also asked to choose the operating mode of Terminal Services. Choose Administration mode. There’s no point in choosing Application Server mode until you are ready, and the mode can be changed at any time.
Windows Management Instrumentation (WMI) provides you with a means of monitoring and controlling system components, both locally and remotely.
DNS. Before a DNS domain namespace can be correctly implemented, the Active Directory structure needs to be available, so you must begin with the Active Directory design and support it with the appropriate DNS namespace. Active Directory domains are named by using DNS names. In choosing DNS names to use for your Active Directory domains, start with the registered DNS domain-name suffix that your organization has reserved for use on the Internet and combine this name with something significant in your organization to form full names for your Active Directory domains. Only use characters in your names that are part of the Internet standard character set permitted for use in DNS host naming. Permitted characters are all letters (a-z), numbers (0-9), and the hyphen (-).
Although many system and operating properties still are controlled through the Control Panel, most administrative functions have moved to the Microsoft Management Console (MMC). The MMC runs under Windows 2003 Server, Windows 2000, Windows 9x, and Windows XP. The MMC itself serves as a framework. Within that framework are various administrative tools called consoles. The MMC lets you combine administrative tools to build your own console configuration, which you can store by name on disk. The next time you need to work with it, you run the MMC console from the Start menu or double-click its icon or shortcut.
MMC provides two different modes: user mode and author mode. In user mode, you work with existing consoles. Author mode enables you create new consoles or modify existing ones.
You can open MMC consoles by selecting them from the Administrative Tools folder in the Start menu or by double-clicking their icons in Explorer. You also can start consoles using a command prompt. The format of the MMC command is as follows: MMC path\file.msc /a, where /a means author mode.
In an apparent effort to simplify the Start menu, Microsoft includes only some of these consoles in the Administrative Tools folder. However, you can open any console by double-clicking its file. When you do so, the MMC loads first and then opens the console. You also can open the MMC and add snap-ins to your own consoles. This gives you the ability to create a custom console containing whichever group(s) of snap-ins you use most often or that are targeted for specific administrative tasks.
Although the MMC forms the framework for integrated administrative tools in Windows 2003, the tools themselves are called snap-ins. Each MMC snap-in enables you to perform a specific administrative function or group of functions. The various MMC snap-ins serve the same function as individual administrative tools did in Windows NT. Snap-ins come in two flavors: standalone and extension. Standalone snap-ins usually are called simply snap-ins. Extension snap-ins usually are called extensions. Snap-ins function by themselves and can be added individually to a console. Extensions are associated with a snap-in and are added to a standalone snap-in or other extension on the console tree.
A taskpad is a page on which you can add views of the details pane and shortcuts to various functions inside and outside of a console. These shortcuts can run commands, open folders, open a Web page, execute menu commands, and so on. In essence, taskpads enable you to create a page of organized tasks to help you perform tasks quickly, rather than use the existing menu provided by the snap-in.
Important: Windows Firewall in SP1 by default blocks incoming traffic on port 445. This port is used by many of the administrative tools for remote management.
The Computer Management console provides tools for managing several aspects of a system. Right-click My Computer and choose Manage to open the Computer Management console. You can use Computer Management to manage either the local computer or a remote computer. Right-click the Computer Management node and choose Connect to Another Computer to manage a remote system.
Many of these extensions can be used individually within their own consoles. For example, you can open Services.msc to configure services, rather than use the Services node in Computer Management. Look in systemroot\System32 for available snap-ins (.msc file extension).
A system includes a handful of shares by default, most of which are hidden shares (suffixed with a $ sign):
The Local Users and Groups branch of the Computer Management snap-in enables you to create and manage local user accounts and groups on Windows 2003 standalone and member servers. This branch is disabled on a domain controller because you use the Active Directory Users and Computers snap-in to create user accounts and groups in the Active Directory.
Another behavior you can configure for services is what happens when the service fails. You can configure the service to restart, execute a file, or reboot the computer. In addition, you can configure a fail counter to track how many times the service has failed. You set a service’s recover options through its Recovery property page
Windows 2003, like Windows 2000 Server before it, provides a Configure Your Server Wizard to help you configure the server for specific uses. You’ll find the Configure Your Server Wizard in the Administrative Tools folder.
Windows Server 2003 Service Pack 1 introduces a new tool called the Security Configuration Wizard to help administrators fine-tune security on a server. The wizard configures security settings based on server roles. The wizard prompts for information about the server and its roles, and then stops all services not required to perform those roles, locks down ports as needed, modifies registry settings, and configures settings for IIS and other components to apply the desired level of security.
The Manage Your Server console provides a handy way to access configuration tools for specific server roles, such as Application Server, IIS, file server, and so on. Manage Your Server works in conjunction with the Configure Your Server Wizard.
Tip: You can configure the Start menu to display the Control Panel applets in the menu, enabling you to access individual Control Panel applets through the Start menu without having to open the Control Panel folder. To display the Control Panel applets on the Start menu, rightclick the taskbar and choose Properties. Click the Advanced tab, select Expand Control Panel in the Start Menu Settings group, and then click OK. If you’ve configured the Start menu to expand the Control Panel and want to open the Control Panel folder, click Start, then rightclick Control Panel and click Open.
Forests consist of one or more DCs that share common schemas and GCs. If multiple domains in a forest share the same DNS naming schema, they are referred to as a domain tree. A forest can also be made up of one or more domain trees. The forest root domain is the first domain in the forest.
Trust relationships are automatically created between adjacent domains when a domain is created in a domain tree. In a forest, a trust relationship is automatically created between the forest root domain and the root domain of each domain tree added to the forest. Because these trust relationships are transitive, users and computers can be authenticated between any domains in the domain tree or forest.
Only a separate forest fully secures two domains from each other because the trusts are not transitive, are not bi-directional, and must be explicitly created.
The three components of Windows Server 2003 and Active Directory networks are domain controllers (the directory hosts), global catalogs, and sites. Note that a DC can service only one domain.
The main purposes of the global catalog (GC) are to provide the point of contact and interface for authentication of users into Active Directory domains (it holds a full replica of all user accounts in its custodian domain), and to provide fast intradomain and interdomain searches of Active Directory without actually iterating the trees, or performing what is known in directory service language as deep searches. In other words, the GC is essentially a subset of the domain that, for search purposes, holds only the attributes or property information necessary to find an object belonging in a domain other than the one it directly serves. The GC contains a partial replica of every domain in the forest and a copy of the schema and configuration-naming contexts used in each forest. A GC is located by using DNS.
The GC network carries an overhead separate from the DC network. Remember that they are not integrated; they are separate resources. The GC, in fact, has no understanding of how a domain works, nor does it care.
The concept of a site was introduced in Windows 2000. It did not exist in Windows NT. Sites provide AD with knowledge of the physical network upon which it is functioning. Sites and domains are independent concepts. A site can belong to multiple domains, and a domain can span many sites. Sites are retained as objects in AD—stored in the Configuration Naming Context (CNC).
A site is identified or addressed in Active Directory according to the TCP/IP subnet on which it resides, and it is resolved to that segment via DNS. A site is directly related to a domain as far as intrasite and intersite replication is concerned, but a site is also indirectly related to the other elements in the forest with respect to the other naming contexts such as the GC, the schema, and so on. A site is also a logical container that is totally independent of the domain namespace.
The Knowledge Consistency Checker (KCC) essentially sets up replication paths between the DCs in a site in such a way that at least two replication paths exist from one DC to another, and a DC is never more than three hops away from the origination of the replication. This topology ensures that even if one DC is down, the replication continues to flow to the other DCs.
Active Directory also enables you to define connection objects. These are essentially manually configured points of replication between domain controllers.
Site links connect two or more sites together. You need to do very little work to create site links because Active Directory automatically creates them when you create sites and add DCs to them. Site links are unidirectional, you need to establish them in two directions.
Site link bridges: Breaking Active Directory into sites can reduce replication-related network traffic, but simply dividing Active Directory into sites is not enough. In order for sites to exchange Active Directory information, you must implement site links. These links provide information to Windows Server 2003, telling it which sites should be replicated and how often. When you link more than two sites using the same link transport, you are essentially causing them to be bridged. By forming a linked bridge, sites can communicate directly with each other.
Synchronization vs. replication: Synchronization and replication are not the same thing. Replication is information exchange between heterogeneous directories, whereas synchronization is information exchange between the same or homogeneous directories for the purpose of keeping each replica current.
Without DNS, you are in the dark. You can deploy a million DCs and GCs, but they run deep and silent without the locator service provided by DNS. Not only do the clients need to use DNS to locate network services and DCs, but DCs also need to use DNS to locate other DCs and other servers.
What is a user? In a nutshell, the Windows Server 2003 security subsystem does not differentiate between a human and a device using its resources. All users are viewed as security principals, which at first are trusted. User objects are derived from a single user class in Active Directory, which in turn derives from several parents. Machine accounts are thus derived from the User object. To obtain access to the User object, you need to reference its distinguished name (DN) in program or script code.
The term local user is often used to describe two types of users: users local to machines that log on locally to the workstation service and users who are local to a network or domain. In referring to generic users on the domain or users collectively, referring to these users as domain users or domain members makes more sense.
You would be right to wonder why Microsoft provides us with both groups and organizational units (OUs) to manage. Groups, however, are a throwback to the Windows NT era. Although groups may appear to be a redundant object next to OUs, they are a fact of Windows Server 2003 and are here to stay. They are also extremely powerful management objects. Specifically, you create and use groups to contain the access rights of User objects and other groups within a security boundary. You also use groups to contain User objects that share the same access rights to network objects, such as shares, folders, files, printers, and so on.
Groups versus organizational units: The Group object is a sophisticated management container that can bestow all manner of control over the user accounts and other groups that it contains. It can be used to contain a membership across organizational and multiple-domain boundaries. An organizational unit, on the other hand, belongs to a domain.
Windows Server 2003 ships with tools to manage local logon accounts and Active Directory accounts. These tools are Users and Passwords and Local Users and Groups on standalone machines (including workstations running Windows Server 2003 Professional) and member servers and Active Directory Users and Computers on domain controllers. A user account can be created in any part of the AD.
Local accounts (users) are identical to network accounts in every way, but they are not stored in Active Directory. Local accounts are machine-specific objects. In other words, a local user account can be validated only against a local security database—the SAM, or Security Account Manager. Second, local accounts provide access only to resources within the “boundaries” of the machine “domain” and no further. Local user accounts are restricted to the Access Control List of the local computer. The tools to manage a local machine’s local accounts and groups (although not on a domain controller) can be accessed through the Users and Passwords and Administrative Tools applications in the Control Panel.
A good idea, as soon as it’s feasible, is to rename the Administrator account to hide its purpose and thus its access and security level. (Hiding was not possible on Windows NT but was added to Windows 2000.) If you have security fears, you can audit the activity of the Administrator to determine who or what is using the account and when.
The Guest account does not require a password, and you can grant it certain access and rights to resources on the computer. We believe that the Guest account on any domain should be relocated to an OU with a security and account policy that is appropriate for managing security risks. You can leave the Guest account in the Users folder (which is a domain folder and not an OU), but the security policy governing that account in the Users folder is inherited from the root domain. Therefore, if for any reason the default or root domain policy changes, it affects the Guest account without you being aware of it.
The Windows Group Policy technology (which also includes account and security policy) governs how all accounts can be configured on both standalone servers and in the Active Directory. The order of precedence for security and account policies, from the highest to the lowest, is as follows:
The onus of “good behavior” rests on the shoulders of User and Group objects in Windows Server 2003. These objects have the total trust of the OS on first being installed. They are often referred to as security principals and trustees. Every other object that is not a security principal or that does not exist in AD within a security context is rejected by the security subsystem and thus cannot present for rights and access. The Contact object is a good example of an object that is not a security principal. You may create other nonsecurity objects and register them in Active Directory.
If a user attempts to log on to Windows Server 2003 by way of the AD or the Local Security Authority (LSA), the security system determines whether the user exists and whether the password provided matches the password stored in the relevant database. If the user is authenticated, Windows Server 2003 creates an access token for the user. The process that Windows Server 2003 uses to “follow” the user through the domain is known as access token assignment. In other words, the access token is assigned to the user for the duration of the logon and acts as a security tag that a user wears in “roaming” from computer to computer and from resource to resource. User account information is replicated to all domain controllers in the enterprise, even across slow WAN links.
The security identifier (SID) is a unique value of variable length that is used to identify an account (known as a trustee to the kernel) to the security subsystem. Windows refers to the SID, rather than to the user or group name, in referencing these objects for security purposes. The SID is not the same thing as the object identifier, or OID. SIDs guarantee that the account and all its associated rights and permissions are unique. If you delete an account and then recreate it under the same name, all rights and permissions of the deceased account are gone. This is because the old SID was deleted with the original account. The first part of the SID identifies the domain in which the SID was created. The second part is called the relative ID (RID), which refers to the actual object created (and is thus relative to the domain). Whenever a user logs onto the computer or domain, the SID is retrieved from the database and placed in the user’s access token. From the moment of logon, the SID is used in the access token to identify the user in all security-related actions and interactions.
RunAs enables you to execute applications, access resources, or load an environment, profile, and so on by using the credentials of another user account, without needing to log off from the account that you initially logged onto your computer with.
Note: Whenever you rename an account, you are changing only the name property as you see it in the AD list. This is very different behavior from legacy NT account management, whereby the username and account name were the same thing. Changing the account name does not change the logon name (UPN) or the legacy NetBIOS name.
Windows 2003 groups come in two flavors: security group and distribution group:
Both group types have three scope types, Universal, Global, and Domain:
Microsoft did not intend groups to function as tools of business administration. Enter the organizational unit (OU). We have touched on OUs but we need to discuss them here briefly in the context of managing groups and users. Organizational units are created to provide hierarchical administrative delegation, organizational structuring, and for setting Group Policy.
Groups are used for granting and denying users access to computer and network resources. Global groups also traverse domain boundaries. A group can contain users and Global groups from other domains, both on a single domain tree and across a forest of domains. OUs are valid only on a contiguous domain space in the domain in which they were created.
Administrators do not get access to everyone’s files and folders by virtue of the wide power that they are given in this group. If a file or folder’s permissions do not permit access, Administrator is also locked out. This ensures protection and enables owners or managers of sensitive shares, files, and folders to lock down their resources securely.
Guests: This is the built-in group that contains accounts for casual users or users who do not have accounts on the domain. Users in this group can usually log on without passwords, and they have very limited or controlled use of the system. It is an ideal group for service-based systems. We recommend moving the accounts from this group into a visitor’s OU, which can be further secured with Group Policy.
Everyone: This “group” means everyone that uses the computer and the network. By admitting this object to a share, you implicitly open all doors to the object, even if the user is an account on an alien OS on a far-away planet. We believe that removing the Everyone group from your resource and using the Users group (containing Domain Users) is a better course. Anytime that you get a call to get someone out of an open share, you can simply knock the person out of the Domain Users or Users group.
Rights are granted to users and groups (and don’t forget that includes processes, threads of execution, and so on that operate in the context of a security principal). Permissions belong to the objects that are the essence of the operating system, and are granted by both the file system (over its objects) and by the Active Directory (over its respective objects).The difference is that rights involve the capability to function, while permissions control access.
A good example is the right to backup files and directories, which overrides any permission that denies access to a user. The Backup Operators group needs the capability to read and change (reset the archive bit or overwrite during a restore) the files that it is backing up, no matter what permissions the owner of the objects has.
Group Policy governs change-control policy for many facets of the operating system, including the following:
The change-control tool on Windows Server 2003 is an MMC snap-in called Group Policy Object Editor (GPOE or just GPE). You can open the local GPO by running gpedit.msc from the command line on any Windows Server 2003, Windows 2000 Server, and Professional or Windows XP computer, or you can pull up the MMC snap-in from installed menu items.
Group Policy is applied by creating an object that contains the properties that extend control of the computer and the user’s access to network and machine resources. This object is known as the Group Policy Object, or GPO. The policy is created from various templates stored on the workstation or server.
If an object is a member of a container that is associated (linked) to the GPO, that object falls under the influence of that GPO. If a container is linked to multiple GPOs, the effects of all GPOs on the linked container are merged. Group Policy is not applied directly to an individual security principal (although you can attain such granular control by creating specific OUs). Instead, it is applied to collections of security principals. Security principals gather under one roof on a Windows Server 2003 network in three places: the site, the domain, and the organization unit. GPOs have more than 100 security-related settings and more than 700 registry-based settings.
Unless you deploy Windows 2000 Professional or Windows XP, GP is not pervasive throughout the enterprise. Windows 9x and NT 4.0 workstations are not influenced to the same extent as Windows 2000/XP clients, because client-side extensions that pull down and read policy are not present in these legacy desktop operating systems.
A GPO is divided into two nodes, known as the Computer Configuration and the User Configuration. Each node contains the policies for the respective security principal.
Group Policy Objects also come in two flavors—local GPOs and domain-bound GPOs—and because the local GPO is applied to a computer before the domain GPO, the actual inheritance hierarchy for a computer is local GPO, nonlocal site, domain, and finally OU. Local GPO is first applied to the computer, and then any policy that is to be applied from the DC takes place after the user logs in. Group Policy application is successively applied. In other words, the last policy that is enabled for a setting is applied, so if a local policy is defined and a site policy undefines it, then the site policy setting wins. One part of GP, however, always wins over local policy, and that is the security policy from the domain.
You can create multiple GPOs for a container. The order of control application specifies that policy applied later overwrites policy applied earlier. This is called administrative order, and the order can be rearranged by using the Up and Down buttons on the Group Policy tab of the OU’s Properties dialog box.
There is a catch: the No Override option— if enabled—takes precedence.
Whenever you edit a GPO, any settings that you change are not immediately applied to the container’s possessions, but the change in policy is immediate. The GPO settings are then applied to the object by default every 90 minutes. The refresh time can be changed, however. Although the GP of a parent container can override a child’s GP, if the child’s GP contradicts the parent, then the child prevails.
GP can also be filtered out of the range of security principals residing in security groups. In other words, you can narrowly define which security group of users or computers is influenced by GP, irrespective of the relationships the group has with an OU. This is achieved by setting the discretionary access control list (DACL) permissions on the group. Not only does the GPO take effect on the security principals much faster, but you can also restrict a specific security policy from creating AD links to GPOs.
The number-one rule of change-control policy engagement is this: Change control policy is enforced over the user by way of the computer. In other words, the target of change control is the user’s computer. If a user has no control over her computer, she is no longer in a position to circumvent policy. Although the GPO is divided into two configuration nodes, user and computer, the computer configuration takes precedence.
Resultant Set of Policy (RSoP), which was introduced in Windows XP, goes a long way toward providing the means to both plan GP and troubleshoot problems that arise at workstations that have applied GP. RSoP enables you to obtain a report of all the GP settings that apply to a user and machine. It thus enables you to troubleshoot GP and determine how the RSoP changes the desktop and work environment of a user’s computer.You can also use the command-line utility, GPRESULT, to discover the sum of GP settings affecting a user and her computer.
To display all connections, each with the name of the program that opened the port, and without resolving names, run "netstat -anvb".
A DNS SRV record enables administrators to use several servers for one domain. These records designate where services are located. For example, ftp can be located on one server while another server can host a Web server or Active Directory. A DNS A record simply maps a server name to the IP address.
You can install DNS through the Add or Remove Programs applet in the Control Panel. Open the Add or Remove Programs applet and in the Add or Remove Programs window that appears, click Add/Remove Windows Components. Double-click Networking Services or select the item and click Details. Select Domain Name System (DNS) and click OK. Follow the remaining prompts to complete installation of the software.
The DNS console included with the DNS service enables you to set up a DNS server, create and manage zones, create and manage resource records, and so on. In short, the DNS console is a single point of contact for all DNS management. How the contents of a zone branch appear depends on whether the zone is for a Windows Server 2003 Active Directory domain or simply a DNS domain. If it’s for a Windows Server 2003 domain, you find additional branches for domain-related services and objects, such as Kerberos, LDAP, sites, and more.
Each domain that you host for DNS requires a forward-lookup zone, a zone file, and associated records. You create the zone in the DNS console by using one of the following three options:
After you create a forward-lookup zone, you can begin populating it with resource records. Before doing so, however, first create any required reverse-lookup zones. Creating the reverse-lookup zone(s) before creating the resource records enables DNS to automatically create the PTR records in the reverse-lookup zones for resource records that you create in the forward-lookup zones.
Service Location, or SRV, records are another common resource record type that offers excellent flexibility if a domain contains multiple servers for specific services, such as multiple HTTP servers. SRV records enable you to easily move a service from one host to another, and to designate certain hosts as primary for a given service and others as secondary for that same service.
The NT File System (NTFS) enables you to secure the data within their files and the folders that contain those files while at the same time providing controlled access to authorized users. NTFS does that on the following three security access levels:
The levels of access that you have to the folders and files are called permissions. Administrators, members of administrative groups (Administrator, Domain Administrators, or groups delegated administrative rights), and the owners of objects can assign permissions and control access to these objects, and they can also encrypt the files. Another means of understanding shares or sharepoints is by understanding ownership. Ownership is not a configuration setting or a mere value in the registry or Active Directory; it derives from the security services of the NTFS and the Win32 security system.
Whenever a process creates a file or a folder—objects—the file system assigns that process the rights of ownership and passes it a key. The process created it, so that process owns it . . . and it can do whatever it wants with that object. Only you and the processes that operate within your security context (activated by the validation of your password) can access that folder.
If Windows Server 2003 R2 is installed, the File Server Management console combines several file server-related management tools into a single interface and can generally replace the original File Server Management console (filesvr.msc) included with Windows Server 2003. You’ll find the new console under the Management and Monitoring Tools branch of the Add/Remove Windows Components applet after installing R2 on the server.
If Windows Server 2003 R2 is not installed, the main file-server management tool on Windows Server 2003 is also called the File Server Management console. This console is a more dedicated management facility for file servers than is the Computer Management console introduced in Windows 2000. The easiest way to open the File Server Management console is to execute filesvr.msc from the command line.
Windows Server 2003 users connect to shared resources on the domain by looking them up in Active Directory or mapping them out by using logon scripts.
As you first create a share, the file system automatically gives read access to the Everyone group, unless you have taken steps to prevent that. If the contents of the files are sensitive, remove the Everyone group and assign access only to authorized users or groups.
Establishing shares on remote computers is handled now by the File Server Management console. You can also create shares from Windows Explorer, the command line, and the Manage Your Server console as you set up your server in the file-server role. You can also create shares from the Active Directory Users and Computers console. If your Computer Management console shortcut is missing, simply create a new one by linking to the compmgmt.msc snap-in in the Windows Server 2003 installation folder—usually Windows or Winnt—and in the system32 subfolder.
The default access permission on a share is Full Control. This permission is assigned to the Everyone group, with read access, so if you create such a share and have your Guest account enabled and not governed by any domain policy, then every computer user has access to it. Of course, you are a sensible administrator and are sure to follow our advice and make sure that your network is locked down. Share permissions do not provide protection from local access to a folder or its contents. Therefore, use NTFS permissions to protect data from local access by unauthorized users. Remember that the access level is at the share only; NTFS permissions provide the “second line of defense” to locked-down resources at the object level.
Hiding shares is possible simply by ending the share name with the dollar sign ($). You can still connect to the share if you have access to it, but it does not appear on the browse list (because nothing ending with the dollar sign appears in the browse list). You connect to the share by using the Run dialog box, as explained in the following section, or at the command line by using NET SHARE.
You can hide servers as well: Run the command NET CONFIG SERVER /HIDDEN:YES, and the server stops appearing on the Browse list. You can still contact it if you know the IP address. To put the server name back on the Browse list, change the /HIDDEN: option to NO in the command.
NETLOGON: This share is used for the Net Logon service, which is the mechanism to service logon requests to the server. It is also used for locating logon scripts. This share is not automatically created in Windows Server 2003.
Permissions are the means by which you control access to network objects. After shares, they are the second and third lines of defense in protecting data and network resources. File and folder permissions are controlled by NTFS.
Windows Server 2003 adds to the Encrypting File System (EFS), introduced in Windows 2000. The EFS enables users and administrators to encrypt and protect the file system in situations where the system is subject to unauthorized physical access.
The print routers in Windows 95, 98 (with the latest service packs), NT, 2000, Me, and XP clients can receive the printer driver from the server every time they make a connection. Keep current and available the printer drivers for every make and model of printer you deploy.
Printers can easily be located by browsing the printer servers, as is the case with legacy Windows NT printer servers. You can also publish printers in Active Directory.To publish or list the printer in Active Directory, you don’t have to do anything other than ensure that the server is an active member of a domain. You can hide print shares the same way you hide folders—by appending the dollar sign ($) to the end of the share name.
You can’t decide who accesses the print share. Microsoft has hard-coded the share to be open to everyone. You can restrict access to printers via security permissions (access control). In Windows Server 2003 R2, Microsoft has enabled the print administrator to set down policy and procedures for using printers. This is achieved with a new printing subsystem—Print Services—that is better tuned to the management of printers over wide area networks, as well as printers that reside at branch offices and remote locations. The main tool of Print Services is the Printer Management Console (PMC).
Terminal Services on Windows Server 2003 can operate in two modes: Remote Desktop for Administration (the equivalent of Windows 2000 Terminal Server in Remote Administration mode) and Full Terminal Server (previously known as the Application Server mode).
Remote Desktop for Administration mode does not need to be installed because it is built into all the Windows Server 2003 platforms. For security reasons, however, it is disabled by default. To enable it, launch the System applet in the Control Panel; on the Remote tab of the System dialog box that appears, select the Allow Users to Connect Remotely to this Computer checkbox. You also need to specify which accounts can use Remote Desktop.
The Terminal Services Manager can be used to manage multiple Windows Server 2003 servers running Terminal Services.
The Terminal Services Configuration enables you to manage connection protocols and settings on a local server.
The Terminal Server Licensing program is used specifically to control licensing settings.
In addition, numerous aspects of Terminal Server management can be handled by using Terminal Services Group Policies, Active Directory Users and Computers, the Terminal Server Extensions to Local Users and Groups MMC snap-in, several command-line utilities, and the Terminal Services WMI Provider.
Change user /install. Used prior to installing applications on a Windows Server 2003 server running Full Terminal Server. This utility changes the way that configuration files and registry entries are handled during the installation, which is critical for enabling shared access to the application. The alternative is to install a program through the Add or Remove Programs Control Panel applet.
Change user /execute. Switches to the default execute mode. Run this command after installation of an application is completed.