Domain User Account

MCSE 70-293: Planning, Implementing, and Maintaining a Security Framework

Martin Grasdal , ... Dr. Thomas W. Shinder , in MCSE (Exam 70-293) Study Guide, 2003

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.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781931836937500154

Feature focus

Dustin Hannifin , ... Joey Alpern , in Microsoft Windows Server 2008 R2, 2010

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:

1.

Log on to a DC and open Server Manager.

2.

Expand the nodes Roles | Active Directory Domain Services | Active Directory Users and Computers | <your domain>.

3.

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

4.

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.

Figure 4.34. Create New User Account Wizard.
5.

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.

6.

Click Next to continue.

7.

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

Best practices

Use a management server or local workstation for admin tasks

As a best practice, you should not perform day-to-day account management operations on a DC. Instead, you should set up a management server or a workstation with the administrative tools installed. You can then run the tools and connect to a DC remotely when creating new accounts. This provides a great level of security by limiting, who can actually log on to a DC.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597495783000049

Securing the Network

Denny Cherry , in Securing SQL Server (Third Edition), 2015

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.

Figure 2.16. Domain users properties page.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128012758000026

Authentication and Granular Access

In How to Cheat at Securing SQL Server 2005, 2007

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:

1.

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

2.

In the left pane, click SQL Server 2005 Services.

3.

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

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491969500200

MCSA/MCSE 70-294 Working with User, Group, and Computer Accounts

Michael Cross , ... Thomas W. Shinder Dr. , in MCSE (Exam 70-294) Study Guide, 2003

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:

Figure 2.13. Account Tab of User's Properties
■

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.

Figure 2.14. Logon Hours Dialog Box

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.

Figure 2.15. Logon Workstations Dialog Box

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.

Figure 2.16. Profile Tab of User's Properties

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781931836944500088

Storage Design Validation

Pierre Bijaoui , Juergen Hasslauer , in Designing Storage for Exchange 2007 SP1, 2008

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.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781555583088000107

Server Rights

Denny Cherry , in Securing SQL Server (Third Edition), 2015

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.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128012758000130

Manipulating Windows with PowerShell

Jason Andress , Ryan Linn , in Coding for Penetration Testers, 2012

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.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597497299000060

Installing and Configuring SQL Server 2000

In Designing SQL Server 2000 Databases, 2001

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.

Using a Domain User Account

The domain user accounts used by SQL Server 2000 use Windows authentication, like any other user account. This is necessary for interserver communication such as:

■

Replication

■

Remote backup strategies

■

Cross-server joins

■

SQL Agent jobs

■

SQL Mail

More than one server can use the domain user account. When configuring security for servers that are using replication, the it is recommended that a Publisher and all its Subscribers share the same service account for the SQL Server service.

Requirements for Domain User Account

All domain user accounts for SQL Server 2000 must have the following permissions:

■

Change level access to the SQL Server directory (\Program Files\Microsoft SQL Server\Mssql).

■

Change level access to the .mdf, .ndf, and .ldf database files.

■

The ability to log on as a service.

■

The ability to read and write registry keys at and under the following registry hives:

■

HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServeror for any named instance: HKEY_LOCAL_MACHINE\Software\Microsoft\ Microsoft SQL Server

■

HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\ MSSQLServer or for any named instance: HKEY_LOCAL_MACHINE\ System\CurrentControlset\Services\MSSQL$Instancename

■

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Perflib

In addition, a domain user account must be able to read and write corresponding registry keys for SQLAgent$InstanceName, MSSearch, and MSDTC services.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781928994190500051

Reporting Services, Analysis Services, and Integration Services

In The Best Damn Exchange, SQL and IIS Book Period, 2007

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.

Configuring the Logon Account

An appropriate logon account for SSAS and permissions for this account must be specified. Make sure the SSAS logon only has those permissions necessary to perform required tasks. This includes appropriate permissions to the data sources.

SSAS executes some tasks in the security context of the Windows logon account that starts Analysis Services and other tasks under the user who requested the task. Regardless of the security context, SSAS verifies permissions of the user issuing the request, prior to running it.

For tasks that SSAS performs in the context of its logon account, the account must have adequate permissions and rights to perform the tasks. The logon account should not, however, be granted rights not required to perform the expected tasks, as granting excessive rights may pose a potential security threat.

Selecting an Appropriate Logon Account

SSAS may run in the security context of different accounts. However, it is recommended that a domain or local user account be used as the logon account for SSAS. Using a domain or local user account depends on the need to connect to network resources.

■

If SSAS needs to connect to network resources using its logon account, SSAS should run under a dedicated domain user account.

■

If SSAS does not need to connect to network resources using its logon account, SSAS can run under a local user account or a domain user account.

■

Do not use the SSAS logon account for other purposes to protect connection string and password encryption.

■

Ensure the logon account has minimal permissions to perform necessary tasks and data source access.

Securing an Instance of Analysis Services

Secure the physical server, operating system, SSAS itself, and the data sources.

The most direct way to access data in SSAS is through the physical computer. If an unauthorized individual obtains physical access to the computer, that individual can potentially access any data stored, regardless of other security measures to secure the data. To prevent this scenario, follow these practices:

■

Ensure only authorized individuals have physical access to the computer.

■

Disable the floppy-based boot option or remove the floppy disk drive.

■

Disable the CD-ROM-based boot option.

■

Use a power-on password, and protect the Basic Input Output System (BIOS) settings by using password.

■

Use a computer case that locks with a key and provides intrusion detection.

■

Store the key safely away from the computer.

The next most effective security measure is securing the operating system and network access:

■

Restrict which users have interactive logon access to the computer. SSAS users and administrators don't need local logon to access data or manage SSAS. These users can connect remotely, and therefore require only network access rights.

■

Use the Local Security Policy tool to prevent the Domain Users global group from being added to the Users local group when a computer joins a domain, because those domain users have permission to log on interactively to the SSAS computer.

■

Rename the default Windows Administrator account and make sure it has a strong password, or allow the Administrator account to exist and remove all access rights, but create a new account to act as administrator to frustrate would-be hackers.

■

Make sure that the Windows Guest account is disabled, which is the default.

■

Enable strong password policies for the Windows operating system using the Local Security Policy tool. Strong password policy is enabled by default in Windows Server 2003.

Last, but not least, controlling access to the underlying data source is your last line of defense.

SSAS connects to the underlying data through a DataSource object. The security account used is either the user's own security credentials or the user name and password in the connection string stored in the DataSource object.

If unauthorized users access the SSAS data sources, those users can access the same information stored in SSAS. Limit access to these data sources. SSAS users browsing cubes and dimensions do not need permissions on the data sources.

Warning

If SSAS connects to its data sources using the logon account, members of a database role having Full Control permissions gain access to the data source, regardless of whether that data source is used within that database.

Configuring Access

Set up and define authorized users. Determine which users have administration permissions on database objects, to view definitions, and access to data sources.

In addition to securing the SSAS computer, you must secure SSAS itself, which only permits connections by users who have been authenticated by Windows, unless anonymous connections have been enabled, and who have specifically been granted permissions within SSAS

Be aware that SSAS does not perform its own authentication of users. Analysis Services relies entirely on Windows to authenticate users before authorizing access to SSAS data or allowing users to perform administrative tasks.

By default, the only users who have permissions within Analysis Services are those who are members of the Server role, which has server-level privileges and can perform any SSAS task.

By default, the local Administrators group, including the local Administrator user and all Domain Administrators, become Server role members, and have Full Control permissions on every SSAS instance.

While members of the local Administrators group are members of the Server role, their membership in the Server role is not visible in the user interface.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492195000273