Microsoft Operations Manager 2000

Chapter 5 - MOM Security

This chapter provides guidance on managing security in MOM.

Send feedback on this chapter to MOM Operations Guide Authors.

On This Page

Concepts
Data Confidentiality
Data Integrity
Data Availability
Functional Access
Architecture
Windows User Accounts and Groups
Agent accounts
Database accounts
Accounts associated with COM+ roles
COM+ Roles and Identity
How impersonation differs from identity
How MOM uses COM+ roles and identity
How SQL Server uses COM+ roles and identity
SQL Server Logins and Database Roles
Access control provided by SQL Server
Logins used by MOM
Roles used by MOM
Administration
Securing Reporting
Setting share permissions
Setting NTFS permissions
Setting IIS access permissions
Enabling encryption
Setting client-side security settings
Securing the MOM Database
Setting NTFS ACLs
Using a remote backup directory
Changing a login account´s password
Securing the MOM Administrator Console
Securing the Web Console
Setting ACLs in the WebConsole directory
Setting IIS Permissions for the WebConsole Virtual Directory
Using HTTPS with Web Console Transmissions
Configuring security on the Web console client
Securing Agents and Agent Managers
Securing ManualMC.txt
Securing the Mission Critical Software directory
Securing log files
Securing port communications
Securing the Windows 2000 Registry
Procedures
How To Secure Reporting
How to Secure the MOM Database
How to Secure the Web Console
How to Secure Agents
How to Secure the Windows 2000 Registry
Reference

Concepts

Securing a Microsoft® Operations Manager 2000 (MOM) server is similar to securing any server, however, there are some details specific to MOM that require specialized knowledge. This chapter discusses these details including security concepts relevant to MOM, how MOM security is structured, suggestions for altering settings to improve MOM security, and the default MOM security settings.

Important The information in this chapter is based on the assumption that you have installed MOM (pre-SP1) on Microsoft Windows® 2000 with the latest updates and service packs, using the NTFS file system, and running Microsoft SQL ServerTM 2000 with the latest service pack.

For more information about Microsoft Windows NT® 4.0 security and installations, see the Microsoft Support Web site or contact NetIQ.

Data Confidentiality

Part of securing a server is ensuring that private or confidential information cannot be viewed or copied by unauthorized parties. You can do this by using access control and encryption. In MOM, this relates to securing information in reports, databases, log files, and temporary files.

Reports, such as those in Microsoft Active Directory, contain information about your internal network´s topology that can potentially be used by an attacker. You should review the reports to determine whether (and how) the information contained in them should be exposed using Web reporting. Any reports that contain sensitive information and that will be exposed on the Internet should be encrypted using the Secure Sockets Layer (SSL). For more information about securing reports, see the Securing Reporting section later in this chapter.

Because the MOM OnePoint database contains most of the information that MOM uses, the information should be protected. You can protect this information by using the correct access-control lists (ACLs) on the file system directories containing the database, log, and the backup files. The SQL Server roles and logins should also be reviewed to make sure that only the proper parties have access to the database. For more information, see the Securing the MOM Database section later in this chapter.

Log files contain information (such as what components are install and where and what actions and configuration changes are possible) that can potentially be used by an attacker. Therefore, this information should be reviewed to determine who should have access to it.

Temporary files stored on the server´s hard disk also contain information that can potentially be used by an attacker. Therefore, this information should be reviewed to determine who should have access to it. For more information about securing logs, see the Securing Agents section in this chapter.

Data Integrity

Ensuring that information is not being removed or altered by unauthorized parties by using access control, cryptographic signing, or regular data backups is an important part of securing your servers. In MOM, this relates to setting appropriate ACLs and permissions for, and performing regular backups of, the OnePoint database and certain files. These assets can represent significant investment by your company and regularly backing up this information can preserve this investment in case of unexpected failures or malicious attacks. MOM does not directly provide backup functionality, however, SQL Server does. For more information, see the Back Up and Restore section in chapter 6, MOM Database Management, and the SQL Server documentation. For more information about setting permissions in the OnePoint database, see the Securing The MOM Database section later in this chapter.

MOM also creates and uses several files on your hard disk. These files represent information that is specific to the current installation and configuration of MOM and therefore represent an investment by your company. These files also represent the current running state of your MOM serves, and any unauthorized changes to them can cause your MOM server to not function correctly or present incorrect information. You can secure and archive these files to protect this investment against loss or defacement. For more information about securing and archiving these files, see the Securing Agents section later in this chapter.

Data Availability

Information must be available in a consistent and timely manner to authorized parties. This is done by adjusting your server and network for optimal performance and by mitigating denial of service attacks. MOM provides the capability to create redundant DCAM servers and security partitions. For more information, see the Security Partitions section in Chapter 7,MOM DCAM Management.

Functional Access

Controlling access to specific functionality not only protects data on your system, but it also protects the system directly. Backing up your data provides a way to recover your data. However, if someone is able to format disks on your system, you will need to reinstall software, set up configurations, and perform many other tasks before the data can be restored. Securing these functions greatly mitigates the need for these recovery procedures. MOM uses Windows user accounts and groups, security policies, file system ACLs, COM+ roles and application identity, and SQL Server logins and roles to provide a robust and granularly configurable access system. For more information, see the Architecture section later in this chapter.

Architecture

MOM uses three layers of access control: Windows user accounts and groups combined with NTFS ACLs, COM+ roles and application identity, and SQL Server roles and logins. These layers interact to provide granular access control in MOM without creating additional administrative overhead for security. Windows user accounts and groups are assigned roles within COM+ that determine what actions a logged-on individual can perform in the MOM Administrator console, the Web console, and to some extent the SQL Server utilities.

COM+ uses roles to authenticate logged-on users and then uses a highly privileged account to act on authenticated users to perform tasks in MOM. This is the same account used for the DCAM server, which is referred to as the Data Access Server (DAS) account.

An interesting relationship exists between the COM+ interfaces and the OnePoint database. This relationship is a correspondence, or mapping, of the COM+ methods to SQL Server stored procedures in the OnePoint database. By changing the membership of the Windows user groups created by MOM during installation, you effectively determine granular access to functionality in the OnePoint database through the COM+ roles.

Windows User Accounts and Groups

Before installing MOM, the user accounts that will be used by DAS and the Consolidator and Agent Manager (CAM) are created by the administrator. These components can use the same account, if required.

If you choose to use an integrated service account, this account must have local administrative rights on both the DCAM and database server. This account also requires either domain administrative rights or local administrative rights on each of the managed computers.

