Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
This chapter is from the book

Application Privileges and Restrictions

Application security can be broken down into two categories. The first deals with managing user access to only those applications they are required to use, and the second deals with controlling what options and functionality within an application are available to different users. The extent to which you need to manage both categories depends on the requirements of your implementation. If you run a large number of applications on your servers, it is likely you will need to limit access to one or more of these applications (or functionality within these applications) based on security, licensing, or performance requirements.

NOTE

Two separate Terminal Server audits I performed easily demonstrate how different organizations can view application security. In both cases, one finding was that all applications remained accessible to all users on the server.

For one administrator this came as no surprise and had been left as such simply be-cause all Terminal Server users accessed the same group of applications, and highly sensitive data was not accessed through their Terminal Server implementation.

For the other administrator it was a completely different story. Application segregation was supposed to have been implemented prior to this team's inheriting the Terminal Server environment, and the lack of any proper controls was a major concern because sensitive sales and customer information was easily accessible to any user interested and determined enough to search for it.

Application Access Restrictions

In a Terminal Server environment, application access is usually managed in one of two ways:

  • Restricting application access—The most common method of access management is to assume that all Terminal Server users have access to all applications on the server, and only those applications that require limited access are restricted through special application security groups.

  • This implementation is commonly used simply because this is the default behavior of Windows. When an application is installed on a Windows Terminal Server, by default it is accessible to all users unless access restrictions are defined at the file system level, the application level, or both. For example, an inventory management system may be installed on a Terminal Server and all users can launch the application and reach the logon prompt, but only those users authorized to actually access the application have a valid user ID and password.

  • Granting application access—The alternate application access method assumes that users have no access to any of the applications on the server unless such access has been explicitly granted. Not only is this management method the more restrictive of the two, but it also takes much more work up front to configure properly and can quickly become cumbersome, particularly when a large number of applications are involved. One benefit to being so restrictive is that users are not automatically able to run new applications introduced onto the server; this as a result helps guard against rogue applications being introduced via e-mail or download.

While the second option is certainly more appealing from a security perspective, trying to manage multiple application access lists for different groups of users can quickly become overwhelming. The best approach to restricting application access is to implement a combination of the two access methods. By combining the two, you still enjoy the additional security benefits of explicitly defining what executables a user can run while minimizing the time required to manage such an implementation.

When combining the two, the first task is to establish a list of all applications users are authorized to run. Specific items on the list are then restricted further, accessible only to the subset of users authorized to run those specific applications. For example, a typical application access list for a Terminal Server user might look like the one shown in Table 16.8. A single application access list is created, but then only users belonging to the appropriate groups can access the Inventory Management or Customer Billing programs.

Table 16.8 A Windows Terminal Server Application Access List Example

Application

Notes

Microsoft Word Excel

These applications are available to all users and not Microsoft restricted based on group membership. Microsoft Outlook Custom Time-Tracking App

Inventory Management

This application is available only to members of the APP_Inventory_Mgr group.

Customer Billing

This application is available only to members of the APP_Cust_Billing group.


How you approach the restriction of application access will depend on the version of Windows that you are running and how tightly you wish to enforce these restrictions. The three different methods of locking down application access that I will discuss are:

  • The "Run only allowed Windows Applications" group policy object. This GPO allows you to manage a list of allowed Windows applications that can be executed by users affected by the policy. Usually the policy is applied to all non-administrative users logged on to a Terminal Server. The one limitation of this policy is that it does not track applications based on their full path, only their application name. This creates the situation where a user could execute any desired application, simply by changing the application's name to be the same as an application that is authorized to run.

  • The APPSEC security utility. This tool, available as part of the Windows 2000 Server Resource Kit allows you to define a list of allowed applications, much like the "Run only allowed Windows Applications" group policy. The three main differences between this utility and the GPO are:

    • All non-administrator users are affected by this application's restrictions. There is no way to limit the access based on a particular security group.

    • Only application executables that reside on a server's physical drive can be executed. Any attempt to launch a network-based executable will fail.

    • The listed applications must reside with the specific path specified for that application. Attempting to run a listed application from any other location will fail.

    These differences greatly increase the effectiveness of the APPSEC utility to more tightly secure an environment when compared to the "Run only allowed Windows Applications" GPO.

  • Windows Server 2003 does not support the APPSEC security utility. Instead it has introduced the "Software restriction policies," a much more robust version of the "Run only allowed Windows Applications" GPO. This GPO allows for the following:

    • Determine whether the default behavior of the GPO is to allow applications to execute based on the access rights of the user, or to restrict access to all executables regardless of access rights.

    • Applications to be allowed or restricted can be identified by a binary hash that is calculated, a certificate or a file system path or Internet security zone. These choices allowing for the clear identification of the authorized executable while still allow flexibility in how it is located and run.

    • Entire folders can also be managed, allowing all applications within those folders to be assigned restricted or unrestricted application execution access.

