WIN.MIT.EDU Container Administrator Training

Architecture Overview

Container maintenance Lab

User features Lab

Disconnected operation

RIS: Remote Installation Services

Security and using Windows Server

Windows Vista Labs

Architecture: Active Directory

Cross-Realm Trust

Trust of MIT Kerberos Realm by WIN.MIT.EDU allows single sign-on to multiple resources. Delegated User Management - MIT Kerberos accounts – departments control resources by

managing group membership, machines and ACL's

Single Domain/Forest Model

Model in use by many large schools, corporations and ISP’s Delegation of Containers (OU’s) – “Islands of Control”

Departmental container administrators have many tools to build their workstation and server environments. Each department builds and customizes their own environment.

Container administrators control machines and access to their resources instead of the users directly Group policy

Software distribution, Security, Registry, and other feature settings can be assigned on a container basis. ACL’s via Moira groups. Custom group policy settings written by IS&T

Standard MIT DNS Services win.mit.edu uses MIT’s UNIX based DNS services instead of Microsoft’s

LDAP Directory populated by data from:

Moira – User, Group, and Container data Populator –Moira host to container mapping, Data Warehouse, spn

WIN.MIT.EDU Architecture

MIT Kerberos KDC’s

WIN.MIT.EDU DC’s

Data Warehouse

Moira Populator

MITnet DNS

Query Data Feed

DFS Storage

Architecture: Moira Data Feed – “Incremental”

The Moira incremental update is used to keep the WIN.MIT.EDU domain synchronized to the Moira database. The Moira incremental will create and maintain the following in Active Directory:

User accounts (MIT Kerberos ID’s – principal’s), and profile options Account status changes such as activation/deactivation

Lists and Groups with their memberships Container Hierarchy

The Moira incremental is a UNIX executable image and resides on the Moira server and runs continuously. This application uses Kerberos V5 authentication to establish an LDAP connection with the Windows domain to perform the updates. It has been completely integrated into Moira operations.

When relevant changes to users groups and containers are made in Moira the incremental is triggered and the change is propagated to Active Directory.

The Moira incremental will distinguish between list and groups when propagating them in Active Directory:

Lists = Distribution groups Groups = Security groups

We do not write directly to AD to create Domain groups The data may be over-written Make these changes in Moira Local groups can be managed directly via Windows

Container maintenance: Web forms for container administrators

Opt into/out of various domain-wide deployments https://wince.mit.edu/optoutrollout/index.jsp A container administrator can opt out of certain deployments until you are ready or to opt into

test deployments early before they are released domain-wide. Containers and/or individual machines can opt-in or opt-out.

Submit a Container Maintenance Job: SelfMaint https://wince.mit.edu/containermaint/index.jsp Schedule a container reboot, defrag, or custom script. Selfmaint scripts can wait until a user is

logged out in order to not disturb normal machine use.

Delete a Machine from Active Directory https://wince.mit.edu/deletemachine/index.jsp A convenient tool if other tools are not available. To reinstall a computer, it’s machine account

must first be deleted from Active Directory, but NOT from Moira.

RIS or Join Computer Page https://wince.mit.edu/getrisaccount/index.jsp a container administrator or a container membership administrator, you may use this service to

obtain a short-term account and password to be used while adding machines to WIN.MIT.EDU (the Moira host information should already exist)

Container maintenance: Joining a machine

One-time considerations for new hosts and users: Is there a Moira record for the machine which has propagated to the MITnet DNS? Has the machine been assigned to a container? (Stella) Is your Kerberos password up-to-date?

General instructions: If reinstalling or rejoining, use the web form located on the Domain Machine

Management page to delete the old machine account Remove existing (non-WIN) MIT Kerberos software and reboot; Verify correct IP and DNS settings, join machine to domain and reboot. If no packages are downloaded, reboot a second time due to the XP fast boot default.

Using the "tempjoin" Account: Regular user accounts in WIN do not have rights to create new machine accounts, a

requirement when joining a machine or using RIS. The web form requires MIT certificates. It creates a Windows account with your

username, followed by ".tempjoin." A temporary password, which is valid for 48 hours, is displayed on the screen. This is the appropriate username and password to use while joining the machine to the domain or authenticating to the RIS server.

Container maintenance: Moira Tools Stella – machine management One-time Assignment of the Machine to a Container

In order for a machine to get group policies and MSI packages it requires to function properly in the domain, it must be assigned, in Moira, to a container that is within the "Machines" container in AD. If there is no assignment, the machine will appear in the "Orphans/Machines" container, and not get the group policy objects it needs.