If you chose to use two separate accounts, the DAS account requires local administrator rights on both the DCAM and database servers but it does not have to be a domain account. During installation, MOM adds the DAS account to the OnePointOp local security groups on both the DCAM and database servers.

The following sections summarize the accounts that are used by DAS and CAM.

DAS account

The DAS account requires local administrator rights on the DCAM server but it does not have to be a domain account. This account is the Windows 2000 account that DAS uses to log on to Windows 2000 and to perform many of the operations in MOM. The primary function of the DAS account is to enable communication between the DCAM server and the MOM database. Each DAS in a configuration group should use the same DAS account. During installation, MOM automatically applies the following rights to the DAS account:

• Local administrator rights

• Act as part of the operating system

• Create a token object

• Log on as a batch job

• Log on as a service

Important The DAS account in most cases is a member of the domain administrators group. The domain administrators group is also a member of the administrators group on every DCAM server and all automatically installed agents. If attackers obtain the password for the DAS account, they can actually use MOM to penetrate and exploit your entire network. The account information for this account, especially the password, should be kept secret.

Consolidator and Agent Manager account

The Consolidator and Agent Manager share an account. In addition to requiring local administrator rights on the DCAM server, this CAM account must be a domain account. You do not have to use the same CAM account on each DCAM server in a configuration group. Before installing MOM, the administrator manually applies the following rights to the CAM account:

• Local administrator rights

• Act as part of the operating system

• Create a token object

• Log on as a batch job

• Log on as a service

In addition to the rights that the CAM account uses on the DCAM server, the Agent Manager requires local administrator rights on each of the managed computers to install agents, manage agent computers, and perform managed computer scans. These rights are gained by giving Domain Admin rights to the CAM account.

The domain rights that are used by the Agent Manager can be extended to agents that are in other domains be creating a trust relationship between domains. However, if security requirements prevent the use of domain rights for agent installation, you can add the account that is used by the Agent Manager to the managed computer. This method can be used when installing agents manually. If you add the Agent Manager account to the managed computer, you must give this account full administrative rights to the managed computer. For more information about security requirements for installing agents, see the Installing Agents section in chapter 8, MOM Agent Management.

Agent accounts

By default, the OnePoint service runs under the local system account on the agent computer. However, before the agent can be installed remotely, the Agent Manager on the DCAM server must have access to the computer´s hard disk and registry. The account under which the service runs can be changed. For more information, see Changing the Agent Service Account section in chapter 8, MOM Agent Management.

Note Rule scripts run in the security context of the agent, usually the provider or agent component. You should be aware of this when attempting to rule rules across domain boundaries, or remotely.

Database accounts

During installation, MOM creates several security groups, and then maps MOM accounts and security groups to tasks that can be performed on the database server. These accounts and security groups are mapped indirectly by making associations with COM+ roles and identities.

The different OnePointOp groups created during a MOM installation have a range of purposes and access levels to tasks in MOM. The following table summarizes the groups and their access to these tasks:

Table 5.1

Function	System	Configuration Administrator	Operator	User	Reporting User
View and create reports	v	v	v	v	v
View information and perform tasks in the Monitor folder of the MOM Administrator console	v	v	v	v
View information and perform tasks in the Rules folder of the MOM Administrator console	v	v	v
View information and perform tasks in the Configuration folder of the MOM Administrator console	v	v
View the Web console	v	v	v	v	v

Accounts associated with COM+ roles

During setup, MOM creates the following security groups and assigns default rights to them:

• OnePointOp ConfgAdms

• OnePointOp System

• OnePointOp Operators

• OnePointOp Users

• OnePointOp Reporting

  Tip To more easily manage group membership, create groups in Active Directory (such as AD_OnePointOp_ConfigAdmn) and make these groups members of each of these local OnePointOp groups. Future membership assignment can then be accomplished by adding users to the distribution groups instead. However, do not do this for the OnePointOp System group. This group is assigned the members that it needs to function correctly and its membership should not be altered.

MOM automatically assigns the OnePointOp groups with specific COM+ roles. These assignments determine what specific tasks the individuals in these groups can perform using the MOM Administrator console, and the Web console. By altering the membership of these groups, you grant or deny individuals and groups access to tasks in MOM. For more information about these roles, see the Reference section later in this chapter. The following table shows the role assignments:

Table 5.2

Windows User Group	COM+ Role
OnePointOp ConfgAdms	EeaConfig, EeaOperator, EeaUser
OnePointOp System	EeaSystem, EeaConfig, EeaOperator, EeaKnowledgeAuthor, EeaUser
OnePointOp Operators	EeaOperator, EeaUser
OnePointOp Reporting	Not associated with any COM+ roles; only used in SQL Server
OnePointOp Users	EeaUser

COM+ Roles and Identity

Security roles enforce access control policy for COM+ applications. Roles are categories of users that determining access permissions to the application's resources. When an application uses role-based security, a caller's role membership is verified on every call to the application. If a caller does not belong to a role having permission to access the application being called, the call will fail. Callers are granted access to the application or its resources strictly according to the constraints defined within the roles to which they belong. Access is not granted according to the rights assigned to the individual user accounts themselves.

How impersonation differs from identity

In COM+, impersonation is where an account with greater privilege performs a task on behalf of an account with lesser privilege, with the privileges of the lesser privileged account. A good example is when the IUSR_ account, which operates within the context of the local system, grants requests for Web pages to anonymous users in Microsoft Internet Information Services (IIS). The IUSR_ account can only access resources that are configured for anonymous authentication and not all the resources available to the Local System account.

Note The identity that COM+ uses for an application or process can be found by opening the Component Services console, right-clicking the application or process, selecting Properties, and then clicking the Identity tab.

In COM+, identity is where an account with greater privilege performs a task on behalf of an account with lesser privilege, with the privileges of the higher privileged account. This means that the Identity account performs tasks on behalf of other accounts at its own level of privilege regardless of the privileges of the caller. An example is when a low-privileged individual uses the MOM Administrator console to update an alert´s status. The user does not have sufficient privilege to perform this task, but COM+ uses the DAS account, which is in the Administrators group, to perform the task instead.

Caution The Everyone user group should never be associated with any COM+ role in MOM. The Everyone group includes anyone with access to your system, intended or not. For example, if attackers are able to penetrate your system, they are automatically a member of the Everyone group.

How MOM uses COM+ roles and identity

MOM specifies the DAS account as the identity account at the interface level for all the OnePointActiveOps interfaces and at the application level for the MOMDasLocator application, which has no COM+ roles defined.