I will now take a brief look at each of these three choices.

Run Only Allowed Windows Applications Group Policy Object

Through use of a group policy object, Windows provides the ability to limit a user's access to only those applications explicitly defined for that user. The specific GPO is located under

User Configuration\Administrative Templates\System

and is called "Run only allowed Windows applications." Typically this particular policy can be defined as part of the Terminal Server Regular Users GPO, so it is applied to all non-administrative users logged on to a Terminal Server. Figure 16.19 shows the dialog box for this policy in a Windows 2003 domain. The applications are added by clicking the Show button and entering the corresponding executable name.

Figure 16.19Figure 16.19 The Run Only Allowed Windows Applications Properties dialog box.

For a user to be able to properly work within a Terminal Server session, you must be certain that you include all the necessary executables the user will need to run. When a user attempts to run an application not included in the list, they receive an error message similar to the one in Figure 16.20.

Figure 16.20Figure 16.20 Attempting to access an application not authorized results in this message.

Contrary to what you might think, you are not required to list any of the core Windows components required for a user to be able to log on, such as winlogon.exe, wfshell.exe, or explorer.exe. This is because the application list applies only to launching programs through Windows Explorer. Applications launched directly from the system or through a command prompt are not controlled by this policy. If you restricted the user's ability to access the command prompt, they cannot circumvent Explorer to launch applications directly. If you enable this policy but include no applications in the list, the user still can log on to the server but once logged on cannot launch any applications.

Table 16.9 shows an actual executable list taken from a Terminal Server implementation where users were restricted to running only the listed applications. Note that this list also includes a batch script. If you provide users with an application shortcut that launches a batch script that in turn launches an executable, you must include the batch script name in the authorized application list or it will fail to launch. The name of the executable itself is not required because it is launched from within the batch script.

Table 16.9 Sample Listing of Allowed Application Executable Names Taken from an Actual Terminal Server Implementation

Executable Name

Application Name

Notes

Excel.exe

Microsoft Excel

 

Iexplore.exe

Internet Explorer

 

Notes.cmd

Custom batch script to launch Lotus Notes

This batch script performs some configuration prior to starting Lotus Notes. Note that the script name is included in the executable list but not the actual Notes executable. This is because the executable is launched from within the CMD session initiated by the batch script and is not controlled by this application access list.

Osa.exe

Microsoft Office Startup Assistant

This is provided with Office XP and a number of shared Office components for use. It is normally found in the Startup folder.

Outlook.exe

Microsoft Outlook

 

PN.exe

Citrix Program Neighborhood

If you're going to allow users to access published applications available on different servers through a Terminal Server session, then PN.exe must be made available. This is required only when using the ICA passthrough client. If users are launching published applications directly from their local PC desktop, this executable does not need to be included in the list.

Powerpnt.exe

Microsoft PowerPoint

 

Winword.exe

Microsoft Word

 


Once the list of all allowable applications has been defined and implemented, access to these applications can be further restricted using security groups if necessary. For example, if access to Microsoft PowerPoint was to be limited to only a few individuals, then a group could be created (for example, APP_TS_PowerPoint_Users) and used to define security on the PowerPoint executable. Any users not belonging to this group who attempted to run PowerPoint would receive an access-denied message.

TIP

Whenever a Terminal Server implementation calls for restriction of access to one or more applications, it can be less confusing to the user if the Start menu has been organized in such a way that applications they cannot access are segregated and, ideally, not even visible. Common applications accessible by all users are usually located under the main portion of the Start menu, while restricted applications available to only a limited number of users are located in subfolders with labels such as "Customer Service Managers" and "Order Desk Sales Reps." The permissions on these subfolders are set to grant read access to only those users authorized to run the applications they contain, so when other users click the subfolder it appears empty, as shown in Figure 16.21.

Figure 16.21Figure 16.21 A sample Start menu configuration based on application access restrictions.

The APPSEC Security Utility

Before running the APPSEC utility you must download the appropriate installation files from the Microsoft Web site and install APPSEC on your Terminal Server. The version of APPSEC that ships with the Windows 2000 Server Resource Kit will not function properly as it is missing some necessary system files. The APPSEC.ZIP file can be downloaded from the Microsoft FTP site at: ftp://ftp.microsoft.com/reskit/win2000/

Once downloaded, extract the contents into a temporary folder and then run InstAppSec to install the tool.