You can use the stella command to assign the container, stella hostname -lcn lists the container if one has been assigned, the -dcn option removes an existing machine-to-container assignment, and -acn adds one. Perhaps this query is a good candidate for a future web application.

If a machine needs to be reinstalled or replaced, the Moira container mapping does not have to be deleted. Only the AD machine account needs to be deleted via the web form.

To check if a host already has been assigned to a container use the -lcn option: stella my-machine -lcn

Machine: my-machine Container: Machines/my-containerIf the machine has not been assigned to a container, you will not get any output from the command.

To assign the machine to a container use the -acn option: stella my-machine -acn Machines/my-container

If the machine already has been assigned to a container, but you wish to move it to another one, you must first delete the old container assignment using the -dcn option, then assign it to the new container with -acn:

stella my-machine -dcn Machines/my-container stella my-machine -acn Machines/my-other-container

Container maintenance: Moira Tools Mitch – container management

You can use mitch to get container info Basic info: mitch machines/my-container List sub-containers: mitch machines/my-container –ls List machines in the container: mitch machines/my-container –lm Use the recursive switch –r to get subcontainer info

You can use mitch to set container properties Memacl: who can add a machine to the container –MA Set the description: mitch Machines/my-container -d “My Container” Modify the contact: mitch Machines/my-container -c my-list

You can also use mitch to map and un-map machines from your container Add a machine: mitch Machines/my-container -am my-machine Remove a machine: mitch Machines/my-container -am my-machine

Do not use the rename function This function does not work properly if there are subcontainers involved GPO object names do not get changed along with the container If you need to do a rename, send mail to the network team with your request

Container maintenance: Moira Tools Blanche – group management

You can use blanche to add and remove members from groups: Blanche groupname –a (add) Blanche groupname –d (remove) user

Add / remove users based on a file: Blanche groupname –al (add) filename Blanche groupname –dl (remove) filename

Modify the description, owner and memacl information -d “My Description”, -o owner, -MA memacl

Always make sure the –G group option is used for Security groups in Active Directory, (referred to as AFS group on the list creation request form).

Use the Use the recursive switch –r to expand nested group memberships

You can use qgrep on your win.mit.edu machine to search a list for a member: Blanche my-very-big-list –r | qgrep myusername

A webform is also a available for group creation and management (requires MIT certificates):

https://webmoira.mit.edu/newwebm/

Container maintenance: Lab

Lab: 1: Using Moira tools and joining a machine

Container maintenance: Group Policy Objects GPO’s are created and stored in SYSVOL

DFS share replicated to each domain controller SYSVOL is a file system, a new directory is created for each GPO, not for

each container A GPO may be linked to multiple containers AD ACL’s may be used to control who can read a GPO or which users or

machines it can be applied to

GPO inheritance favors the lower level GPO unless the override bit is set (called enforce in gpmc)

GPO’s are created when a container is requested. The default configuration is one parent container with server and workstation

subcontainers Individual GPO’s are created for each of these containers Additional subcontainers and GPO’s may be requested Additional GPO links may be requested

Container maintenance: Group Policy Management Tools

Group Policy Management Console – gpmc.msc Preferred GP Management tool. An add-on MSI for XP, installed by default on

Vista. There is also an add-on MSU for Vista with updated tools for administration of Server 2008

View GPO settings and permissions Can launch gpeditor

Resultant Set of Policy – rsop.msc Diagnostic tool to view how GP inheritance is working

AD Users and Computers – dsa.msc Views and info of containers and machines

Group Policy Editor – gpedit.msc Launched by gpmc or dsa, edit settings and a new preferences section for Vista

Gpupdate - Command line utility Refresh group policy

GPFind – win.mit.edu command line script Search by GPO name and launch the gpeditor

Container maintenance: Group Policy .adm and .admx files The SYSVOL share contains ASCII files with the .adm extension that define

administrative template group policy settings. Within win.mit.edu, updated template versions are propagated across SYSVOL to insure

consistency across containers. New versions are released by Microsoft with every new service pack

IS&T has written custom .adm templates to augment group policy options

Windows Vista and above employs an XML file format using the .admx extension. Existing .adm settings still apply to Vista machines where applied

Settings particular to the .admx file format need to be managed from a machine running Windows Vista or above

Some new .admx settings have the ability to apply only to Vista and not XP if the administrator chooses. They employ .ini files on the GPO’s directory in SYSVOL to track desired behavior

New SYSVOL storage options are available to optimize storage utilization. All .admx files can be stored centrally instead of being replicated in each GPO directory

Container maintenance: Group Policy Settings - Software

The Software section is where MSI based applications are assigned to a container.

The assigned MSI should be referenced via a UNC path

Transforms and ACL’s may be assigned to an MSI via the “Modifications” tab on the MSI properties

