Securing and Troubleshooting Authentication

Once you have configured user objects, and users are authenticating against those accounts, you expose yourself to two additional challenges: security vulnerabilities, which if unaddressed could compromise the integrity of your enterprise network; and social engineering challenges, as you work to make the network and authentication in general, friendly and reliable for users. Unfortunately, these two dynamics are at odds with each other—the more secure a network, the less usable it becomes. In this topic, we will address issues related to user authentication. You will learn the impact of domain account policies, including password policies and account lockout policies. You will also learn how to configure auditing for logon-related events, and to perform various authentication-related tasks on user objects.

Securing Authentication with Policy

Active Directory on Windows Server 2003 supports security policies to strengthen pass-words and their use within an enterprise. Of course, you must design a password policy that is sufficiently daunting to attackers while being sufficiently convenient for users, so that they do not forget passwords (resulting in increased calls to the help desk) or, worse, write down their passwords.

A system running Windows Server 2003 as a member server maintains a policy related to its local user accounts. The local security policy can be managed using the appropriately named snap-in: Local Security Policy.

You will more often be concerned with the policy that affects domain user objects. Domain account policy is managed by the Default Domain Policy. To examine and modify this policy, open Active Directory Users and Computers. Select the domain node and choose Properties from the Action menu. Click the Group Policy tab. The GPO listed as the first, or top object link is the policy object that will drive the domain account policies. It is typically, and in best practice, the Default Domain Policy. Select that policy and click Edit. The Group Policy Object Editor console opens, focused on the Default Domain policy. Navigate to Computer Configuration, Windows Settings, Security Settings, Account Policies.

Password Policy

The domain password policies enable you to protect your network against password compromise by enforcing best-practice password management techniques. The policies are described in below Table

Enforce Password History: When this policy is enabled, Active Directory maintains a list of recently used passwords, and will not allow a user to create a password that matches a password in that history. The result is that a user, when prompted to change his or her password, cannot use the same password again, and therefore cannot circumvent the password lifetime. The policy is enabled by default, with the maximum value of 24. Many IT organizations use a value of 6 to 12.

Maximum Password Age: This policy determines when users will be forced to change their passwords. Passwords that are unchanged or infrequently changed are more vulnerable to being cracked and utilized by attackers to impersonate a valid account. The default value is 42days. IT organizations typically enforce password changes every 30 to 90 days.

Minimum Password Age: When users are required to change their passwords—even when a password history is enforced—they can simply change their passwords several times in a row to circumvent password requirements and return to their original passwords. The Minimum Password Age policy prevents this possibility by requiring that a specified number of days must pass between password changes. Of course, a password can be reset at any time in Active Directory by an administrator or support person with sufficient permissions. But the user cannot change their password more than once during the time period specified by this setting.

Minimum Password Length: This policy specifies the minimum number of characters required in a password. The default in Windows Server 2003 is seven

Passwords Must Meet Complexity Requirements: This policy enforces rules, or filters, on new passwords. The default password filter in Windows Server 2003 (passfilt.dll) requires that a password:

* Is not based on the user’s account name.

* Is at least six characters long.

* Contains characters from three of the following four character types:

1. Uppercase alphabet characters (A…Z)

2. Lowercase alphabet characters (a…z)

3. Arabic numerals (0…9)

