50331B-EnU StudentGuide M04

7/30/2019 50331B-EnU StudentGuide M04

1/38

Module 4: Identify and Resolve Logon

Issues

Table of Contents

Overview .................................................................................................................................................................... 4-1Lesson 1: Authentication Process .............................................................................................................................. 4-2Lesson 2: Machine Accounts ..................................................................................................................................... 4-7Lesson 3: Trust Relationships .................................................................................................................................. 4-11Lesson 4: Network Services ..................................................................................................................................... 4-17Lesson 5: User Account Properties .......................................................................................................................... 4-22Lesson 6: User Profiles ............................................................................................................................................ 4-24Resolve Logon Issues .............................................................................................................................................. 4-28Review Module 4: Identify and Resolve Logon Issues ........... .......... ........... .......... ........... .......... ........... .......... ..... 4-30Labs Module 4: Identify and Resolve Logon Issues .......... .......... ........... .......... .......... ........... .......... ........... .......... 4-32


2/38


3/38


4/38

4-2 Module 4: Identify and Resolve Logon Issues

Lesson 1: Authentication Process

Local Authentication

Domain Authentication

Multi-Factor Authentication

Most users logon to their systems using a user name and password to authenticate to the local computer or the

active directory domain. Although transparent to the user, the process is different for both methods and

understanding the services involved will make it easier for a technician to diagnose problems that might come up.


5/38

Module 4: Identify and Resolve Logon Issues 4-3

Local Authentication

SAM database

Local Policy Settings

No Network Access

If user and group accounts are created on the local machine, verification of user credentials during a logon is done by

checking information in the local Security Accounts Manager (SAM) database. This is so whether the computer is a

part of a domain or not. Local policy settings can be used to create user account policies to make local accounts

more secure.

No network services are needed to support local authentication. Once the SAM database verifies the credentials, the

user is logged on with their user profile. The account will not have access to resources on the network. The user will

need to be authenticated again for each server or resource they connect to.


6/38


Domain Authentication

DNS

DHCP

Domain Controller

Network Access

When a domain user account and password are used to login to a computer, the authentication process takes place

using services on the network. The computer first tries to find a domain controller for the domain to which the user is

connecting. This information is found by using service (SRV) records on the DNS server. The DNS server to which

the computer is pointing must have service records for the respective domain, or it must be able to forward requests

to a DNS server that does. From the list of domain controllers passed to the computer, one is chosen, and the user

credentials are sent to it.

Once the credentials are verified and accepted, an access token with a time-stamp is created and sent back to the

computer. This access token will be used as a key to connect to network resources without having to provide login

credentials again. This access token will also work with other domains that are a part of the active directory forest, or

other domains that have trust relationships with the domain.

Network problems might interfere with domain authentication. Some services to check out if there are problems

include:

DNS: DNS services are used to find domain controllers, so if the server is down, or it has out-of-date

information, the authentication process will be affected.

DHCP: DHCP is needed to have network connectivity, but also because it is often used to point users to

their DNS servers.


7/38


Domain Controllers: Client computers will cache the information about domain controllers it can use, and if

these are not available for later logons, problems might occur. Making sure that local domain controllers are

available and flushing the cache on computers can solve this problem.


8/38


Multifactor Authentication

Smart Card

Fingerprint

Driver Support

Using Smart Card or Fingerprint authentication methods, a network administrator can improve the security of the

logon process in the network. Biometrics and multifactor authentication methods are becoming more popular and are

now simpler to implement using Windows 7.

Special middleware is no longer necessary when using smart card devices from vendors. Drivers can be

downloaded using Windows Updates in the same way it is done for other devices. Smart cards can also be used to

unlock encrypted drives on the system. Consideration should be given to how certificates will be issued if smart card

authentication is chosen. The option to limit an account so that it only uses the smart-card and not the user name

and password, while more secure, should be thought over carefully.


9/38


Lesson 2: Machine Accounts

Computer Authentication

Active Directory Placement

Creating Computer Accounts

Like user accounts, computers also register their information in the Active Directory domain that they are a part of.

They also have passwords assigned to them during this process. The passwords are automatically changed every