When a user attempts to perform a task in MOM the specific COM+ interface called verifies whether the user´s COM+ role has permission to call the method. If the user is permitted to call the method, the DAS account performs the task, as an administrator, on the user´s behalf.

At first glance, this might not seem secure because individuals with minimal privileges could perform tasks as if they were administrators. However, because the MOM server administrator determines whether they can perform the tasks, and because the DAS account performs only the task for which the callers are enabled, the call is secure. Callers cannot take control of the DAS account and use it to perform tasks for which they are not permitted by using their assigned COM+ roles.

This security method allows the server administrator to enable individuals and groups to perform tasks in MOM without having to do the following:

• Alter the security policies on that individual´s user account

• Add an ACE for that individual on the resources targeted by the function

• Assign the user account to a SQL Server role or login

• Make any other configurations changes depending upon the application

How SQL Server uses COM+ roles and identity

Many of the tasks in MOM are performed in the OnePoint database. Ultimately, Windows user accounts are mapped to stored procedures in this database that perform these tasks in MOM. This mapping is performed indirectly through the COM+ roles and identity.

Windows user accounts and groups are associated with COM+ roles, which are given access to specific COM+ interfaces and methods. The COM+ interfaces correspond to tables in the OnePoint database. The COM+ interface methods correspond to stored procedures in the OnePoint database. The effective outcome of this is that Windows user accounts and groups are indirectly mapped to stored procedures in the OnePoint database. The actual stored procedures run under the db_owner SQL Server role, of which the DAS account is a member because it is a member of the Administrators group. For more information about the specific T-SQL commands that the COM+ roles can performs on the OnePoint database tables, see Table 5.5.

Note Access changes should be performed by adjusting the membership of the Windows user groups assigned to the COM+ roles and not by changing the role memberships themselves.

SQL Server Logins and Database Roles

Access control provided by SQL Server

SQL Server 2000 has three layers of access control: server logins, server roles, and database roles. Logins determine who can log in to a given SQL Server instance and what roles they are assigned. A login can either use Windows user accounts and user groups or a SQL Server instance-specific login created by an administrator, called standard logins. The default standard login is the sa login. This is a built-in account on every SQL Server instance that allows administrative access to the SQL Server instance. Additional logins of either type can create and assign server roles and database roles as needed.

Server roles assign access to the entire SQL Server instance, are automatically created by the SQL Server installation program, and are assigned access rights to the SQL Server instance and all databases. These server roles cannot be altered and additional server roles cannot be created.

Tip To see a comprehensive list of the possible access rights, view the permissions granted to the System Administrator server role.

To do this, open SQL Server Enterprise Manager, expand SQL Server, expand Security, and then select Server Roles. In the right pane, right-click System Administrators, click Properties, and then click the Permissions tab.

Database roles determine the level of access to a particular database and are configured for each database. SQL Server automatically creates some default database roles when each database is created. These database roles cannot be deleted or altered with the exception that you can add and delete members for the role. Note, however, that the dbo member cannot be removed from the db_owner role.

You can also create custom database roles. MOM creates the Eea_ roles and assigns database access to them during the MOM installation process. These database roles partially determine how MOM gains access to the OnePoint database.

You can determine whether the database role is a default role by right-clicking it. If the Permissions button in the Database Role Properties dialog box is available, the role is not a default role. The permissions of default roles cannot be viewed or altered. The exception is the database role called public.

Important Do not alter the permissions assigned to the MOM-created database roles because altering them can have negative affects on MOM functionality and possibly expose your OnePoint database to security threats.

Logins used by MOM

The only SQL Server logins used by MOM are the OnePointOp reporting and the Administrators login. The reporting login is given access only to the OnePoint database. The login has both the public and the EeaReportViewer database roles. The EeaReportViewer database role has read-only (that is, SELECT) access to a number of tables and views created by MOM for reporting. The properties assigned to the EeaReportViewer permissions group do not need to be altered in the process of limiting access to the reporting features of MOM.

All other functions used by MOM in the SQL Server database use the BUILTIN\Administrators login. This login is automatically granted to the System Administrator server role and can therefore perform any action in the SQL Server instance and in any database.

Roles used by MOM

With the exception of the reporting features, the only database role that MOM uses is the db_owner role. This role can perform any action in the database with which it is associated. The DAS account is included in the db_owner role because it is a member of the Administrators group, which is automatically assigned the db_owner role for all databases. This means that when authenticated users perform database tasks in MOM, they can perform the tasks regardless of their own access levels in SQL Server. This is because the DAS account is actually performing the tasks for them.

Administration

Your security policies might require that you alter the default security settings. The changes that you make could affect other areas of MOM functionality or data. The information in this section pertains to issues that you might encounter when you alter the default security settings in MOM. The issues covered in this section are reporting, the OnePoint database, the Administrator console, the Web console, and agents.

Securing Reporting

By default, MOM installs the reporting components and the Web reports directory and subdirectories with permissions inherited from the Program Files directory. It also installs the Reports directory with the share permission set to Everyone (Full Control). Your security policies might require, however, that you restrict these permissions further. The information in this section covers some areas that can help you increase security.

Setting share permissions

Share permissions differ slightly from file system permissions (NTFS ACLs). Share permissions control only how users can gain access to resources using the sharing mechanism and do not determine their access to the resources within the share. NTFS ACLs are used to determine how users access the actual resources. As a result, users that have share access to a directory might be able to see the share but might not be able to open the directory or list its contents. To grant share access to resources both share permissions and NTFS permissions must be granted to the users.

The default share permission given to all newly created shares in Windows 2000 is Everyone (Full Control). This situation can produce some administrative overhead if users can see a share but not access its resources and call your help desk with this issue. One way to resolve this situation is to modify the share permissions to mirror the ACLs of the directory. For more information about the ACLs, see the Reference section later in this chapter.

Another issue that this situation can create is that attackers (who are part of the Everyone group as soon as they penetrate your network) can also see a directory and might attempt to gain access to it. Modifying the share permissions to mirror the ACLs of the directory will mitigate this situation because potential attackers cannot see the share without having permissions to it.

Setting NTFS permissions

If the default ACLs set on the

%Program Files%\Microsoft Operations Manager 2000\Event\Report directory are not restrictive enough for your environment, you can change them to suit your security needs. The following issues need to be reviewed before you make changes in the directory ACLs in the
%Program Files%\Microsoft Operations Manager 2000 directory and subdirectories:

• The %Program Files%\Microsoft Operations Manager 2000\OnePoint\Reporting\EeaRept.mdb file must have the same ACLs as those used for the %Program Files%\Microsoft Operations Manager 2000\Event\Reports directory.

• If you select another directory to store your HTML reports, assign that directory the same ACLs as those used for the

  %Program Files%\Microsoft Operations Manager 2000\OnePoint\Reporting\EeaRept.mdb file.

Setting IIS access permissions

By default, MOM creates the IIS virtual directories with sufficiently secure settings for most environments. Depending on your needs, you might need to enable basic authentication for viewers outside of your network. If you enable basic authentication, the credential information of users is transmitted over the network in cleartext. As a result, attackers can readily obtain credential information for users on your network. This situation is not secure. To prevent potential attackers from accessing this information, you should only enable basic authentication with SSL encryption also enabled and required.

Caution Exposing domain user account information by using basic authentication without SSL encryption presents a serious threat to the safety and integrity of your MOM servers and possibly your entire domain. If you must do this, do not use a domain account that is a member of the Administrators, Power Users, or Backup Operators groups and never use the DAS account.

An alternative to using basic authentication is to use Remote Access Service (RAS) over a virtual private network (VPN). For more information about these options, see the Windows 2000 Help or the Windows 2000 Resource Kit.

Enabling encryption

Regardless of whether you use basic authentication, you should be aware that report information is being transmitted across the network or Internet in cleartext. Because some of this information might be useful to an attacker, you should use SSL encryption over HTTPS. This requires using a server certificate and could lower performance on the reporting server. These issues need to be investigated to determine whether to encrypt the reporting traffic within your network. You must obtain and install a server certificate before you can enable SSL encryption.

Setting client-side security settings

MOM requires the Snapview.ocx Microsoft ActiveX control on the client browser to view Web reports. The Web console will not retain all of its functionality if any of the following conditions exist:

• The browser is incapable of using ActiveX Controls

• The browser security settings do not allow ActiveX Controls to be downloaded and used

• The Snapview.ocx control is not on the client computer

• The user who is logged on also needs to have sufficient access privileges to download and run the ActiveX Controls in the %WINDOWS%\Downloaded Program Files directory.

If the client computer has Microsoft Access installed, it has the control available. The control is installed on the server in the

%Program Files%\Microsoft Operations Manager 2000\Event\Reports directory.

Securing the MOM Database

Setting NTFS ACLs

By default, MOM installs its database and database log files (EeaData.mdf and EeaLog.ldf respectively) in the

%Program Files%\Microsoft Operations Manager 2000\ActiveOperations\DB directory, not in the %Program Files%\Microsoft SQL Server\MSSQL\Data directory. The ACLs on the DB directory are inherited from the Program Files directory by default and these settings are sufficient for most MOM environments.

Note The OnePoint database is a SQL Server database and the Reports database is a Microsoft® Access database. The procedures for securing these two databases might differ. For more information about securing these databases, see the SQL Server or Access documentation.

If you need to change the ACL on the OnePoint database, be aware of the following:

• Narrowing the ACL can cause some functions in the MOM Administrator console or the Web console to function improperly or not at all. Testing should accompany any changes the further restrict the ACL.

• Widening the ACL can grant access to unintended parties, especially if you add groups. Review the memberships of the groups before deploying these settings to other DCAM servers.

Using a remote backup directory

The default SQL Server backup directory is

%Program Files%\Microsoft SQL Server\MSSQL\BACKUP.
However, you can back up to any directory, even on a remote server. Having a remote backup directory is a good precaution against data loss. The ACLs on the remote backup directory should be more restrictive than those on the Data directory because the data does not need to be accessed by the OnePoint service or any other MOM functionality. To back up to the Data directory, use the SQL Server data transformation services (DTS). For more information, see the SQL Server documentation.

Changing a login account´s password

Your security policy might require that passwords for domain accounts be changed regularly. If any of these accounts are used for SQL Server logins, the passwords must be changed in SQL Server.

Securing the MOM Administrator Console

Restricting access to the MOM Administrator console is not necessary because the tasks that individuals can perform in the Administrator console are controlled through COM+ roles. However, you might want to restrict the access to opening the console itself. The file for the Administrator console (MOM Administrator Console.msc) is located in the

%Program Files%\Microsoft Operations Manager 2000\Event\MMC directory. This file contains information for running the default Administrator console and the ACL inherited from the Program Files directory. You can restrict who can open the MOM Administrator console by altering the ACLs on this file.

However, this method should not be considered secure. If individuals have authoring rights for the Administrator console and are members of the OnePointOp Users group, they can do create their own MOM Administrator console and assign whatever rights they want to their console. By default, only members of the Administrators group can do this.

Caution Changing the ACLs for MMC.exe itself will affect every console on your computer, not just the MOM Administrator console.

Securing the Web Console

The Web console uses Active Server Pages (ASP) applications and ActiveX Controls over HTTP connections to provide a read-only view of your MOM server similar to the Administrator console. The transmissions between the Web console and the MOM DCAM server are not encrypted by default. The console also does not allow you to change any settings in MOM.

Setting ACLs in the WebConsole directory

By default, the %ROOT%\Inetpub\wwwroot\WebConsole directory is installed with Everyone (Read and Execute, Read, List folder content) access. Because this ACE might not be sufficiently restrictive for your security needs, you should remove the Everyone ACE. Be sure to remove the ACE and do not deny it access. Add one or more of the OnePointOp groups and give them Read and Execute, Read, and List folder contents rights.

Setting IIS Permissions for the WebConsole Virtual Directory

By default, MOM installs the WebConsole virtual directory with anonymous authentication enabled. This means that anyone with access to your default Web site can use the Web console to view information about your domain servers, which might be useful to an attacker or competitor. Disabling anonymous authentication increases your server security. The other settings are sufficient for most MOM installations.

Using HTTPS with Web Console Transmissions

Because the Web console provides almost all of the configuration information for your MOM server, you might want to increase the security of the transmissions between the Web console and your MOM server by using SSL encryption over HTTPS. The Web console also provides access to Web-available reports. Therefore, if you plan to use SSL encryption with Web reports, you should also use SSL encryption with the Web console.

Configuring security on the Web console client

The Web console requires ActiveX Controls on the client browser to function properly. If the browser is incapable of using ActiveX Controls or the browser security settings do not allow ActiveX Controls to be downloaded and used, the Web console will not retain all of its functionality. The user who is logged on also needs to have sufficient access privileges to download and run the ActiveX Controls in the

