WIN.MIT.EDU Container Administrator Training

Architecture Overview

Container maintenance and group policy


Lab
User features

Lab

Disconnected operation/Laptop support

PXE Installation Services

Security and using Windows Server

Windows 7

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”



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


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
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
Moira
Populator
MIT Kerberos KDC’s
WIN.MIT.EDU DC’s
MITnet DNS
DFS Storage
Query
Data Feed
Data Warehouse
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



Submit a Container Maintenance Job: SelfMaint – Will be phased out over 2010



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/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.
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:




General instructions:






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?
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.
Windows 7: An additional reboot is usually required to complete the trust relationship of
the machine and AD. This will resolve the error – no account found in security database.
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




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-container
If 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:


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.
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





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



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
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:



Add / remove users based on a file:



Blanche groupname –a (add)
Blanche groupname –d (remove) user
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
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




Resultant Set of Policy – rsop.msc



Launched by gpmc or dsa, edit settings and a new preferences section for Vista
Gpupdate - Command line utility


Views and info of containers and machines
Group Policy Editor – gpedit.msc


Diagnostic tool to view how GP inheritance is working
AD Users and Computers – dsa.msc


Preferred GP Management tool. There is an add-on MSU with updated tools
View GPO settings and permissions
Can launch gpeditor
Refresh group policy
Gpresult - Command line utility
GPFind.pl – 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



MIT Kerberos for Windows 2.6.5
MIT LogonBefore Provider





Print queue resolution
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.

The latest release of KfW does not fix the Vista UAC issue. 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:









System Section highlights:






User Profiles
Scripts
Logon
Disk Quotas
Group Policy
Network Section highlights:







NetMeeting
RSS Feeds
Task Scheduler
Windows Messenger
Windows Media Digital Rights Management
Windows Movie Maker
Windows Update - patching
Windows Media Player
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



An opt-out of all Kerberized printer clients is available
Network Printers: Standard Microsoft Network Printers assigned per machine


additional drivers can be added but in some cases are not compatible with the UNIX print queue
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. Now with the release of Server 2008 Microsoft
provides their own tools so regpoledit no longer needs to be used.

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

Selfmaint will be phased out over 2010 and replaced with the new Microsoft Server 2008 tool to
assign scheduled tasks via group policy.

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
Win7.group : Machines running Windows 7
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: 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 or Windows 7 computer
with a local account enter
machinename\username in the username field.
User features:
Web forms for users

Change your Kerberos Password.


Change Your Active Directory Password.



https://wserv.mit.edu/fcgi-bin/cpw
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/Windows 7:
Default 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/Windows 7:
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:





Desktop-Sync: In order to preserve consistency of the desktop files and shortcuts for users
logging into both XP and Vista/Win 7 machines, WIN.MIT.EDU synchronizes the desktop
folders of both profiles when a user logs on:





XP: H:\.winprofile
Vista/Windows 7: 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
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 IS&T remediated the issue.
Windows 7 has changed back from Documents to My Documents, we
changed the User Shell Folder registry key in the default profile back to
My Documents (effective for new profiles)
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 2008 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.
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/Win 7, 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): 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/WDS: PXE Installation Services

Requirements





Execution




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
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) is now available by selecting the WIN.MIT.EDU
– WDS option in the PXE menu. WDS supports Vista and Server 2008 and Win 7
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


(Allow) Logon Locally





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


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


Generally restricted to the local Administrators group
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 Security Recommendations: Windows
Firewall

Supports






Limitations



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
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/Win 7)
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 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 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 and Security Recommendations:
Using the MIT Windows Update Services

Overview





Currently running Microsoft WSUS 3.0
Internal repository of patches synchronized
with Microsoft
Only patches approved and tested by IS&T Microsoft
Microsoft
are available through WSUS
Applied by default on all WIN.MIT.EDU
machines – auto download and auto install
Internet
KMS Hosting
KMS
Hosting
Machine
KMS
Hosting
F5 Load balancers
WSUS
Servers
Machine
Machine
Options

Domain default – Option 4: auto download and auto install any day @ 2:00 AM



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 – nothing
Usually good for simple file and print servers, simple web servers
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
Windows Vista/Win 7:
Connecting via Remote Desktop

Similar to disconnected operations, a UPN
(a user principal name: i.e.
username@REALMNAME) format is used
to connect via remote desktop

HKEY_CURRENT_USER\Software\Micros
oft\Terminal Server Client\Servers

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 /2008 R2

Support in WIN.MIT.EDU



Behavior of roaming profiles and folder redirection is the same as Vista



Computers running Server 2008 R2 may be joined to Active Directory
Support for OS groups has been added for software installation assignments
The .winprofile.V2 directory used by Vista is also used by Server 2008
Disable IPV6
 Like Vista and Window 7, Server 2008 enables IPV6 by default. We
recommend that IPV6 be turned off for network connections on
MITnet.
Like Vista and Windows 7, server 2008 requires Activation


Vista uses a DNS based KMS activation for volume media for computers
within MITnet.
DNS based activation will is integrated for Server 2008/2008 R2
Security and using Server 2003:
Lab

Lab 5: Using IPSec and the Windows Firewall