30-days by default. This allows computers to also be authenticated when a user is logging on. If the authentication

process for the machine does not work, the user will not be able to logon either.

Because the process is handled without user intervention, normal user activity does not create any problems for

these operations. The passwords do not expire like those on user accounts, so taking the computer off the network

for an extended period of time does not create any issues. The password will be changed when it first contacts a

domain controller after being put back on the network. Problems might develop however, if the machine password is

changed manually or automatically and this change is not synchronized quickly with all domain controllers. Dual boot

systems that use the same computer name might also have issues. Disabling the automatic changing of machine

passwords in group policy can prevent these issues. This causes requests by client computers to change the

machine password to be refused.


10/38


Computer Authentication

Password Assignment

Resetting Password

Disabling Accounts

Computer accounts can be manually disabled and have their passwords reset from Active Directory Users and

Computers. They can be assigned permissions and be added to groups. Applications installed on the computer that

require account delegation might need the account of the user to be reconfigured to allow this. This change might

also have to be made to the computer account as well.


11/38


Active Directory Placement

GPO Settings

OU Placement

Command-line Tools

GPO settings in Active Directory are applied to computers during startup. Machine settings will therefore be applied

before user account settings. If any group policy settings must be applied to certain machines to compliment or

facilitate user logon processes, then the computer account might need to be relocated to facilitate this. Machines are

added to the Computers container by default, but using tools like Active Directory Users and Computers make it easy

to move them to appropriate OUs when necessary. This does not change the machine password. Containers that

are not OUs, like Computers, cannot have GPOs linked to them.


12/38


Creating Computer Accounts

Pre-Staging

Adding During Setup

Scripting

New computer accounts can be created automatically when the machine is joined to a domain, or they can be pre-

staged in Active Directory. Pre-staging the accounts allows them to be created in the correct OUs instead of

automatically putting them in the Computers container and then moving them. The default computers container can

be changed with the redircmp.exe command by the domain administrator. For large deployments, scripting strategies

that use dsadd.exe or csvde.exe or ldifde.exe can be used to import many computer accounts and locate them in

appropriate OUs.

When older machines are replaced but the same computer account names are used, one possible strategy is to

replace the old accounts by deleting them from Active Directory and then create new ones. The existing accounts

can also be re-used, but the old system must be off the network before making this change.


13/38


Lesson 3: Trust Relationships

Transitive Trusts

Shortcut Trusts

Forest Trusts

External Trusts

Realm Trusts

Once a user is authenticated with a domain account, they are able to access resources anywhere in that domain

without needing to verify their identity again. In networks where there are multiple domains, this single sign-on

configuration might not work if the trust relationships are not configured properly. If setup properly, users can access

resources in and logon to computers in any domain.

There are different types of trust relationships that can be constructed to facilitate easy access to resources. All

trusts express relationships between two domains only. Some will allow pass-through authentication while others will

only work with the domains that they are directly connected to. Some will allow authentication in both directions while

others will not. We will learn about the different types of trusts that can be constructed and in what environments they

might be needed.


14/38


Transitive Trusts

Pass-through

Two-Way Authentication

Within a Forest

For all domains in an Active Directory forest, trust relationships will be created automatically that are transitive and

two-way. The transitive nature of the trusts means that direct connections are not needed between all domains. If

domain A is connected to domain B, but not to domain C, it will still be able to use the trust relationship between B

and C to access resources in it. The two-way nature of each connection means that domain C can use the same

trust relationships to access resources in domain A.

This kind of structure means that without any other changes, any user can access any resource in any domain as

long as they all belong to the same Active Directory forest. Appropriate permissions will still need to be assigned to

the user to work with these resources. The DNS servers used by the client computers and domain controllers must

be able to access domain controllers in all domains. This authentication model is facilitated by communication

between the domain controllers in each domain.


15/38


Shortcut Trusts

Pass-through

One-Way

Within a Forest

Shortcut trusts are created to provide direct authentication between two domains in a single forest. While they are

not necessary to allow authentication, they provide faster authentication between two domains that would normally

need to authenticate through two or more transitive trusts. These kinds of trusts are normally used where many

