Client-6.1-6.4.docx
Document Details
Uploaded by ExtraordinaryMars
Anoka-Ramsey Community College
Tags
Full Transcript
Group Policy Categories Account policies - Use account policies to control: - Password settings - Account lockout settings - Kerberos settings - Account policies only exist when configured in a GPO linked to the domain itself. They cannot be applied if the GPO is link...
Group Policy Categories Account policies - Use account policies to control: - Password settings - Account lockout settings - Kerberos settings - Account policies only exist when configured in a GPO linked to the domain itself. They cannot be applied if the GPO is linked to an OU. Local policies-audit policy - Use audit policy settings to configure auditing for events (such as log on, account management, or privilege). Local policies-User Rights Assignment - Computer policies include a special category of policies called *user rights* . User rights identify system maintenance tasks and the users or groups who can perform those tasks. Examples of User Rights Assignment include: - Access a computer from the network (the ability to access resources on the computer through a network connection). - Load and unload device drivers. - Backup files and directories (does not include restoring files and directories). - Shut down the system. - Remove a computer from a docking station. Local policies-security options - Security options allow you to apply or disable rights for all policy users. Examples of security options policies include: - Computer shut down when the security event log reaches capacity. - Unsigned driver installation. Registry policies - You can use registry policies to: - - - - File system policies - Use file system policies to configure file and folder permissions that apply to multiple computers. For example, you can limit access to specific files on all client computers. Software restriction policies - Use software restriction policies to define the software permitted to run on any computer in the domain. You can apply these policies to specific users or all users. You can use software restrictions to: - Identify allowed or blocked software. - Allow users to run only specified files on multi-user computers. - Determine who can add trusted publishers. - Apply restrictions to specific users or all users. Administrative templates - Administrative templates are registry-based settings that you can configure within a GPO to control the computer and overall user experience, such as: - Use Windows features such as BitLocker, offline files, and parental controls. - Customize the Start menu, taskbar, or desktop environment. - Control notifications. - Restrict access to Control Panel features. - Configure Internet Explorer features and options Starter Group Policy Objects - Starter Group Policy Objects, or Starter GPOs, allow you to store a collection of administrative template policy settings in a single object. - When you create a new GPO from a starter GPO, the new GPO has all of the administrative template policy settings and values defined in the starter GPO. - You can easily distribute starter GPOs by exporting and then importing them to another environment. A policy is a set of configuration settings applied to objects such as users or computers. Group policies allow the administrator to apply multiple settings to multiple objects within the Active Directory domain at one time. Collections of policy settings are stored in a Group Policy object (GPO). The GPO includes registry settings, scripts, templates, and software-specific configuration values. Managing Local Group Policy - - - Managing domain GPOs - - - - - - - - Assigning GPO permissions - - - - - Using Administrative Templates - - Using a Central Store - - - - **GPO Considerations** Keep in mind the following about GPOs: - If possible, combine multiple settings into one Group Policy. Reducing the number of Group Policies that require processing reduces boot and logon time. - The Default Domain Policy contains the only account and password policies that will take effect unless you create a Password Settings object (PSO). - GPOs do not exist at the forest level. To enforce a GPO in multiple domains, create the GPO in one domain, export it, and import it into other domains. **GPO Categories** Each GPO has a common structure with hundreds of configuration settings that can be enabled and configured. Settings in a GPO are divided into two categories: Computer configuration - - - - - User configuration - - - - All computer policies run before any user policies run. Password policies define characteristics of passwords that are enforced by the system, such as the minimum number of characters or how often the passwords must be changed. **Account Lockout and Password Policies** Account lockout and password policies control passwords and user lockout properties for the entire domain. - Password Policy settings control characteristics enforced for user passwords. - Account Lockout Policy settings control what happens when a user enters one (or more) incorrect passwords. - Policy settings apply to the computer, not the user. - Although you can configure Account Policies settings in any GPO, only the settings configured in a GPO linked to the domain take effect. *"Enforce password history"* requires users to create unique passwords. Set this to a high number to keep users from frequently repeating passwords. Windows can remember up to 24 old passwords. *"Maximum password age"* requires the user to change the password after a given time. Setting this value to 0 means that the password never expires. A maximum password age must be configured for this setting to take effect. "*Minimum password age"* keeps users from changing passwords immediately after resetting their passwords. Doing so prevents users from defying the password history by initiating multiple password changes in a sequence to get back to their preferred password. The value must be less than the maximum age and should be a setting greater than 0. A setting of 0 allows the user to reset the password immediately. "*Minimum password length"* prevents users from using passwords that are too short. At a minimum, enforce passwords of eight characters or longer. *Password must meet "complexity requirements"* prevents passwords that are easy to guess or crack. This setting: - Requires users to create a password with a minimum of three of the four types of special characters (lowercase letters, uppercase letters, numbers, or !, @, \#, \$, %, \^, &, \*). - Prevents the use of dictionary words or any part of the user\'s login identification. - Requires that passwords be six characters long (or longer). *"Store passwords using reversible encryption"* is equivalent to storing plaintext passwords. This setting should be disabled unless a specific application requires access to the plaintext password. "*Account lockout duration"* determines the duration the account will be disabled (in minutes). When the time expires, the account will be unlocked automatically. When set to a value of 0, an administrator must unlock the account. "*Account lockout threshold"* determines the number of attempts a user can make before the account is locked. A typical setting is 3. "*Reset account lockout counter after"* determines the amount of time (in minutes) that must pass before the number of invalid attempts counter resets. **Granular Password Policies** Granular password policies allow you to create password policies for users and global groups separate from the password policy applied to the entire domain. For example, you could require an eight-character password for regular users and use granular password policies to require administrators to use 14-character passwords. Generally, it would be best to use account policies to enforce a domain-wide password policy. Then you would use granular password policies for groups of users with more restrictive password policy needs than the domain-wide password policy. You should know the following facts about granular password policies: - The domain must be running at the Windows Server 2008 domain functional level or higher. - Password policies affect only user account passwords, not computer account passwords. - Only members of the Domain Admins group can set granular password policies, but you can delegate the permission. - Granular password policies are saved as a Password Settings Object (PSO) in the Password Settings Container (PSC). - There is one default PSC. It cannot be renamed, deleted, or moved. - You can create additional PSCs, but they will not take effect. - The PSC holds one or more PSOs. You can define multiple PSOs with unique password policy settings. - PSOs have attributes for all the settings defined in the Default Domain Policy except Kerberos settings. - Policies can be applied to user accounts or global security groups. - You can apply each granular policy to multiple users and/or groups. - Granular password policies affect only users within the current domain. - When applied to OUs, the domain policies (or other group types) are excluded. When you move a user account to a different OU, remember to also change the group membership so that the granular password policy no longer applies. **Azure Username and Password Policies** Users have a User Principal Name (UPN) and password associated with their account. The User Principal Name must follow the following length constraints: - Up to 64 characters can be entered before the "@" symbol. - Up to 48 characters can be entered after the "@" symbol. - Up to 113 characters can be entered in total. The following character types are allowed in a UPN: - a-z - A-Z - 0-9 -.'\_-\#!\~\^ The following character types are *not* allowed in a UPN: - An "@" symbol cannot immediately precede the "." character. - The "@" sign can only be used when separating the username and domain. The following character types are allowed in an Azure AD password: - a-z - A-Z - Blank space - 0-9 - @ \# \$ % \^ & \* - \_ ! + = \[ \] { } \| \\ : \' ,. ? / \` \~ \" ( ) ; \< \> The following password restrictions apply to Azure AD: - Unicode characters cannot be used. - Passwords must use at least three of the following: symbols, numbers, uppercase letters, and lowercase letters. - A minimum of eight characters is required. - A maximum of 256 characters can be used. - Azure AD provides a global banned password list based on ongoing security analysis. An administrator cannot edit the default list but can add up to 100 banned words for a custom banned password list. The following default policies apply to Azure AD passwords: - The maximum password age (password expiration policy) is 90 days. - Users are notified of this expiration 14 days before the password expires. - The user cannot use the last password again when changing or resetting their password. **Azure Self-Service Password Reset** If a user forgets their password or gets locked out of their account, Azure AD provides the convenient option of a user self-service password reset. This reduces the time and effort needed to contact the help desk or administrator for a password reset. Note the following about the self-service password reset (SSPR): - SSPR can be enabled for none, all, or selected users. - If the user needs additional help with their reset, they can click on the **contact your administrator** link. Administrators can customize this button with their help desk email or URL. - By default, regular users are required to use one authentication method, and admin accounts are required to use two authentication methods for password resets. You can enable additional authentication methods as needed. - Before a user can unlock or reset, they need to register their contact information with Azure AD. This information is used for authentication. Best practices for the self-service password reset include: - If you are using SSPR for the first time, start with a small group of users before expanding to the full organization. Doing so helps you to work through potential user concerns. It also gives you time to familiarize yourself and your users with the registration process and workflow. - User contact information should be kept up to date. This ensures that the user can unlock their account when needed. - When testing the self-service password reset, you should use a non-administrator account. **Organizational Password Strategies** Use the following strategies to protect against password attacks: - Educate users on how to create and remember strong passwords. Enforcing strict password restrictions might weaken network security if you do not educate users about taking proper procedures to protect login credentials. If users do not understand the restrictions that have been implemented, users might try to circumvent these restrictions by writing down passwords. Take the following measures to educate users: - Tell users that they should not write down passwords or share login credentials with other users. - Teach users how to construct and remember complex passwords. For example, for the password *bw2Fs3d* , users might create the following sentence: *bob went 2* the capital *Florist shop* *3* times *daily* . - Educate users about social engineering tactics. Instruct them not to respond to requests for passwords from administrators or other seemingly trusted personnel. Implement policies that prevent administrators from asking for sensitive information. - Implement two-factor authentication. **Organizational Password Policies** Password policies detail the requirements for an organization\'s passwords. These policies can include the following: - The same password should never be used for different systems. - Accounts should be disabled or locked out after a specified amount of failed login attempts. - Passwords should never contain words, slang, or acronyms. - Users should be required to change their passwords within a certain time frame and use a rotation policy. - A strong password policy should be enforced. Strong passwords: - Contain multiple character types, uppercase letters, lowercase letters, numbers, and symbols. - Have a minimum length of eight characters or more. - Use no part of a username or email address. **Security Options** Security Options is one of the policy groups included within Group Policies. These policies are related to authentication. You can use the Group Policy Management Console (GPMC) to manage Security Options. Accounts - - - - - - - Devices - - - - Interactive logon - - - - - - Network security Shutdown - - User Account Control - - **User Rights** Permissions are associated with objects and grant the users or groups the ability to access objects such as files, folders, and printers. Rights are associated with user accounts and grant a user (or group) the ability to perform actions on an object, such as logging on, shutting down, backing up, and restorng a computer. When assigning rights, keep the following in mind: - Rights are part of the security policy for the computer. - You can use local or domain policies to assign rights. Use the Local Group Policy Editor for local policies and Group Policy Management for domain policies to configure user right policy settings. - If a right is assigned in a domain GPO, the right affects the local security settings on the computer accounts the GPO affects. - You can explicitly deny a right to users or groups. For example, you could deny the Print Operators group the right to log on locally. **User Rights Assignment Policies** There are many User Rights Assignment policies that you can use to manage the actions users are allowed to take on the system where the policies are applied. User Rights Assignment policies include: - Access this computer from the network. - Add workstations to the domain. - Back up files and directories. - Change the system time. - Change the time zone. - Deny access to this computer from the network. - Deny log on locally. - Deny log on through Remote Desktop Services. - Force shutdown from a remote system. - Load and unload device drivers. - Perform volume maintenance tasks. - Restore files and directories. - Shut down the system. - Take ownership of files or other objects.