% WINDOWS%\Downloaded Program Files directory.

Securing Agents and Agent Managers

Agents and Agent Managers contain information specific to their individual installations and operations and therefore might useful to an attacker. This information is also useful for tracking and troubleshooting and cannot be reconstructed completely; therefore, protecting these files will help safeguard against data loss.

Securing ManualMC.txt

ManualMC.txt contains a list of the manually installed agents and is located in the

%Program Files%\Microsoft Operations Manager 2000\OnePoint directory on the Agent Manager. You can back up, or archive, this file regularly as a precaution against loss. If the list is removed, renamed, or changed your manually installed agents cannot correctly contact the Agent Managers and Consolidators.

Securing the Mission Critical Software directory

By default, the Mission Critical Software directory (%Documents and Settings%\All Users\Application Data\Mission Critical Software) is created with Everyone (Read and Execute, Read, List folder contents). The Everyone ACE should be removed from the ACL because an attacker gaining access to your MOM server through the network will be able to view these temporary files. These files contain information that can be useful to an attacker. This directory contains data for the temporary storage in the Agents and Configuration Group directories. The remaining ACEs should be sufficiently secure.

Warning Do not make these setting changes in the

%Documents and Settings%\All Users\Application Data

directory or in its parent directories. Doing so can cause other applications to not function properly.

Securing log files

Log files stored on the agent and Agent Manager include information that might be useful to an attacker, such as services that are installed, registry values that are created, directories that are created, files that are copied onto the agent computer, and the associated date and time stamps for each action.

The following log files and directory should be kept secure by using restrictive ACLs on the files. These ACLs must be altered after installing the agents. The ACEs you use depend on your security policy, although the Administrator, Domain Administrators, SYSTEM, and OnePointOp ConfgAdms groups should always be in the ACL.

• %Program Files%\Microsoft Operations Manager 2000\AgentInstall.log. This file contains detailed installation information and is located on all manually installed agents. For more information about the AgentInstall log file, see Chapter 8, MOM Agent Management.

• %Program Files%\Microsoft Operations Manager 2000\OperationsInstall.log. This file is located on the DCAM server and contains detailed information about how and when MOM was installed on that particular server. This data is different for each DCAM server and is useful for troubleshooting installation problems.

• %Program Files%\Operations Manager 2000\OnePoint\InstallService\ComputerLogs. This directory is located on the DCAM server and contains log files that show how and when MOM installed agents automatically.

Securing port communications

Communication between the agent and Consolidator is socket-based, encrypted (but not authenticated) Transmission Control Protocol (TCP). By default, the agent uses port 1270 for encrypted communication and port 51515 for unencrypted communication. For security reasons, it is more detrimental for the agent to trust the Consolidator than for the Consolidator to trust the agent. For this reason, the agent is designed to always initiate communication with the Consolidator.

You might also consider changing the communication port to a port that is only known to the administrators of your organization. This method, however, is not secure because an attacker could potentially discover the port being used through various means. For more information about changing the port number, see the Overview of Security Issues section in chapter 8, MOM Agent Management.

For even greater security outside a firewall, you can use IP access lists on your firewall (based on the source and destination IP addresses of monitored computers) to prevent the misuse of port 1270 by unauthorized parties. Be aware that these lists need to be updated when new agents are added or when new MOM consoles are added on your network. For more information about IP access lists, see the product documentation of your firewall.

If the Use unencrypted communication port check box is selected, MOM uses unencrypted communications. Because unencrypted communications can expose information that is potentially useful to an attacker, use this option with caution.

Securing the Windows 2000 Registry

MOM stores important and sensitive data in the Windows registry. Access to the registry should therefore be reviewed and restricted as part of securing MOM. In Windows 2000, there is no graphical user interface for assigning or configuring permissions on the individual registry hives. Therefore, permissions are set on the executable files that read and alter to registry. By default, Windows 2000 installs Regedit.exe (in the WINNT directory) with sufficient permissions. However, because Regedt32.exe is installed with the Everyone (Read and Execute, Read) ACE, need to remove the Everyone ACE from this ACL.

Procedures

You can use the following procedures to administrate the security of your MOM servers. The procedures are listed in the order outlined in the Administration section later in this chapter.

For more information about Windows NT 4.0 installations, see the Microsoft Support Web Site or contact NetIQ. For more detailed information about Windows 2000 or SQL Server 2000 security procedures, see the respective documentation.

Important You should thoroughly test all changes to configuration settings before deploying them a production server.

How To Secure Reporting

To set share permissions on the Reports directory

1. Using Windows Explorer, navigate to the share

   %Program Files%\Microsoft Operations Manager 2000\Event\Reports.

2. Right-click the Reports directory, and then click the Sharing tab.

3. Click Permissions.

4. In the list of user accounts and groups with permission to the directory, select the Everyone group, and then click Remove.

5. Click OK.

Note Setting Deny on the Everyone account can have unpredictable side effects because of the order in which Windows 2000 reads and applies the access-control entries (ACEs) in an ACL. To deny access to the Everyone group, remove its ACE from the ACL instead of setting a Deny permission on the ACE.

To set NTFS permissions on the Reports directory

1. Using Windows Explorer, navigate to the share

   %Program Files%\Microsoft Operations Manager 2000\Event\Reports.

2. Right-click the Reports directory, and then click the Security tab.

3. In the list of user accounts and groups with permission to the directory, select the Everyone group (if it exists), and then click Remove.

4. Click OK.

To set NTFS permissions on the reports database file (EeaRept.mdb)

1. Using Windows Explorer, navigate to

   %Program Files%\Microsoft Operations Manager 2000\OnePoint\Reporting\EeaRept.mdb.

2. Right-click EeaRept.mdb, and then click Properties.

3. In the EeaRept.mdb Properties dialog box, click the Security tab.

4. In the list of user accounts and groups with permission to the directory, select the Everyone group, and then click Remove.

5. Make sure that the ACLs on this file are the same for the Reports directory.

6. Click OK.

To disable basic authentication

1. On the taskbar, click the Start button, click Programs, click Administrative Programs, and then click Internet Services Manager.

2. In the left pane, expand the MOM server node, and then expand Default Web Site.

3. Right-click the Reporting virtual directory, and then click Properties.

4. Click the Directory Security tab, and then click Edit under Anonymous access and authentication control.

5. In the Authentication Methods dialog box, clear the Basic Authentication check box.

6. Click OK.

To enable SSL encryption (for use with basic authentication)