Software policy processing occurs only at boot time

Packages may be assigned to upgrade existing packages

Do not use your GPO to upgrade a package currently opted in using the web form since the Software Distribution GPO uses the no override option. If you need to do this, remove the opt-in via the webform.

Packages assigned domain wide: ActivePerl MIT Hesiod client

Print queue resolution MIT Kerberos for Windows 2.6.5 MIT LogonBefore Provider

Was for disconnected operations – being phased out MIT Moira client MIT Self Maintenance MIT Syslog client Previous Versions Client

XP and 2003 only, built into Windows Vista

Container maintenance: Group Policy Settings – Security

Recommended uses of the security section:

Startup scripts

User Rights Assignments This will be covered in more

detail in the server section

Restricted groups You may use addmin.exe as a

non-exclusive alternative to this setting

System Services

IPSec (this must be sent to the network team as a request)

Windows Vista:MIT KfW and the UAC

WIN.MIT.EDU uses a different KfW 2.6.5 installer then the one on the software download site. Unlike the download site installer, our 2.6.5 installer is fully Vista compatible. Therefore there are no pressing reasons for users to upgrade to version 3.2.2.

Since the latest release of KfW does not fix the Vista UAC issue, we are waiting for a later release which is UAC compatible to upgrade WIN.MIT.EDU machines. When such a version is released, we will announce a schedule for the upgrade. The decision to wait on this upgrade was made by consensus with us and the Kerberos Development Team months before version 3.2.2 was released.

Our current workaround for KfW has been to disable the UAC by default, then KfW 2.6.5 functions normally. However, those who wish to enable the UAC in their containers may do so by applying the settings to their container policies. When a UAC compliant version of KfW is available, we will consider changing the default UAC settings back to Microsoft's setting of enabled.

Container maintenance: Group Policy– Administrative Template Settings

Windows Components section highlights: NetMeeting RSS Feeds Task Scheduler Windows Messenger Windows Media Digital Rights Management Windows Movie Maker Windows Update - patching Windows Media Player

System Section highlights: User Profiles Scripts Logon Disk Quotas Group Policy

Network Section highlights: DNS Client Offline Files Network Connections QoS Packet Scheduler SNMP Background Intelligent Transfer Service

Win.mit.edu settings Pictured on the left IE, Sendbug and Logoff settings will be phased out shortly

New: Preferences section

New server 2008 management tools available for Vista

Many features that IS&T had to build custom tools for have now been built in by Microsoft

Registry keys can be deployed here instead of using Regpoledit

Scheduled tasks can be deployed via group policy as an alternate to Selfmaint

Network and local printers can be deployed here instead of using the win.mit.edu custom settings

Other new features: Computer based control panel settings such as

power options, local accounts and folder options

Container maintenance:

Group Policy – win.mit.edu Printer settings Microsoft did not have a machine based group policy option to assign printers prior

to Server 2003 R2/Windows Vista. When Windows 2000 was released, IS&T developed custom printer extensions for

win.mit.edu. When Windows XP is closer to being phased out, we plan to phase out these custom settings. The new Microsoft settings are available today for Vista users

IS&T is phasing out Kerberized printing, the KLPR packages are no longer being maintained. The KLPR packages do not support Windows Vista.

New Microsoft GP settings for Vista are available. Two types of printers may be assigned using the win.mit.edu extensions:

“KLPR” Printers: Queues that require Kerberos authentication Use the MIT Hesiod client installed on the machine for queue resolution Currently the KLP MSI is deployed by default There is an opt-in for the newer LPNG MSI There is a specific list of supported drivers

additional drivers can be added but in some cases are not compatible with the UNIX print queue An opt-out of all Kerberized printer clients is available

Network Printers: Standard Microsoft Network Printers assigned per machine Uses standard UNC path name

Both options have the ability to assign a default printer to the machine

Container maintenance: Group Policy - Custom registry keys

IS&T developed a utility called regpoledit to edit the binary .pol file allowing us to manually insert custom registry keys without having to extend the .adm templates.

Sets of custom registry keys are applied to win.mit.edu machines for the following applications: Cross-realm MIT Kerberos logon Internet Explorer Windows Explorer Eventsyslogger

These keys can be viewed in the Administrative Template/Extra Registry Keys section of the RSoP utility

If container administrators require custom keys the network team can be contacted for assistance

Container maintenance: Selfmaint

The Selfmaint package is an MIT developed MSI that is installed on all domain machines.

Selfmaint is a container based scheduling service that is provided in addition to the Windows Task Scheduler service, and runs under the SYSTEM account. It’s main features are:

