Windows NT® Server
Server Operating System
White Paper
This White Paper describes Microsoft® Security Configuration Editor, a Microsoft Management Console (MMC) snap-in tool designed to reduce costs associated with security configuration and analysis of Windows NT®-based operating system networks. The Security Configuration Editor allows you to configure security for a Windows NT system, and then perform periodic analysis of the system to ensure that the configuration remains intact or to make necessary changes over time.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
The BackOffice logo, Microsoft, Win32, Windows, and Windows NT are registered trademarks of Microsoft Corporation.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0997
This White Paper describes Microsoft® Security Configuration Editor, a Microsoft Management Console (MMC) tool designed to reduce costs associated with security configuration and analysis of the Windows NT® operating systems.
The Microsoft Management Console is a Windows®-based, multiple-document interface (MDI) application that makes extensive use of Internet technologies. MMC is a core part of Microsoft's management strategy and is designed to provide a single host for all management tools, facilitate task delegation, and lower total cost of ownership for enterprise users of Windows and Windows NT. MMC itself does not supply any management behavior, but instead provides a common environment for snap-ins, which define the actual management behavior. Snap-ins are administrative components integrated into a common host—the MMC interface.
Security Configuration Editor is a snap-in component for MMC that is designed to provide a central repository for security-related administrative tasks. With Security Configuration Editor, you will be able to use a common tool to configure and analyze security on one or more Windows NT-based machines in your network.
The current version of the Windows NT network operating system has excellent security features built in. A single sign-on to the Windows NT domain allows user access to resources anywhere in the corporate network. The system provides tools for security policy and account management, and the Windows NT Domain model is flexible and can support a wide range of network configurations. Window NT 5.0 extends these features to provide support for Internet-aware enterprise networks and the new distributed services included in the operating system.
From the administrator’s point of view, Windows NT provides a number of graphical tools that can be used individually to configure various aspects of system security. However, these tools are not centralized—an administrator may need to open three or four applications to configure security for one computer. Using these applications is therefore considered costly and cumbersome by many security-conscious customers. In addition, security configuration can be complex—and with the distributed security features added in Windows NT 5.0, this complexity has increased.
While Windows NT 4.0 does provide adequate (if somewhat inconvenient) configuration tools, it lacks powerful tools for security analysis. The only tool provided that can be used to monitor security is Event Viewer, and it was not designed for performing corporate-level audit analysis. There are third-party tools for such analysis; however, those tools either lack enterprise-level features or are not comprehensive.
Security Configuration Editor, which is intended to answer the need for a central security configuration tool, will provide the framework for enterprise-level analysis functionality. Most importantly, it will reduce security-related administration costs by defining a single point where the entire system’s security can be viewed, analyzed, and adjusted as necessary. The goal is to provide a comprehensive, flexible, extensible, and simple tool for configuring and analyzing system security.
The primary goal of Security Configuration Editor is to provide a single point of administration for Windows NT system security. To meet that goal, the tool must allow the administrator to:
The process of configuring security in a Windows NT-based network can be complex and detailed in terms of the system components involved and the level of change that may be required. Therefore, Security Configuration Editor is designed to allow you to perform configuration at a macro level. In other words, the editor allows you to define a number of configuration settings and have them enacted in the background. With this tool, configuration tasks can be grouped and automated; they no longer require numerous, iterative key presses and repeat visits to a number of different applications to configure a group of machines.
Note that Security Configuration Editor is not designed to replace system tools that address different aspects of system security—such as User Manager, Server Manager, Access Control List (ACL) Editor, and so forth. Rather, its goal is to complement them by defining an engine that can interpret a standard configuration template and perform the required operations automatically in the background. Administrators can continue to use existing tools to change individual security settings whenever necessary.
To address the security analysis gap in Windows NT security administration, Security Configuration Editor will provide analysis at a micro level. The Editor is designed to provide information about all system aspects related to security. Security administrators can view the information and perform security risk management for their entire information technology (IT) infrastructure. In future versions, they will be able to create reports and perform specialized queries.
Security Configuration Editor is designed to be comprehensive, flexible, extendible, and simple.
Unlike other operating system features, security is a characteristic of the system as a whole. Almost every component of the system is responsible for some aspect of system security. Therefore, questions such as “Is my computer secure?” or “Is my network secure?” are extremely difficult to answer. Typically, a system administrator must examine many different system components and use many tools in an attempt to answer these questions. Microsoft’s goal is to have Security Configuration Editor be the resource for answering security-related questions, whether they are general (such as those listed above) or very specific. To provide comprehensive security administration and information, Security Configuration Editor allows you to configure and analyze all of the following:
Security Configuration Editor allows you to define Security Configuration Templates that include settings for security attributes in each of the areas outlined above. Using these templates, you can configure the system. Additionally, you can perform a security analysis on the system by using these templates as recommended configurations.
The templates are text-based .inf files. Configuration information is specified in different sections, and the information is parsed by the Editor’s configuration engine. The architecture is sufficiently flexible to support new sections if you need to specify new areas of security configuration and analysis as the system evolves.
Security Configuration Editor will include a set of predefined templates. You can choose to use these templates as shipped, or you can use them as starting points for building your own customized templates. The Editor’s template-editing functionality provides this flexibility.
The Security Configuration Editor is architected to be extendible. You can add extensions as new areas of security configuration, or as new attributes within an existing area. Since the configuration information is stored in a standard .inf file format, it can be easily extended without affecting backward compatibility.
Additionally, system services is a currently defined area that has been architected to be extendible within itself. It permits any service writer to implement a Security Editor Attachment that can configure security settings for a particular system service, as well as perform any analysis that may be required. Different Windows NT systems can be configured to run different sets of services. Also, Microsoft expects that independent software vendors (ISVs) who develop services will want to add their service’s security configuration and analysis to this overall security framework.
The tool initially supports security configuration and analysis for several native Windows NT services, including CIFS Server and Spooler.
Because Security Configuration Editor is designed to reduce costs associated with administering a network, it is vital that the tool be easy to learn and use. The Editor contains no complicated options—only a simple uniform graphical user interface (GUI) for defining configuration templates and viewing security analysis data. The interface uses the standardized context menus and views supported by Microsoft Management Console. There are no superfluous graphics or statistics, only a simple tabular view of the information with visual cues to flag security problems. In addition, the Editor contains a command-line utility to allow administrators to run configuration and analysis as part of a script. Administrators can use the graphical interface or the command line to apply a configuration template and perform analysis, enabling them to easily fit the tool into an existing administration model. And they can use the graphical interface to define templates and browse through analysis data.
The next section of this document provides a more in-depth evaluation of the Security Configuration Editor, its architecture, and how it fits into Windows NT.
Windows NT Distributed Security Services has many new features to simplify domain administration, improve performance, and integrate Internet security technology based on public-key cryptography. Highlights of the Windows NT Distributed Security Services include:
The security enhancements were specifically designed to meet the needs of distributed enterprise networks. While security services in Windows NT 5.0 are impressive, the need for a tool to easily configure and administer such capabilities is obvious. The Security Configuration Editor, a Microsoft Management Console snap-in, fills this need. (For a detailed description of the Microsoft Management Console, see the technical White Paper Microsoft Management Console: Overview, available from microsoft.com.)
Security Configuration Editor allows you to define Security Configuration Templates with prescribed security settings for attributes in each security area (areas include system policy, user accounts, registry, and so forth). Then, using these templates, you can configure the system or perform security analysis using the templates as your recommended configurations. Security Configuration Templates are standard text-based .inf files. After you create and install your template, Security Configuration Editor’s configuration engine parses the template and makes the corresponding changes to the system.
The Security Configuration Editor snap-in tool provides a graphical user interface that allows you to edit security configuration templates to define customized configurations. It also allows you to generate a template from settings in an existing system. (See Figure 1.)
Figure 1. Security Configuration Templates Prototype UI
As shipped, Security Configuration Editor will include standard and recommended configuration templates that will be effective in typical Windows NT configurations, including those installations that have Internet and intranet components. In addition, the snap-in’s editing capabilities will allow you to use the standard templates or create new ones by customizing them for your particular environment.
Security configuration for a system is subdivided into security areas, as stated previously. Microsoft has identified several security areas; however, new areas can be added in the future to support enhanced system functionality without breaking backward compatibility with existing templates. The security areas currently supported are:
For each object tree, Security Configuration Template allows you to configure and analyze settings for security descriptors, including object ownership, the Access Control List (ACL), and auditing information.
The Security Configuration Editor GUI is provided as a Microsoft Management Console (MMC) snap-in. The graphical interface supports the following administrative functions:
Note: While the graphical user interface provides all of the functionality listed above, the command-line utility supports configuring the system and collecting analysis data only. It does not support the creation or editing of templates or the viewing of analysis data.
Figure 2 is an example of the graphical user interface showing both the editor and analysis functionality (on the left side of the screen). Note that the System Services Settings analysis data is being viewed (see the right side of the screen).
Figure 2. Security Configuration Editor Snap-in Graphical User Interface
Figure 3 shows the usage parameters available with the Security Configuration command-line utility, secedit.
Figure 3. Secedit Command-Line Utility
The command syntax is:
secedit {/configure [/areas areas ] | /analyze} [/scppath scppath ] [/sadpath sadpath ] [/log logpath]
where:
/configure—configures the system.
/analyze—analyzes the system.
/scppath scppath—specifies the full path to the security configuration profile.
/sadpath sadpath—specifies the path to where the analysis database will be created for future security analysis. This information is ignored if the system has been configured or analyzed previously.
/areas areas—defines the security areas to be configured or analyzed.
/log logpath—specifies the path to the file where process errors will be logged.
This section describes how to use the Security Configuration Editor to configure various security aspects of a Windows NT 5.0 system. Note that this tool relies entirely on the security features of Windows NT—it does not alter the security capabilities of the system. Its sole purpose is to allow you to more easily configure and manage the advanced security features included in the latest version of the operating system.
In Windows NT 5.0, security policy can be set at the domain and computer level. This allows very fine-grained security control but can be difficult to configure. Figure 4 shows the template view for the Security Policies area.
Figure 4. Configuring Security Policy Settings
In Windows NT 5.0, a domain is a physical security boundary, and full administrative control is contained within a domain. A domain’s security policy defines how strong the passwords have to be, the password history, the lifetime of Kerberos tickets, account lockouts, and more. And you can define all of these attributes from the template.
Restricted Group Management allows you to manage the membership of built-in groups that have certain predefined capabilities. These groups include local groups such as Administrators, Power Users, Print Operators, Server Operators, and so forth, as well as global groups such as Domain Administrators.
You can also add groups that you consider sensitive or privileged to the Restricted Group Management list, along with their membership information. This allows you to track and manage these groups as well.
In addition to group membership, the area tracks and controls reverse membership of each restricted group in the MemberOf column. This column shows other groups to which the restricted group members can belong. You can use this field to control exactly which groups your restricted group members can join—You can also use this feature to limit a group of users to one group and prevent them from joining any others. (See Figure 5.)
Figure 5. Configuring Restricted Groups
The configuration engine ensures that group memberships are set as specified in the template. Groups and users not specified in the template are removed from the restricted group. In addition, the reverse membership configuration option ensures that each restricted group is a member of only those groups specified in the MemberOf column.
Rights and Privileges Management allows you to control who is granted rights and privileges on a given system. You can use this area to set rights and privileges for users and groups from the local machine as well as domain users and groups from any of the trusted domains (including the domain the machine is a member of).
When you submit the template for processing, the Security Configuration engine grants the rights and privileges as specified. Any additional users and groups who formerly had privileges on the system are removed, and these users are logged in to the configuration log
Figure 6 shows the Rights and Privileges Management area of the snap-in tool:
Figure 6. Configuring User Rights and Privileges
There are three object trees in which the Security Configuration Editor allows you to manage the object by placing a security descriptor on the object. Directory security is one of these areas. The configuration template allows you to specify a list of fully qualified directory object LDAP names and the security descriptor you would like applied to each of them. In this case, the configuration template contains the fully qualified distinguished name and security descriptor in a text format called the Security Descriptor Definition Language (SDDL). The configuration engine runs through the list and applies the names and security descriptor to the corresponding objects.
In theory, you could specify each node in the tree and the security on that node, causing the template to be huge and unmanageable. This is not the best approach, however, as there is full support for inheritance (for example, if you specify security at the top-most node, down-level nodes will have the same security). Microsoft recommends that you use the inheritance capabilities to specify security only at top-level nodes, and then redefine security only for those downlevel nodes that require it. This approach will greatly simplify your security structure and will reduce the administrative overhead that would result from an overly complex access control structure.
Note: The Directory Security area supports security descriptor configuration for Directory Services objects only; tools such as DS Admin provide general directory administration. DS Admin also allows you to manage security on a per-object basis. Microsoft recommends that you use Security Configuration Editor to configure security for a large number of objects or to analyze security when diagnosing problems.
The registry is another object tree in which the Security Configuration Editor allows you to manage the object by placing a security descriptor on the object. In the case of the registry, however, the objects are registry keys. Again, the configuration template contains the fully qualified registry key path and security descriptor in SDDL format.
Because Windows NT 5.0 is going to support a dynamic inheritance model for all object providers, when applying security on registry keys, the Security Configuration Editor will follow the same inheritance algorithm, as did the directory tree. The snap-in’s template layout for registry security configuration is shown in Figure 7.
Figure 7. Configuring Registry Security Settings
Local file system security is the third object tree supported within the Security Configuration Editor. The editor treats all volumes on a given system as part of a single tree, with first-level nodes as the root directory of each volume. This is similar to the Directory and Registry security configuration, because the configuration template contains a list of fully qualified file or directory paths and security descriptors for each. The dynamic inheritance model is supported on NTFS files also. The snap-in’s template layout for file system security is illustrated in Figure 8:
Figure 8. Configuring File System Security Settings
System Services include critical functionality such as network services, file and print services, telephony and fax services, and Internet/intranet services. Because of the breadth and diversity of this area, Security Configuration Editor’s System Services area is architected to be extendable. Security Configuration Editor directly supports general settings for each system service. These general settings include the service startup settings and security on the service. Note that the name of the service must be the same as the one used by Service Control Manager. (See Figure 9.)
Figure 9. Configuring System Services Security
To extend this area of the Security Configuration Editor so it can be used to configure specific settings for a new service, you need to create and attach a Security Configuration Editor Attachment (a DLL). A Security Configuration Editor Attachment consists of the following:
Figure 10. Security Configuration Editor and Service Attachment Architecture
Microsoft will provide attachments for some services that are shipped with the system. In its initial release, Microsoft plans to ship security configuration attachments for the CIFS File Sharing Service.
In addition, the interface used to extend the editor is described in Appendix A, “Implementing Service Security Attachments.”
This section describes how to use the Security Configuration Editor to analyze various security aspects of a Windows NT 5.0 system. Security analysis is the other half of Security Configuration Editor’s capabilities. Security Configuration Editor provides a graphical interface that allows you to view the analysis information collected from the system. Additionally, you can use the graphical user interface or the command-line utility, secedit, to collect analysis data from the system. This enables you to collect the data interactively or to schedule data collection as part of an off-hour batch processing script.
To promote ease of use (and to eliminate the steep learning curve normally associated with new administration tools), the GUI design of the analysis display has been kept simple and informational. Instead of complicated graphics or error alerts, it provides simple visual cues (font and color) to identify security problems—and the information required to fix those problems. The interface uses a simple table that lists the attributes, their corresponding values, and the recommended values. Potential problems are identified by changes in color and font. Figure 11 shows the analysis user interface.
Figure 11. Security Analysis User Interface
The Security Configuration Editor uses a base configuration template when performing its security analysis. The base template, which lists the preferred or recommended settings, is necessary to do comparisons and to provide recommended configuration information so that potential problems can be avoided. Security Configuration Editor’s analysis engine queries settings for various security attributes in each of the security areas and compares the values to the recommendations in the base template. If the settings match the template, they are assumed to be correct. If not, they are identified as potential problems that need investigation. These potential problems are noted and displayed in the snap-in’s Analysis Viewer interface.
By default, the base template is the one used during system configuration. However, you can explicitly specify another template during analysis. The analysis information is collected by the analysis engine and stored in an ISAM database. The use of standard Microsoft database technology is intentional. It allows us to build integrated reporting mechanisms and high-end capabilities such as querying, transactions, and so forth. In the future, ODBC support will also be provided.
The Security Configuration Editor supports two modes of security analysis for Windows NT systems: configured system analysis and unconfigured system analysis.
In addition to analyzing the system’s current configuration, the Security Configuration analysis interface allows you to make interactive changes of two kinds: you can change the system configuration, or you can change the configuration template.
The Analysis Viewer provided with the Security Configuration Editor displays the system security configuration information organized into security areas, as defined previously in this document. The next sections describe the analysis capabilities associated with each area.
When analyzing system security, the Security Configuration Editor queries all of the defined security attributes that fall into this area and saves them in the current analysis section of the analysis database. You can then use the Analysis Viewer to see the information.
The Analysis Viewer provides a tabular view of the information. For each attribute, it displays the current and recommended settings (recommended settings are obtained from the stored copy of the configuration template). Attributes that are not using the recommended settings are clearly identified (by color, font, and icons) so that you can easily recognize and correct the problems. To correct a problem, you can either accept the current setting, in which case the stored template is modified, or you can change the system setting to match the recommendation, in which case the corresponding attribute is reset when the system is reconfigured.
Figure 12 shows the Analysis Viewer displaying the Security Policy information.
Figure 12. Analyzing Security Policy Settings
Analysis of restricted groups involves tracking group memberships, including recursive membership. Problems are identified by color, font, and icon. To correct a problem, you can either accept the current settings, in which case the stored template is modified, or you can change the system setting to match the recommendation, in which case the problematic group memberships are changed when the system is reconfigured.
Figure 13 shows the Analysis Viewer displaying the Restricted Group Management information.
Figure 13. Analyzing Restricted Group Membership
Analysis of rights and privileges involves tracking security principals who are directly or indirectly granted each right or privilege (by group memberships). Problems are identified by color, font, and icon. To correct a problem, you can either accept the current settings, in which case the stored template is modified, or you can change the system setting to match the recommendation, in which case the rights and privileges are changed when the system is reconfigured.
Figure 14 shows the Analysis Viewer displaying the Rights and Privileges Management information.
Figure 14. Analyzing Rights and Privileges
Directory Security analysis falls into the general category of analyzing security descriptors on object trees. The Security Configuration Editor analysis engine uses the list of directory object names present in the stored base configuration template to build a partial image of the tree. (The image is partial because some paths may not be included in the template.) The engine analyzes all tree branches that are reflected in the template and provides information about the similarity of security descriptors to the ones defined. It also detects the highest subtree node, which is not specified in the template, and provides information about that node. The analysis engine uses the notions of match, mismatch, and unknown to categorize the security descriptor information on the actual tree as compared to that in the template.
You can accept or change unknown security descriptors, which are then included in the template. You can also accept or change mismatched descriptors. Changes are also allowed to descriptors that match. These are considered updates and are recorded in the stored configuration template in the database. If you select any of these settings and choose the Change action, the ACL Editor is invoked. The editor displays the current security settings and allows you to modify them directly. The changes made are stored in the copy of the template in the database and applied to corresponding objects when the system is reconfigured.
Registry Security analysis falls into the same general category of analyzing security descriptors on object trees as did Directory Security analysis. The Security Configuration Editor analysis engine uses the paths to the registry keys and their security descriptors (the paths and descriptors are stored in SDDL in the base configuration template) as the basis for its analysis. The engine analyzes the registry information and provides information about the similarity of security descriptors to the ones defined. The analysis engine again uses the notions of match, mismatch, and unknown to categorize the security descriptor information on the actual tree as compared to that in the template.
Figure 15 shows the Analysis Viewer displaying the Registry Security information.
Figure 15. Analyzing Registry Security Settings
Local file system security is the third object tree supported within the Security Configuration Editor. The Security Configuration Editor analysis engine uses the list of fully qualified file or directory paths and their security descriptors stored in the base configuration template as the basis for its analysis. The engine analyzes the information and determines the similarity of the actual security descriptors to the ones defined. The analysis engine again uses the notions of match, mismatch, and unknown to categorize the security descriptor information on the actual tree as compared to that in the template.
Figure 16 shows the Analysis Viewer displaying the Registry Security information.
Figure 16. Analyzing File System Security Settings
Security Configuration Editor collects general security information on all services configured to run on the system. General information includes startup settings and security descriptors. The editor detects problems, such as mismatches or services not specified in the template, and reports them.
Analysis of service-specific security settings for each service is also provided by the service security attachment architecture for Security Configuration Editor as discussed in the configuration section above. In this case, the Security Configuration Editor calls the defined interfaces to allow the attachment to collect the necessary data and store it in a specific place in the analysis database. The Analysis Viewer then calls the extension snap-in’s analysis interface to display the information, as well as to accept user actions to correct problems. (See Figure 17.)
Figure 17. Analyzing System Services Settings
As stated previously, Microsoft plans to ship a security configuration attachment for CIFS File Sharing Service in the initial release of the Security Configuration Editor. The interface used to extend the editor is documented in Appendix A, “Implementing Service Security Attachments.” This interface will allow ISVs to build security attachments for other services.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).
This appendix describes the procedures for building and implementing Service Security Attachments for the Security Configuration Editor.
Security Configuration Editor handles general security settings for individual services directly. These general settings include the service invocation policy (disabled, automatic, or manual) as well as the security descriptors for each service. Therefore, no Security Configuration Editor Attachment should attempt to configure these settings. The Service Security Attachment architecture within the Security Configuration Editor provides an infrastructure to configure and analyze specific security settings for individual services. For example, Spooler is a Windows NT service that defines private objects (in this case, printers) that need to be secured. In addition, it has configuration parameters that are security-sensitive. For Spooler, a Service Security Attachment must allow configuration and analysis of security settings on printer objects and security-sensitive parameters for the service.
Service Security Attachment architecture requires implementation of the following two pieces:
Security Configuration Editor provides a set of support APIs that the attachment engine or extension snap-in can use to query or set service-specific information contained in the Security Configuration Editor database.
Figure 1A shows the three pieces of the snap-in architecture where the attachment infrastructure fits in (the extension snap-ins for attachments, the service attachment engines, and the inspection database).
Figure 1A. Security Configuration Editor Snap-in, Engine, and Extension Architecture
Security Configuration Editor, which consists of the main engine and the MMC snap-in, provides the overall framework for configuring and analyzing system security for Windows NT installations.
In the attachment framework, attachment engine DLLs register with Security Configuration Editor. Security Configuration Editor then loads the attachment during execution. It calls the attachment’s configuration interface when the system is configured, the analysis interface when the system is analyzed, and the update interface when parameters in the database are modified by the extension snap-in.
Similarly, the extension snap-in for the service attachment must register as a Security Configuration Editor snap-in extension. The Security Configuration Editor snap-in loads the extension snap-in as a node under the Services security area in each template node, as well as in the configuration/inspection node. If you are writing an extension snap-in, you must follow the MMC extension writer’s documentation to implement the overall extension snap-in. In addition, you must implement the component object model (COM) interface described below, to communicate with the Security Configuration Editor snap-in.
Building the service attachment involves implementing three interfaces and installing/registering the attachment with Security Configuration Editor. Security Configuration Editor will load the attachment and call these interfaces based on user-invoked operations.
Before describing which interfaces need to be implemented and how to implement them, it is important to define various data structures and support APIs provided by Security Configuration Editor.
Note that the data structures described here are defined in scesvc.h, included in the Microsoft Win32® SDK.
typedef DWORD SCESTATUS;
#define SCESTATUS_SUCCESS 0L
#define SCESTATUS_INVALID_PARAMETER 1L
#define SCESTATUS_RECORD_NOT_FOUND 2L
#define SCESTATUS_INVALID_DATA 3L
#define SCESTATUS_OBJECT_EXIST 4L
#define SCESTATUS_BUFFER_TOO_SMALL 5L
#define SCESTATUS_PROFILE_NOT_FOUND 6L
#define SCESTATUS_BAD_FORMAT 7L
#define SCESTATUS_NOT_ENOUGH_RESOURCE 8L
#define SCESTATUS_ACCESS_DENIED 9L
#define SCESTATUS_CANT_DELETE 10L
#define SCESTATUS_PREFIX_OVERFLOW 11L
#define SCESTATUS_OTHER_ERROR 12L
#define SCESTATUS_ALREADY_RUNNING 13L
#define SCESTATUS_SERVICE_NOT_SUPPORT 14L
typedef PVOID SCE_HANDLE;
typedef ULONG SCE_ENUMERATION_CONTEXT, *PSCE_ENUMERATION_CONTEXT;
typedef enum _SCESVC_INFO_TYPE {
SceSvcConfigurationInfo,
SceSvcAnalysisInfo,
SceSvcInternalUse// DO NOT USE.
} SCESVC_INFO_TYPE;
typedef struct _SCESVC_CONFIGURATION_LINE_ {
LPTSTR Key;
LPTSTR Value;
DWORD ValueLen; // number of bytes
} SCESVC_CONFIGURATION_LINE, *PSCESVC_CONFIGURATION_LINE;
typedef struct _SCESVC_CONFIGURATION_INFO_ {
DWORD Count;
PSCESVC_CONFIGURATION_LINE Lines;
} SCESVC_CONFIGURATION_INFO, *PSCESVC_CONFIGURATION_INFO;
typedef enum _SCESVC_INFO_TYPE {
SceSvcConfigurationInfo,
SceSvcAnalysisInfo,
SceSvcInternalUse// DO NOT USE
} SCESVC_INFO_TYPE;
typedef struct _SCESVC_ANALYSIS_LINE_ {
LPTSTR Key;
PBYTE Value;
DWORD ValueLen; // number of bytes
} SCESVC_ANALYSIS_LINE, *PSCESVC_ANALYSIS_LINE;
typedef struct _SCESVC_ANALYSIS_INFO_ {
DWORD Count;
PSCESVC_ANALYSIS_LINE Lines;
} SCESVC_ANALYSIS_INFO, *PSCESVC_ANALYSIS_INFO;
Security Configuration Editor provides a set of support application programming interfaces (APIs) that the attachment should use to read or write information to the template and the database.
These APIs are:
These APIs are defined in scesvc.h in the Win32 SDK. The static library to link to is scedll.lib, available for x86 and Alpha platforms. These APIs are described in greater detail next.
SceSvcQueryInfo
SCESTATUS
WINAPI
SceSvcQueryInfo(
IN SCE_HANDLE sceHandle,
IN SCESVC_INFO_TYPE sceType,
IN LPTSTR lpPrefix OPTIONAL,
IN BOOL bExact,
OUT PVOID *ppvInfo,
OUT PSCE_ENUMERATION_CONTEXT psceEnumHandle
);
The SceSvcQueryInfo support API allows the attachment to query configuration or analysis information from the database.
The parameters are:
SCE_SERVICE_CONFIGURATION_INFO if configuration information is being queried, or be SCE_SERVICE_ANALYSIS_INFO if analysis information is being queried.SCESVC_CONFIGURATION_INFO if the sceType is SceSvcConfigurationInfo. Otherwise, it must be SCESVC_ANALYSIS_INFO if the sceType is SceSvcAnalysisInfo. Security Configuration Editor—and not the attachment—will allocate the buffer; therefore the pointer must point to NULL.This API returns the following codes:
SCESTATUS_SUCCESSSceSvcSetInfo
SCESTATUS
WINAPI
SceSvcSetInfo(
IN SCE_HANDLE sceHandle,
IN SCESVC_INFO_TYPE sceType,
IN LPTSTR lpPrefix OPTIONAL,
IN BOOL bExact,
IN PVOID pvInfo
);
The SceSvcSetInfo support API allows the attachment to set/overwrite configuration/analysis information stored in the database about a particular service.
The parameters are:
SCE_SERVICE_CONFIGURATION_INFO if configuration information is being set, or SCE_SERVICE_ANALYSIS_INFO if analysis information is being set.SCESVC_CONFIGURATION_INFO if the sceType is SceSvcConfigurationInfo. Otherwise, it must be SCESVC_ANALYSIS_INFO if the sceType is SceSvcAnalysisInfo. This API returns the following codes:
SCESTATUS_SUCCESSSceSvcFree
SCESTATUS
WINAPI
SceSvcFree(
IN PVOID pvServiceInfo
);
The attachment must call this API to free buffers allocated by Security Configuration Editor in calls to SceSvcQueryInfo.
The pointer ServiceInfo points to the allocated buffer.
This API returns the following codes:
SCESTATUS_SUCCESSSceSvcConvertSDToText
SCESTATUS
WINAPI
SceSvcConvertSDToText (
IN PSECURITY_DESCRIPTOR pSD,
IN SECURITY_INFORMATION siSecurityInfo,
OUT PWSTR *ppwszTextSD,
OUT PULONG pulTextSize
);
SceSceConvertSDToText is a helper API that allows the attachment to convert a self-relative security descriptor into a textual form that can be stored in the configuration template and the database. This API is useful when attachment is configuring security on a service that supports private objects that have security descriptors on them.
The parameters are:
The string to return the textual form is allocated by this helper API. It must be freed using LocalFree.
This API returns the following codes:
SCESTATUS_SUCCESSSceSvcConvertTextToSD
SCESTATUS
WINAPI
SceSvcConvertTextToSD (
IN PWSTR pwszTextSD,
OUT PSECURITY_DESCRIPTOR *ppSD,
OUT PULONG pulSDSize,
OUT PSECURITY_INFORMATION psiSeInfo
);
SceSvcConvertTextToSD is a helper API that allows the attachment to convert a textual form of a security descriptor (created earlier using SceSvcConvertSDToText) back to its self-relative binary form.
The parameters are:
The buffer to return security descriptor is allocated by this helper API. It must be freed using LocalFree.
This API returns the following codes:
SCESTATUS_SUCCESSThe three interfaces that the attachment must implement are:
SceSvcAttachmentConfig
SCESTATUS
WINAPI
SceSvcAttachmentConfig(
IN SCE_HANDLE sceHandle,
OUT PWSTR *ppszErrMessage OPTIONAL,
OUT PDWORD pdErrLength
);
The parameters are:
This interface must do the following:
This interface returns the following codes:
SCESTATUS_SUCCESS if the call completes successfully.SCESTATUS
WINAPI
SceSvcAttachmentConfig(
IN SCE_HANDLE sceHandle,
OUT PWSTR *ppszErrMessage,
OUT PDWORD *pdErrLength
)
{
//
//variable definitions
//
PSCESVC_CONFIGURATION_INFOpConfigInfo = NULL;
SCESTATUSretCode;
SCE_ENUMERATION_CONTEXTEnumContext = 0;
if ( sceHandle == NULL ) {
return(SCESTATUS_INVALID_PARAMETER);
}
//
// now read the information and configure system using it.
//
// NOTE: you may decide to read all the information first
// and then do the configure, it is implementor’s choice.
//
do {
retCode = SceSvcQueryInfo(
sceHandle,
SceSvcConfigurationInfo,
NULL,
FALSE,
(PVOID *)&pConfigInfo,
&EnumContext
);
if(retCode == SCESTATUS_SUCCESS &&
pConfigInfo != NULL)
{
ULONGi;
//
// We have some information, let’s configure.
//
for(i = 0;i < pConfigInfo->Count; i++)
{
if(pConfigInfo->Line[i].Key == NULL)
continue;
//
// We have a key that we should process.
// This will the core of doing configuration.
//
ProcessConfigurationLine(pConfigInfo->Line[i]);
}
//
// free the data we got back.
//
SceSvcFree((PVOID)pConfigInfo);
PConfigInfo = NULL;
}
//
// handle other return codes, as needed.
//
} while ( retCode == SCESTATUS_SUCCESS && CountReturned > 0);
//
// if return code is not success, we should set up
// error message appropriately.
//
//
// return the retCode.
//
return retCode;
}
SceSvcAttachmentAnalyze
SCESTATUS
WINAPI
SceSvcAttachmentAnalyze(
IN SCE_HANDLE sceHandle,
OUT PWSTR *ppszErrMessage,
OUT PDWORD pdErrLength
);
The parameters are:
This interface must do the following:
This interface returns the following codes:
SCESTATUS_SUCCESS if the call completes successfully.SCESTATUS error codes are accepted.SCESTATUS
WINAPI
SceSvcAttachmentAnalyze(
IN SCE_HANDLE sceHandle,
OUT PWSTR *ppszErrMessage,
OUT PDWORD pdErrLength
);
{
//
// define various local variables.
//
if(sceHandle == NULL)
return (SCESTATUS_INVALID_PARAMETER);
//
// now read the base config information, query system
// setting corresponding to it, compare them
// and write to the database.
//
//
do {
retCode = SceSvcQueryInfo(
sceHandle,
SceSvcConfigurationInfo,
NULL,
FALSE,
&pConfigInfo,
&EnumContext
);
if(retCode == SCESTATUS_SUCCESS &&
pConfigInfo != NULL)
{
ULONGi;
//
// We have some information, let’s configure.
//
for(i = 0;i < pConfigInfo->Count; i++)
{
if(pConfigInfo->Line[i].Key == NULL)
continue;
//
// We have a key that we should query.
// This function is expected to query
// the system configuration corresponding
// to the key value.
//
QueryConfigurationLine(pConfigInfo->Line[i].Key,
&SystemValue);
//
// now compare the values.
//
CompareValue(pConfigInfo->Line[i].Key,
SystemValue,
pConfigInfo->Line[i].Value,
&Result
);
//
// Check if there is something that should
// be written to analysis part of the // database.
if(Result != NULL)
{
//
// we will overwrite exactly one// value.
// more efficient way to do this
// would be to accumulate a
// set of values and commit.
//
retCode = SceSvcSetInfo(
sceHandle,
SceSvcAnalysisInfo,
PconfigInfo->Line[I].Key,
TRUE,
Result
);
if(retCode != SCESTATUS_SUCCESS)
{
// if it doesn’t get set, we
// need to do some cleanup
// here.
}
}
}
//
// free the data we got back.
//
SceSvcFree((PVOID)pConfigInfo);
PConfigInfo = NULL;
//
// should also free possible buffers SystemValue and
// Result, up to each attachment
//
}
//
// handle other return codes, as needed.
//
} while ( retCode == SCESTATUS_SUCCESS && pConfigInfo != NULL);
//
// if return code is not success, we should set up
// error message appropriately, if error buffer is not NULL
//
//
// return the retCode.
//
return retCode;
}
SceSvcAttachmentUpdate
SCESTATUS
WINAPI
SceSvcAttachmentUpdate(
IN SCE_HANDLE sceHandle,
IN SCESVC_CONFIGURATION_INFO *ServiceInfo
);
Security Configuration Editor calls this interface when the Security Configuration Editor snap-in passes service-specific changes to the configuration settings stored in the database.
The parameters are:
This attachment interface must do the following:
This interface returns the following codes:
SCESTATUS_SUCCESS if the call completes successfully.SCESTATUS error codes are accepted.SCESTATUS
WINAPI
SceSvcAttachmentUpdate(
IN SCE_HANDLE sceHandle,
IN SCESVC_CONFIGURATION_INFO *ServiceInfo
);
{
if(sceHandle == NULL || ServiceInfo == NULL)
return(SCESTATUS_INVALID_PARAMETER);
//
// process each line of the passed information.
//
for(i=0; i < ServiceInfo->Count; i++)
{
EnumContext = 0;
retCode = SceSvcQueryInfo(
sceHandle,
SceSvcConfigurationInfo,
ServiceInfo->Line[i].Key,
TRUE,
(PVOID *)&pConfigInfo,
&EnumContext
);
if(retCode != SCESTATUS_SUCCESS &&
retCode != SCESTATUS_RECORD_NOT_FOUND)
{
//
// handle the error here.
//
break;
}
//
// if the value specified is NULL, deletion
// of the key is requested.
//
if(ServiceInfo->Line[i].Value == NULL)
{
if(retCode == SCESTATUS_SUCCESS)
{
//
// Lets ensure that analysis is ok.
//
EnumContext = 0;
retCode = SceSvcQueryInfo(
sceHandle,
SceSvcAnalysisInfo,
ServiceInfo->Line[i].Key,
TRUE,
(PVOID *)&pAnalInfo,
&EnumContext
);
if(retCode == SCESTATUS_RECORD_NOT_FOUND)
{
//
// Analysis Info was not found,
// this means it was matched during
// actual analysis. Now, we are
// deleting the configuration info,
// hence current configuration is
// what analysis should save.
//
UpdateInfo->Count = 1
UpdateInfo->Line = &UpdateLine;
UpdateLine.Key = pConfigInfo->Line[0].Key;
UpdateLine.Value =
(PBYTE)pConfigInfo->Line[0].Value;
RetCode = SceSvcSetInfo(
SceHandle,
SceSvcAnalysisInfo,
NULL,
TRUE,
&UpdateInfo
);
if(retCode != SCESTATUS_SUCCESS)
{
//
// cleanup, something
// failed.
//
}
}
elseif (retCode == SCESTATUS_SUCCESS)
{
//
// simply delete the configuration.
// we already have analysis info in
// place.
}
else
{
//
// handle other error codes.
//
}
//
// delete the key
//
RetCode = SceSvcSetInfo(
SceHandle,
SceSvcConfigurationInfo,
ServiceInfo->Line[i].Key,
TRUE,
NULL
);
if(retCode != SCESTATUS_SUCCESS)
{
//
// error cleanup.
//
}
}
//
// SCESTATUS_RECORD_NOT_FOUND means nothing more.
// as the key does not even exist.
//
}
else
{
//
// Value to set is non-NULL,
// hence we must compare with current analysis
// if it is same, then delete the current analysis
// if it is different, do nothing to the analysis.
// Simply update the configuration info.
//
// left as exercise to the implementor.
//
}
SceSvcFree(pConfigInfo);
pConfigInfo = NULL;
SceSvcFree(pAnalInfo);
PAnalInfo = NULL;
}
//
// error cleanup
// set detail error message appropriately if the buffer
// is not NULL
//
return retCode;
}
The service DLL must be installed on the Windows NT system where it is expected to be used. In addition, Security Configuration Editor needs to be made aware of the presence of the attachment. This process of installation and registration should include the following steps:
Copy the service attachment DLL to a particular directory. The preferred directory is %windir%\secedit\attachments. You can create this directory if it does not already exist.
Create a registry key under
HKEY_LOCAL_MACHINE\
Software\
Microsoft\
Windows NT\
CurrentVersion\
SecEdit\Services\
[Service Name]
The Service Name used here will be the registered name for the attachment. It should be unique so as to not collide with other attachments. The service name must be the same name used in Service Control Manager. The name used in Service Control Manager is the name to link each service with Security Configuration Editor.
Create the following values in this key:
The Security Configuration Editor snap-in is designed to be extensible to support the service attachment extension snap-ins. The communication between the Security Configuration Editor snap-in and the extension snap-ins is handled by the standard MMC mechanisms and two well-defined Component Object Model (COM) interfaces, as described in this section. While the service attachment engine is responsible for configuring and analyzing service security and updating the service template in the database, the service attachment extension allows user to view, create, and modify templates and analysis information. To function correctly, it is imperative that the service snap-in follow the MMC extension snap-in guidelines and the attachment guidelines provided in this document.
Each service attachment snap-in must be an extension snap-in, and these extension snap-ins provide functionality only when invoked by the Security Configuration Editor snap-in. Each service attachment snap-in can extend a Services node type only. It declares itself as being a subordinate to nodes of Services, and then for each occurrence of the Services node type, the MMC console automatically adds the related snap-in extensions. Each service attachment owns one scope pane node and the related result pane in MMC. Service attachment extensions must allow the user to create or modify service security settings in a template managed by the Security Configuration Editor snap-in. It must also be able to display configuration and/or analysis security settings with analysis status. It must support editing of service configuration settings for a system, and the analysis results must be updated based on the updated configuration settings.
It is up to the service attachment extension to determine the format and implementation logic of its own result pane. COM interfaces provide a way to extend Security Configuration Editor’s functionality for services without dictating how each service extension performs its particular tasks. See the COM interface layout shown in Figure A2.
Figure A2. COM Interface Layout for Service Attachment
In this illustration, the Security Configuration Editor Snap-in implements a COM interface called ISceSvcAttachmentData. The interface provides the attachment snap-in to query configuration and analysis information from templates or the database respectively. The attachment snap-in implements the COM interface ISceSvcAttachmentPersistInfo, which is used by the Security Configuration Editor snap-in to get any modified information that may need to be written to the template or the database. The snap-in will then save this information appropriately.
There are three operations that the attachment snap-in must support:
When creating or editing a template, if the services node is expanded, all registered extension snap-ins will be notified by the MMC directly. Each attachment should then insert itself under the Services node, and then complete the following steps:
#define CCF_SCESVC_ATTACHMENT ( L”CCF_SCESVC_ATTACHMENT” )
This clipboard is used for each attachment snap-in to extract the template name from Security Configuration Editor. The template name is a PWSTR. This template name is used in further communications between the service attachment and Security Configuration Editor in the Initialize method.
The extension snap-in queries the following Security Configuration Editor snap-in interfaces.
ISceSvcAttachmentData
class ISceSvcAttachmentData : public IUnknown
{
public:
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE GetData(
/* [in] */ SCE_HANDLE sceHandle,
/* [in] */ SCESVC_INFO_TYPE sceType,
/* [out] */ PVOID *ppvData,
/* [in out] */ PSCE_ENUMERATION_CONTEXT psceEnumHandle ) = 0;
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE Initialize(
/* [in] */ LPCTSTR ServiceName,
/* [in] */ LPCTSTR TemplateName,
/* [in] */ LPUNKNOWN lpUnknown,
/* [out] */ SCE_HANDLE *sceHandle) = 0;
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE FreeBuffer(
/* [in] */ PVOID pvData) = 0;
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE CloseHandle(
/* [in] */ SCE_HANDLE sceHandle) = 0;
};
ISceSvcAttachmentData is the COM interface implemented by the Security Configuration Editor snap-in to support extension snap-ins. The attachment extension snap-in should use it to retrieve service-specific information for display user modification.
ISceSvcAttachmentPersistInfo
class ISceSvcAttachmentPersistInfo : public IUnknown
{
public:
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE Save(
/* [out] */ SCE_HANDLE *sceHandle,
/* [out] */ PVOID *ppvData,
/* [out] */ PBOOL pbOverwriteAll ) = 0;
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE IsDirty() = 0;
virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE FreeBuffer(
/* [in] */ PVOID pvData) = 0;
};
The IsceSvcAttachmentPersistInfo interface is an abstract class that must be implemented by each attachment extension snap-in. The Security Configuration Editor snap-in calls this interface to check if there is modified information that must be written back to the template or the database (using IsDirty). If that is the case, it calls the Save method to make the extension snap-in communicate the information that must be saved.
The Security Configuration Editor snap-in provides extensions only through the Security Configuration Editor namespace. Context menus, toolbars, toolbar buttons, and property pages are not extensible at this point. The attachment snap-in must extend the Security Configuration Editor namespace by populating its own node at well-defined places in the namespace.
Attachment snap-ins should be registered under the registry key:
HKEY_LOCAL_MACHINE\
Software\
Microsoft\
MMC\
Snapins
The StandAlone key should NOT be created under the snap-in because each attachment snap-in must be an extension only.
Attachment snap-ins must also register themselves under the Security Configuration Editor Services NodeType subkeys as follows:
HKLM\
Software\
Microsoft\
MMC\
NodeTypes\
24a7f717-1f0c-11d1-affb-00c04fb984f9\
Extensions\
NameSpace
HKLM\
Software\
Microsoft\
MMC\
NodeTypes\
678050c7-1ff8-11d1-affb-00c04fb984f9\
Extensions\
NameSpace
For more information, refer to the public header scesvc.h in the Platforms SDK.
To register the attachment snap-ins as extensions to the Security Configuration Editor snap-in, create these keys in your DllRegisterServer and DllUnregisterServer function implementations.
When a Services node under either a template or under Last Configuration/Inspection is expanded, MMC uses IComponentData::Notify and the MMCN_EXPAND event to notify Security Configuration Editor and all of its extensions. Security Configuration Editor then extracts its internal format from the lpDataObject and stop further processing when it sees the Services node type. The attachment snap-ins (registered as extensions) also extract the node type from the lpDataObject. If the node type is one of the Services node types defined earlier, the attachment snap-ins insert their root nodes under the specified parent node.
//
// detect which extension node to extend
//
GUID* nodeType = ExtractNodeType(lpDataObject);
if ( nodeType == NULL ) {
return S_OK;
}
if ( ::IsEqualGUID(*nodeType, cNodetypeSceTemplateServices) == TRUE )
folderType =ATTACHEMNT_STATIC;// defined by attachment writer.
else if (::IsEqualGUID(*nodeType, cNodetypeSceAnalysisServices)
== TRUE)
folderType =ATTACHMENT_STATIC_ANALYSIS;
// defined by attachment writer
// Free resources
::GlobalFree(reinterpret_cast<HANDLE>(nodeType));
//
// As an extension snapin, the service attachment
// root node should be added
// Insert that node, and remember it
// as the root of the SMB Extension namespace.
//
CheckAndInsertRootNodeToMMCScopePane
The next major step in the initialization is to establish communication with the Security Configuration Editor snap-in. This is necessary because the attachment gets its data, as well any changes made by the user, from the Security Configuration Editor. To do this, follow these steps:
Obtain the template name. If the Services node type that the attachment is inserted under was that of a template, then the attachment needs to know which template it is. It communicates this information to the Security Configuration Editor during interface initialization. The template name can be obtained via the clipboard format, as follows:
PWSTR * TemplateName = ExtractTemplateNameFromDataObject(lpDataObject);
Set up the context with the Security Configuration Editor. Once the template name is known (or if the Service node is of type Inspection), the attachment snap-in must query the ISceSvcAttachmentData interface and call Initialize to set up the context.
//
// QueryInterface for the main snap-in’s IUnkown.
//
LPUNKNOWN pUnk;
hr = lpDataObject->QueryInterface(IID_IUnknown,
reinterpret_cast<void**>(&pUnk));
//
// QueryInterface ISceSvcAttachmentData
//
if ( SUCCEEDED(hr) ) {
hr = pUnk->QueryInterface(IID_ISceSvcAttachmentData,
reinterpret_cast<void**>(&pSceData));
}
…
//
// QueryInterface the attachment’s IUnknown as
// that is needed by the main snap-in.
//
((LPUNKNOWN)m_pSnapin)->QueryInterface(IID_IUnknown, reinterpret_cast<void**>(&pUnk));
//
// Call Initialize to setup context with main snap-in.
//
m_pSceData->Initialize(ServiceName, TemplateName, pUnk, &sceHandle);
…
NOTE: You must call CloseHandle to close the sceHandle once you are done.
Get the appropriate data. (The previous step really completes the initialization.) The attachment snap-in can use the established context to query appropriate data from Security Configuration Editor as needed by using the GetData interface. The attachment may decide to do this proactively as soon as it initializes with Security Configuration Editor, or it may wait until the user actually attempts to expand the attachment node by clicking it. The attachment can display the information received using any UI controls available.
//
// GetData – we get the configuration information here.
//
m_pSceData->GetData (sceHandle, SceSvcConfigurationInfo, &pData,
&enumHandle );
NOTE: You must use the FreeBuffer method to free the buffer allocated here by Security Configuration Editor.
After initialization, it is important that the attachment implement the ISceSvcAttachmentPersistInfo interface. The Security Configuration Editor queries this interface at various times—for example, when saving the template and when closing the snap-in—to allow the attachment to save any modifications that the user may have made to the inspection database or to the associated template.
class CSceSvcAttachmentPersistInfo:
public ISceSvcAttachmentPersistInfo,
public CComObjectRoot
{
BEGIN_COM_MAP(CSceSvcAttachmentPersistInfo)
COM_INTERFACE_ENTRY(ISceSvcAttachmentPersistInfo)
END_COM_MAP()
friend class CSceSmb;
friend class CDataObject;
friend class CComponentDataImpl;
CSceSvcAttachmentPersistInfo();
~CSceSvcAttachmentPersistInfo();
public:
// ISceSvcAttachmentPersistInfo interface members
STDMETHOD(IsDirty)();
STDMETHOD(Save)(SCE_HANDLE *sceHandle, PVOID *ppvData,
PBOOL pbOverwriteAll );
STDMETHOD(FreeBuffer)(PVOID pvData);
...
private:
CString m_TemplateName;
LPSCESVCATTACHMENTDATA m_pSceData;
SCE_HANDLE m_sceHandle;
...
};
//
// Implementing IsDirty()
//
STDMETHODIMP CSceSvcAttachmentPersistInfo::IsDirty()
{
if ( m_pSnapin == NULL ) {
return S_FALSE;
}
//
// just calling the snapin’s main IsDirty.
//
return m_pSnapin->IsDirty();
}
//
// Implementing Save()
//
STDMETHODIMP CSceSvcAttachmentPersistInfo::Save(
SCE_HANDLE *psceHandle,
PVOID *ppvData,
PBOOL pbOverwriteAll )
{
if ( psceHandle == NULL || ppvData == NULL ||
pbOverwriteAll == NULL ) {
return E_INVALIDARG;
}
if ( m_pSnapin != NULL ) {
m_pSnapin->SaveDataInBuffer(ppvData, pbOverwriteAll);
*psceHandle = m_sceHandle;
}
return S_OK;
}
//
// Implementing FreeBuffer
//
STDMETHODIMP CSceSvcAttachmentPersistInfo::FreeBuffer(PVOID pvData)
{
if ( pvData == NULL ) {
return S_OK;
}
PSCESVC_ANALYSIS_INFO pTempInfo=(PSCESVC_ANALYSIS_INFO)pvData;
if ( pTempInfo->Lines != NULL ) {
for ( DWORD i=0; i < pTempInfo->Count; i++ ) {
if ( pTempInfo->Lines[i].Key != NULL )
LocalFree(pTempInfo->Lines[i].Key);
if ( pTempInfo->Lines[i].Value != NULL )
LocalFree(pTempInfo->Lines[i].Value);
}
LocalFree( pTempInfo->Lines);
}
LocalFree(pTempInfo);
return S_OK;
}