4. Non alphanumeric characters (for example, !$#,%)

Windows Server 2003 enables this policy, by default.


Account Lockout Policy

Account lockout refers, in its broadest sense, to the concept that after several failed logon attempts by a single user, the system should assume that an attacker is attempting to compromise the account by discovering its password and, in defense, should lock the account so no further logons may be attempted. Domain account lockout policies determine the limitations for invalid logons, expressed in a number of invalid logons in a period of time, and the requirements for an account to become unlocked, whether by simply waiting or contacting an administrator. Below Table summarizes Account Lockout policies.

Account Lockout Threshold: This policy configures the number of invalid logon attempts that will trigger account lockout. The value can be in the range of 0 to 999. A value that is too low (as few as three, for example) may cause lockouts due to normal, human error at logon. A value of 0 will result in accounts never being locked out.
The lockout counter is not affected by logons to locked workstations.

Account Lockout Duration: This policy determines the period of time that must pass after a lockout
before Active Directory will automatically unlock a user’s account. The policy is not set by default, as it is useful only in conjunction with the Account Lockout Threshold policy. Although the policy accepts values ranging from 0 to 99999 minutes, or about 10 weeks, a low setting (5 to 15 minutes) is sufficient to reduce attacks significantly without unreason-ably affecting legitimate users who are mistakenly locked out. A value of 0 will require the user to contact appropriate administrators to unlock the account manually.

Reset Account Lockout Counter After: This setting specifies the time that must pass after an invalid logon attempt before the counter resets to zero. The range is 1 to 99999 minutes, and must be less than or equal to the account lockout duration.


Auditing Authentication

If you are concerned that attacks may be taking place to discover user passwords, or to troubleshoot authentication problems, you can configure an auditing policy that will create entries in the Security log that may prove illuminating.

Audit Policies

The following policies are located in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy node of Group Policy Object Editor (or the Local Security Policy snap-in). You can configure auditing for successful or failed events.

*Audit Account Logon Events This policy audits each instance of user logon that involves domain controller authentication. For domain controllers, this policy is defined in the Default Domain Controllers GPO. Note, first, that this policy will create a Security log entry on a domain controller each time a user logs on inter-actively or over the network using a domain account. Second, remember that to evaluate fully the results of the auditing, you must examine the Security logs on all domain controllers, because user authentication is distributed among each domain controller in a site or domain.

*Audit Account Management Configures auditing of activities including the creation, deletion, or modification of user, group, or computer accounts. Password resets are also logged when account management auditing is enabled.

*Audit Logon Events Logon events include logon and logoff, interactively or through network connection. If you have enabled Audit Account Logon Events policy for successes on a domain controller, workstation logons will not generate logon audits. Only interactive and network logons to the domain controller itself generate logon events. Account logon events are generated on the local computer for local accounts and on the domain controller for network accounts. Logon events are generated wherever the logon occurs.

Security Event Log

Once you have configured auditing, the security logs will begin to fill with event messages. You can view these messages by selecting Security from the Event Viewer snap-in, and then double-clicking the event.

Administering User Authentication

When users forget their passwords, are transferred or terminated, you will have to manage their user objects appropriately. The most common administrative tasks related to user account security are unlocking an account, resetting a password, disabling, enabling, renaming, and deleting user objects.

Unlocking a User Account

The account lockout policy requires that when a user has exceeded the limit for invalid logon attempts, the account is locked and no further logons can be attempted for a specified period of time, or until an administrator has unlocked the account.

To unlock a user, select the user object and, from the Action menu, choose Properties. Click the Account tab and clear the check box: Account Is Locked Out.

Resetting User Passwords

If a user forgets his or her password, you must reset the password. You do not need to know the user’s old password to do so. Simply select the user object and, from the Action menu, choose the Reset Password command. Enter the new password twice to confirm the change, and as a security best practice, select the User Must Change Pass-word At Next Logon option.

Disabling, Enabling, Renaming, and Deleting User Objects

Personnel changes may require you to disable, enable, or rename a user object. The process for doing so is similar for each action. Select the user and, from the Action menu, choose the appropriate command, as follows:

*Disabling And Enabling A User When a user does not require access to the network for an extended period of time, you should disable the account. Re-enable the account when the user needs to log on once again. Note that the only one of the commands to Disable or Enable will appear on the Action menu depending on the current status of the object.

*Deleting A User When a user is no longer part of your organization, and there will not soon be a replacement, delete the user object. Remember that by deleting a user, you lose its group memberships and, by deleting the SID, its rights and per-missions. If you recreate a user object with the same name, it will have a different SID, and you will have to reassign rights, permissions, and group memberships.

*Renaming A User You will rename a user if a user changes their name, for example through marriage, or in the event that a user is no longer part of your organization, but you are replacing that user and you want to maintain the rights, permissions, group memberships, and most of the user properties of the previous user.

Managing User Profiles

You probably wouldn’t read this Blog if you weren’t supporting users, and you know that there are elements of the user’s system that cause the user pain when they are not present. For example, if a user logs on and does not have access to his or her Internet Explorer Favorites, or must reconfigure his or her custom dictionary, or does not see familiar shortcuts or documents on the desktop, the user’s productivity takes an instant plunge, and the help desk gets a call. Each of these examples relate to components of the user profile. Profiles can be configured to enhance their availability, security, and reliability. In this Topic, you will learn how to manage local, roaming, group, and mandatory profiles.

User Profiles

A user profile is a collection of folders and data files that contain the elements of your desktop environment that make it uniquely yours. Settings include:

*Shortcuts in your Start menu, on your desktop, and in your Quick Launch bar

*Documents on your desktop and, unless redirection is configured, in your My Documents folder

*Internet Explorer favorites and cookies

*Certificates (if implemented)

*Application specific files, such as the Microsoft Office custom user dictionary, user templates, and auto complete list

*My Network Places

*Desktop display settings, such as appearance, wallpaper, and screensaver

These important elements are specific to each user. It is desirable that they are consistent between logons, available should the user need to log on to another system, and resilient in the event that the user’s system fails and must be reinstalled.

Local User Profiles

By default, user profiles are stored locally on the system in the %Systemdrive% \Documents and Settings\%Username% folder. They operate in the following manner:

*When a user logs on to a system for the first time, the system creates a profile for the user by copying the Default User profile. The new profile folder is named based on the logon name specified in the user’s initial logon.

*All changes made to the user’s desktop and software environment are stored in the local user profile. Each user has their individual profiles, so settings are user-specific.

*The user environment is extended by the All Users profile, which can include shortcuts in the desktop or start menu, network places, and even application data. Elements of the All Users profile are combined with the user’s profile to create the user environment. By default, only users of the Administrators group can modify the All Users profile.

*The profile is truly local. If a user logs on to another system, the documents and settings that are part of their profile do not follow the user. Instead, the new system behaves as outlined here, generating a new local profile for the user if it is the user’s first time logging on to that system.

Roaming User Profiles

If users work at more than one computer, you can configure roaming user profiles (RUPs) to ensure that their documents and settings are consistent no matter where they log on. RUPs store the profile on a server, which also means that the profiles can be backed up, scanned for viruses, and controlled centrally. Even in environments where users do not roam, RUPs provide resiliency for the important information stored in the profile. If a user’s system fails and must be reinstalled, an RUP will ensure that the user’s environment is identical on the new system to the one on the previous system.

To configure an RUP, create a shared folder on a server. Ideally, the server should be a file server that is frequently backed up.

On the Profile tab of the user’s Properties dialog box, type the Profile Path in the format: \\server \share\%Username%. The %Username variable will automatically be replaced with the user’s logon name.

It’s that simple. The next time the user logs on, the system will identify the roaming profile location.

When the user logs off, the sytem will upload the profile to the profile server. The user can now log on to that system or any other system in the domain, and the documents and settings that are part of the RUP will be applied.

When a user with an RUP logs on to a new system for the first time, the system does not copy its Default User profile. Instead, it downloads the RUP from the network location. When a user logs off, or when a user logs on to a system on which they’ve worked before, the system copies only files that have changed.

Creating a Preconfigured User Profile

You can create a customized user profile to provide a planned, preconfigured desktop and software environment. This is helpful to achieve the following:

*Provide a productive work environment with easy access to needed network resources and applications

*Remove access to unnecessary resources and applications

*Simplify help desk troubleshooting by enforcing a more straightforward and consistent desktop

No special tools are required to create a preconfigured user profile. Simply log on to a system and modify the desktop and software settings appropriately. It’s a good idea to do this as an account other than your actual user account so that you don’t modify your own profile unnecessarily.

Once you’ve created the profile, log on to the system with administrative credentials. Open System from Control Panel, click the Advanced tab, and then click Settings in the User Profiles frame. Select the profile you created, and then click Copy To. Type the Universal Naming Convention (UNC) path to the profile in the format: \\server\share\username. In the Permitted To Use section, click Change to select the user for whom you’ve configured the profile. This sets the ACL on the profile folder to allow access to that user. Below Figure shows an example. Click OK and the pro-file is copied to the network location.

Finally, open the properties of the user object and, on the Profile tab, enter the same UNC Profile Path field. The next time that user logs on to a domain computer, that profile will be downloaded and will determine his or her user environment.







Creating a Preconfigured Group Profile

Roaming profiles enable you to create a standard desktop environment for multiple users with similar job responsibilities. The process is similar to creating a preconfigured user profile except that the resulting profile is made available to multiple users.

Create a profile using the steps outlined above. When copying the profile to the server, use a path such as: \\server\share\group profile name.You must grant access to all users who will utilize the profile, so, in the Permitted To Use frame, click Change and select a group that includes all the users, or the BUILTIN\USERS group, which includes all domain users. The only users to whom the profile will actually apply are those for which you configure the user object’s profile path.

After copying the profile to the network, you must configure the profile path for the users to whom the profile will apply. Windows Server 2003 simplifies this task, in that you can multiselect users and change the profile path for all users simultaneously. Type the same UNC that you used to copy the profile to the network, for example, \\server\share\group profile name.

Finally, because more than one user will be accessing a group profile, you must make a group profile mandatory, as described in the following section.

Configuring a Mandatory Profile

A mandatory profile does not allow users to modify the profile’s environment. More specifically, a mandatory profile does not maintain changes between sessions. There-fore, although a user can make changes, the next time the user logs on, the desktop will look the same as the last time he or she logged on. Changes do not persist.

Mandatory profiles can be helpful in situations in which you want to lock down the desktop. They are, in a practical sense, critical when you implement group profiles because you obviously don’t want the changes one user makes to affect the environ¬ments of other users.

To configure a profile as mandatory, simply rename a file in the root folder of the pro-file. Interestingly, mandatory profiles are not configured through the application of per-missions. The file you need to rename is Ntuser.dat. It is a hidden file, so you must ensure that you have specified to “Show hidden files and folders” in the Folder Options program in Control Panel, or use attrib from the command-line to remove the Hidden attribute. You may also need to configure Windows Explorer to display file extensions.

Locate the Ntuser.dat file in the profile you wish to make mandatory. Rename the file to Ntuser.man. The profile, whether romaing or local is now mandatory

Creating Multiple User Objects

Occasionally, situations emerge that require you to create multiple user objects quickly, such as a new class of incoming students at a Institute or a group of new hires at an organization. In these situations you must know how to facilitate or automate user object creation effectively so that you do not approach the task on an account-by-account basis. In topic Creating and Managing User Objects, you learned how to create and manage user objects with Active Directory Users and Computers. This topic will extend those concepts, skills, and tools to include user object creation through template objects, imported objects, and command-line scripting of objects.


Creating and Utilizing User Object Templates

It is common for objects to share similar properties. For example, all sales representatives may belong to the same security groups, are allowed to log on to the network during the same hours, and have home folders and roaming profiles on the same server. In such cases, it is helpful when creating a user object for that object to be pre-populated with common properties. This can be accomplished by creating a generic user object—often called a template—and then copying that object to create new users.

To generate a user template, create a user and populate its properties. Put the user into appropriate groups.

To create a user based on the template, select the template and choose Copy from the Action menu. You will be prompted for properties similar to those when you created a new user: first and last name, initials, logon names, password, and account options. When the object is created, you will find that properties are copied from the template based on the following property-page-based description:

*General: No properties copied

*Address: All properties except Street address are copied

*Account: All properties are copied, except for logon names, which you are prompted to enter when copying the template

*Profile: All properties are copied, and the profile and home-folder paths are modified to reflect the new user’s logon name

*Telephones: No properties are copied

*Organization: All properties are copied, except for Title

*Member Of: All properties are copied

* Dial-in, Environment, Sessions, Remote Control, Terminal Services Profile, COM+: No properties are copied

Importing User Objects Using CSVDE

CSVDE is a command-line utility that allows you to import or export objects in Active Directory from (or to) a comma-delimited text file (also known as a comma-separated value text file), which is, of course, a common format easily read in Notepad and Microsoft Excel. The command is a powerful way to generate objects quickly. The command’s basic syntax is

csvde [-i] [-f FileName] [-k]

-i: Specifies import mode. If not specified, the default mode is export.

-f: FileName: Identifies the import file name.

-k: Ignores errors including “object already exists,” “constraint violation,” and “attribute or value already exists” during the import operation and continues processing.

The import file itself is a comma-delimited text file (*.csv or *.txt), in which the first line is a list of Lightweight Directory Access Protocol (LDAP) attribute names for the attributes imported, followed by one line for each object. Each object must contain exactly the attributes listed on the first line. A sample file follows:

DN,objectClass,sAMAccountName,sn,givenName,userPrincipalName

"CN=Prashant Pandey,OU=Employees,DC=mcseweb,DC=com", user,ppandey,pandey,prashant,prashant.pandey@mcseweb.com

This file, when imported, would create a user object in the Employees OU called Scott Bishop. The logon names, first, and last name are configured by the file. The object will be disabled initially. Once you have reset the password, you can enable the object.

Utilizing Active Directory Command-Line Tools

Windows Server 2003 supports a number of powerful command-line tools to facilitate the management of Active Directory. The following is a list, and brief description, of each tool:

* DSADD Adds objects to the directory.

* DSGET Displays (“gets”) properties of objects in the directory.

* DSMOD Modifies select attributes of an existing object in the directory.

* DSMOVE Moves an object from its current container to a new location.

* DSRM Removes an object, the complete subtree under an object, or both.

*DSQUERY Queries Active Directory for objects that match a specified search criteria. This command is often used to create a list of objects, which are then piped to the other command-line tools for management or modification.

These tools use one or more of the following components in their command-line switches:

*Target object type: One of a predefined set of values that correlate with an object class in Active Directory. Common examples are: computer, user, OU, group, and server (meaning domain controller).

*Target object identity: The distinguished name (DN) of the object against which the command is running. The DN of an object is an attribute of each object that represents the object’s name and location within an Active Directory forest. For example, you created a user object with the distinguished name: CN=Manu, OU=Employees, DC=mcseweb, DC=com.

*Server: You can specify the domain controller against which you want to run the command.

*User: You can specify a user name and password with which to run the command. This is useful if you are logged in with non-administrative credentials and wish to launch the command with elevated credentials.

In addition, switches and parameters are case-insensitive, and can be prefixed with either a dash (“-”) or a slash (“/”).

DSQUERY

The DSQUERY command queries Active Directory for objects that match a specific criteria set. The command’s basic syntax is:

dsquery object_type [{StartNode forestroot domainroot}] [-o {dn rdn samid}] [-scope {subtree onelevel
base}] [-name Name] [-desc Description] [-upn UPN] [-samid SAMName] [-inactive NumberOfWeeks] [-stalepwd NumberOfDays] [-disabled] [{-s Server -d Domain}] [-u UserName] [-p {Password *}]

The basic parameters are summarized in below table:

Parameters for the DSQUERY Command


Query scope

object_type: Required. The object type represents the object class(es) which will be searched. The object type can include computer, contact, group, OU, server, user, or the wildcard “*” to represent any object class. This lesson will focus on the command’s use in querying for the user object type.

{StartNode forestroot domainroot}: Optional. Specifies the node from which the search begins. You can specify the forest root (forestroot), domain root (domainroot), or a node’s dis-tinguished name (StartNode). If forestroot is specified, the search is performed using the global catalog. The default value is domainroot.

-scope {subtree onelevel base}: Specifies the scope of the search. A value of subtree indicates that the scope is a subtree rooted at start node. A value of onelevel indicates the immediate children of start node only. A value of base indicates the single object represented by start node. If forestroot is specified as StartNode, subtree is the only valid scope. By default, the subtree search scope is used.

How to display the result set

-o {dn, rdn, samid}: Specifies the format in which the list of entries found by the search will be outputted or displayed. A dn value displays the distinguished name of each entry. A rdn value displays the relative distinguished name of each entry. A samid value displays the Security Accounts Manager (SAM) account name of each entry. By default, the dn format is used.

Query criteria

-name Name: Searches for users whose name attributes (value of CN attribute) matches Name. You can use wildcards. For example, “jo*” or “*hn” or “j*hn”.

-desc Description: Searches for users whose description attribute matches Description. You can use wildcards.

-upn UPN: Searches for users whose UPN attribute matches UPN.

-samid SAMName: Searches for users whose SAM account name matches SAMName. You can use wildcards.

-inactive NumberOfWeeks: Searches for all users that have been inactive (stale) for the specified number of weeks.

-stalepwd NumberOfDays: Searches for all users who have not changed their passwords for the specified number of days.

-disabled: Searches for all users whose accounts are disabled.

Domain controller and credentials used for the command

{-s Server -d Domain}: Connects to a specified remote server or domain.

-u UserName: Specifies the user name with which the user logs on to a remote server. By default, -u uses the user name with which the user logged on. You can use any of the following formats to specify a user name

*user name (for example, rocky)

*domain\user name (for example, widgets\ rocky)

*UPN (for example, rocky @widgets.microsoft.com)

-p {Password *} Specifies to use either a password or a * to log on to a remote server. If you type *, you are prompted for a password.

DSADD

The DSADD command enables you to create objects in Active Directory. When creating a user, utilize the DSADD USER command. DSADD parameters allow you to con-figure specific properties of an object. The parameters are self-explanatory, however the Windows Server 2003 Help And Support Center provides thorough descriptions of the DSADD command’s parameters if you desire more explanation.

dsadd user UserDN…

The UserDN… parameter is one or more distinguished names for the new user object(s). If a DN includes a space, surround the entire DN with quotation marks. The UserDN… parameter can be entered one of the following ways:

*By piping a list of DNs from another command, such as DSQUERY.

*By typing each DN on the command line, separated by spaces.

*By leaving the DN parameter empty, at which point you can type the DNs, one at a time, at the keyboard console of the command prompt. Press ENTER after each DN. Press CTRL+Z and ENTER after the last DN.

The DSADD USER command can take the following optional parameters after the DN parameter:

*-samid SAMName

*-upn UPN

*-fn FirstName

*-mi Initial

*-ln LastName

*-display DisplayName

*-empid EmployeeID

*-pwd {Password *} where * will prompt you for a password

*-desc Description

*-memberof GroupDN;...

*-office Office

*-tel PhoneNumber

*-email Email

*-hometel HomePhoneNumber

*-pager PagerNumber

*-mobile CellPhoneNumber

*-fax FaxNumber

*-iptel IPPhoneNumber

*-webpg WebPage

*-title Title

*-dept Department

*-company Company

*-mgr ManagerDN

*-hmdir HomeDirectory

*-hmdrv DriveLetter:

*-profile ProfilePath

*-loscr ScriptPath

*-mustchpwd {yes no}

*-canchpwd {yes no}

*-reversiblepwd {yes no}

*-pwdneverexpires {yes no}

*-acctexpires NumberOfDays

*-disabled {yes no}

As with DSQUERY, you can add -s, -u, and -p parameters to specify the domain controller against which DSADD will run, and the user name and password—the credentials—that will be used to execute the command.

*{-s Server -d Domain}

*-u UserName

*-p {Password *}

The special token $username$ (case-insensitive) may replace the SAM account name in the value of the -email, -hmdir, -profile, and -webpg parameters. For example, if a SAM account name is “mac,” the -hmdir parameter can be written in either of the following formats:

*-hmdir\users\ mac \home

*-hmdir\users\$username$\home

DSMOD

The DSMOD command modifies the properties of one or more existing objects.

dsmod user UserDN ... parameters

The command handles the UserDN… parameter exactly as the DSADD command, and takes the same parameters. Of course now, instead of adding an object with properties, you are modifying an existing object. Note that the exceptions are that you cannot modify the SAMName (-samid parameter) or group membership (-memberof parameter) of a user object using the DSMOD USER command. You can use the DSMOD GROUP command, discussed in Topic, “Group Accounts,” to change group membership from a command-line utility.

The DSMOD command also takes the -c parameter. This parameter puts DSMOD into continuous operation mode, in which it reports errors but continues to modify the objects. Without the -c parameter, DSMOD will stop operation at the first error.

DSGET

The DSGET command gets, and outputs, selected properties of one or more existing objects.

dsget user UserDN ... parameters

The command handles the UserDN… parameter exactly as the DSADD command does, and takes the same parameters except that DSGET takes only the parameter and not an associated value. For example, DSGET takes the -samid parameter, not the -samid SAMName parameter and value. The reason for this is clear: You are displaying, not adding or modifying, a property. In addition, DSGET does not support the password parameter because it cannot display passwords. DSGET adds the -dn and -sid parameters, which display the user object’s distinguished name and SID, respectively.

DSMOVE

The DSMOVE command allows you to move or rename an object within a domain. It cannot be used to move objects between domains. Its basic syntax is:

dsmove ObjectDN [-newname NewName] [-newparent ParentDN]

DSMOVE also supports the -s, -u, and -p parameters described in the section regarding DSQUERY.

The object is specified using its distinguished name in the parameter ObjectDN. To rename the object, specify its new common name in the NewName parameter. Specifying the distinguished name of a container in the ParentDN parameter will move the object to that container.

DSRM

DSRM is used to remove an object, its subtree, or both. The basic syntax is:

dsrm ObjectDN ... [-subtree [-exclude]] [-noprompt] [-c]

It supports the -s, -u, and -p parameters described in the section about DSQUERY.

The object is specified by its distinguished name in the ObjectDN parameter. The -subtree switch directs DSRM to remove the objects contents if the object is a container object. The -exclude switch excludes the object itself, and can be used only in conjunction with -subtree. Specifying -subtree and -exclude would, for example, delete an OU and its subtree, but leave the OU intact. By default, without the -subtree or -exclude switches, only the object is deleted.

You will be prompted to confirm the deletion of each object, unless you specify the -noprompt parameter. The -c switch puts DSRM into continuous operation mode, in which errors are reported but the command keeps processing additional objects. With-out the -c switch, processing halts on the first error.

Creating and Managing User Objects

The user account is integrated into the Active Directory user object. The user object includes not just the user’s name, password, and SID, but also contact information, such as telephone numbers and addresses; organizational information including job title, direct reports and manager; group memberships; and configuration such as roam¬ing profile, terminal services, remote access, and remote control settings. This Topic will review and enhance your understanding of user objects in Active Directory.

Creating User Objects with Active Directory Users and Computers

You can create a user object with the Active Directory Users and Computers snap-in. Although user objects can be created in the domain or any of the default containers, it is best to create a user in an organizational unit, so that administrative delegation and Group Policy Objects (GPOs) can be fully leveraged.

To create a user object, select the container in which you want to create the object, click the Action menu, then choose New and choose User. You must be a member of the Enterprise Admins, Domain Admins, or Account Operators groups, or you must have been delegated administrative permissions to create user objects in the container. If you do not have sufficient permissions to create user objects, the New User com¬mand will be unavailable to you.

The New Object–User dialog box appears, as shown in below Figure. The first page of the New Object–User dialog box requests properties related to the user name.

Property Description

First Name: The user’s first name. Not required.

Initials: The middle initials of the user’s name. Not required.

Last Name: The user’s last name. Not required.

Full Name: The user’s full name. If you enter values for the first or last name, the full name property is populated automatically. However, you can easily modify the sug¬gested value. The field is required. The name entered here generates several user object properties, specifically CN (common name), DN (distinguished name), name, and display Name. Because CN must be unique within a container, the name entered here must be unique relative to all other objects in the OU (or other container) in which you create the user object.

User Logon Name: The user principal name (UPN) consists of a logon name and a UPN suffix Which is, by default, the DNS name of the domain in which you create the object. The property is required and the entire UPN, in the format logon¬name@UPN-suffix, must be unique within the Active Directory forest. A sample UPN would be anyone@mcseweb.com. The UPN can be used to log on to any Microsoft Windows system running Windows 2000, Windows XP, or Windows Server 2003.

User Logon Name (Pre-Windows 2000): This logon name is used to log on from down-level clients, such as Microsoft Name (Pre– Windows 95, Windows 98, Windows Millennium Edition (Windows Me), Windows 2000) Windows NT 4, or Windows NT 3.51. This field is required and must be unique within the domain. Once you have entered the values in the first page of the New Object–User dialog box, click Next. The second page of the dialog box, shown in below Figure, allows you to enter the user password and to set account flags.

Once you have entered the values in the first page of the New Object–User dialog box, click Next. The second page of the dialog box, shown in Below Figure, allows you to enter the user password and to set account flags.

Property Description

Password: The password that is used to authenticate the user. For security reasons, you should always assign a password. The password is masked as you type it.

Confirm Password: Confirm the password by typing it a second time to make sure you typed it correctly.

User Must Change Password At Next Logon: Select this check box if you want the user to change the password you have entered the first time he or she logs on. You cannot select this option if you have selected Password Never Expires. Selecting this option will automatically clear the mutually exclusive option User Cannot Change Password.

User Cannot Change Password: Select this check box if you have more than one person using the same domain user account (such as Guest) or to maintain control over user account passwords. This option is commonly used to manage service account pass-words. You cannot select this option if you have selected User Must Change Password At Next Logon.

Password Never Expires: Select this check box if you never want the password to expire. This option will automatically clear the User Must Change Password At Next Logon setting, as they are mutually exclusive. This option is commonly used to manage ser¬vice account passwords.

Account Is Disabled: Select this check box to disable the user account, for example, when creating an object for a newly hired employee who does not yet need access to the network.

Managing User Objects with Active Directory Users And Computers

When creating a user, you are prompted to configure the most common user properties, including logon names and password. However, user objects support numerous additional properties that you can configure at any time using Active Directory Users And Computers. These properties facilitate the administration of, and the searching for, an object.

To configure the properties of a user object, select the object, click the Action menu, and then choose Properties. The user’s Properties dialog box appears, as shown in below Figure. An alternative way to view an object’s properties would be to right-click the object and select Properties from the shortcut menu

The property pages in the Properties dialog box expose properties that fall into several broad categories

Account properties: the Account tab These properties include those that are configured when you create a user object, including logon names, password and account flags.

Personal information: the General, Address, Telephones, and Organization tabs The General tab exposes the name properties that are configured when you create a user object.

User configuration management: the Profile tab Here you can configure the user’s profile path, logon script, and home folder locations.

Group membership: the Member Of tab You can add and remove user groups, and set the user’s primary group.

Terminal services: the Terminal Services Profile, Environment, Remote Control, and Sessions tabs These four tabs allow you to configure and man-age the user’s experience when they are connected to a Terminal Services session.

Remote access: the Dial-in tab Allows you to enable and configure remote access permission for a user.

Applications: the COM+ tab Assigns Active Directory COM+ partition sets to the user. This feature, new to Windows Server 2003, facilitates the management of distributed applications.

Account Properties

Of particular note are the user’s account properties, on the Account tab of the user’s Properties dialog box. An example appears in below Figure

Several of these properties were discussed below. Those properties were configured when creating the user object and can be modified, as can a larger set of account properties, using the Account tab. Several properties are not necessarily self-explanatory, and deserve definition is given below

Property Description

Logon Hours: Click Logon Hours to configure the hours during which a user is allowed to log on to the network.

Log On To: Click Log On To if you want to limit the workstations to which the user can log on. This is called Computer Restrictions in other parts of the user interface. You must have NetBIOS over TCP/IP enabled for this feature to restrict users because it uses the computer name, rather than the Media Access Control (MAC) address of its network card, to restrict logon.

Store Password using reversible encryption:This option, which stores the password in Active Directory without using Active Directory’s powerful, nonreversible encryption hashing algorithm, exists to support applications that require knowledge of the user pass-word. If it is not absolutely required, do not enable this option because it weakens password security significantly. Passwords stored using reversible encryptions are similar to those stored as plaintext.
Macintosh clients using the AppleTalk protocol require knowledge of the user password. If a user logs on using a Macintosh client, you will need to select the option to Store password using reversible encryption.

Smart Card Is Required For Interactive Logon: Smart cards are portable, tamper-resistant hardware devices that store unique identification information for a user. They are attached to, or inserted into, a system and provide an additional, physical identification component to the authentication process.

Account Is Trusted For Delegation: This option enables a service account to impersonate a user to access network resources on behalf of a user. This option is not typically selected, certainly not for a user object representing a human being. It is used more often for service accounts in three-tier (or multi-tier) application infrastructures.

Account Expires: Use the Account Expires controls to specify when an account expires.

Managing Properties on Multiple Accounts Simultaneously

Windows Server 2003 allows you to modify the properties of multiple user accounts simultaneously. You simply select several user objects by holding the CTRL key as you click each user, or using any other multi selection options. Be certain that you select only objects of one class, such as users. Once you have multi selected, on the Action menu, choose Properties.

When you have multi selected user objects, a subset of properties is available for modification.

General tab: Description, Office, Telephone Number, Fax, Web Page, E-mail

Account tab: UPN Suffix, Logon Hours, Computer Restrictions (logon workstations), all Account Options, Account Expires

Address: Street, PO Box, City, State/Province, ZIP/Postal Code, Country/Region

Profile: Profile Path, Logon Script, and Home Folder

Organization: Title, Department, Company, Manager

Moving a User

If a user is transferred within an organization, it is possible that you might need to move his or her user object to reflect a change in the administration or configuration of the object. To move an object in Active Directory Users and Computers, select the object and, from the Action menu, choose Move. Alternatively, you can right-click the object and select Move from the shortcut menu

User Accounts

1. Creating and Managing User Objects
2. Creating Multiple User Objects
3. Managing User Profiles
4. Securing and Troubleshooting Authentication

Using Remote Assistance

Remote Assistance provides a way for users to get the help they need and makes it easier and less costly for corporate help desks to assist their users.
Making the Request for Assistance
In Windows Server 2003 Help, there is a wizard-driven section for Remote Assistance, the first page of which is shown in Below Figure

The wizard-driven connection allows for a request to be sent either through a Microsoft .NET Passport account, through sending a saved file, or through a non-Passport e-mail account, along with allowing you to make a request using Windows Messenger. For a successful request through e-mail, both computers must be using a Messaging Appli¬cation Programming Interface (MAPI)-compliant e-mail client.

To use the Windows Messenger service for your Remote Assistance connection, you must have the assistant’s Windows Messenger user name in your contact list, and make the request from a Windows Messenger client. Windows Messenger will display their status as online or offline. Remote Assistance can only be requested directly when your assistant is online. Remote Assistant requires that both computers are running Windows XP or a product in the Windows Server 2003 family.

After receiving a request for Remote Assistance, the helper (expert) can remotely connect to the computer and view the screen directly to fix the problem. When you initiate a request for help, the Remote Assistance client sends an encrypted ticket based on Extensible Markup Language (XML) to the helper, who is prompted to accept the invitation.

Using Remote Assistance
A user can request assistance from another Windows Messenger user by placing the request through the Help and Support Center application or directly through Windows Messenger. Both applications use the same mechanisms for determining if the expert is online, and then making a request for assistance. Below Figure illustrates making a request for Remote Assistance using Windows Messenger.

The Windows Messenger window opens, and the user selects the expert’s Windows Messenger account. The expert receives the invitation as an Instant Message. When the expert clicks Accept, the Remote Assistance session is initiated. The requesting user confirms the session by clicking Yes.
When the remote connection is established, the Remote Assistance session begins on the expert’s computer. The expert and user can share desktop control, file transfer capabilities, and a chat window through which they work together to solve the user’s problem.

Offering Remote Assistance to a User

Remote Assistance is especially useful if you want to initiate troubleshooting on a user’s computer. To do this, you must enable the Offer Remote Assistance Local Group Policy setting on the target (user’s) local computer:

1. On the user’s computer, click Start, Run, and then type gpedit.msc. The local Group Policy editor appears, enabling you to adjust policies that affect the local machine.

2. Under the Computer Configuration node, expand Administrative Templates, then System, and then click Remote Assistance.

3. Double-click Offer Remote Assistance and then select Enabled.

4. Next, click Show, then specify the individual users that will be allowed to offer assistance by assigning helpers within the context of this policy. These “helper” additions to the list should be in the form of domain\username, and must be a member of the local administrators group on the local computer.

Initializing Remote Assistance

You can now initiate Remote Assistance from your computer, to a users computer, providing that the credentials that you supply match those of a helper defined in the target computer’s local Group Policy:

1. Open the Help And Support Center, click Tools, and then click Help And Support Center Tools. Next click Offer Remote Assistance. Below Figure illustrates the Help And Support Center Tools interface.

2. In the dialog box, type the name or IP address of the target computer, and then click Connect. (If prompted that several users are logged on, choose a user ses¬sion.) Then click Start Remote Assistance.
The user receives a pop-up box showing that the help-desk person is initiating a Remote Assistance session.


3. The user accepts, and Remote Assistance can proceed.




Firewall Constraints to Remote Assistance

Remote Assistance runs on top of Terminal Services technology, which means it must use the same port used by Terminal Services: port 3389. Remote Assistance will not work when outbound traffic from port 3389 is blocked. In addition, there are several other firewall-related concerns, particularly in relation to Network Address Trans¬lation (NAT).

* Remote Assistance supports Universal Plug and Play (UPnP) to Traverse Network Address Translation devices. This is helpful on smaller, home office networks, as Windows XP Internet Connection Sharing (ICS) supports UPnP. However, Windows 2000 ICS does not support UPnP.
* Remote Assistance will detect the Internet IP address and TCP port number on the UPnP NAT device and insert the address into the Remote Assistance encrypted ticket. The Internet IP address and TCP port number will be used to connect through the NAT device by the helper or requester workstation to establish a Remote Assistance session. The Remote Assistance connection request will then be forwarded to the client by the NAT device.

* Remote Assistance will not connect when the requester is behind a non-UPnP NAT device when e-mail is used to send the invitation file. When sending an invitation using Windows Messenger, a non-UPnP NAT device will work if one client is behind a NAT device. If both the helper and requester computers are behind non-UPnP NAT devices, the Remote Assistance connection will fail.

If you are using a software-based personal firewall or NAT in a home environment, you can use Remote Assistance with no special configurations. However, if you are using a hardware-based firewall in a home environment, the same restrictions apply: you must open port 3389 to use Remote Assistance.

Managing Servers with Remote Desktop for Administration

Terminal Services is now an integral, default component of the Windows Server 2003 family, and Remote Desktop has been improved and positioned as an out-of-the-box capability, so that with one click, a Windows Server 2003 computer will allow two concurrent connections for remote administration. By adding the Terminal Server component and configuring appropriate licensing, an administrator can further extend the technologies to allow multiple users to run applications on the server.

Enabling and Configuring Remote Desktop for Administration
The Terminal Services service enables Remote Desktop, Remote Assistance, and Termi¬nal Server for application sharing. The service is installed by default on Windows Server 2003, configured in Remote Desktop for remote administration mode. Remote Desktop mode allows only two concurrent remote connections, and does not include the application sharing components of Terminal Server. Therefore, Remote Desktop operates with very little overhead on the system, and with no additional licensing requirements.
Other components—Terminal Server and the Terminal Server Licensing service—must be added using Add Or Remove Programs. However, all of the administrative tools required to configure and support client connections and to manage Terminal Server are installed by default on every Windows Server 2003 computer. Each of the tools and their functions are described below:


Default Components of Terminal Server and Remote Desktop

Terminal Services Configuration: Setting properties on the Terminal Server, including session, net-work, client desktop, and client remote control settings

Terminal Services Manager: Sending messages to connected Terminal Server clients, disconnect-ing or logging off sessions, and establishing remote control or shad-owing of sessions

Remote Desktop Client Installation Files: Installation of the Windows Server 2003 or Windows XP Remote Desktop Client application. The 32-bit Remote Desktop client soft-ware is installed in %Systemroot%\System32\Clients\Tsclient\Win32 of the Terminal Server

Terminal Services Licensing: Configuration of licenses for client connections to a terminal server. This tool is not applicable for environments which utilize only Remote Desktop for Administration.

To enable Remote Desktop connections on a Windows Server 2003 computer, open the System properties from Control Panel. On the Remote tab, select Allow Users to Connect Remotely to This Computer.

Remote Desktop Connection

Remote Desktop Connection is the client-side software used to connect to a server in the context of either Remote Desktop or Terminal Server modes. There is no functional difference from the client perspective between the two server configurations.
On Windows XP and Windows Server 2003 computers, Remote Desktop Connection is installed by default, though it is not easy to find in its default location in the All Programs\Accessories\Communications program group on the Start menu.
For other platforms, Remote Desktop Connection can be installed from the Windows Server 2003 CD or from the client installation folder (%Systemroot%\System32\Clients \Tsclient\Win32) on any Windows Server 2003 computer. The .msi-based Remote Desktop Connection installation package can be distributed to Windows 2000 systems using Group Policy or SMS.



Configuring the Remote Desktop Client
You can control many aspects of the Remote Desktop connection from both the client and server sides.

Remote Desktop Settings

General: Options for the selection of the computer to which connection should be made, the setting of static log on credentials, and the saving of settings for this connection.

Display : Controls the size of the Remote Desktop client window, color depth, and whether control-bar functions are available in full-screen mode.

Local Resources: Options to bring sound events to your local computer, in addition to standard mouse, keyboard, and screen output. How the Windows key combinations are to be interpreted by the remote computer (for exam¬ple, ALT+TAB), and whether local disk, printer, and serial port connections should be available to the remote session.

Programs: Set the path and target folder for any program you want to start, once the connection is made.

Experience: Categories of display functions can be enabled or disabled based on available bandwith between the remote and local computers. Items include showing desktop background, showing the contents of the win¬dow while dragging, menu and window animation, themes, and whether bitmap caching should be enabled (this transmits only the changes in the screen rather than repainting the entire screen on each refresh period).

Server Settings

Logon Settings: Static credentials can be set for the connection rather than using those provided by the client.

Sessions: Settings for ending a disconnected session, session limits and idle time-out, and reconnection allowance can be made here to override the client settings.

Environment: Overrides the settings from the user’s profile for this connection for start¬ing a program upon connection. Path and target settings set here over-ride those set by the Remote Desktop Connection.

Permissions: Allows for additional permissions to be set on this connection.

Remote Control: Specifies whether remote control of a Remote Desktop Connection session is possible, and if it is, whether the user must grant permission at the initiation of the remote control session. Additional settings can restrict the remote control session to viewing only, or allow full interac¬tivity with the Remote Desktop client session.

Client Settings: Override settings from the client configuration, control color depth, and disable various communication (I/O) ports.
Network Adapters: Specifies which network cards on the server will accept Remote Desktop for Administration connections.

General: Set the encryption level and authentication mechanism for connections to the server.

Terminal Services Troubleshooting
When using Remote Desktop for Administration, you are creating a connection to a server’s console. There are several potential causes of failed connections or problematic sessions:

*Network failures Errors in standard TCP/IP networking can cause a Remote Desktop connection to fail or be interrupted. If DNS is not functioning, a client may not be able to locate the server by name. If routing is not functioning, or the Terminal Services port (by default, port 3389) misconfigured on either the client or the server, the connection will not be established.

*Credentials Users must belong to the Administrators or Remote Desktop Users group to successfully connect to the server using Remote Desktop for Administration.

*Policy Domain controllers will only allow connections via Remote Desktop to administrators. You must configure the domain controller security policy to allow connections for all other remote user connections.

*Too many concurrent connections If sessions have been disconnected with-out being logged off, the server may consider its concurrent connection limit reached even though there are not two human users connected at the time. An administrator might, for example, close a remote session without logging off. If two more administrators attempt to connect to the server, only one will be allowed to connect before the limit of two concurrent connections is reached.

DHCP Interview Questions & Answers

1.What is DHCP?
Dynamic Host Configuration Protocol: assigns IPs to the clients requested dynamically or automatically.

2.Process of DHCP (DORA)?
Discover: The Client discovers DHCP
Offers: The DHCP server offers a group of IPs to the clients to pick any
Request:The client selects an IP and request DHCP to confirm it
Acknowledgement: The DHCP server makes a confirmation by sending an DHCPPACK to the client.

3.What is a Scope?
Range of IP Addresses.

4.What is an IP Lease?
DHCP server clients an IP to the client for a period of 8 days. This offer is called IP Lease.

5.What is the default duration of a lease?
8 Days.

6.What is authentication DHCP server?
Enabling AD Know the availability of DHCP server Useful when we have multiple DHCP Server and you want to you designate one particular DHCP server to be active. Then we should authorize.

7.What is IP Reservation?
Resolving a particular dynamic IP for a particularly system.

8.What is exclusion?
Omitting assigning from the range selected IPs.

9.What is a SUPER SCOPE?
Group of scopes is called as super scope.

10.Purpose of DHCP Relay agent?
DHCP server is available on another N/W and you want another N/W to obtain IPs from the DHCP server. Then the DHCP, RA can forward the request from the clients to the DHCP server to obtain IPs for the clients it acts like a mediator between clients and DHCP.

11.How to given an IP obtained from DHCP?
Start>Run>CMD>IPConfig/Release.

12.How to obtain a new IP from DHCP server?
Start>run>CMD>IPConfig/renew.

13.Switching used with IPCONFIG?
IPCONFIG/ all, Release/ Renew/ FLUSHDNS

14.If the client is unable to contact DCHP server, what happens?
Obtains an IP from APIPA

15.What is APIPA?
Automatic Private IP Addressing, when client machines unable to contact DHCP then APIPA assign an IP to the client. This enables the N/W Availability.

16.What are the IP ranges provided by APIPA?
169.254.0.0 to 169.254.255.255

17.What is WINS?
Windows Internet Naming Services: - useful in windows N/W only. Resolves NETBIOS names to IP addresses and IPs to NetBIOS names

Managing Computers Remotely with the MMC

Setting Up the Snap-In for Remote Use

To connect to and manage another system using the Computer Management console, you must launch the console with an account that has administrative credentials on the remote computer. If your credentials do not have elevated privileges on the target computer, you will be able to load the snap-in, but will not be able to read information from the target computer.



When you’re ready to manage the remote system, you may open an existing console with the snap-in loaded, or configure a new MMC with a snap-in that you configure for remote connection when you build the console. If you configure an existing Computer Management console, for example, follow these steps:




1.Open the Computer Management console by right-clicking My Computer and choosing Manage from the shortcut menu.
2.Right-click Computer Management in the tree pane and choose Connect To Another Computer.
3.In the dialog box shown in Figure 2-4, type the name or IP address of the com¬puter or browse the network for it, and then click OK to connect.













Once connected, you can perform administrative tasks on the remote computer.

The Microsoft Management Console

The MMC is an administrative tool for managing Windows Server 2003. The MMC provides a standardized, common interface for one or more of the applications, called snap-ins, that you use to configure the elements of your environment. These snap-ins are individualized to specific tasks, and can be ordered and grouped within the MMC to your administrative preference.

The administrative tools in Windows Server 2003 are MMC consoles with col¬lections of snap-ins suited to a specific purpose. The Active Directory Users and Com¬puters administrative tool, for example, is specifically designed to administer the security principals (Users, Groups, and Computers) in a domain. The snap-ins within the MMC—not the MMC itself—are the administrative tools that you use.

The MMC

The MMC looks very much like a version of Windows Explorer, only with fewer but-tons. The functional components of an MMC are contained within what are called snap-ins: Menus and a toolbar provide commands for manipulating the parent and child windows, and the console itself (which contains the snap-ins) allows targeted functionality. In addition, an MMC can be saved with and the various options and modes appropriate to the situation.

Navigating the MMC

An empty MMC is shown in Figure 2-1. Note that the console has a name, and that there is a Console Root. It is this Console Root that will contain any snap-ins that you choose to include.

Figure 2-1
















Each console includes a console tree, console menu and toolbars, and the detail pane. The contents of these will vary, depending upon the design and features of the snap-in use. Figure 2-2 shows a populated MMC with two snap-ins loaded, and a child window of the Device Manager snap-in.

Figure 2-2
















Using the MMC Menus and Toolbar

Although each snap-in will add its unique menu and toolbar items, there are several key menus and commands that you will use in many situations that are common to most snap-ins, as shown in Table 2-1.

Menu Commands

File: Create a new console, open an existing console, add or remove snap-ins from a console, set options for saving a console, the recent console file list, and an exit command
Action: Varies by snap-in, but generally includes export, output, configuration, and help features specific to the snap-in
View: Varies by snap-in, but includes a customize option to change general console characteristics
Favorites: Allows for adding and organizing saved consoles
Window: Open a new window, cascade, tile, and switch between open child windows in this console
Help: General help menu for the MMC as well as loaded snap-in help modules

Building a Customized MMC

Each MMC contains a collection of one or more tools called snap-ins. A snap-in extends the MMC by adding specific management capability and functionality. There are two types of snap-ins: stand-alone and extension.
You can combine one or more snap-ins or parts of snap-ins to create customized MMCs, which can then be used to centralize and combine administrative tasks. Although you can use many of the preconfigured consoles for administrative tasks, customized consoles allow for individualization to your needs and standardization within your environment.

Stand-Alone Snap-Ins

Stand-alone snap-ins are provided by the developer of an application. All Administra¬tive Tools for Windows Server 2003, for example, are either single snap-in consoles or preconfigured combinations of snap-ins useful to a particular category of tasks. The Computer Management snap-in, for example, is a collection of individual snap-ins use¬ful to a unit.

Extension Snap-Ins

Extension snap-ins, or extensions, are designed to work with one or more stand-alone snap-ins, based on the functionality of the stand-alone. When you add an extension, Windows Server 2003 places the extension into the appropriate location within the

stand-alone snap-in.
Many snap-ins offer stand-alone functionality and extend the functionality of other snap-ins. For example, the Event Viewer snap-in reads the event logs of computers. If the Computer Management object exists in the console, Event Viewer automatically extends each instance of a Computer Management object and provides the event logs for the computer. Alternatively, the Event Viewer can also operate in stand-alone mode, in which case it does not appear as a node below the Computer Management node.


Console Options

Console options determine how an MMC operates in terms of what nodes in the con-sole tree may be opened, what snap-ins may be added, and what windows may be created.
Author Mode
When you save a console in Author mode, which is the default, you enable full access
to all of the MMC functionality, including:

*Adding or removing snap-ins
*Creating windows
*Creating taskpad views and tasks
*Viewing portions of the console tree
*Changing the options on the console
*Saving the console

User Modes

If you plan to distribute an MMC with specific functions, you can set the desired user mode, then save the console. By default, consoles will be saved in the Administrative Tools folder in the users’ profile. Table 2-2 describes the user modes that are available for saving the MMC.

Type of User Mode Description
Full AccessAllows users to navigate between snap-ins, open windows, and access all portions of the console tree.

Limited Access, Prevents users from opening new windows or accessing a portion of Multiple Windows the console tree, but allows them to view multiple windows in the console.

Limited Access, Single Window
Prevents users from opening new windows or accessing a portion of the console tree, and allows them to view only one window in the console.

Administering Microsoft Windows Server 2003

1.The Microsoft Management Console
2.Managing Computers Remotely with the MMC
3.Managing Servers with Remote Desktop for Administration
4.Using Remote Assistance

Active Directory Overview

Active Directory

Networks, Directory Services, and Domain Controllers

Microsoft Windows networks support two directory service models: the workgroup and the domain. The domain model is by far the more common in organizations imple¬menting Windows Server 2003. The domain model is characterized by a single direc¬tory of enterprise resources—Active Directory—that is trusted by all secure systems that belong to the domain. Those systems can therefore use the security principals (user, group, and computer accounts) in the directory to secure their resources. Active Directory thus acts as an identity store, providing a single trusted list of Who’s Who in the domain.
Active Directory itself is more than just a database, though. It is a collection of support¬ing files including transaction logs and the system volume, or Sysvol, that contains logon scripts and group policy information. It is the services that support and use the database, including Lightweight Directory Access Protocol (LDAP), Kerberos security protocol, replication processes, and the File Replication Service (FRS). The database and its services are installed on one or more domain controllers. A domain controller is a server that has been promoted by running the Active Directory Installation Wizard by running DCPROMO from the command line or, as you will do in Exercise 2, by run¬ning the Configure Your Server Wizard. Once a server has become a domain controller, it hosts a copy, or replica, of Active Directory and changes to the database on any domain controller are replicated to all domain controllers within the domain.

Domains, Trees and Forests

Active Directory cannot exist without at least one domain, and vice versa. A domain is the core administrative unit of the Windows Server 2003 directory service. However, an enterprise may have more than one domain in its Active Directory. Multiple domain models create logical structures called trees when they share contiguous DNS names. For example microsoft.com, micro.com and amazing.com share contiguous DNS namespace, and would therefore be referred to as a tree.
If domains in an Active Directory do not share a common root domain, they create multiple trees. That leads you to the largest structure in an Active Directory: the forest. An Active Directory forest includes all domains within that Active Directory. A forest may contain multiple domains in multiple trees, or just one domain. When more than one domain exists, a component of Active Directory called the Global Catalog becomes important because it provides information about objects that are located in other domains in the forest.

Objects and Organizational Units (OUs)

Enterprise resources are represented in Active Directory as objects, or records in the database. Each object has numerous attributes, or properties, that define it. For exam¬ple, a user object includes the user name and password; a group object includes the group name and a list of its members.
To create an object in Active Directory, open the Active Directory Users And Computers console from the Administrative Tools program group. Expand the domain to reveal its containers and OUs. Right-click a container or OU and select New object_type.
Active Directory is capable of hosting millions of objects, including users, groups, com¬puters, printers, shared folders, sites, site links, Group Policy Objects (GPOs), and even DNS zones and host records. You can imagine that without some kind of structure, accessing and administering the directory would be a nightmare.
Structure is the function of a specific object type called an organizational unit, or OU. OUs are containers within a domain that allow you to group objects that share com¬mon administration or configuration. But they do more than just organize Active Direc¬tory objects. They provide important administrative capabilities, as they provide a point at which administrative functions can be delegated and to which group policies can be linked.

Delegation

Administrative delegation relates to the simple idea that you might want a front-line administrator to be able to change the password for a certain subset of users. Each object in Active Directory (in this case, the user objects) includes an access control list (ACL) that defines permissions for that object, just as files on a disk volume have ACLs that define access for those files. So, for example, a user object’s ACL will define what groups are allowed to reset its password. It would get complicated to assign the front-line administrator permissions to change each individual user’s password, so instead you can put all of those users in a single OU and assign that administrator the reset password permission on the OU. That permission will be inherited by all user objects in the OU, thereby allowing that administrator to modify permissions for all users.
Resetting user passwords is just one example of administrative delegation. There are thousands of combinations of permissions that could be assigned to groups adminis¬tering and supporting Active Directory. OUs allow an enterprise to create an active rep¬resentation of its administrative model, and to specify who can do what to objects in the domain.

Group Policy

OUs are also used to collect objects—computers and users—that are configured similarly. Just about any configuration you can make to a system can be managed centrally through a feature of Active Directory called Group Policy. Group Policy allows you to specify security settings, deploy software, and configure operating system and applica¬tion behavior without ever touching a machine. You simply implement your configu¬ration within a GPO.
GPOs are collections of hundreds of possible configuration settings, from user logon rights and privileges to the software that is allowed to be run on a system. A GPO is linked to a container within Active Directory—typically to an OU, but can also be domains, or even sites—and all the users and computers beneath that container are affected by the settings contained in the GPO.

Installing and Configuring Windows Server 2003

Installing Windows Server 2003

This installation should be performed on a computer compatible with Windows Server 2003. It assumes that the primary hard drive is completely empty. If your disk already has partitions configured, you can modify the installation to match the configuration of your system.

1. Configure the computer’s BIOS or the disk controller BIOS to boot from CD-ROM. If you are not sure how to configure your computer or disk controller to boot from CD-ROM, consult your hardware documentation.
2. Insert the Windows Server 2003 installation CD-ROM into the CD-ROM drive and restart the computer.
3. If the primary disk is not empty, a message appears prompting you to press any key to boot from CD. If you see this message, press any key, after the computer starts, a brief message appears explaining that your system configuration is being inspected, and then the Windows Setup screen appears.
4. If your computer requires special mass storage drivers that are not part of the Windows Server 2003 driver set, press F6 when prompted and provide the appropriate drivers.
5. The system prompts you to press F2 to perform an Automated System Recovery (ASR). Automated System Recovery is a new feature in Windows Server 2003 that replaces the Emergency Repair Disk feature of previous versions of Windows, and is described in Chapter 13. Do not press F2 at this time. Setup will continue.
Notice that the gray status bar at the bottom of the screen indicates that the com¬puter is being inspected and that files are loading. This is required to start a min¬imal version of the operating system.
6. If you are installing an evaluation version of Windows Server 2003, the Setup Noti¬fication screen appears informing you of this. Read the Setup Notification mes¬sage, and then press Enter to continue.
Setup displays the Welcome To Setup screen.
Notice that, in addition to the initial installation of the operating system, you can use Windows Server 2003 Setup to repair a damaged Windows installation.
7. Read the Welcome To Setup message, and then press Enter to continue. Setup dis¬plays the License Agreement screen.
8. Read the license agreement, pressing Page Down to scroll to the bottom of the screen.
9. Press F8 to accept the agreement.
Setup displays the Windows Server 2003 Setup screen, prompting you to select an area of free space or an existing partition on which to install the operating system. This stage of setup provides a way for you to create and delete partitions on your hard disk.
To complete the exercises in this book, you will need to configure a partition large enough to host the operating system installation (recommended minimum size is 3 GB) and unallocated space of at least 1 GB. The following steps assume your disk is at least 4 GB in size and is currently empty. You may make adjustments to accommodate your situation.
10. Press C to create a partition.
11. To create a 3 GB partition type 3072 in the Create Partition Of Size (In MB) box and press Enter.
12. Confirm that your partitioning is similar to that shown in Figure 1-2. Again, the recommendation for the hands-on exercises is a C: partition of at least 3 GB and 1 GB of unpartitioned space.



13. Select C: Partition1 [New (Raw)] and press Enter to install. You are prompted to select a file system for the partition.
14. Verify that the Format The Partition Using The NTFS File System option is selected, and press Enter to continue.
Setup formats the partition with NTFS, examines the hard disk for physical errors that might cause the installation to fail, copies files to the hard disk, and initializes the installation. This process takes several minutes.
Eventually, Setup displays a red status bar that counts down for 15 seconds before the computer restarts and enters the GUI mode of the setup process.
15. After the text mode of setup has completed, the system restarts. Do not, when prompted, press a key to boot to the CD-ROM.
Windows Setup launches and produces a graphical user interface that tracks the progress of installation in the left pane. Collecting Information, Dynamic Update, and Preparing Installation options are selected. Collecting Information was com¬pleted before the GUI appeared, and Dynamic Update is not used when starting from the CD-ROM. The system is now Preparing Installation by copying files to the local disk drive.
16. On the Regional And Language Options page, choose settings that are appropriate for your language and text input requirements, and then click Next.
Setup displays the Personalize Your Software page, prompting you for your name and organization name.
17. In the Name text box, type your name; in the Organization text box, type the name of an organization, and then click Next.
Setup displays the Your Product Key page.
18. Enter the product key included with your Windows Server 2003 installation CD-ROM, and then click Next.
Setup displays the Licensing Modes dialog box, prompting you to select a licens¬ing mode.
19. Verify that the Per Server Number Of Concurrent Connections option is 5, and then click Next.
Setup displays the Computer Name And Administrator Password page.

Notice that Setup uses your organization name to generate a suggested name for the computer. If you didn’t enter an organization name earlier in the installation process, Setup uses your name to generate part of the computer name.
20. In the Computer Name text box, type any name do u want i.e. Server01, Micro etc.
The computer name displays in all capital letters regardless of how it is entered.
21. In the Administrator Password text box and the Confirm Password text box, type a complex password for the Administrator account (one that others cannot easily guess). Remember this password because you will be logging on as Administrator to perform most tasks
If the server has a modem installed, you will be presented with the Modem Dialing Information dialog box.
22. Type your area code, and then click Next. The Date And Time Settings page appears.
23. Type the correct Date & Time and Time Zone settings, and then click Next.
24. On the Networking Settings page, select Typical Settings, and then click Next. The Workgroup Or Computer Domain page appears.
25. Verify that the first option is selected and that the workgroup name is Workgroup, and then click Next.
Setup installs and configures the remaining operating system components. When the installation is complete, the computer restarts automatically and the Welcome To Windows dialog box appears.
26. Press Ctrl+Alt+Delete to initiate logon, and type the password you configured for the Administrator account.
27. Click the balloon that appears in the System tray to initiate activation of Windows Server 2003. Follow the on-screen prompts.

After installing and activating Windows, you can configure the server using a well-thought-out Manage Your Server page, as shown in Figure 1-1 that launches automat¬ically at logon. The page facilitates the installation of specific services, tools, and configurations based on server roles. Click Add Or Remove A Role and the Configure Your Server Wizard appears.



If you select Typical Configuration For A First Server, the Configure Your Server Wizard promotes the server to a domain controller in a new domain, installs Active Directory services, and, if needed, Domain Name Service (DNS), Dynamic Host Configuration Protocol (DHCP), and Routing And Remote Access (RRAS) service.
If you select Custom Configuration, the Configure Your Server Wizard can configure the following roles:
■File Server Provides convenient, centralized access to files and directories for individual users, departments, and entire organizations. Choosing this option allows you to manage user disk space by enabling and configuring disk quota management and to provide improved file system search performance by enabling the Indexing service.
■Print Server Provides centralized and managed access to printing devices by serving shared printers and printer drivers to client computers. Choosing this option starts the Add Printer Wizard to install printers and their associated Windows printer drivers. It also installs Internet Information Services (IIS 6.0) and configures Internet Printing Protocol (IPP) and installs the Web-based printer administration tools.
■Application Server (IIS, ASP.NET) Provides infrastructure components required to support the hosting of Web applications. This role installs and config¬ures IIS 6.0 as well as ASP.NET and COM+.
■Mail Server (POP3, SMTP) Installs POP3 and SMTP so that the server can act as an e-mail server for POP3 clients.
■Terminal Server Provides applications and server resources, such as printers and storage, to multiple users as if those applications and resources were installed on their own computers. Users connect with the Terminal Services or Remote Desktop clients. Unlike Windows 2000, Windows Server 2003 provides Remote Desktop for Administration automatically. Terminal Server roles are required only when hosting applications for users on a terminal server.
■Remote Access/VPN Server Provides multiple-protocol routing and remote access services for dial-in, local area networks (LANs) and wide area networks (WANs). Virtual private network (VPN) connections allow remote sites and users to connect securely to the network using standard Internet connections.
■Domain Controller (Active Directory) Provides directory services to clients in the network. This option configures a domain controller for a new or existing domain and installs DNS. Choosing this option runs the Active Directory Installa¬tion Wizard.
■DNS Server Provides host name resolution by translating host names to IP addresses (forward lookups) and IP addresses to host names (reverse lookups). Choosing this option installs the DNS service, and then starts the Configure A DNS Server Wizard.
■DHCP Server Provides automatic IP addressing services to clients configured to use dynamic IP addressing. Choosing this option installs DHCP services and then starts the New Scope Wizard to define one or more IP address scopes in the network.
■Streaming Media Server Provides Windows Media Services (WMS). WMS enables the server to stream multimedia content over an intranet or the Internet. Content can be stored and delivered on demand or delivered in real time. Choos¬ing this option installs WMS.
■WINS Server Provides computer name resolution by translating NetBIOS names to IP addresses. It is not necessary to install Windows Internet Name Service (WINS) unless you are supporting legacy operating systems, such as Windows 95 or Windows NT. Operating systems such as Windows 2000 and Windows XP do not require WINS, although legacy applications on those platforms may very well require NetBIOS name resolution. Choosing this option installs WINS.