AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 20. Windows Security Policy (Cont. 1)

10.8.20  Windows Security Policy (Cont. 1)

10.8.20.5 
Technical Controls

10.8.20.5.1 
Identification and Authentication

10.8.20.5.1.9  (03-28-2008)
Account Management

  1. User accounts shall be reviewed to determine if the account should be renamed or disabled to deter unauthorized access to standard accounts, such as the standard administrator account. This shall include, but not be limited to the accounts in the security options settings detailed below. Additionally, Windows and Windows applications, when first installed, may contain default passwords (e.g., User = guest, password = guest).

  2. Default passwords shall be changed. The following is an explanation of the Windows specific Security Options dealing with accounts.

    1. Account: Administrator account status
      Each Windows installation creates an "Administrator" account that has the highest access to the system. The account has the highest possible access and can bypass most security controls local to the machine; it is comparable to the "root" account in Unix. Many system maintenance features require use of the Administrator account. However, in some environments, the existence of this account can present a security risk. By setting the " Administrator Account Status" to disabled, the account becomes unavailable.

    2. Account: Guest account status
      The Guest account can provide some regulation to unauthenticated users. Disabling this account will prevent unknown users being authenticated as Guests.

    3. Account: Limit local account use of blank passwords to console logon only
      Windows divides computer logons into two main types: console or local logons and remote logons. In a console logon, one physically logs on to the device with the attached keyboard. Remote logons are performed across the network using various protocols such as telnet, FTP and remote desktop.

    4. Account: Rename administrator account
      (Windows 2000 - Rename administrator account)
      Often disabling the Administrator account is not practical. However, simply knowing the name of an account on a machine can be valuable information to an attacker. In an attempt to hide the account define this policy setting and use a name unique to an implementation.

    5. Account: Rename guest account
      (Windows 2000 - Rename administrator account)
      Similar to the Administrator account, the Guest account shall be renamed and disabled. The operating system places additional safeguards on the Guest account, and it is less of a target than the Administrator account. It still deserves significant attention and warrant changing the account name.

    • See Exhibit 10.8.20-4, Security Options. Account Management settings are contained therein.

10.8.20.5.1.9.1  (03-28-2008)
Additional Default Accounts

  1. Additional default Windows accounts that might be installed and shall be disabled include:

    1. Support_388945a0 account - The Support_388945a0 account enables Help and Support Service interoperability with signed scripts. This account is primarily used to control access to signed scripts that are accessible from within Help and Support Services. This account shall be disabled.

    2. HelpAssistant account - This account is used only for Remote Assistance sessions. The HelpAssistant account shall be disabled.