Note You must obtain a server certificate before you can enable SSL encryption. For information about obtaining a server certificate, see the Internet Information Services online Help.

1. On the taskbar, click the Start button, click Programs, click Administrative Tools, and then click Internet Services Manager.

2. In the left pane, expand the MOM server node, and then expand the Default Web Site node.

3. Right-click the Reporting virtual directory, and then click Properties.

4. In the Reporting Properties dialog box, click the Directory Security tab, and then click Edit under Secure Communications. If the Edit button is disabled, you need to install a server certificate. For more information about installing a server certificate, see the Internet Information Services documentation.

5. In the Secure Communications dialog box, select the Require secure channel (SSL) check box.

   Important Enable SSL encryption in the Reporting Properties dialog box and not in the Default Web Site Properties dialog box because the latter will require SSL over HTTPS for all of the default Web site resources.

6. Click OK.

To set reporting to use an HTTPS URL

Note: You must change the Uniform Resource Locator (URL) used for the reporting features to HTTPS because it is required for SSL encryption.

1. In the MOM Administrator console, expand Configuration.

2. Click Global Settings and in the right pane, right-click Web Addresses, and then click Properties.

3. In the Configuration Group Global Settings dialog box, click the Web Addresses tab,

4. Under Reports, type s after http to the URL in the Address box.

5. Click OK.

   Reporting will immediately use the new HTTPS address.

6. Inform users of the URL change, because using the old URL will result in an error in the Web browser.

To set permissions for the client-side reporting tools

1. Using Windows Explorer, navigate to the

   %Program Files%\Microsoft Operations Manager 2000\Event\Reports
   directory.

2. Right-click the Reports directory, and then click Properties.

3. Click the Security tab, and then make sure that the user account or group that accesses the reporting features on the client have sufficient privileges to the directory.

How to Secure the MOM Database

To set NTFS permissions on the OnePoint database

1. Using Windows Explorer, navigate to the

   %Program Files%\Microsoft Operations Manager 2000\ActiveOperations\DB
   directory.

2. Right-click the DB directory, and then click Properties.

3. Click the Security tab, and then make alterations to the ACLs on the directory.

   This ensures that both the database file and log file have the same ACLs.

To set the password for a SQL Server login account

1. On the taskbar, click the Start button, click Programs, click Administrative Tools, and then click Services.

2. In the Services console, right-click MSSQLSERVER, and then click Properties.

3. Click the Log On tab, and then type the new password in the Password and Confirm password boxes for the account in the This account box.

4. Click OK.

5. Right-click SQLSERVERAgent, and then click Properties.

6. Click the Log On tab, and then type the new password in the Password and Confirm password boxes for the account in the This account box.

7. Click OK.

   You do not need to restart the server for the changes to take place.

How to Secure the Web Console

To set NTFS permissions on the Web console directory

1. Using Windows Explorer, navigate to the %ROOT%\Inetpub\wwwroot\WebConsole directory.

2. Right-click the WebConsole directory, and then click Properties.

3. Click the Security tab, and then clear the Allow inheritable permissions to propagate to this object check box.

4. In the Security dialog box, click Copy to copy the parent directory´s permissions to the WebConsole directory.

   Note After the check box is cleared, changes to the permissions for the parent directory will not be propagated to the WebConsole directory.

5. In the Properties dialog box, select Everyone in the list, and then click Remove.

6. Click Add.

7. In the Select Users, Computers, or Groups dialog box, select the appropriate user account or user group in the list, and then click Add.

8. When all of the users or groups are added to the list, click OK.

9. In the Properties dialog box, click OK.

To disable anonymous authentication

1. On the taskbar, click the Start button, click Programs, click Administrative Programs, and then click Internet Services Manager.

2. In the left pane, expand the MOM server node, and then expand Default Web Site.

3. Right-click the Web Console virtual directory, and then click Properties.

4. Click the Directory Security tab, and then click Edit under Anonymous access and authentication control.

5. In the Authentication Methods dialog box, clear the Anonymous Authentication check box.

6. Click OK.

To enable SSL encryption (for use with Web console)

Note You must obtain a server certificate before you can enable SSL encryption. For information about obtaining a server certificate, see the Internet Information Services Help.

1. On the taskbar, click the Start button, click Programs, click Administrative Tools, and then click Internet Services Manager.

2. In the left pane, expand the MOM server node, expand Default Web Site.

3. Right-click the Web Console virtual directory, and then click Properties.

4. In the Web Console Properties dialog box, click the Directory Security tab, and then click Edit under Secure Communications. If the Edit button is disabled, you need to install a server certificate. For more information about installing a server certificate, see the Internet Information Services documentation.

5. In the Secure Communications dialog box, select the Require secure channel (SSL) check box.

   Important Enable SSL encryption in the Reporting Properties dialog box and not in the Default Web Site Properties dialog box because the latter will require SSL over HTTPS for all of the default Web site resources.

6. Click OK.

To set the Web console to use a HTTPS URL

Note You must change the URL used for the Web console to HTTPS because it is required for SSL encryption.

1. In the MOM Administrator console, expand Configuration.

2. In the right pane, right-click Web Addresses, and then click Properties.

3. In the Configuration Group Global Settings dialog box, click the Web Addresses tab.

4. Under Web Console, type s after http to the URL in the Address box.

5. Click OK.

   Reporting will immediately use the new HTTPS address.

6. Inform users of the URL change, because using the old URL will result in an error in the Web browser.

How to Secure Agents

To set NTFS permissions on ManualMC.txt

1. Using Windows Explorer, navigate to the

   %Program Files%\Microsoft Operations Manager 2000\OnePoint directory.

2. Right-click ManualMC.txt, and then click Properties.

3. Click the Security tab, select Everyone in the list, and then click Remove.

4. Make whatever changes you find necessary to comply with your security policy, and then click OK.

To set NTFS permissions on the Mission Critical Software directory

1. Using Windows Explorer, navigate to the

   %Documents and Settings%\All Users\Applications Data\Mission Critical Software directory.

2. Right-click the Mission Critical Software directory, and then click Properties.

3. Click the Security tab, select Everyone in the list, and then click Remove.

Warning: Do not make these setting changes in the %Documents and Settings%\All Users\Application Data directory or in its parent directories. Doing so can cause other applications to not function properly.

How to Secure the Windows 2000 Registry

Caution Any changes made involving the Windows registry should be done with caution. The ACLs on the Regedit.exe and Regedt32.exe determine who can access the registry. When restricting access to the registry, never remove the SYSTEM.

To set access to the Windows registry