users need to be authenticated more quickly to resources in a domain to which there is no direct connection.

Shortcut trusts are transitive, but not two-way.


16/38


Forest Trusts

Between Forests

Pass-through

Kerberos Authentication

These trusts are constructed to provide authentication between domains in two different forests. They can provide

authentication between domains in either forest. The connection is created between the root domains in both forests.

These trusts are transitive and two-way. Since Kerberos authentication must be used for all transitive trust

connections, the time on the computers in both forests must be synchronized within five minutes.


17/38


External Trusts

Non-Transitive

NTLM Authentication

One-Way

When a connection is made to a domain that does not use Kerberos authentication (Windows NT 4.0 or earlier), only

external trust relationships can be created. They will use NTLM authentication. They are one-way trust connections

and do not pass-through authentication since they are non-transitive. If authentication is needed by user accounts in

both domains, two separate trust relationships must be constructed.


18/38


Realm Trusts


Transitive or Non-Transitive

One-Way or Two-Way

To facilitate access to resources between a Kerberos Realm and an Active Directory domain, a Realm Trust can be

created. The trust relationship can be transitive or non-transitive. The administrator will also have the option of

making the connection one-way or two-way. Because Kerberos Realms use the same authentication protocol as

Active Directory (Kerberos), a single sign-on environment can be constructed in such an environment. In some

cases, account mappings might need to be between user accounts in both environments.

Important ConsiderationsIf all computers to not use the same DNS servers, they must be configured to replicate with each other or be able to

forward requests when necessary. Care should be taken when constructing two-way trusts. Only domains from

which user accounts need to access resources need to be trusted. The time on all machines should be synchronized

by configuring all computers to use the same time servers. The netdom.exe command can be used to create, delete

and test trust relationships.


19/38


Lesson 4: Network Services

DNS

DHCP

SNTP / Time Server

Domain Controller

When a user logs into a domain, the connection between the client computer and the domain controller are important,

but other services on the network also play a part. Kerberos is the authentication protocol normally used and that

service also has its own unique requirements as well. If problems develop during domain authentication, these

network services might need to be examined.


20/38


DNS

SRV Records Dynamic & Static Updates

Multiple DNS Configuration

Active Directory Integrated Zones

Primary Zones

Secondary Zones

Client computers locate domain controllers by querying service records on the DNS server it is connected to. That

DNS server must host the zone records for the respective domain or have a forwarder that it can use to locate them.

Domain controllers register information about the services they provide on the DNS server when they are first started

up. This assumes that the DNS server allows dynamic updates. If not, the static records will need to be manually

updated when the IP address or computer name of the domain controller changes.

Client computers will normally retrieve information for more than one domain controller and cache them. This

prevents them from having to go back to the DNS server every time a DC is needed. When cached records become

out of date, they can be flushed from the DNS server and client computers manually with the ipconfig.exe command.

Site information is stored as a part of the DNS service records so client computers can find the servers that are

closest to them. It is good practice to have an alternate DNS server configured in case a connection to the first one

fails.

When DNS server zones are configured as Active Directory Integrated or Primary, they can be updated directly by

client and server computers if dynamic updates are enabled. Secondary zones are read-only and cannot be updated

directly. Servers with this setup should not be used as the primary DNS server for domain controllers.


21/38


DHCP

DNS & DHCP Integration

Updating Client Configuration

Client computers are often configured to get information about DNS servers from their DHCP server. This makes

them important, not only for normal network connectivity, but also for accessing domain controller records. If DNS

server records are updated on the DHCP server, these changes are not automatically pushed to client computers.

The ipconfig.exe command can be used to manually update these records instead of rebooting the system (e.g. type

ipconfig.exe /release and then ipconfig.exe /renew).


22/38


Time Server


PDC Emulator

Net Time command

The Kerberos authentication process will not work if the time on the client & server computers is out of sync by more

than 5 minutes. It is therefore important that all systems on the network use the same time server. By default, the

PDC emulator in a domain performs this function. This can be verified by running the net time command from any

machine in that domain. A computer can be configured to use a specific time server or time servers with the

