For decades, mainframes and servers implemented a user control scheme of "super user" and "user." This had an obvious...
security component within it that prevented typical users from gaining unauthorized access.
Since the introduction of the DOS PC and through subsequent Windows operating systems that followed, the controlled access paradigm became more complicated. Early Windows operating systems did not have the ability to allow different sets of user privileges on the same machine; all actions were performed as super user. However, with the introduction of Windows NT, administrator and user roles were finally defined, though in practice most users needed super user access to perform their normal operations.
Today, with many enterprise business models demanding federated operations across large geographic locations, the crude privileged/non-privileged user-management function of Windows NT is no longer granular enough. Recognizing this trend, in 2009 Microsoft introduced Windows Server 2008 with a multi-tiered administrative model based on a multi-level privilege attribute system. This model improves the security of Microsoft Windows by limiting standard users so they can only run application software in a non-privileged manner except for the minimal administrative rights needed to perform their function. For example, a help desk user may only be able to change other users' passwords. This way, users within a large organization can be granted limited administrative privileges with fewer super user accounts in operation. In this tip, we'll discuss how to use Windows Server 2008 to maintain control over privilege allocation.
Managing privileges at the domain level
Within the Windows Server 2008 environment, there are two types of policies: Active Directory (AD) global domain policies and local server Security Accounts Manager (SAM) registry policies. AD uses its directory hierarchy to control group privileges for any given domain of Windows servers -- a group of servers supporting a universal set of security policies. This allows it to enforce a common set of account privileges for all user accounts in that domain.
As new Windows servers are added, they are connected to Active Directory, which examines all of the Group Policy Objects (GPOs) -- applications and services that can be executed by users -- and links these privileges to the root of the domain in the directory's Active Directory Users and Computers branch. It then passes on these defined, default privileges to the new server to begin managing its users. Organization Unit (OU) branches under Active Directory's directory hierarchy can also be defined to create local account policies for computers with that OU. For example, an OU of help desk can define a set of global policies to grant privileges to help desk personnel to perform a common set of privileged activities.
Windows Server 2008 Active Directory also introduced a new feature called fine-grained password policy, which includes a lockout policy as well. With this new feature, companies can apply different password and lockout policies to different users within the same domain based upon the value or sensitivity of content and/or applications they interact with. Prior to this feature, there was one policy for the whole domain. In order to take advantage of this feature, the Active Directory administrator must create a new object called a Password Settings Object (PSO). In the PSO he or she sets the same maximum password age, complexity requirements, lockout thresholds, etc. The PSO is then linked to an Active Directory group where the group scope is Global (not Local or Universal) and group type is Security (not Distribution). All members of the group will then inherit the password and lockout policy defined in the PSO linked to that group.
Local multi-level controls
Once global policies have been configured at the domain level, local privileges can be defined on an individual Windows Server 2008 system through a feature called User Rights Assignment (URA). User rights govern what tasks users can perform on a computer. These rights include both logon rights and privileges. Logon rights control who is authorized to log on to a computer and how they can log on, which would be through a network, locally, as a batch job, or as a service. Privileges control access to computer and domain resources and can override permissions that have been set on specific objects, such as to backup files and directories, create global objects, debug programs, etc. These privileges are managed in Group Policy under the system's URA object and both types of user rights are assigned by administrators to groups or individual users as part of the security settings for the system. Note, where possible, administrators should manage local rights by groups to ensure consistent conformity to the organization's policies and to minimize the more arduous management of privileges on an individual basis.
In order to access the local URA object to add, delete or modify privileges, an administrator must open Local Security Settings on the Windows Server 2008 system by using the Windows Control Panel. On the left side, he or she will see a tree-like directory. By clicking on the Local Policies, then choosing User Rights Assignment, all 39 login rights and privileges will be available for edit.
Ensuring proper privileges
Nine audit policies with two subcategories come with Windows Server 2008 to ensure the Windows administrators have set user privileges correctly. To view a system's audit policy settings, a security team can open the Local Security Policy console on the computer and maneuver to Security Settings\Local Policies\Audit Policy. A brief description of each of these policies and how they can be used is included below:
- Audit account logon events -- tracks all attempts to log on with a domain user account, regardless of where the attempt originates. If enabled, this policy on a workstation or member server will record any attempts to log on using a local account stored in that computer's SAM.
- Audit account management -- used to monitor changes to user accounts and groups and is valuable for auditing the activity of administrators and help desk staff. This policy logs password resets, newly created accounts and changes to group membership and Active Directory domain controllers. The policy also logs changes to domain users, domain groups and computer accounts.
- Audit directory service access -- provides a low-level audit trail of changes to objects in Active Directory. The policy tracks the same activity as Audit Account Management Events, but at a much lower level. By using this policy, it can identify exactly which fields of a user account or any other Active Directory object were accessed. Audit account management events provide better information for monitoring maintenance to user accounts and groups, but audit directory service access is the only way to track changes to OUs and GPOs, which can be important for change-control purposes.
- Audit logon events -- records all attempts to log on to the local computer, whether by using a domain account or a local account. On Active Directory domain controllers, this policy records attempts to access the domain controller only.
- Audit object access -- handles auditing access to all objects outside Active Directory. It can be used to audit access to any type of Windows object, including registry keys, printers, and services. (Note: this policy can greatly affect the performance of a server if it has too many objects.)
- Audit policy change -- provides notification of changes to important security policies on the local system, such as changes to the system's audit policy, or changes to trust relationships when the local system is an Active Directory domain controller.
- Audit privilege use -- tracks the exercise of user rights found in the Local Security Policy under Security Settings\Local Policies\User Right Assignment.
- Audit process tracking -- tracks each program that is executed, either by the system or by the end users. It can also determine how long the program was open. By tying this policy, Audit logon events and Audit object access events together, and by using the Logon ID, Process ID and Handle ID fields within the various event descriptions, a detailed picture of a user's activities is created.
Each of these policies allows corporate security personnel to verify that users haven't taken advantage of administrative privileges to do harm, either intentionally or unintentionally, to the company, even if they've accidently been given unnecessary privileges. Enterprises should enable as many of these audit policies as possible, but keep in mind that loading all these policies can have an effect on the performance of Windows systems.
When they are enabled, an organization has the choice of enabling them for success events, failure events, or both, depending on the policy. All nine audit policies can generate success events along and some of the policies can generate failure events, as a best practice, organizations shouldn't ignore success events -- which generate a large security log -- by just enabling the failure events. A common misconception is that a failure-only audit policy will alert the security team to all suspicious activity. In reality, many of the most important events in the security log are success events such as changes to critical user accounts and groups, account lockouts and changes to security settings.
With the release of Windows Server 2008, Microsoft has finally offered a set of privilege management capabilities that can be used to create a complex set of user privileges without the need for a complex methodology to manage it. But with complex privilege sets comes the ability to misconfigure privileged access without the ability to recognize one's mistakes. So it's equally important to understand the associated audit services that accompany this capability.
With proper forethought and planning up front, Windows Server 2008 finally grants organizations the long-awaited capability to successfully match user capabilities and privileges, not only with the needs of the business and the ability to trust, but also to verify they've been done correctly.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.