10.8.20.5.1.10  (03-28-2008)
Account Logon Security Options

  1. Below is an explanation of the Windows specific Security Options dealing with Account Logon.

  2. Interactive logon: Display user information when the session is locked
    (Windows 2003 only)    .
    This policy setting determines whether the account name of the last user to log on to the client computers in your organization will display in each computer's respective Windows logon screen. If you enable this policy setting, intruders will not be able to collect account names visually from the screens of desktop or laptop computers in your organization.

  3. Interactive Logon: Do not display last user name
    (Windows 2000 - Do not display last user name in logon screen).
    Anyone attempting to log into a computer may see the name of the last valid user who logged on to that system. This does not prevent displaying the currently logged on user when unlocking a workstation. This information may seem trivial, but it helps an attacker tie a workstation to a particular individual, or may help an attacker gain access to a stolen mobile device

  4. Interactive Logon: Do not require CTRL+ALT+Delete
    (Windows 2000 - Disable CTRL+ALT+DEL requirement for logon).
    When CTRL+ALT+Delete is typed, a user is guaranteed that the operating system authentication process will handle the logon request. With the CTRL+ALT+Delete requirement lifted, the user could actually be typing their password into a trojaned application, rather than the operating system authentication process.

  5. Interactive Logon: Message text for users attempting to log on
    (Windows 2000 - Message text for users attempting to log on).
    Displaying of a system use notification, a system banner, provides criminal trespass warnings for those that unlawfully enter system resources.

  6. Interactive Logon: Message title for users attempting to log on
    (Windows 2000 - Message title for users attempting to log on).
    The message title acts as part of the logon banner discussed above. The workstation places this text as the title for the logon banner window.

  7. Interactive Logon: Number of previous logons to cache
    (Windows 2000 - Number of previous logons to cache - in case domain controller is not available).
    When a workstation belongs to a domain, users can log on to it using domain credentials. The domain credentials can be cached in the local workstation’s Security Accounts Manager (SAM) database. On next logon, should no domain controller be available, the user can still log on locally by authenticating against the cached account information.

  8. Interactive Logon: Prompt user to change password before expiration
    (Windows 2000 - Prompt user to change password before expiration).
    Should a user’s password be near its expiration date, the logon process warns the user and asks if they would like to change the password. Once the password has expired, the user will be required to change the password to complete the logon. This setting governs the window of convenience between the time when the system offers the user to change the password, and the time when they are required to change the password.

  9. Interactive Logon: Require Domain Controller authentication to unlock workstation.
    Enable this setting to protect against brute force password attacks through the screen saver. However, enabling it will hinder the user who locks and hibernates their workstation, and then attempts to resume when the domain controller is unavailable. Disabling this setting (or leaving it undefined) minimizes domain controller traffic.

  10. Interactive Logon: Require smart card.
    Requires a smart card for authentication.

  11. Interactive Logon: Smart card removal behavior
    (Windows 2000 - Smart card removal behavior).
    When users authenticate with smart cards, the system can be set to lock or log out the user when the smart card is removed.

  12. Domain Member: Disable machine account password changes
    (Windows 2000 - Prevent system maintenance of computer account password).
    If a computer is a member of a domain, it has an account within the domain. During the boot up process, the computer logs in to the domain and establishes a secure channel for the exchange of sensitive information. Although the account cannot be used for interactive logons, it can be used to authenticate to domain resources. This setting only impacts workstations which have joined a domain.

  13. Domain Member: Maximum machine account password age.
    This setting determines how often the computer resets its password

  14. Microsoft Network Server: Amount of idle time required before suspending session
    (Windows 2000 - Amount of idle time required before disconnecting session).
    This setting applies specifically to communications using the SMB protocol. When a client establishes a connection with an SMB server, they exchange credentials, perform authentication, and set aside resources to manage the connection. After a period of inactivity, the client or server may close the connection to conserve resources. When the client again attempts to use the SMB server, it reestablishes the connection without interaction with the user. The reconnection typically happens fast enough to hide the activity from the user. Computers that do not share resources with other Windows computers are not affected by this setting

  15. Microsoft network server: Disconnect clients when logon hours expire.
    This setting only applies to workstations joined to a domain, as logon hours cannot be set for local accounts. Additionally, this applies only to network connections established with the SMB protocol. Domain accounts may be limited to specific hours when they may be used. By default, the domain controller only enforces these settings upon logon, but not after the session is established. With this setting enabled, should a user remotely log in to this workstation (the workstation acts as a server), the user’s network connections will be closed when their allotted time has been reached.

  16. Network security: Force logoff when logon hours expire.
    This security setting determine whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. When this policy is enabled, it causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire.

  17. Shutdown: Allow System to be Shut Down Without Having to Log On.
    (Windows 2000 - Allow System to be Shut Down Without Having to Log On)
    Some systems run critical processes and should only be shut down by authorized users.

  18. Prevent System Maintenance of Computer Account Password
    (Windows 2000 only).
    Ensures that the systems protect passwords from unauthorized disclosure and modification when stored and transmitted.

    • See Exhibit 10.8.20-4, Security Options. Account Logon settings are contained therein.

10.8.20.5.2  (03-28-2008)
Access Control

  1. The IRS shall implement access control measures that shall provide protection from unauthorized alteration, loss, unavailability, or disclosure of information. Access control shall follow the principle of least privilege and separation of duties. See IRM 10.8.1 for general access control requirements.

10.8.20.5.2.1  (03-28-2008)
Windows Roles and User Groups

  1. Each individual and organization that is part of the development, implementation, maintenance, or use of a Windows system or network, has an important role in maintaining system trust.

  2. This section further details the separation of duties requirements stated in IRM 10.8.1. For example, an employee or contractor shall not be responsible for performing security-related duties on any system for which they are a Workstation Administrator (WA). See System Administrator in IRM 10.8.1.

  3. This section covers only Windows specific groups. See IRM 10.8.2for general security roles and responsibilities.

  4. Windows Group Requirements

    1. Windows operating system default groups are used to facilitate role-based access.

    2. Windows groups shall be established with least privilege access requirements.

    3. The management and documentation of Windows groups shall be incorporated into the operational system life cycle.

    4. Individuals shall be added only to a given group when the individual has a specific need for the implied functionality provided by the given group.

    5. Membership in groups shall be periodically reviewed on the same schedule as the review of IRS IT resources and users’ accounts/profiles. See IRM 10.8.1, Access Control section for requirements.