command net time /setsntp:server1.com server2.com server3.com. If the default time server configuration for

client computers is preferred, the PDC emulator should still be pointed to an authoritative time server.


23/38


Domain Controller

DNS Registration

Netlogon Service

Domain Controllers will register their service records with a DNS server automatically during startup, if the DNS

server is configured for dynamic updates. Changes made to them after this are not sent until a reboot of the system.

To avoid this, the netlogon service can be manually restarted to update the DNS server.


24/38


Lesson 5: User Account Properties

Logon Hours

Logon To

Password Expiration

Account Expiration

Using Smart Cards

Other User Account Properties

Not all account properties will have a direct effect on the logon process, but a number of them will. Using these

properties an administrator can control what computers a user logs into, the time of day they have access to the

network, whether or not they can change their own password and other settings. We will be looking at some of these

properties and considering how they can be used to manage user accounts.

Logon Hours: By default a user can logon to the domain at any hour on any day of the week. This setting

allows you to change this on an individual user level. If the user is already logged in, group policy settings

can be used to force the user to log off if they are still on the system after specified hours.

Log On To: This setting controls which computers the user is able to logon to. The default allows them to

logon to any machine in the domain. For secure servers on the network, policy settings can be used to

restrict local logon to specific groups as is done for domain controllers. This feature allows you to create a

list of machines for the user. They will not be able to logon locally to any other computer. They will still be

able to connect to other machines over the network.

Password Expiration: Users are normally notified 14 days before their passwords expire. This can be

changed with group policy settings. The Maximum password age setting is a part of the Account Policies

which can now be managed on a group level if needed. The Password never expires setting should not be

used for end-user or administrator accounts. In some cases it is advantageous to use it for dedicated

service accounts. The User cannot change password setting is normally enabled for accounts used bycontractors or accounts used by a group of people. Administrators will still be able to change the passwords

on these accounts.

Account Expiration: User accounts never expire by default. When temporary employees are assigned

user accounts however, this option allows an administrator to set the account to be automatically disabled

after a certain period of time.

Require Smart Card: If users are allowed to use smart cards during authentication, the account policies

allow the option to use a user name and password to be disabled. Smart cards use two-factor

authentication (The card plus the PIN number) which makes them more secure than the default login


25/38


method. When this is done, plans should be in place to deal with situations where the users forget the cards

or lose them.

Account Disabled: A number of situations might arise where an administrator decides to disable user

accounts to prevent logon. If a user is on vacation, if the account is used as a template for new users or if

the user no longer works for the company. Even when the user is fired, it is considered good practice to

keep the account and disable it or at least 30-days.

Account Delegation: Some applications, like SQL Server, can be configured to take user credentials andautomatically pass them to another resource they need to connect to. The user account delegation setting

normally needs to be enabled in order to do this. Other options might need to be configured on the

application or server computer in order for this feature to work properly.

Unlock Account: If a user has too many login attempts with the incorrect password, their account might be

locked out. This depends on the account lockout policies for the domain. If the lockout policies specify that

the user accounts are locked after a specific number of incorrect passwords, the next step depends on

whether an Account Lockout Duration is specified. If so, the user can wait until that threshold is met. If not,

an account administrator must unlock the account for them. Both Password Policies and Account Lockout

Policies can now be controlled on a user account or group level if the domain has Windows Server 2008

domain controllers.

Changing these user properties is normally done from Active Directory Users and Computers, but most of these

options can also be managed with the net userordsmod usercommand-line tools.


26/38


Lesson 6: User Profiles

Local Profiles

Roaming Profiles

Mandatory Profiles

Whenever a user logs into a machine, a user profile is created for them. A folder is created for them that will contain

their desktop, Internet Explorer, Outlook and other settings unique to them. Subsequent logons to that machine will

use the existing profile that was created for them. Profiles are created on the system drive in the users folder by

default. This can be changed by modifying the registry settings and should be done right after setup before any users

start logging into the system. This change can be scripted as a part of the setup process to automate this procedure.

User Profiles can be either Local or Roaming. Both configurations have their advantages and some networks will use

