What Active Directory feature can be used to apply default user account permissions?

Kerberos Policies

Kerberos policies are used for domain user accounts only. They determine Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in Local Computer Policy. By right-clicking the policy, you can change the following options:

Enforce User logon restrictions Enabling this could slow your network performance. This is used to specify whether the Kerberos v5 Key Distribution Center (KDC) validates each request it receives for a session ticket against the target computer’s user rights policy.

Maximum lifetime for service ticket This setting must be greater than 10 minutes and less than or equal to the setting for the Maximum lifetime for user ticket setting. This is used to specify the time in minutes that a granted session ticket can be used to access a specified service.

Maximum lifetime for user ticket This setting is used to specify the time in hours that a user’s ticket granting ticket (TGT) can be used. A new TGT must be requested when the old one expires. By default, this is set to 10 hours.

Maximum lifetime for user ticket renewal This is used to determine the time in days during which a user’s TGT can be renewed. The default is seven days.

Maximum tolerance for computer clock synchronization This can be used to prevent replay attacks. This setting will determine the maximum time in minutes that can differ between the time on a server clock and the time on a user clock.

User account properties

In addition to the username and password properties, domain user accounts include additional properties such as office location, office phone number, and e-mail address. These fields can be referenced (and populated) by various applications, including Microsoft Exchange Server, Office Communications Server, and SharePoint Server. Some of the additional user account properties are:

First Name

Last Name

Initials

Display Name

Description

Office

Telephone Number

E-mail

Web page

Physical Address Information (Street, City, State, Country)

Organization Information (Job Title, Department, Company, Manager, Direct Reports)

The following exercise will walk you through setting up a user account in AD:

Log on to a DC and open Server Manager.

Expand the nodes Roles | Active Directory Domain Services | Active Directory Users and Computers | .

Right-click on the User's container. Then, select the option New → User. The New Object User wizard will launch.

Type John and Doe in the First name and Last name fields, respectively. Type jdoe in the User logon name text box as seen in Figure 4.34. Then, click Next.

Enter and confirm a password for the user. In our example, we will use [email protected]. Leave the box selected for User must change password at the next logon. This will force John Doe to change his password the first time he logs on to the network. The following password options are available when creating user accounts:

User must change password at next logon—This setting forces the user to change his password during the first logon.

User cannot change password—This prevents the user from changing his password.

Password never expires—This exempts the user from any account policies that might force password changes after x number of days.

Account is disabled—This disables the user account. It cannot be logged onto until it is enabled again.

Click Next to continue.

Verify the account settings and click Finish to create the user account.

Best practices

Allowing Users to VPN in to the Network

After the VPN server is configured users must be granted access to VPN in. This is done at the domain level by editing the users’ domain account within Active Directory. To edit a user’s account log onto a server which has the “Active Directory Users and Computers” application installed. By default this is only installed on domain controllers, but can be installed on other servers or workstations by installing the “Remote Server Administration Tools” on the machine. “Remote Server Administration Tools” can be downloaded from Microsoft’s webpage.

In order to grant a user access to the Windows VPN when not using RADIUS (as shown in Figure 2.15) this is done by simply locating the users account and opening the properties for the user. Open the properties page is open select the “Dial-In” tab, as shown in Figure 2.16 . On the “Dial-In” tab within the “Network Access Permission” box change the radio button to “Allow access” as shown in Figure 2.16. Click OK to close the window and save the change.

SQL Server Service Account

The first thing to determine is the service account under which SQL Server is running. In order for Kerberos to be supported, SQL Server must either be running under a domain user account or the Local System or Network Service account. If a domain user account is being used, the SPNs must be configured under it. Otherwise, the SPNs must be configured under the computer account in the Active Directory domain. The easiest way to determine this is via SQL Server Configuration Manager:

In the left pane, expand SQL Server Configuration Manager (Local).

In the left pane, click SQL Server 2005 Services.

In the right pane, note the value for the Log On As column for the SQL Server instance.

Best Practices According to Microsoft