Schedule one job for an entire container and subcontainers or individual machines. Can reboot, defrag disks, or run custom scripts Scripts reside on the network and will continue to run if the OS is reinstalled or a new computer is added

to the container

A script can either wait until no user is logged in to run or run unconditionally.

A web request form exists to have job setup for your container. You may choose common tasks or provide your custom scripts. The available scheduling options are built into the form. We recommend using Perl or VB if you are submitting a custom script.

Microsoft Hotfixes not supported by WSUS can be installed.

Certain scripts run domain wide, such as mirror-distrib.

Scripts reside on DFS, the Selfmaint service checks for new jobs and maintains a logfile with the most recent time a particular script ran in %programfiles%\MIT\Shared Files\selfmaint.log.

At bootup (or service start) the logfile is checked for any scripts that are overdue to run and Selfmaint runs them immediately

Container maintenance: Scripts“Mirror-distrib” At first startup machines in win.mit.edu apply group policy and install assigned MSI

applications which restart the computer afterward installation. Once this is done WSH and Perl scripts assigned via group policy begin running.

When a machine is booted up it looks locally for a script that synchronizes the local script and utility cache. If the script does not exist locally it will run off a network path. Startup and logon scripts also will run from a local copy as first preference but can run from the network copy as a fallback.

The script that initially creates, than later synchronizes the local script and utility cache with DFS is a Perl script called mirror-distrib.

The local cache is in %ProgramFiles%\MIT\mirror\distrib. After the initial first time bootstrapping when the cache is created, this script continues to run both at startup and daily as a Selfmaint job to propagate any updates to these scripts to client machines.

To troubleshoot the bootstrap process, first check that the machine is in it’s proper container. If it is, run gpupdate /force and reboot, then check if the default MSI installations went successfully. If the Perl MSI fails to install, mirror-distrib and other scripts cannot run.

Container maintenance: Scripts Main Startup Script Operations Script operations are logged to the system Application log Group policy tells the machine to check locally for the script, then run it from DFS

if it is not found locally: Example: myscript.pl – the GPO is set to run cmd.exe with these parameters

/c if exist "%programfiles%\mit\mirror\distrib\myscript.pl” ("%programfiles%\mit\mirror\distrib\myscript.pl") else (\\win.mit.edu\dfs\ops\distrib\myscript.pl)

Startup Scripts Mirror-distrib (.pl):

Checks for local script cache and creates it if necessary, otherwise syncs the contents with DFS Adds the local cache directory to the system path if its not already there

Startup (.wsf) Sets a machine environment variable with the domain name Checks if the machine is connected to MITnet and runs the following operations

Checks if the machine is in the proper container Win.mit.edu – remote event-log settings are enforced Win.mit.edu – root password settings are enforced Win.mit.edu – printer settings are enabled Fix system path script is run Local Administrator is denied access to the machine over the network Tempjoin accounts are denied interactive logon If not already set earlier by the populator service, the service principal name is set in AD Athena sys variable is set for AFS compatibility

If the machine is not running Vista or higher, default root of C: drive permission lock downs are enforced

Container maintenance: Eventsyslogger and OS Groups The Eventsyslogger package is an MIT developed MSI that is installed on all domain

machines. Eventsyslogger is a Windows syslog client that runs as a service under the SYSTEM account. Event logs are sent to a central syslog server, three default filters are setup by the installer and their

settings are enforced by group policy. Additional filters may be added and logs from those filters can be sent to the syslog server of your

choice. The application can be administered via a control panel

Description of the OS Groups Service: A service named "OS Groups" runs as part of the Populator services. It automatically populates the following groups in Active Directory:

Win2KPro.group : Machines running Windows 2000 Professional Win2KSrv.group : Machines running Windows 2000 Server Win2K.group : Machines running Windows 2000 Professional or Server WinXPPro.group : Machines running Windows XP Professional WinSrv2003.group : Machines running Windows Server 2003 WinVista.group : Machines running Windows Vista WinSrv2008.group : Machines running Windows Server 2008 WinOther.group : Machines running another OS or an unknown OS Note: These are not Moira groups. They exist only in the Active Directory When a new machine enters the domain or an existing machine upgrades its OS, it is automatically

added to the proper group. These groups can therefore be placed on access control lists in Active Directory. This is especially useful for GPO application and MSI software installation, and it eliminates the need for separate containers for XP Professional, Vista, and Server 2003 machines

Container maintenance: Lab

Lab: 2: Using Group Policy Management tools

User features:Logon

Single Sign-on:

User Accounts via the Moira incremental

A corresponding user is created in Active Directory and automatically mapped to the MIT Kerberos principal