both strategies, assigning an appropriate profile type to individual users or groups.


27/38


Local Profiles

Optimize Logon Time

Use with Large Profiles

Multiple Profiles

Local profiles, as the name suggests, are created and stored locally on the computer. Once created, the logon time

is optimized since the profile does not have to be retrieved from over the network. In environments where users

always work on the same machine and do not use other systems, this configuration is best. This configuration is also

better suited for users with very large profiles.

Because there is only one local copy of these settings however, this configuration presents problems for users who

work on many machines. For users who store work documents in their profile, like the My Documents folder, it is

easy to end up with multiple versions of the same file. Desktop and network settings might also need to be re-

created for each computer they login to. Users could also end up wasting time when they are unsure about which

computer important documents are located on. Using the redirection and scripting features in group policy can

mitigate such situations.


28/38


Roaming Profiles

Stored on the Network

Increased Logon Time

Same Profile on all Domain Computers

A roaming profile is stored in a network location. It is retrieved each time the user logs in so the settings and files are

always the same regardless of which machine they log into. Any changes made to the profile are written back to the

network as soon as the user logs off the machine. Because the profile will always be the same, this configuration is

well suited to users that work on different machines. All desktop and network settings will be the same and the

documents they store in it will be accessible from any machine. Because network locations where the profiles are

stored are normally backed up, this provides protection for user documents and settings.

For users that have large profiles however, this can significantly increase the time it takes them to logon. Profiles

might also be more likely to get corrupted because of the constant copying back and forth of information. In

environments where many users work with large roaming profiles, available network bandwidth can be seriously

impacted. Having the users clean up their profiles regularly by deleting documents and temporary data can reduce

these problems. Redirecting documents to an alternate location will still keep them accessible from any machine, but

also help to reduce the size of roaming profiles.

A user can be configured to use a roaming profile by changing the properties of his user account. Using environment

variables, roaming profiles can be automatically assigned to new user accounts when they are created from template

accounts.


29/38


Mandatory Profiles

Stored on the Network

Never Changes

Can be shared with other users

Local or Roaming profiles can be modified to make them read-only. This allows a profile to be updated with all

necessary settings once and then never have to worry about it again. Users will still be able to make changes to their

desktop configuration, but they will not be saved when they log off. Many users will also be able to use the same

profile. Mandatory profiles are created by renaming the ntuser.dat file in the root of the profile directory to

ntuser.man. This file normally has the hidden and system attributes set. This configuration is useful when certain

settings and options must always be available to a user or group of users.


30/38


Resolve Logon Issues

Review the scenarios and problems presented along with

their solutions

RESOLVE LOGON ISSUES

When trying to solve an authentication or logon problem, all the services and resources involved must be considered.

Problems can be caused by the computer or user account configuration, trust relationships, user profile problems or

account policy settings.

Here are some situations that might arise when users have difficulty logging on and how you might go about solving

them.

A user is complaining that the logon process is taking far too long. How can you improve logon

performance?

Find out if the user is working with a roaming profile, if so, they can make it smaller to speed up the logon time by

deleting unnecessary data. Other sources of this problem could be with issues finding a domain controller or

connecting to remote authentication servers instead of local ones. Fixing the DNS configuration can reduce these

problems.

A user is unable to login to a remote domain that has a trust relationship with their domain. What might

cause this problem?

The trust relationship might be one-way and pointing in the wrong direction. The netdom.exe command can be used

to verify the trust configuration or you can use Active Directory Domains and Trusts under Administrative Tools.

Five contractors will be working with the same user account and they should not be able to be able to

change the account password or desktop configuration. How can this be done?

Enable the User cannot change password property setting and convert the user profile to be mandatory by renaming

ntuser.dat to ntuser.man.

How can you automatically disable a new user account after 60-days?

By assigning an account expiration date


31/38


You need to speed up authentication between two domains in the same forest. They currently pass through

trust relations in two other domains. What can be done?

Create a shortcut trust between the domains

You have a Windows Server 2008 Active Directory forest and an old NT 4.0 domain. How can you configure

authentication the old NT 4.0 domain and each domain in your forest?

