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
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 the