Profile and Home directory options are written to the users account data along with Office location, phone and email

A random 127 character password is generated and stored in the user properties in Active Directory so the password does not need to be propagated. Cross-Realm authentication will verify the users password directly from the MIT Kerberos KDC’s.

Windows Service exists to refresh random passwords every 30 days

Webform to set the users Windows password to a known value for use with special applications where required

To logon to a Vista computer with a local account enter machinename\username in the username field.

User features:Web forms for users

Change your Kerberos Password. https://wserv.mit.edu/fcgi-bin/cpw

Change Your Active Directory Password. https://wince.mit.edu/changepasswd/index.jsp For users: under certain circumstances, it might be necessary to set

your native WIN domain password, but in most cases this is not necessary and should only be used when needed.

Change Profile and Home directory options. https://wince.mit.edu/changeprofile/index.jsp A user can change their default DFS roaming profile and home

directory locations to a local profile and home directory or to a path on a departmental server

User features:Profiles and Home directories Default is roaming profile in DFS

Configurable via web form

.winprofile (or .winprofile.V2) is created in the users DFS home directory

Copied to local drive at logon

NTFS user quotas

Drive H: is mapped to the users DFS home directory

Currently 2 GB User quota by default

Previous Versions support. This is a self service feature where users can retrieve old versions of files and folders up to 64 days back

Accessed over network as needed

Used for folder redirection of Windows home directory

The H:\WinData directory is created in DFS for redirected user data to minimize the amount of data that is copied at logon and logoff

My Documents Application Data Favorites

Windows Vista:Default Vista Desktop

When logging on with a domain account to a Vista machine for the first time, a default profile is downloaded from a network share

When logging on with a local machine account for the first time, the local profile is generated from the Default profile on the local computer. This is the Microsoft default Vista profile

When logging on with a domain account that does not use roaming profiles, the domain default profile will still be used. The logon scripts will detect these cases and if not already done, set the directory structure to the Microsoft defaults. Possible cases where this will happen are:

Disconnected operation The account is set to local profiles via the web form The container is set to local profiles only

The ability to display the Aero interface will depend on the graphics card of the computer.

Users will be able to enable Aero if supported by the hardware and the video driver

Profiles are no longer stored in the Documents and Settings folder, the new location is in the Users folder off the root of the system drive

User features:Folder Redirection – Windows XP

By default, all users and machines use both roaming profiles and folder redirection.

Computers download the default user profile from a DFS share.

For the Windows XP environment, WIN.MIT.EDU redirects the following folders: Application Data = H:\WinData\Application Data My Documents = %HOMESHARE%\WinData\My Documents My Pictures = %HOMESHARE%\WinData\My Documents\My Pictures Favorites = %HOMESHARE%\WinData\Favorites

%HOMESHARE% is the location of the users home directory as specified by the user account properties in Active Directory. These properties are managed by Moira and can be modified via the change profile options webform.

Machines opted into the disconnected operations laptop policy mapped H: to their local user profile in C:\Documents and Settings instead of the users DFS home directory. These machines do not use roaming profiles.

Users who used the change profile options webform to set their account to local profiles and no folder redirection see similar behavior to those who use machines covered under the laptop policy.

Windows Vista:Folder redirection By default, all users and machines use both roaming profiles and folder redirection.

Computers download the default user profile from a DFS share.

For the Windows Vista environment, WIN.MIT.EDU redirects the following folders: AppData(Roaming) = %HOMESHARE%\WinData\Application Data Contacts = %HOMESHARE%\WinData\My Documents\Contacts Documents = %HOMESHARE%\WinData\My Documents Downloads = %HOMESHARE%\WinData\My Documents\Downloads Music = %HOMESHARE%\WinData\My Documents\My Music Videos = %HOMESHARE%\WinData\My Documents\My Videos Pictures = %HOMESHARE%\WinData\My Documents\My Pictures Saved Games = %HOMESHARE%\WinData\My Documents\Saved Games Searches = %HOMESHARE%\WinData\My Documents\Searches Favorites = %HOMESHARE%\WinData\Favorites Links = %HOMESHARE%\WinData\Favorites\Links

The redirected paths for Vista were chosen in such a way as to preserve the continuity of user experience from XP.

Both XP and Vista share the same My Documents and Favorites folder. Documents don’t exist in two locations.

If the user has chosen local profiles only via the web form, there will be no drive H: mapping.

Folder redirection is disabled when the machine is logged into disconnected operations. If the machine is on MITnet when the user logs on, drive H: will be mapped to the users network based home directory. If the machine is not connected to MITnet at logon, there will be no drive H: mapping.

Windows Vista:Roaming Profiles