Microsoft recommends against the use of either the local System account or the Network Service account. In the case of the local System account, this account has more rights than SQL Server needs. As to the Network Service account, Microsoft doesn’t give a specific recommendation as to why to avoid it, citing that local or domain user accounts are preferred. The most secure connection is to use a local user account that does not have administrative rights. However, doing so will prevent Kerberos authentication from working. In order for Kerberos authentication to function, SQL Server must be running under a domain account. That domain account can be the computer account (which is why the local System account would work).

Account Settings

Not all of the tabs in the user’s Properties deal with personal information. As seen in Figure 2.13, the Account tab is used to store information relating to the domain user account, including password options. The fields on this tab include:

User logon name This text box is used to specify the UPN that the user will use when logging on to the domain. This field also includes a drop-down list for specifying the UPN suffix.

User logon name (pre-Windows 2000) This text box is used to specify the logon name that is used when logging on from pre-Windows 2000 computers.

Account is locked out This check box specifies that the account is locked out, preventing the user from logging in.

User must change password at next logon This check box specifies that the user must change his or her password when he or she first logs on.

User cannot change password This check box prevents the user from changing his or her password. This is used to restrict password changes so only administrators have the ability to manage them.

Password never expires This check box prevents the password from expiring after a specific time. If the User must change password at next logon option is set, this option is overridden.

Store password using reversible encryption This check box requires users to use reversible encryption. Users who are logging on from Macintosh computers require this setting. Some forms of Windows authentication, such as CHAP and Digest, also require this setting to be enabled.

Account is disabled This check box prevents users from logging on with this account.

Smart card is required for interactive logon This check box allows the user to log on using a smart card.

Account is trusted for delegation This allows the account to be used to run as an identity of a service, so that it can impersonate the account and acquire necessary access.

Account is sensitive and cannot be delegated This check box allows a user to assign responsibility over a portion of the namespace to another user, group, or computer.

Use DES encryption types for this account This check box requires Data Encryption Standard (DES) to be used with this account.

Do not require Kerberos preauthentication This check box removes the need for preauthentication for accounts that are using another version of Kerberos that doesn’t require it.

Account expires This option button is used to set the expiration date of the account. Options for this field are Never, which means the account never expires; or End of, which requires a date to be set specifying when the account will expire.

In addition to the fields we’ve discussed, the Account tab also includes a Logon Hours button, which opens a dialog box that allows you to control when this user can log on or remain logged on to the network. By default, users are able to log on and remain logged on to the network 24 hours a day, 7 days a week. However, in secure environments, you might want to control when a user is able to log on. To provide a maintenance window, you might want to limit users’ ability to log on or remain logged on after regular hours of work, or during weekends.

As shown in Figure 2.14, the Logon Hours dialog box contains a series of boxes that determine the times and days when a user can log on. After selecting the boxes representing the times and dates to log on, click the Logon Permitted or Logon Denied option buttons to respectively permit or deny access during those times. If all of the boxes are selected and Logon Permitted is selected, then there are no restrictions set for the user.

The other button that appears on the Account tab is the Log On To button. When this button is clicked, the Logon Workstations dialog box shown in Figure 2.15 appears. On this dialog box, you can control what computers the user can use when logging on to the domain. By default, users can log on from any computer. However, by using the fields on this tab you can heighten security by limiting users to working on the machine at their desk, or a group of computers within their department. For example, you might want to prevent users from logging on to the domain from a specific machine so that they cannot access another user’s data that is stored on that computer.

On this dialog box, there are two options: All computers and The following computers. When All computers is selected, there are no restrictions regarding which machines a user can log on from. When The following computers is selected, you can then enter the name of the computer(s) you want to restrict a user to using. After entering the NetBIOS name of the computer, click the Add button to add that computer to the list. You can then select computer names from the listing, and click Edit to modify the entry or Remove to delete it from the list.