1. Using Windows Explorer, navigate to the %WINNT%\System32 directory.

2. Right-click Regedt32.exe, and then click Properties.

3. Click the Security tab, select Everyone in the list, and then click Remove.

4. In the list, select the OnePointOp group that is appropriate, and then click Add.

5. Repeat step 4 for each group that you want to add, and then click OK.

Reference

MOM installs a wide range of default settings. Understanding these settings and their implications can help you plan and complete the security administration of your MOM servers. The following tables show the default settings for COM+, IIS, NTFS ACLs, Windows user accounts and groups, SQL Server, and events that are of interest to security administration.

COM+ Settings

Table 5.3

Application	Level	Account	Role	Component
MOMDasLocator	Application	DAS	None	DasLocator.DasServers
OnePointActiveOpsDas	Interface	DAS	See table 5.4	See table 5.4

Table 5.4

Role	Member
EeaConfig	<servername>\Administrators <servername>\OnePointOp System <servername>\OnePointOp ConfgAdms
EeaKnowledgeAuthor	<servername>\Administrators <servername>\OnePointOp System
EeaOperator	<servername>\Administrators <servername>\OnePointOp System <servername>\OnePointOp ConfgAdms <servername>\OnePointOp Operator
EeaSystem	<servername>\Administrators <servername>\OnePointOp System
EeaUser	<servername>\Administrators <servername>\OnePointOp System <servername>\OnePointOp ConfgAdms <servername>\OnePointOp Operator <servername>\OnePointOp Users

Understanding and using Table 5.5

Table 5.5 relates several facets of information about the specific tasks that users assigned to COM+ roles can perform in the OnePoint database. The table shows what COM+ roles can perform tasks on these tables, and what specific type of access the COM+ role has to the table.

Important The table is provided for information purposes only. Changes to the role memberships or any other facet of the COM+ settings related in the table are not supported.

The letters under the roles in Table 5.5 indicate whether there are any methods that the role can call and what specific type of access the role can have to the OnePoint database tables. For example, in the Alert row, the System role has letters that represent SELECT, UPDATE, INSERT, DELETE, and BULK INSERT access to the OnePoint.Alert table, whereas the Operator and Users roles have only SELECT and UPDATE access to the table. The other roles do not have access to the table.

The letters in Table 5.5 have the following meanings:

• S = SELECT (read) access

• U = UPDATE (write) access

• I = INSERT (write) access

• D = DELETE (write) access

• BI = BULK INSERT (write) access

Table 5.5

Table	System	Config Admin	Operator	User	Author
Akm					S,U,I,D
AkmToMonitorView					S,I,D
Alert	S,U,I,D,BI		S,U	S,U
AlertEventSupression	I
AlertHistory	S,I,D		S,I	S
AlertLevel	S,U,I,D			S
AlertToEvent	D,BI
Common				S
Component		S,U,I,D		S
Computer	S,U,I,D	S,U	S,U	S
ComputerAttribute		S,U,I,D	S,D	S
ComputerAttributeDefinition			S,U,I,D
ComputerResponsibility		S,U,I,D
ComputerRule			S,U,I,D	S
CompouterRuleToProcessRuleGroup			S,U,I,D
ComputerToComputerRule		S,I,D	D
Configuration		S,U,I,D		S,U,I
DasServers		S,I,D		S
Event	S,U,I,BI			S
EventConsolidated	S,I,D			S
EventParam	S,BI			S
EventParamName	S,I,D
EventSource	S,I			S
EventType	S,I,D			S
GroomJob		S,U
GroomJobCriteria		S
GuiClass		S,U,I,D		S
KBase					S,U,I,D
KBaseComment					S,U,I,D
KBaseHistory			S,I	S
KBaseSection					S,I,D
KpcType	S,I,D		S
License	S	S,I,D		S
Logging	I
MessageDll	S	S		S
MonitorView				S,U,I,D
NotifyGroup			S,U,I,D	S
NotifyGroupMember			S,I,D	S
NotifyHistory	S,I,D			S
Operator			S,U,I,D	S
PerfmonCounterScale	S,I			S
ProcessRule			S,U,I,D,BI	S
ProcessRuleComment			S, I,D,BI	S,I,D
ProcessRuleMembership			S,U,I,D,BI
ProcessRuleToNotifyGroup			I,D,BI	S
ProcessRuleToScript			S,U,I,D,BI
ProviderInstance			S,U,I,D
ProviderType	S,U,I,D		S
ResolutionState		S,U,I,D		S
RoleSecurity	S*	S*	S*	S*	S*
RuleType	S,I,D			S
RuleTypeToProviderType			S,I,D
SampledNumericData	S,I,D,BI			S
SampledNumericDataSource	S,U,I			S
Script			S,U,I,D
StringLocalization	I			X
Task				S,U,I,D
TodayStatistics				S,U
User				S,I
UserDefiniedField		S,U		S
Vendor	S,I			S
AuditLog	S,U,I,D,BI
AuditLogValues	S,U,I,D,BI

* Each role can only view information about its own role.

IIS Settings

Table 5.6

Virtual Directory	File System Directory	Access Permission	Execute Permission	Authentication
OnePointOperations	wwwroot\WebConsole	Read, Log visits, Index this resource	Scripts and executables	Integrated Windows
Reporting	Program Files\Microsoft Operations Manager 2000\Event\Reports	Read, Log visits, Index this resource	Scripts and executables	Integrated Windows
WebConsole	wwwroot\WebConsole	Read, Log visits, Index this resource	Scripts only	Integrated Windows

Windows NTFS Settings

Table 5.7

Directory	ACL	Share Permissions
% Program Files%\Microsoft Operations Manager 2000	Administrators (Full Control) CREATOR OWNER (Special) Power users (Modify, Read & Execute, List Folder Contents, Read, Write) SYSTEM (Full Control) TERMINAL SERVER USER (Modify, Read & Execute, List Folder Contents, Read, Write) Users (Read & Execute, Read)	None
% Program Files%\Microsoft Operations Manager 2000\Reports	[inherited from parent]	Everyone (Full Control) [Web Share] (Read, Execute)
% Program Files%\Microsoft Operations Manager 2000\OnePoint	[inherited from parent]	None
% Program Files%\Microsoft Operations Manager 2000\ActiveOperations *	[inherited from parent]	None

* The ActiveOperations directory is created during the MOM database installation and is found only on a server which has the MOM database installed.

Windows User Accounts and Groups

Table 5.8