External trust relationships must be created between the NT 4.0 domain and each domain in the forest. NT 4.0 doesnot support transitive trust because it only uses NTLM authentication.

A user complains that they cannot log into a computer that is a part of their domain. They are able to login to

other machines successfully. What are some possible reasons for this?

The computer might have user rights configured to only allow users in certain groups to login. Their user account

properties might also have restrictions as to which computers they are allowed to login to.

You have been assigned the task of preventing a user from logging onto the network after 4:00PM. Where

can you do this task?

Using Active Directory Users and Computers, change the user account properties for Logon Hours.

A user computer has incorrect information about available domain controllers cached on the system. What

command will remove these entries?From the command prompt type: ipconfig /flushdns

You need to create a script that includes a command to point to two new time servers. What command will

you include in the script?

net time /setsntp: server1.com server2.com


32/38


Review Module 4: Identify and Resolve Logon Issues

Examine the review questions as a class

REVIEW

1. What network services are needed to support domain authentication?

2. Besides using a user name and password, what other authentication methods are possible on Windows?

3. True or False. Time differences between a DC and the client computer can prevent authentication.

4. How often are computer account passwords reset in a domain?

5. What are some tools that can be used to create computer accounts?

6. What kind of trust relationships are automatically created between domains in the same forest?

7. What authentication protocols are supported with External Trust relationships?

8. What command can be used to change the time server of a computer?

9. What kind of DNS zones do not allow dynamic updates?


33/38


10. What DNS record types provide information about computers that provide authentication services?

11. When might you use the User Cannot Change Password property setting?

12. True or False. All user accounts in a domain must share the same Account Policy settings.

13. What are some reasons to create a roaming profile for a user?

14. How can documents saved in local profiles be automatically protected on the network?

15. How are mandatory profiles created?


34/38


Labs Module 4: Identify and Resolve Logon Issues

Exercise 1: Join the computer to the domain

Exercise 2: Remote Server Administration Tools

Exercise 3: Test and Verify Domain User Accounts

Exercise 4: Create a PowerShell Logoff Script

Exercise 5: Test a Roaming Profile

Exercise 6: Test a Mandatory Profile

Overview: Learn how to add a computer to a domain and use Administration Tools to manage

domain accounts. Unless stated otherwise, use the Windows 7 client and domain controller

images for this lab. Login as Admin1 with a password of Pa$$w0rd.

Note: All user accounts should be reconfigured to use local profiles at the end of this lab.

Estimated time to complete this lab is 75 minutes.

Exercise 1: Rename your computer and join it to the domain

1. Login to STUDENT1 as Admin1.

2. Click Start, Right click Computer and choose Properties. Click Change settings.

3. Click Change and specify Computer1 as the new computer name and Contoso.com as the domain. When

asked for credentials, use Contoso\Admin1.

4. Reboot the computer for the changes to take effect.

5. Login as Computer1\Admin1

6. Use the Computer Management console to add the Contoso\Classroom Administrators group to the local

Administrators group.7. Logout and login again as Contoso\Admin1

8. Login with your domain admin account (Contoso\Admin1)

9. Use the Computer Management console to add Contoso\Admin1 to the local Administrators group


35/38


Exercise 2: Install Remote Server Administration Tools (RSAT)

1. From the Administrator:Command Prompt, run the command NET USE S: \\NYC-DC1\CLASSFILESto map

the\\NYC-DC1\CLASSFILESshare to the S: drive.

2. Install the RSAT by running the command S:\RSAT\amd64fre_GRMRSATX_MSU.msu.

3. Accept all default installation options to complete the setup.4. Read the information in the help file about how to enable the tools.

5. Navigate to Control Panel > Programs > Programs and Features and click Turn Windows features on or

off.

6. In the Windows Features window, use the check boxes to select ALL the Remote Server Administration

Tools.

7. Click OK.

8. When the installation is complete, click Start > Administrative Tools to verify that the tools were installed.

Exercise 3: Test and Verify Domain User Account Properties

1. Logoff the computer and try logging on with your Contoso\User1 account. Note the error message.