The Profile tab is also used to configure elements of the user’s account, relating to profiles, logon scripts, and home folders. Roaming profiles can be used to provide consistency across the network, by ensuring that a user has the same desktop environment, application settings, drive mappings, and personal data regardless of which computer he or she uses on the network. The Profile path field on this tab is used to specify the path to the user’s profile. Similarly, logon scripts are also used to apply settings to a user’s account, by running a script when the user logs on to the network. The Logon script field is used to set where this script is located, so it will automatically run each time the user logs on to this account. Through these, the user’s environment is configured each time he or she logs on to a DC.

Note

The Logon script field on this tab is a hold over from Windows NT days. Group Policy allows you to specify multiple logon, logoff, startup, and shutdown scripts. However, if the computers that your users are logging on from does not support Group Policy, this field comes in handy to ensure that they can still get a logon script applied to them. Windows 2000 and later computers are capable of using Group Policy.

Finally, as shown in Figure 2.16, the Home folder section of this tab is used to specify the location of a home directory that will contain the user’s personal files. The Local path text box is used to specify a path to the directory on the local system. Alternatively, you can specify a network location by using the Connect drop-down box to specify a drive letter that the path will be mapped to, and then enter a UNC path to the directory in the To text box.

Important Note

The online documentation contains the following warning message:

Exchange Load Generator should be used only in test environments that have no connection to the production environment. This tool should not be used in a production environment, an environment that is mission critical, or one that contains important information of any kind anywhere in the network.

Exchange Load Generator uses many simulated user mailboxes to create the server workload. Because mailboxes must be part of a domain user's account, the Exchange Load Generator tool therefore creates many domain user accounts to support these user mailboxes. By design, Exchange Load Generator requires that the password associated with these domain accounts be the same. Because this most likely does not comply with your organization's security requirements, to lessen any risk this could present, we recommend that this tool be used only on isolated test networks that do not have connectivity to your production network.

Because load simulation works by using system resources, Exchange Load Generator is unsuitable for use on production networks because it could interfere with production operations by competing for those resources.

The End User License Agreement (EULA) contains this statement:

You may not test the software in a live operating environment unless Microsoft permits you to do so under another agreement.

This clause in the EULA forbids the usage of LoadGen in a production environment.

Managed Service Accounts

Managed Service Accounts (MSAs) are a combination between domain accounts and virtual accounts such as the “Network Service\MSSQLSERVER” accounts which are discussed in this chapter. Managed Service Accounts are user accounts created within the Active Directory domain for a specific Windows service on a single Windows server. The benefit to the Managed Service Accounts over a traditional domain user account is that Managed Service Accounts never need to have their passwords changes as the Windows server which runs the service which uses the account will automatically change the password for the account every 30 days. Because the password change is automated and controlled by the Windows operating system itself the passwords are able to be changed without the need to take an outage of the SQL Server service. Managed Service Accounts are available starting in Windows Server 2008 R2 and SQL Server 2008 R2.

Managed Service Accounts are created within Active Directory just like any other user account, with the exception of having a dollar sign ($) placed after the username. While a normal domain user might look like “DOMAIN\UserName” a Managed Service Account will look like “DOMAIN\UserName$.” When the account is created the password field should be left blank as the Windows Operating System will set the password manually when you configure the service to use the account.

Due to the fact that the Windows Operating System will be what creates the password and changes the password, Managed Service Accounts are not able to be used on clustered instances of Microsoft SQL Server as of Windows Server 2012 R2 and SQL Server 2014 as there is no way for the Windows servers to exchange the password with other members of the Windows cluster. When using AlwaysOn Availability Groups, Managed Service Accounts should also not be used as you should be using the same domain account for each instance which is working as a database replica within the AlwaysOn Availability Group configuration (more information regarding AlwaysOn Availability Groups and their security requirements is available earlier in this chapter).

Microsoft SQL Server is configured to use a Managed Service Account just like any other account by using the SQL Server configuration manager shown in Figures 13.2 and 13.3. Managed Service Accounts make for a great way to configure domain user accounts for standalone SQL Server instances as the password is changed automatically by the server every time the password expires without any downtime to the SQL Server service.

PowerDump

PowerDump is one of the interesting modules available in Metasploit, and it can allow us to dump out the Security Accounts Manager (SAM) database on a Microsoft OS. The caveat here is that this particular module and the PowerShell code that backs it are foiled by the security measures set in the Registry on more recent Microsoft OSes.