Vista roaming profiles are not compatible with XP profiles. Microsoft added code in Vista to create a new profile directory in the users home directory with a .V2 extension:

XP: H:\.winprofile Vista: H:\.winprofile.V2 Each profile has its own desktop folder: e.g., XP’s is H:\.winprofile\desktop If you have certificates in your XP profile, you will still need to get them separately for Vista

Desktop-Sync: In order to preserve consistency of the desktop files and shortcuts for users logging into both XP and Vista machines, WIN.MIT.EDU synchronizes the desktop folders of both profiles when a user logs on:

Files saved to an XP desktop will appear on the Vista desktop. Files saved to a Vista desktop will appear on the XP desktop. If a file is updated on one of the desktops, the other desktop will receive the updated version at the next

user logon regardless of which OS they logon to. Important! A cached roaming profile may only be deleted via the system control panel. If the

files are deleted manually, the roaming profile will fail to load. To fix this the relevant registry keys will have to be deleted from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Upgrades: If a machine is upgraded to Vista, the upgraded cached copy of a roaming profile should be copied to a new folder via the system control panel and not used (more about this in the folder redirection topic).

A local logon should be used for the upgrade and immediately after the upgrade to rename the old cached profile.

Upgraded versions of non-roaming profiles can be preserved and do not need to be modified.

Windows Vista:

User Files Directory View

The user’s files folder is a programmatically merged view of the local cached profile and the redirected folders.

It’s possible to view duplicate entries if a directory exists in each location.

We reported this to Microsoft, but action was taken to remediate the issue.

We implemented our own workaround to the user file view issue: The default domain Vista roaming profile which is the source for the

cached profiles has the folders which are redirected removed. Users in the domain who use a local profile either on a desktop by

opting out of roaming profiles or using a computer opted into disconnected operation (laptop policy) have the removed directories recreated at logon when the profile is first created.

New logon scripts include logic to detect whether the user is roaming or not and create the directories if they do not exist.

Windows Vista:Changes to “AppData”

In XP, all application data was redirected to the home directory

Vista still redirects most application data to the home directory, but now also stores some settings data and certificates in the roaming profile

In XP, non-roaming data was stored in the “Local Settings” directory

Vista stores non-roaming data in AppData\Local

Vista has a new store for low security data called AppData\LocalLow. This is used by IE running in protected mode. This data does not roam.

User features:Previous Versions

Uses VSS: Windows Server 2003 Shadow copy services for user Home directories

Point-in-time copies of files. View, Copy or Restore files and folders as they existed at points of time in the past.

Recover files that were accidentally deleted or overwritten. Compare versions of file while working. Self service file restore capability for the end user.

Snapshots are made every 4 AM. Versions of up to 64 days are available. Shadow copies are read-only. You cannot edit the contents of a shadow copy.

User features: Scripts Main Logon Script Operations Group policy tells the machine to check locally for the script, then run it from DFS

if it is not found locally. These checks are similar to startup scripts. Logon Scripts

Logonbefore (.wsf) (only runs if the AFS client is installed and running) Is launched by the AFS service before explorer.exe Checks if the machine is connected to MITnet and runs the following operations

Map drive z: to \\afs\all If specified in win.mit.edu AFS Settings, map the selected drive letter to the users AFS

home directory. Drive I: is commonly used. Logonafter (.wsf)

Is launched by the operating system after explorer.exe Checks if the machine is connected to MITnet and runs the following operations

Checks if Windows XP home directory mapping should be turn off for disconnected operations (not needed for Vista)

Enforces win.mit.edu default machine printer settings if they are set On XP, maps drive H: to the local profile if not mapped to any network based home directory.

This is for disconnected operations or the local profile option in the user profile options web form (XP only, not run for Vista).

Runs Desktop-Sync (this will be covered in the Vista section) Imports user Kerberos tickets from the MS LSA cache to the MIT Kerberos cache

Disconnected operation:Laptop support Requires opt-in of the machine or container via a web form Domain wide scripts have internal checks for network based operations, they test for RPC

availability to win.mit.edu over port 445, if there is no connectivity the operation is skipped. If a machine boots with no network connectivity the user logs on using their domain account

with cached credentials. Roaming profiles and folder redirection are disabled for disconnected users, by default all files

are saved to the local disk. When using disconnected operations with Vista, drive H: will not be mapped to the local

profile as in XP. If the machine is connected to MITnet at logon, the drive will be mapped to the network home directory specified in AD.

(XP only): People using laptops that are frequently used remotely over a broadband connection should install the MIT VPN client.