10.8.20.5.2.1.1  (03-28-2008)
Workstation Administrator (WA)

  1. A WA equates to an SA as defined in IRM 10.8.2 and performs the same duties. The WA is the local administrator account within the local administrator group.

  2. A WA can manage a single or group of workstations.

  3. A WA shall not be a domain administrator.

  4. The WA shall log in using their own user account and use the " Run As" command to ensure all administrative actions can be tracked to the individual.

  5. Domain administrators shall not be given the WA password.

10.8.20.5.2.1.1.1  (03-28-2008)
Workstation Administrator Group

  1. The Workstation Administrator Group, are local administrator accounts within the local administrator group.

    Note:

    The local administrator account is renamed and disabled, and shall not be used.

  2. Domain Administrators shall not be included in the Workstation Administrator Group.

  3. The Workstation Administrator Group shall be limited to authorized, trained employees.

10.8.20.5.2.1.2  (03-28-2008)
Domain Administrator (DA)

  1. The Domain Administrator (DA) is a member of the Domain Admins Group and shall manage the security configuration of the workstations and servers of the domain through the security policy.

  2. The DA shall add, change and delete workstations and servers within the domain, following CM procedures.

  3. The DA shall add, change and delete users within the domain per the Form 5081.

  4. The DA shall perform relevant monitoring of the domain.

  5. The DA is the administrator for the domain controllers.

    Note:

    The DA can function as a WA for any workstations in the domain.

10.8.20.5.2.1.2.1  (03-28-2008)
Domain Administrator Group

  1. Procedures shall be established for determining membership in Domain Admins groups.

  2. Membership in this group shall be limited to trained employees who are assigned responsibility for managing servers and the domain infrastructure.

  3. Management shall review the membership of Domain Admins groups, at least annually, to validate the need for continued privileged group membership.

  4. Administrators shall logon using their unique user logon, not the general "Administrator" or renamed Administrator account.

10.8.20.5.2.1.3  (03-28-2008)
Account Operator

  1. Account Operators are members of the Account Operators Group. Local management shall identify members of the Account Operators group needed to perform help desk type functions.

  2. The Account Operators Group shall manage all domain user accounts:

    1. Adding user accounts per Form 5081. See IRM 10.8.1 for Access Authorization.

    2. Deleting or disabling user accounts; and

    3. Unlocking accounts. Account Operator activities are predicated on the Enterprise Account Administration group not being responsible for a given system/application.

10.8.20.5.2.1.3.1  (03-28-2008)
Account Operators Group

  1. The Account Operators Group shall include only designated employees, with the responsibility and authority for adding/deleting users and managing their accounts. This may include unlocking user accounts, as necessary.

  2. The Account Operators Group shall add or remove workstations from the domain, as authorized by written documentation.

  3. The Account Operators Group shall include only employees whose required capabilities warrant membership in this group.

10.8.20.5.2.1.4  (03-28-2008)
Backup Operator Group

  1. The Backup Operators Group:

    1. Backs up and restores files;

    2. Can only logon locally to a workstation; and

    3. Shuts down a workstation.

  2. This group shall not be granted any other administrative tasks or capabilities.

10.8.20.5.2.1.5  (03-28-2008)
Power Users Group

  1. Members of the Power Users Group have rights, which are a superset of the Users group.

  2. The Power Users group shall be restricted to no users on all IRS systems.

10.8.20.5.2.1.6  (03-28-2008)
Server Operators Group (Domain Controllers)

  1. Members of this group can administer domain servers. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.1.7  (03-28-2008)
SecSpec Group

  1. The SecSpec group, also known as the Security Admins Group, is responsible for reviewing all activity of administrators and responsible for administration of IT equipment.

  2. The SecSpec group ensures that all users and systems are compliant with security requirements.

10.8.20.5.2.1.8  (03-28-2008)
Tivoli_Admin_Privileges Group

  1. Tivoli_Admin_Privileges group exists on all machines, and is used to administer Tivoli.