In order to make use of this code, we need to be able to read Registry keys such as HKLM:\SAM\SAM\Domains\Accounts\Users. Similar to our discussion earlier in the chapter when we talked about needing administrative access to write to HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, this portion of the Registry is configured with a very restrictive set of permissions. In this particular case, administrative access will not be enough to get us there. Although it is entirely possible to change the permissions on this portion of the Registry, this is really outside the scope of what we're trying to do here, as it would involve relatively heavy modifications to the system.

We may be able to make this work against older systems, however, such as Windows XP or Server 2003, depending on the patch level of the systems in question.

Creating Service Accounts for SQL Server

SQL Server service accounts allow SQL Server to run with the rights and privileges assigned to the service account. This is better than using an existing user’s account, because if the password on the account is changed, it is necessary to change the password in SQL Server 2000. This is easily done through properties in Enterprise Manager but will cause SQL Server to fail to start.

When running under Windows NT or Windows 2000, SQL Server and SQL Server Agent run as services. These can be viewed, started, and configured under the Services applet in Control Panel.

SQL Server 2000 and SQL Server Agent require a user account to run. These can be run under any user account that has the appropriate access, but general practice is to assign them their own service accounts. Typically, SQL Server and SQL Server Agent are assigned the same user account, either the local system or domain user account, but this is not required. In order for interserver processes to work smoothly, it’s best to use a domain account.

It’s good practice to create the service accounts prior to beginning to install SQL Server.

The local system account is a built-in account that doesn’t require a password. This account has no network access that will limit the ability of SQL Server to communicate with other SQL servers on the network. Generally, it is preferred to use a domain service account in instances in which the SQL Server is on a network.

Note

Since Windows 98 doesn’t support services, SQL Server and SQL Server agent “simulate” a service account, it is not necessary (nor is it possible) to create a service account in Windows 98.

Securing Analysis Services

Securing SQL Server 2005 Analysis Services (SSAS) is a multilevel process. Each instance of Analysis Services and the data sources must be secured to ensure only authorized users have permissions on cubes, dimensions, data sources, and so on. It is essential to prevent unauthorized users from accessing information. Securing Analysis Services is described in the following sections.

Architecture

SQL Server 2005 Analysis Services (SSAS) relies on Windows to authenticate users (see Figure 27.12).

Figure 27.12. Analysis Services Architecture

Understanding the Security Architecture of Analysis Services

By default, only authenticated users having SSAS rights can connect. After connection, permissions that users have in SSAS are determined by rights assigned to SSAS roles of which that user has membership, directly or through a Windows role membership.

SSAS contains a fixed server role, which grants permission to members to perform tasks. Users who are not server role members can be made members of a database role. Each database role has a customized permission set allowing user access to data and to perform tasks on that database.

Database role members that have administrator permissions can view or update all data in the database. Other database role members can only view or update data objects to which they have been specifically granted permissions.

SSAS permissions are initially granted at the database level. The role must then be granted specific permissions for each object in the database, such as cube dimensions, dimension members, cubes, cells within a cube, mining structures and models, data sources, and stored procedures.

SSAS encrypts all communication to protect sensitive information from unauthorized use. SSAS features that might possibly compromise security if inappropriately configured or used are disabled by default. Users could be permitted to connect without authentication or submit credentials in clear text, but these features require modification of default settings.

Supporting Unauthenticated Clients

If data security is not a concern, SSAS can allow unauthenticated clients to connect. Using SQL Server 2005 Management Studio, make a connection to an instance of Analysis Services. In the Object Explorer, right-click the SSAS instance and click Properties. On the General page, change the Security | RequireClientAuthentication property from a default of true to false to allow unauthenticated clients.

Modifying Encryption Settings

If Internet Information Services (IIS) is used to access SSAS data from the Internet, SSL should be required to protect data. If using a secure intranet connection, encryption may be disabled to increase performance. Please consult the latest Microsoft documentation for this procedure.