(XP only): Note about Intel Proset Wireless management software: This software is currently packaged with many laptops, including those from Dell. We recommend that you uninstall this portion of the software via the add/remove programs control panel for use with disconnected operations within win.mit.edu. While it is possible to set this software to use the Microsoft client to manage wireless connections, this setting won’t be preserved across system reboots.

To logon/logoff without the VPN we currently recommend that it not be connected to the home network until after the Windows logon so the operating system understands it is doing a disconnected logon. This can be done by disconnecting a network cable, or using a function key to disable integrated wireless (F2 on most Dell laptops). This is because Windows detects network connectivity and attempts to authenticate with a domain controller. VPN logon can be started after reconnection to the network.

Vista users should disable IPV6 before using the MIT VPN client 5.0 or greater.

RIS: Remote Installation Services Requirements

PXE support enabled for subnet and the computer BIOS Moira record should exist for machine and already be mapped to container If reinstalling, the previous computer object in Active Directory must be removed Tempjoin credentials are used for the installation

Execution Boot with Network Boot option (using F12) Access to Windows XP images by default, there is an ACL for Server 2003 images Machines automatically join the domain

RIS Info RIS will format and install the OS on the first physical disk Images exist for particular Dell and IBM models

If a new model is commonly used, a new image can be requested Generic images exist as well that can be used for Virtual Machines WDS (Windows Deployment Services) will soon replace RIS. WDS will support Vista

and Server 2008

User features:Lab

Lab 3: Using Previous Versions on the Home directory

Lab 4: Desktop Sync

Server Security Recommendations:Common Security policies to implement for server Logon restrictions: Computer Configuration/Windows Settings/Security

Settings/User Rights Assignment Allow logon through Terminal Services

Generally restricted to the local Administrators group (Allow) Logon Locally

Generally restricted to the local Administrators group but sometimes a service account may require this right depending on the application

Deny Logon through Terminal services It is recommended to deny the local Administrator account logon over Terminal Services. This way, the local

Administrator account can only be used when physically in front of the machine. We already deny this account access to the machine over the network, this setting is a logical extension of the same precaution.

Do not use groups or known security principles without understanding their scope Authenticated Users, which includes both local and domain users, but not anonymous Local Users, which by default includes the Domain Users group

Always implement the Windows Firewall and only open necessary ports to relevant subnets If possible, implement Microsoft IPSec

Resource Management and Administration Use NTFS ACL’s, not Share permissions for more granular security

Use one or two top level shares and set NTFS ACL’s on the sub-folders instead of creating many shares Avoid disabling of inheritance, as it will tend to yield unexpected results if not well documented Avoid granting Full Control (which allows users to change permissions) over resources, use the Modify right.

Use local Groups containing Moira groups or at least moira groups on NTFS ACL’s Do not assign NTFS permissions or rights to users directly, use the group membership When a user leaves the department rights can be easily removed by removing their group memberships in moira

Server Security Recommendations:Least Privilege Access & Minimize Attack Surface

Least Privilege Access (Authorization) Security Principle

Assign only the necessary permissions for application service accounts, refrain from granting Administrator privileges if possible

Limit the rights granted to an account, use multiple accounts for different services Limit how application service accounts can be used

deny logon interactively deny logon through terminal services, only allow logon to specific computers

Minimize Attack Surface Ensure machines are up-to-date on patches (using WSUS) Disable all unnecessary services (using group policies) Only open necessary ports to appropriate networks (using a combination of IPSec and Firewall)

or use a hardware firewall if necessary. Utilize Encryption, such as SSL over HTTP on web server or IPSec for other applications

Server 2003 Security Recommendations: Windows Firewall Supports

Available on Windows XP SP2, Server 2003 SP1 and higher Can be configured to block incoming connections Allows exceptions based on Ports (UDP/TCP) and Applications Can apply to all or some Network Connections Scopes to limit exceptions to specified Hosts or Subnets

Limitations Cannot create an exception for a range of ports

(but a host/subnet scope can be defined) Does only block incoming not outgoing traffic

(Outgoing traffic blocking available in Windows Vista/Server 2008) Domain defaults

For Windows XP we use the Microsoft default, the firewall is on The firewall can be enabled by setting Computer Settings/Administrative

Templates/Network/Network Connections: Prohibit use of Internet Connection Firewall on your DNS domain network = Disabled. Then the firewall can be configured locally or via group policy.

Vista’s default Firewall settings depend on the location chosen when the network for first setup (Home, Work or Public). Due to the nature of the MIT network Public is the recommended selection.

Server 2003 Security Recommendations:IPSec Features

Microsoft IPSec has been a built-in component since the release of Windows 2000. It can be used to create an encrypted channel between two machines, or it can be leveraged to implement simple IP based block/allow policies

