WIN.MIT.EDU Container Administrator Training

1. 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

2. 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

3. WIN.MIT.EDU Architecture Moira Populator MIT Kerberos KDC’s WIN.MIT.EDU DC’s MITnet DNS Data Warehouse DFS Storage Query Data Feed

4. 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

5. 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 – 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/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)

6. 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. • 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.

7. 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-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: • 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

8. 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

9. 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/

10. Container maintenance: Lab • Lab: 1: Using Moira tools

11. 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

12. Container maintenance: Group Policy Management Tools • Group Policy Management Console – gpmc.msc • Preferred GP Management tool. There is an add-on MSU with updated tools • 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 • Gpresult - Command line utility • GPFind.pl – win.mit.edu command line script • Search by GPO name and launch the gpeditor

13. 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

14. 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

15. 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)

16. 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.

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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.

23. 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

24. 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

25. Container maintenance: Lab Lab: 2: Group Policy Management tools

26. 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:Logon

27. 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

28. 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

29. 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

30. 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.

31. 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.

32. 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/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 • 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: • 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.

33. 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.

34. 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.

35. 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.

36. 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

37. 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.

38. RIS/WDS: PXE 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) is now available by selecting the WIN.MIT.EDU – WDS option in the PXE menu. WDS supports Vista and Server 2008 and Win 7

39. User features:Lab • Lab 3: Using Previous Versions on the Home directory • Lab 4: Desktop Sync

40. 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

41. 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

42. Server 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/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.

43. 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

44. 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

45. 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 are available through WSUS • Applied by default on all WIN.MIT.EDU machines – auto download and auto install Microsoft F5 Load balancers WSUS Servers • 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

46. 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\Microsoft\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

47. Windows Server 2008 /2008 R2 • Support in WIN.MIT.EDU • Computers running Server 2008 R2 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 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

48. Security and using Server 2003: Lab • Lab 5: Using IPSec and the Windows Firewall