2. Logon with your Contoso\Admin1 account.3. Click Start > All Programs > Administrative Tools > Active Directory Users and Computers

4. Navigate to Contoso > Classroom > Users and locate your Admin1 account.

5. Right click on the account and choose properties.

6. Use the Member Of and Account tabs to verify the groups the account belong to, the logon hours, logon

computers and the expiration date of your account. Close the properties window

7. Right click on the User1 account and choose Enable Account

8. Use the properties of the User1 account to add it to the Classroom Users group and restrict its logon hours

to Monday Friday from 6:00AM 6:00PM.

9. Navigate to Contoso > Classroom > Contractors and locate your Contractor1 account

10. Right click on the Contractor1 account and choose Enable Account

11. Use the properties of the Contractor1 account to restrict its logon access to Computer1 and its logon hours

to Sunday from 12:00AM 6:00AM.

12. Create a new user account in the Contoso > Classroom > Contractors OU named Temp1.13. Give the account a password of Pa$$w0rd, prevent the user from changing the password, restrict the

logon computer to Virtual1, restrict its logon hours to Monday Friday from 6:00AM to 6:00PM and set the

account to expire in 30 days.

14. Try changing the group membership of any user account outside of the Classroom OU.

15. Try creating an account in any OU outside of Classroom. You should not be successful since the

Classroom Administrators group membership only gives you control of the Classroom OU.

16. Logout of the computer and test the logon of the User1 and Contractor1 and Temp1 accounts. Only the

User1 account logon should be successful.

17. Test the logon of the User1, Contractor1 and Temp1 accounts from your Virtual1 machine. Only the

Contractor1 logon should fail.