10.8.20.5.2.1.9  (03-28-2008)
DHCP Administrators Group

  1. Members of this group can administer DHCP servers.

  2. Membership to this group shall be carefully controlled and restricted.

  3. Only Domain Admins and Enterprise Admins should be members of the DHCP Administrators group.

10.8.20.5.2.1.10  (03-28-2008)
Group Policy Restricted Groups

  1. The Restricted Groups policy can control group membership. Using the policy, an SA can specify what members are part of a group. Any members that are not specified in the policy are removed during configuration or refresh. In addition, the reverse membership configuration option ensures that each Restricted Group is a member of only those groups that are specified in the Member Of column.

  2. An empty "Members" list means the restricted group shall have no members while an empty "Member Of" list means it does not matter what groups the restricted group belongs to.

  3. As an example, if the IRS wanted the Administrators group to only consist of the built-in Administrator account, the Administrators group could be added to the Restricted Groups and added to the Members of Administrators column. This setting could prevent other users from elevating their privilege to the Administrators group through various attack tools and hacks.

10.8.20.5.2.1.11  (03-28-2008)
Service Accounts

  1. Service accounts are to be treated as user accounts. Service accounts are used to perform scheduled services and other Windows maintenance tasks.

  2. See IRM 10.8.1for the general requirements of service accounts.

  3. There may be instances where a service account password cannot be changed or reset without adversely impacting the system. In this instance, the "Password Never Expires" may be selected/checked for the service account password. This is the only allowable exception.

  4. A descriptive identifier shall be created for the service account and noted in the project technical documentation. Place "svc" in the existing description field to enable the Windows Policy Checker Tool to correctly identify the service account. Alternatively, the account can be identified by adding "svc" to the start of or at the end of the user name.

10.8.20.5.2.1.12  (03-28-2008)
Fire Call Account

  1. See IRM 10.8.1for requirements.

10.8.20.5.2.1.13  (03-28-2008)
LocalLogonBatch Group

  1. The LocalLogonBatch group exists only on servers and provides members the user right to logon on as a batch job.

  2. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.1.14  (03-28-2008)
LocalLogonService Group

  1. The LocalLogonService group exists only on servers and provides members the user right to logon on as a service.

  2. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.1.15  (03-28-2008)
LocalLogonAllowed Group

  1. The LocalLogonAllowed group exists only on servers and provides members the user right to log on locally.

  2. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.1.16  (03-28-2008)
LocalSQLService Group

  1. The LocalSQLService Group is a local group that exists on SQL servers and provides members certain user rights that are required for SQL functionality.

  2. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.1.17  (03-28-2008)
IRS GPO Admins Group

  1. By default, in Active Directory domains, the Domain Admins group is allowed to create, modify, delete, and link Group Policies Objects (GPO). However, in the IRS environment, this group is replaced by IRS GPO Admins Group. Not all the members of the Domain Admins group are authorized to develop or manage GPOs in Active Directory IRS Domains. The group exists in each Active Directory Domain and is delegated to have the rights to link GPOs and to change the link orders to Domains, Sites, and OUs.

  2. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.1.18  (03-28-2008)
GPO Read-Only Users Group

  1. This group only exists in the Active Directory DS domain. This group is designed to allow authorized administrative users to read the Single-Purpose Group Policies Objects (GPOs), and its links and link orders.

  2. Membership to this group shall be carefully controlled and restricted.

10.8.20.5.2.2  (03-28-2008)
User Rights

  1. Below is a list of the Windows specific settings dealing with user rights.

    1. Access this computer from the network

    2. Act as part of the operating system

    3. Add workstations to domain

    4. Adjust memory quotas for a process (2000: Increase quotas)

    5. Allow logon through Terminal Services

    6. Back up files and directories

    7. Bypass traverse checking

    8. Change the system time

    9. Create a pagefile

    10. Create a token object

    11. Create Global Objects

    12. Create permanent shared objects

    13. Debug programs

    14. Deny access to this computer from the network

    15. Deny logon as a batch job

    16. Deny logon as a service

    17. Deny logon locally

    18. Deny logon through Terminal Services

    19. Enable computer and user accounts to be trusted for delegation

    20. Force shutdown from a remote system

    21. Generate security audits

    22. Increase scheduling priority

    23. Load and unload device drivers

    24. Lock pages in memory

    25. Log on as a batch job

    26. Log on as a service

    27. Log on locally (2003: Allow Log on Locally)

    28. Manage auditing and security log

    29. Modify firmware environment values

    30. Perform volume maintenance tasks

    31. Profile single process

    32. Profile system performance

    33. Remove computer from docking station

    34. Replace a process level token

    35. Restore files and directories

    36. Shut down the system

    37. Synchronize directory service data

    38. Take ownership of files or other objects

    • See Exhibit 10.8.20-5. User Rights settings are contained therein.

    • See Exhibit 10.8.20-32, Glossary, under "User Rights" .