The APPSEC security utility is launched by running APPSEC from a command prompt or using the Run command on the start menu. Once started, the main APPSEC application window will appear as shown in Figure 16.22. The application automatically includes a set of applications required for a user to be able to log onto the server. By default the APPSEC utility will be disabled until explicitly enabled by an administrator.

Figure 16.22Figure 16.22 The APPSEC Windows 2000 application security utility.

Once APPSEC has been enabled, the settings will immediately be applied to any new user session logons. Users currently logged onto the server will not pickup these changes until they have logged out and back into the server. APPSEC settings apply only to regular users and will never restrict anyone with administrative privileges. When a user attempts to run an application not in the list they will receive an error message stating that "Access to the specified device, path or file is denied."

Adding and removing applications from the list are very straightforward and performed by selecting the desired option. When adding new applications to the list, there is an option available to "track" the results of running a particular application (Figure 16.23). Tracking allows an administrator to run an application while APPSEC monitors and adds any associated executables to the list. This helps to ensure that a particular program has all of the necessary components in order to work properly.

Figure 16.23Figure 16.23 The APPSEC utility provides a means of tracking any associated executables for an application to ensure they are all added to the allowed application list.

While APPSEC provides a very rudimentary interface, it can be a very powerful tool for securing a Windows 2000 Terminal Server environment.

Windows Server 2003 Software Restriction Policies

Windows Server 2003 provides the specific GPO for Software Restriction Policies, which can be found under

Windows Settings\Security Settings\Software Restriction Policies

By default this policy is not enabled and must be created by right-clicking Software Restriction Policies and selecting New Software Restriction Policies (SRP). Once selected the appropriate settings for the policy are created and available to be set as shown in Figure 16.24.

Figure 16.24Figure 16.24 Software Security Policies in Windows Server 2003 replace the APPSEC tool.

The basic layout of the Software Restriction Policies is as follows:

  • Only one SRP is created for each GPO. After selecting New Software Restriction Policies, that option will no longer be available unless the existing SRP is deleted.

  • Under the Software Restriction Policies folder, there are three attributes, which are

    • Enforcement—This setting dictates the general enforcement criteria for the policy. By default, it will restrict only executables (not executable libraries such as DLLs) and will apply to all users affected by the policy, including administrators.

    • Designated File Types—In addition to the standard executables files with the suffix EXE all of the file types listed here are assumed to represent executables and will be included in the software restrictions. File types can be added and removed on this screen.

    • Trusted Publishers—Defines whether or not the user has any control over what publishers will be trusted when presented with certificates that verify the authenticity of an application.

  • The Security Levels folder has two items, Disallowed and Unrestricted. Only one of these items can be set as the default at any given time. When Disallowed is chosen, the policy enforces that no users will be able to run software, unless the software has been designed as an additional rule, which is discussed next. If the Unrestricted option is chosen, then all applications are accessible unless explicitly denied in the Additional Rules section.

  • The Additional Rules folder is where the majority of the items will be managed. The purpose of this folder is to store either specific entries that are unrestricted or disallowed. Entries are added here simply by right-clicking and choosing the rule to define the entry. The four choices are Certificate Rule, Hash Rule, Internet Zone Rule and Path Rule. The most common select is Path Rule, allowing an administrator to provide an explicit path to a folder, executable file, or registry location. The security level for the rule dictates if the entry is unrestricted or disallowed.

In a Terminal Server deployment, the Software Restriction Policies are usually created within the Terminal Server Regular Users policy so that the changes are picked up by the non-administrative users in the environment.

Application Functionality Restrictions

In addition to allotting the desired application access to your various user groups, quite often you will want to control what options and functionality in an application are available to different users. The exact method by which these changes are performed (if they're even supported) will vary from application to application. Many provide their own integrated security based on a logon ID and password managed from within the program, while others such as Microsoft Office leverage functionality of group policy objects to allow customization based on group membership. When an application supports configuration changes using a GPO, the functionality is added into the active directory through what are know as administrative template files. Figure 16.25 shows the Add/Remove Templates submenu along with some of the Office XP templates already loaded into the Administrative Templates folder. Custom template files are usually stored in the WINNT\INF folder and have the extension ADM. More details on general installation and use of template files are provided in Chapter 15.

Figure 16.25Figure 16.25 Custom and third-party administrative template files can be added to a group policy in the active directory.

As part of a complete security implementation, I recommend that whenever you have the opportunity to customize and/or lock down any of the applications you are implementing, you should do so. By pre-configuring options such as target data directories, turning off Web-based integration, or disabling automatic update features, you are simplifying the user's environment and reducing the exposed areas where potential security issues could develop. The fewer the number of customization options available to the end user, the less likely you are to have application-related issues in the environment. In Chapter 20, I look more closely at some of the configuration options available for Microsoft Office through administrative templates.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020