Exercise 4: Assign a PowerShell Logoff Script (Deletes Files in the %TEMP% folder)Note: Configure Windows Explorer to show all file extensions before starting this exercise. (From the menu

bar (Alt + F) click Tools > Folder Options. In the View tab, uncheck the checkbox for Hide extensions for

known file types.

1. Login to VIRTUAL1 as Contoso\Admin1.

2. Use the Command-Prompt or Windows Explorer to map the S: drive to \\NYC-DC1\Classfiles.

3. Click Start. In the Search programs and files window, type Group Policy

4. Click Edit Group Policy and navigate to User Configuration > Windows Settings > Scripts > Logoff.
http://nyc-dc1/CLASSFILEShttp://nyc-dc1/CLASSFILEShttp://server01/CLASSFILEShttp://server01/CLASSFILEShttp://server01/CLASSFILEShttp://server01/CLASSFILEShttp://nyc-dc1/CLASSFILES


36/38


5. Double click Logoff and in the Logoff Properties window, click the PowerShell Scripts tab.

6. Click Show Files. This opens a Windows Explorer window with a path of

C:\WINDOWS\SYSTEM32\GROUPPOLICY\USER\SCRIPTS\LOGOFF. Keep this window open.

7. Use Notepad to open and examine the code in S:\MOD04\Logoff.ps1 file. Close Notepad.

8. Use Windows Explorer to go to the S:\MOD04 folder. Copy the S:\MOD04\Logoff.ps1 file to the LOGOFF

folder.

9. Close all Windows Explorer windows.10. In the Logoff Properties window, click Add then click Browse.

11. Choose the logoff file and click Open.

12. Click OK twice to close the properties window.

13. In Local Group Policy Editor navigate to Computer Configuration > Administrative Templates > System >

Scripts.

14. Change the properties of the Maximum wait time for Group Policy scripts setting to be Enabled and set

the Seconds: box to be 60.

15. Read the Help: section of this policy and click OK.

16. In Local Group Policy Editor navigate to User Configuration > Administrative Templates > System >

Scripts.

17. Change the properties of the Run logoff scripts visible setting to be Enabled. Click OK.

18. Close Local Group Policy Editor.

19. Click Start %TEMP% and press Enter to see the files presently in the %TEMP% directory.20. Logoff the computer and logon again with the same account. (The logoff process might take a few minutes.)

21. Verify that the files in the %TEMP% folder were deleted. A few files might still be left that were involved in

active processes.

22. Use Local Group Policy Editor to remove the logoff script.

Exercise 5: Test a Roaming Profile

1. Boot your Virtual1 machine and login as Contoso\Admin1

2. Create a folder named Scripts on your desktop.

3. Copy the PS1 scripts from the \\NYC-DC1\CLASSFILES share to the new Scripts folder.

4. Use the Personalization settings to change the Desktop Background to any solid color.

5. Click Start and then right click Computer. Click Show on Desktop.6. Install the RSAT using the steps provided earlier.

7. Click Start > All Programs > Administrative Tools

8. Right Click and drag Active Directory Users and Computers (ADUC)

9. Drag the icon to the desktop and use the prompted options to copy a shortcut on the Desktop.

10. Right click the ADUC icon on the desktop and choose properties.

11. In the Shortcut key box type the letter A. It should fill in the box with Ctrl + Alt + A. These shortcut keys

can now be used to launch the tool.

12. Click Advanced. Check the box forRun as administrator and click OK.

13. Click OK.

14. Use the shortcut keys Ctrl + Alt + A to launch ADUC.

15. Open the properties window of your Admin1 account.

16. In the Profile tab, verify that you cannot change the Profile Path for your user account. Close ADUC.

17. Hold down the Shift Key and right click ADUC. and Run as different user. Use the Contoso\Administratoraccount with a password of Pa$$w0rd.

18. Open the properties window of your Admin1 account.

19. In the Profile tab, change the Profile path to\\NYC-DC1\USERS\%USERNAME%.

20. Click Apply. Click OK. Close ADUC

21. Logoff and logon again as Admin1. Do this step twice.

22. Boot your Computer1 machine and login as Contoso\ Administrator.

23. Open the System Properties window and go to the Advanced tab.

24. User the User Profiles section, click the Settings button.
http://server01/CLASSFILEShttp://server01/USERS/%25USERNAME%25http://server01/USERS/%25USERNAME%25http://server01/USERS/%25USERNAME%25http://server01/CLASSFILES


37/38


25. Delete the local profile for Contoso\Admin1.

26. Close System Properties and logout.

27. Login as Contoso\Admin1

28. Verify that the profile configurations you made on Virtual1 are still available. (Note: Remember that the

roaming profile is only updated when you logoff.)

Exercise 6: Test a Mandatory Profile

1. Login to COMPUTER1 as Admin1

2. Use ADUC to change the Logon Hours of Contractor1 so he can login at any time.

3. In the properties of the Contractor1 account, Use the Profile tab to change the Profile path to \\NYC-

DC1\USERS\%USERNAME%

4. Close ADUC and logoff.

5. Login as Contoso\Contractor1.

6. Click Start, right click Computer and choose Show on Desktop.

7. Change the Desktop Background to a solid color and create a new text document on the desktop.

8. Logoff and logon with the Contractor1 account twice.

9. Login as Contoso\Admin1

10. Use Windows Explorer to navigate to the C:\USERS\Contractor1 folder11. Press Alt + F to show the menu bar and go to Tools > Folder Options

12. In the Folder Options window, go to the View tab and enable the following options:

Always show menus

Show hidden files, folders, and drives

13. In the same tab as the previous step, disable the following options:

Hide empty drives in the Computer folder

Hide extensions for known file types

Hide protected operating system files

14. Click OK.

15. In the\\NYC-DC1\USERS\Contractor1.v2folder, rename NTUSER.DAT to NTUSER.MAN

16. Log on with the Contractor1 account. Create a text file on the desktop and change the background to a

different color.

17. Logoff and on again with the Contractor1 account to verify that changes to the profile are NOT being saved.

Note: Login to the system as Contoso\Administrator and use the ADUC to remove all the roaming

profile configurations for the user accounts. Verify that the Admin1 and User1 accounts can login

without problems after these changes.
http://nyc-dc1/USERS/Contractor1.v2http://nyc-dc1/USERS/Contractor1.v2http://nyc-dc1/USERS/Contractor1.v2http://nyc-dc1/USERS/Contractor1.v2


38/38


50331B-EnU StudentGuide M04

Documents

Transcript of 50331B-EnU StudentGuide M04