10.8.20.5.2.3  (03-28-2008)
Screen Saver

  1. A screen saver with the password-protected option shall be enabled for all Microsoft Windows operating systems.

  2. The system lock shall be invoked after a period of inactivity as whose length is set by IRM 10.8.1. All users shall have password-protected screen savers that locks the system after this period of inactivity.

  3. Animated screen savers shall not be used on Windows systems. The Logon or "Blank Screen" screen saver is recommended to be used.

10.8.20.5.2.4  (03-28-2008)
Domain Controller Security Options

  1. Below is an explanation of the Windows specific Security Options dealing with the Domain Controller.

  2. Domain Controller: Allow server operators to schedule tasks
    Windows 2000 - Allow server operators to schedule tasks (domain controllers only)

  3. Domain Controller: LDAP server signing requirements

  4. Domain Controller: Refuse machine account password changes

    • See Exhibit 10.8.20-4, Security Options. Domain Controller security settings are contained therein.

    • See Exhibit 10.8.20-32., Glossary, under "Domain Controller" .

10.8.20.5.2.5  (03-28-2008)
Device Security Options

  1. Below is an explanation of the Windows specific Security Options dealing with device settings.

  2. Devices: Allow undock without having to log on

  3. Devices: Allowed to format and eject removable media
    Windows 2000 - Allowed to eject removable NTFS media

  4. Devices: Prevent users from installing printer drivers
    Windows 2000 - Prevent users from installing printer drivers

  5. Devices: Restrict CD-ROM access to locally logged-on user only
    Windows 2000 - Restrict CD-ROM access to locally logged-on user only

  6. Devices: Restrict floppy access to locally logged-on user only
    Windows 2000 - Restrict floppy access to locally logged-on user only

  7. Devices: Unsigned driver installation behavior
    Windows 2000 - Unsigned driver installation behavior

    • See Exhibit 10.8.20-4, Security Options. Device settings are contained therein.

10.8.20.5.2.6  (03-28-2008)
Network Access Security Options

  1. Below is an explanation of the Windows specific Security Options dealing with network access.

  2. Network Access: Allow anonymous SID/Name translation

  3. Network Access: Do not allow anonymous enumeration of SAM accounts

  4. Network Access: Do not allow anonymous enumeration of SAM accounts and shares
    Windows 2000: Additional restrictions for anonymous connections

  5. Network Access: Let Everyone permissions apply to anonymous users

  6. Network Access: Named pipes that can be accessed anonymously

  7. Network Access: Remotely accessible registry paths
    (For Windows XP, this setting includes subpaths)

  8. Network Access: Remotely accessible registry paths and subpaths

  9. Network Access: Restrict anonymous access to Named Pipes and Shares

  10. Network Access: Shares that can be accessed anonymously

  11. Network Access: Sharing and security model for local accounts

  12. Additional restrictions for anonymous connections (Windows 2000 only)
    Allows the reduction in the risk of unauthorized access of guest and anonymous connections.

  13. DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax.
    (Available in Windows 2003 SP1 and Windows XP SP2 or greater only)

  14. DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax.
    (Available in Windows 2003 SP1 and Windows XP SP2 or greater only)

    • See Exhibit 10.8.20-4, Security Options. Network Access settings are contained therein.

    • See Exhibit 10.8.20-32, Glossary, under"Network Access" .