Encrypted channels can be established either by Kerberos V5 authentication or via a shared key. 3DES keys are used by default when doing Kerberos authentication.

Policies can be configured either to try to establish a secure channel but fall back if not supported, or to enforce secure channel communications only

The most common use of IPSec are the IP based block/allow rules. Rules can be host or subnet based, include all traffic or only specific ports or

protocols. An IPSec implementation consists of Policies that contain Rules, which are based on

Filters & Actions IPSec Policies can be created and assigned locally, imported and exported to a file,

or assigned through group policy Assigning an IPSec policy via group policy must be done via a request to the

network team

Server 2003 and Security Recommendations:IPSec filters and policies

IPSec can be managed locally on a computer using the IP Security Policy Management MMC snap-in.

Multiple policies and filters may be stored on a machine, but only one policy at a time may be assigned

Leaving the Default Response filter enabled opens port 88 for Kerberos. If not using Kerberos to authenticate for an encrypted channel, this filter may be disabled

A filter may have only one filter action assigned, but it may have multiple items in the filter list to control multiple host, subnet and protocol connections

Filter items which require the same filter action should be grouped into one filter when possible for best practices

Group policy assignments override local IPSec policy assignments

Avoid reusing filters on multiple policies since the local machine stores these filters. If an existing filter is reused to create a policy it will overwrite that filter on another policy

Server 2003 and Security Recommendations:Using the MIT Windows Update Services

Options Domain default – Option 4: auto download and auto install any day @ 2:00 AM

Action – nothing Usually good for simple file and print servers, simple web servers

Custom setting – Option 4: Auto download and auto install on custom schedule Action – Set Computer Settings/Administrative Templates/Windows Components/Windows Update/Configure

Automatic Updates to Option 4: Auto download and notify for install, and set custom schedule below

Custom setting – Option 3: Auto download and notify for install Action – Set Computer Settings/Administrative Templates/Windows Components/Windows Update/Configure

Automatic Updates to Option 3: Auto download and notify for install

Do not set/reset the WSUS server name, this is already done When using option 3, a balloon window notification will appear when new patches are available.

Patch install can be run manually from this interface If the administrator wishes, certain patch may be skipped using the client interface

Microsoft

InternetKMS Hosting

MachineKMS Hosting MachineKMS Hosting

MachineF5 Load balancers WSUS ServersMicrosoft

Overview Currently running Microsoft WSUS 3.0 Internal repository of patches synchronized

with Microsoft Only patches approved and tested by IS&T

are available through WSUS Applied by default on all WIN.MIT.EDU

machines – auto download and auto install

Windows Vista:Connecting via Remote Desktop

Similar to disconnected operations, IS&T is awaiting a hotfix from Microsoft that will remove the requirement of using the UPN (a user principal name: i.e. username@REALMNAME) format to connect via remote desktop

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers

This issue was resolved when IS&T worked with Microsoft regarding XP SP1 and the fix was rolled into SP2. Unfortunately, this code was not ported to the Vista release and we are awaiting the Kerberos regression hotfixes from Microsoft to be re-released for Vista

The Remote Desktop client will not store the UPN format when it makes connections to Vista machines the way it does to XP and 2003. We are reporting this behavior to Microsoft as well

The Windows Aero interface cannot be displayed over Remote Desktop

Windows Server 2008

Support in WIN.MIT.EDU Computers running Server 2008 may be joined to Active Directory Support for OS groups has been added for software installation assignments

Behavior of roaming profiles and folder redirection is the same as Vista The .winprofile.V2 directory used by Vista is also used by Server 2008

Disable IPV6 Like Vista, Server 2008 enables IPV6 by default. We recommend that

IPV6 be turned off for network connections on MITnet. Like Vista requires Activation

Vista uses a DNS based KMS activation for volume media for computers within MITnet.

DNS based activation will be integrated for Server 2008 during the Spring term. In the interim activation may be done manually: c:\windows\system32\slmgr.vbs -skms kms2008.mit.edu c:\windows\system32\slmgr.vbs –ato

Looking forward for 2009 Continued deployment and enhancements to Altiris

Hardware and Software inventory and asset management (current) Software deployment via task scheduling (planned)

WDS: Windows Deployment Services (WDS) is the revised version of Remote Installation Services (RIS). WDS enables the deployment of Microsoft Windows operating systems, particularly Windows Vista and Windows Server 2008

McAfee ePolicy Orchestrator (ePO): ePO is an integrated management platform that manages the security needs of your client computers

Web console, deploy McAfee agents, DAT’s, McAfee products, configuration policy manager, reporting

Security and using Server 2003: Lab

Lab 5: Using IPSec and the Windows Firewall