Account	Security Policies	Member Of	Notes
DAS	Act as part of the operating system. Create a token object. Log on as a batch process. Log on as a service.	Administrators; Users	Manually created before installing MOM. Policies are manually configured.
CAM	Act as part of the operating system. Create a token object. Log on as a batch process. Log on as a service.	Administrators; Users	Manually created before installing MOM. Policies are manually configured.

Table 5.9

Account	Default Members
ConfgAdms	DAS; Administrators
System	DAS; Administrators
Operators	DAS; Administrators
Users	DAS; Administrators
Reporting*	DAS; Administrators

* To enable reporting, you must add this group to the ACLs on the

%Program Files%\Microsoft Operations Manager 2000\OnePoint\Reporting\EeaRept.mdb file. Give the group Read, Read & Execute, and Write permissions.

SQL Server 2000 Settings

Table 5.10

Login	Default Database	Server Roles	Database Permissions
BUILTIN\Administrators	Master	System Administrator	ALL : public, db_owner
sa	Master	System Administrator	ALL : public, db_owner
BUILTIN\Users *	OnePoint	None	none
OnePointOp Reporting	OnePoint	None	OnePoint : public, EeaReportViewer

* BUILTIN\Users login appears only in single-server installations.

Table 5.11

Database Role	Users	Permissions
EeaConfig	None	OnePoint.DasServer (Table) - SELECT OnePoint.DasServerSelectAll (Stored Procedure) - SELECT
EeaKnowledgeAuthor	None	OnePoint.DasServer (Table) - SELECT OnePoint.DasServerSelectAll (Stored Procedure) - SELECT
EeaOperator	None	OnePoint.DasServer (Table) - SELECT OnePoint.DasServerSelectAll (Stored Procedure) - SELECT
EeaSystem	None	OnePoint.DasServer (Table) - SELECT OnePoint.DasServerSelectAll (Stored Procedure) - SELECT
EeaUser	None	OnePoint.DasServer (Table) - SELECT OnePoint.DasServerSelectAll (Stored Procedure) - SELECT
EeaReportViewer	OnePointOp Reporting	[numerous Tables and Views] - SELECT

MOM Security Alerts and Events

Table 5.12

Event ID	Alert Text	Notes
9200	Malformed packet	The socket server on the port received a malformed packet. This might indicate a possible attack attempt.
9201	Large packet	The socket server on the port received a very large packet. This might indicate a possible attack attempt.
21280	Agent cannot send encrypted data due to operating system restrictions	The operating system installed on the Agent machine does not permit encryption.
25012	Log cleared	The event log appears to have been cleared since it was last read. This might indicate the an attacker is trying to remove evidence of their actions.
25001	Log cleared	Log appears to have been cleared while the event provider was down. This might indicate the an attacker is trying to remove evidence of their actions.
25215	Unrecoverable error occurred	Application Log source was unable to load configuration information from the registry. Application Log source shut down.
21195	Agent Manager Alert: User attempted to initiate an Agent Manager operation	A user attempted to initiate an Agent Manager operation. The attempt was rejected because the user is not a member of the EeaConfig role of the OnePointActiveOpsDas COM+ application. The user account can be placed in this role by making it a member of the OnePointOp ConfgAdms local user group on the DAS computer. This might signal an attack attempt.

Table 5.13*

Event ID	Event Description	Notes
Success – 517	The audit log was cleared	This is one way that attackers could remove any evidence of their actions.
Success – 576	Special privileges assigned to new logon	This might indicate an attacker is elevating privileges.
Success – 608	User Right Assigned	This might indicate an attack elevating privileges.
Success – 610	New Trusted Domain	The identified user created a trust relationship with the specified domain. Creating certain trust relationships can have serious security implications. Trusted relationships created by a user who is not trusted can be a security risk.
Success – 611	Removing Trusted Domain	The identified user removed a trust relationship with the specified domain. Removing certain trust relationships can have serious security implications. Trusted relationships removed by a user who is not trusted can be a security risk.
Success – 612	Audit Policy Change	This might indicate that an attacker is attempting to remove evidence of the attack.
Success – 624	User Account Created	This might indicate that an attacker is creating an account to use later.
Success – 628	User Account password set	This might indicate that an attacker has taken control of an existing privileged account.
Success – 630	User Account Deleted	This might indicate that an attacker is locking out a user or attempting to remove evidence of the attack.
Success – 632	Security Enabled Global Group Member Added	This might indicate that an attacker is creating a group to use later.
Success – 632	Security Enabled Global Group Member Removed	This might indicate that an attacker is locking out a group of users or attempting to remove evidence of the attack.
Success – 636	Security Enabled Local Group Member Added: WHERE Target Account ID: Administrators	This might indicate that an attacker has been added to the Administrators group. Additions to this group should be monitored carefully.
Success – 637	Security Enabled Local Group Member Removed: WHERE Target Account ID: Administrators	This might indicate that an attacker is locking out one or more of the administrators or attempting to remove evidence of the attack. Deletions from this group should be monitored carefully.
Success – 642	User Account Changed	This might indicate an attacker is elevating privileges.
Success – 643	Domain Policy Changed: Password Policy	This might indicate an attacker is making it easier to guess passwords on the system or to create a social engineering attack.
Failure – 628	User Account Password Set	This might indicate that an attacker attempting to take control of an existing privileged account.
Failure – 529	Logon Failure: Unknown user name or bad password	An attempt to log on using an unknown user account or a valid user account but with an incorrect password. An unexpected increase in the number of these audits could represent an attempt by someone to find user accounts and passwords (such as a "dictionary" attack, in which a list of words is used by a program to attempt entry).
Failure– 530	Logon Failure: Account logon time restriction violation	An attempt to log on was made and rejected because the user tried to log on before or after the hours that the user is allowed to connect to the server.
Failure – 533	Logon Failure: User not allowed to logon at this computer	An attempt to log on to a computer the user is not authorized on
Failure – 534	Logon Failure: The user has not been granted the requested logon type	An attempt was made to log on, but the local security policy of the computer does not allow the user to log on in the requested fashion (such as interactively).
Failure – 535	Logon Failure: The specified account's password has expired	An attempt to log on using an account whose password has expired.
Failure – 535	Logon Failure: The specified account has expired	An attempt to log on using an account that has expired.
Failure – 539	Logon Failure: Account locked out	A logon attempt was made and rejected because the account has been locked out. An account gets locked out after the number of unsuccessful logon attempts exceeds the preset limit established in the domain policy.

*This list is only a subset of Windows Audit Events that can be reviewed regularly.