10.8.20.5.2.7  (03-28-2008)
System Objects and Settings Security Options

  1. Below is an explanation of the Windows specific Security Options dealing with system objects and settings.

  2. System objects: Default owner for objects created by members of the Administrators group.
    When an Administrator creates an object (file, directory, account, or any object which obtains and ACL from the operating system), an owner will be assigned. Normally, the account which created the object is assigned as the owner; however, changing this option allows assignment to the "Administrators Group" rather than an individual account.

  3. System objects: Require case insensitivity for non-Windows subsystems.
    The Windows operating systems ignore case when accessing resources; for example, "C:\/Windows" , "C:\/WINDOWS" and " c:\/windows" all refer to the same directory. However, the Windows kernel allows interfaces with other case-sensitive operating systems (e.g., Unix). Enabling this setting causes the interoperability features to be case-insensitive as well. This setting has no effect when the workstation communicates only with other Windows systems

  4. System objects: Strengthen default permissions of internal system objects.
    This setting strengthens the ACL of share objects.

  5. System Settings: Optional subsystems
    Can define subsystems which support running applications. The default entry of "POSIX" allows the POSIX subsystem to run. Defining this option but leaving the list blank will effectively disable the POSIX subsystem, which is only useful for Unix emulation services running on Windows. Subsystems can spawn processes which access multiple user sessions. The poorly written subsystem may allow a process to escalate privileges by accessing another account’s process.

  6. System Settings: Use Certificate Rules on Windows Executables for Software Restriction Policies Software restriction policies define the software that is allowed to run on a computer. These policies help protect against malicious code introduced into the environment. Policies can be set based on a hash of the executable, the path to the executable, the source internet zone (for MSI packages only), or based on the certificate used to sign the executable.

    • See Exhibit 10.8.20-4, Security Options. Settings for System Objects and Settings are contained therein.

10.8.20.5.2.8  (03-28-2008)
File, Folder and Directory Access Control

  1. The following are the File, Folder and Directory Access Controls for the Windows environment. See IRM 10.8.1 for general information and access control requirements.

10.8.20.5.2.8.1  (03-28-2008)
Directory Locations

  1. Server User Home Directory

    1. Windows operating systems domain/project owners shall pursue installation of servers with sufficient capacity to store user data files in home directories.

    2. Workstations shall include a mapped network drive (home share), supplemented by user training and awareness of this feature. This installation will provide the highest level of protection for data files and assurance that adequate file backup is occurring.

    3. Users shall be notified of the length of time backup media is retained. Backup media containing home directory data will be kept according to retention requirements defined in IRS procedures.

  2. Workstation User Data Directory

    1. System owners shall ensure that COTS application settings are configured to save user files in specific directories/folders. The recommended location is D:\/Users\/userlogonname (or C:\/... if the D:\/ partition is too small to retain the information). Users shall receive instructions on these procedures with the goal that all data files (whether sensitive or non-sensitive) are saved in these locations.

    2. Users are responsible for the backup of any files in these locations.

  3. Temporary Directories

    1. Software packages will occasionally store open files in temporary (C:\/temp or \/tmp) directories while in use. Since these renamed files (e.g., ~WRS000.tmp) may contain sensitive information, permissions will be applied, only as necessary to use the software.

10.8.20.5.2.8.2  (03-28-2008)
User Directory Permissions

  1. Domain/project owners shall ensure that NTFS permissions for server user home directories are limited to the settings contained in Exhibit 10.8.20-10.

10.8.20.5.2.8.3  (03-28-2008)
File and Folder Permissions

  1. Folders and files not explicitly listed in the Exhibits are assumed to inherit the permissions of their parent folder. Folders with " ignore" are explicitly excluded and retain their original permissions.

  2. The following system variables are referenced in the file permissions:

    1. %SystemDrive% - The drive letter on which Windows is installed (usually C:\/).
      %SystemRoot% - The folder containing the Windows operating system files (usually %SystemDrive%\/winnt for Windows 2000 systems, %SystemDrive%\/windows for Windows XP and 2003).

    2. %SystemDirectory% - %SystemRoot%\/system32.

    • See Exhibit 10.8.20-6 for Program Files and Folder Permissions.

    • See Exhibit 10.8.20-7 for System Directory (C:\/winnt\/system32 or C:\/windows\/system32) File and Folder Permissions.

    • See Exhibit 10.8.20-8 for System Drive (C:\/) File and Folder Permissions.

    • See Exhibit 10.8.20-9 for System Root (C:\/winnt or C:\/windows) File and Folder Permissions.

10.8.20.5.2.8.4  (03-28-2008)
Creating Shares

  1. When creating shares and share permissions, adhere to the following criteria.

    1. Ensure that "Everyone" is not given Full Control on any shares.

    2. Use the "Authenticated Users" group in place of the "Everyone" group.

    3. Give users and/or groups the minimum amount of permissions needed on a share.

    4. On Domain Controllers, these requirements are not applicable to the netlogon and sysvol shares.