Security Essentials. Working with Systems Management Server (SMS) 2.0 to maximize SMS security and avoid security-related problems.

Transcription

1 Security Essentials Working with Systems Management Server (SMS) 2.0 to maximize SMS security and avoid security-related problems.

2 2000 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 Technical paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. The BackOffice logo, Microsoft, 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 USA

3 Contents Security Essentials 1 Contents 3 Foreword i About this Document i SMS Security Checklist iii More Information iv Part 1: The SMS Security Environment 6 Windows NT Security 6 Windows NT Security Subtleties 7 Windows NT Authentication 9 Pass-Through Authentication 11 Domain Models 13 Other Windows NT Security Features 15 NetWare Security 17 SQL Server Security 17 SQL Server SQL Server WMI Security 18 DCOM Security 19 DCOM's Component-Oriented Security 20 Physical Security 21 Security Policies and Procedures 21 Part 2: The SMS Security Model 23 Elements of SMS Security 23 Security Principles 24 SMS Object Security 26 Object Permissions 28 Accounts and Groups 30 Accounts and Account Roles 31 The Accounts 31 Site Server Accounts 38 Server Connection Accounts 38 Site System Connection Accounts 39 SQL Server Accounts 39

4 Remote Site System Service Accounts 39 Client Service Accounts 40 Client Connection Accounts 40 Client Installation Accounts 40 Reporting Accounts 41 Software Metering Test Account 41 Access Account Lists 41 Groups 42 Connectivity 42 Server Connectivity 42 Client Connectivity 44 Console Connectivity 46 Feature-Level Security 48 SMS Administrator Console Security 48 SMS Reporting Security 48 Remote Tools Security 49 Software Distribution Security 51 Status Subsystem Security 52 Query Security 52 Network Monitor Security 52 SMS Installer Security 53 Software Metering Security 54 Site and Domain Models 54 SMS Domain Issues 55 General SMS Domain Solutions 56 SMS Security Architectures 56 Site Setup 60 Setup Command-Line Options 60 Setup Initialization File Options 61 Site Reset 61 Part 3: Novell NetWare in the SMS Security Model 64 Novell Bindery and Bindery Emulation 64 Novell Directory Services 64 NDS Objects 65 Directory Tree Structure 66 Accessing NDS 67

5 NetWare NDS Rights 68 Directory Rights 68 File Rights 69 Object Rights 70 Property Rights 71 SMS Security Requirements 71 Rights Granted to Client Access Points, Distribution Points, and Logon Points 71 Connection Accounts 73 Part 4: Planning, Implementing, and Using SMS Security 77 Planning and Implementation Considerations 77 Organizational Issues 77 General SMS Security Planning 78 SMS Accounts in the Typical Domain Models 79 SMS Account Considerations 83 Accounts That You Might Have to Create 83 Optional Accounts 84 Managing SMS Account Password Changes 85 SMS Security Best Practices 94 SMS Security Configuration Best Practices 95 SMS Security Usage Best Practices 101 Windows NT Security Best Practices 102 Future Security Best Practices 103 Standard Procedures 103 Procedures for Creating or Modifying SMS Accounts 103 Using SMS Feature-Level Security 119 Testing SMS Security 120 Security Implications of Backup and Recovery 121 Part 5: SMS Security Troubleshooting 122 Common Troubleshooting Procedures 122 General Troubleshooting 122 Security Troubleshooting 124 Troubleshooting SMS Administrator Console Connections 125 Known Issues 126 Orphaned Clients 126 Account Lockouts 128 Client Setup Troubleshooting 132

6 Client Setup Flowchart 132 Client Setup Troubleshooting Steps 138 Locked Down Clients 139 Appendix: Default SMS Permissions 141 Glossary 145 Index 158

7 SMS 2.0 Security Essentials Foreword Microsoft Systems Management Server 2.0 (SMS) is a complex system that addresses one of today s most complex problems - computer management. You can deploy SMS 2.0 in a large variety of environments, each with special considerations. SMS 2.0 includes sophisticated security options to ensure that its use is well controlled. You must carefully consider this combination of complexity, variety, and sophistication to ensure that you deploy and use SMS successfully. Computer managements systems are powerful by nature, and they might involve all the computers in your organization. It is critical that the security of your management systems is not compromised. By properly securing your management systems, you ensure that unauthorized persons cannot use your management systems to access or disable your organization's computers. You must give serious consideration to the issues in this paper. Also, because security risks are continually emerging from new sources and advancing technologies make it easier to abuse computer systems, you must also reconsider these issues on a regular basis. About this Document This technical paper discusses the security environment in which SMS works and the security features that SMS includes. It outlines how to deploy and use SMS and its related technologies to take advantage if their security effectively. Finally, this paper discusses SMS security troubleshooting. This paper consists of the following major parts, in addition to Appendixes and a Glossary: Part 1: The SMS Security Environment Part 2: The SMS Security Model Part 3: Novell NetWare in the SMS Security Model Part 4: Planning, Implementing, and Using SMS Part 5: SMS Security Troubleshooting This paper is intended for technical architects and administrators who plan, configure, and use SMS. Readers should be comfortable with administering SMS 2.0 and with basic Microsoft Windows NT security concepts. This paper discusses SMS security issues that are relevant to SMS 2.0 with Service Pack 2, computers running Windows NT Server version 4.0. The clients and NetWare configurations that SMS 2.0 supports are also included in this paper. This paper addresses many of the same issues that Chapter 4, "Creating Your SMS Security Strategy" of the Systems Management Server Version 2.0 Administrator's Guide addresses. This technical paper also discusses SMS security topics not included in that chapter, and provides additional background material and greater detail than that chapter does. i

8 Foreword ii This paper does not discuss security issues for the following items: Software metering Status subsystem 16-bit clients Microsoft Windows 2000-related security Microsoft Health Monitor - both controlling the use of Health Monitor or using Health Monitor to monitor the security of client computers Security implications of hardware inventory extension Creating remote secondary sites Using SMS with third-party security solutions (like Mission Critical Software's "Enterprise Administrator") Using SMS with Samba servers, or other SMB servers Service Manager security (and connectivity) Collection propagation to child sites (and whether rights are propagated with them) Courier Sender security, including the rights required at receiving sites SMS 1.2 security issues - either integrated with SMS 2.0 or as a stand-alone system. SMS 1.2 upgrade security issues are also not discussed. The Systems Management Server Version 2.0 Administrator's Guide includes details about SMS upgrades. SMS 1.2 security is discussed in the Systems Management Server Version 1.2 Administrator's Guide.

9 SMS 2.0 Security Essentials iii SMS Security Checklist Review the following checklist to ensure that you have considered all security issues related to SMS. Use this checklist when planning your deployment, soon after the deployment is completed, and on a routine basis thereafter. Using this checklist helps to ensure that key SMS security issues have not been overlooked. However, every implementation has different security issues and you must consider which ones apply to your environment that are not included in this checklist. To review this checklist effectively, you must have a full understanding of SMS security issues and techniques. SMS Security Checklist Task Benefit Done 1 Review overall computer security, including sources of risk, physical security, your organization's security policies and procedures, and your network security. 2 Review your implementation of security for technologies that SMS uses, including Microsoft SQL Server, Windows NT (including domains), and others technologies outlined in this paper. 3 Review your use of SMS connection, service, and special purpose accounts, where SMS does not automatically manage them. 4 Review who has access to your site servers at the WMI level (by using the SMS Admins group or similar accounts or groups). 5 Review who has access to SMS objects, by using SMS class and instance security rights, as administered in the SMS Administrator console. 6 Review access to software distribution shares. Helps you to better understand the environment your SMS implementation will exist in, and to understand the issues that SMS security must address. Helps you to further understand the environment your SMS implementation will exist in, but also allows you to adjust the security of specific technologies when it could benefit SMS security. Minimizes opportunities for future problems. Take advantage of SMS's modular security model, but do not make SMS administration too complex. Ensures that only authorized individuals have appropriate levels of access to the SMS systems. Further restricts access. Ensures that users have access only to the software that they are authorized to access.

10 Foreword iv SMS Security Checklist (continued) Task Benefit Done 7 Review Remote Tools security. Ensures that only authorized staff can remotely control appropriate client computers. 8 Review the security issues of your reporting solutions. 9 Review security issues related to your SMS Installer scripts. Also review the scripts and their availability. 10 Review Network Monitor security. Assess the risk that unauthorized network monitor use might pose. 11 Review your SMS security policies and procedures documentation. 12 Review this document fully, watch for alerts about security issues at the Microsoft Web site or on SMS community mailing lists and newsgroups, and look for weaknesses in your SMS security model. Restricts access to sensitive system details. Ensures that there is no opportunity to expose security details that you do not want to expose. Restricting usage of this powerful tool will ensure that it is not abused. Ensures that your documentation is up-to-date and complete. Minimizes the possibility that security holes remain in your security model, or that new ones will develop as technologies evolve. More Information This paper attempts to provide a comprehensive discussion of SMS security, including relevant background on the important subtleties of related security technologies. Inevitably, documentation cannot provide enough details for everyone, and additional information could come to light after this document has been published. Therefore, it is recommended that you refer to other sources of security information, especially those related to SMS security. The following list is a good starting point. For general administration information about SMS 2.0, including an overview of SMS 2.0 security, see the Systems Management Server Version 2.0 Administrator's Guide. Note that the Service Pack 1 (or later) version of the SMS 2.0 Administrator's Guide (available only in electronic form with Service Pack 1 (or later)) has a more up-to-date discussion of security than the printed book. If you obtained SMS through the Select or Open program, you can order copies of the SMS 2.0 Administrator's Guide by calling , which is Microsoft World Wide Fulfillment. Use part number If you did not get SMS through the Select or Open programs, you can call Microsoft Supplemental and Replacement Parts, at and request the SMS 2.0 Administrator's Guide, Part No For detailed information about how to use the SMS Administrator console, see the Systems Management Server Version 2.0 online Help. Some security suggestions are also included in the Help (for example, search for "About Managing SMS Accounts and Passwords"). For additional SMS security issues and details supplementing the SMS 2.0 Administrator's Guide, see the Service Pack 2 release notes.

11 SMS 2.0 Security Essentials v For advanced SMS 2.0 information, see the Systems Management Server 2.0 Resource Guide, which is part of the Microsoft BackOffice 4.5 Resource Kit (ISBN ), and is available separately (ISBN ). For product information about SMS 2.0, see For other technical papers about SMS 2.0 subjects, see For information on security subjects related to all Microsoft products, see For in-depth Windows NT security documentation, see the Windows NT Server 4.0 Resource Kit and the Windows NT Workstation 4.0 Resource Guide. For in-depth information on Windows Management Instrumentation (WMI), including WMI security, see There are a variety of books available for in-depth information about Distributed Component Object Model (DCOM), including DCOM security, and Microsoft has a variety of resources available at For complete information about SQL Server, including SQL Server security, see the Books Online that can be installed with SQL Server consoles. Many general purpose computer security books are available about such issues as risk assessment, physical security, network security, and policies and procedures.

12 Part 1: The SMS Security Environment 6 Part 1: The SMS Security Environment Microsoft Systems Management Server 2.0 (SMS) is implemented with a combination of technologies. Those technologies provide a rich security environment for SMS. You must understand the security details of each technology well in order to understand their relationship to SMS and how they might affect access to or from SMS. In addition, you must use the security technologies in a secure physical environment and establish appropriate policies and procedures. With a complete understanding of the SMS security environment, you can see that SMS security is readily understandable and very thorough. Each aspect of the SMS security environment is easy to work with separately, and, once understood, it is easy to use the parts together. Part 1 of this paper discusses the technologies that support the SMS security environment, including: Microsoft Windows NT security Microsoft SQL Server security Windows Management Instrumentation (WMI) security, including DCOM security Physical security Organizational security policies and procedures Windows NT Security Not surprisingly, SMS is very dependent on Windows NT and Windows NT security. Not only does SMS run on Windows NT, but it also uses Windows NT file sharing to communicate between sites, site servers, and clients and site servers. Understanding Windows NT security is fundamental to understanding SMS security. Experienced Windows NT administrators are familiar with the basics of Windows NT security, including the concepts related to accounts, groups, and domains. However, there are a number of Windows NT subtleties that, if relevant to your SMS implementation, can be critical to the success of your project. This section clarifies those concepts, which include: Windows NT security subtleties in relation to accounts, processes, privileges, and rights Windows NT authentication Pass-through authentication Domain model issues Windows NT security mechanisms Profiles and Impersonation For an explanation of the fundamentals of Windows NT security, see any books about Windows NT that include a security discussion. In the Microsoft Windows NT Server 4.0 Resource Kit, Networking Guide, the "Network Security and Domain Planning" chapter is a particularly good source of such information.

13 SMS 2.0 Security Essentials 7 Windows NT Security Subtleties SMS 2.0 uses many accounts to run its various components, which allows it to have very specific security for each component, thus minimizing the overall risk of a breach of SMS security. In order to understand SMS design and how to use SMS accounts properly, you must understand how Windows NT uses accounts. Accounts and Processes Two common misconceptions about Windows NT accounts are that they run programs and that they log onto computers. In fact, the computer runs programs in processes and the processes each have a security context. Each process has a security token, which includes details about the privileges that are available for that process to use. Processes are created when they are needed to run programs. Processes are always created from other processes (except for the initial system processes, which are created during system boot), and most often inherit the security context of the process that created them. A common example of a process being created with a new security context is a user logging on to a computer. The user provides a user name, password, and domain (or computer name), which are known collectively as credentials. The credentials are authenticated against a database of accounts. If a match is found, then the user is said to be logged on, and a process is created running Explorer.exe. Another example of a process being created with a new security context is when a program is run as a service. Services are started by the operating system (sometimes at the direction of a privileged user). Services can be run in the security context of the operating system, but in that case the service has very specific privileges, and those privileges do not include the right to use the network to connect to other computers. To be given additional privileges, services are often associated with an account, user name and password, and those are authenticated using the same authentication process as when a user logs on. SMS runs many of its server components using SMS accounts (and also some of its client components). The final example of when a process is created with a new security context is when a process creates another process which must use a specific account. The process creating the new process supplies an account, user name and password, which will be authenticated. When you start a program, this is how you create a process. This is also how SMS runs many of its client components. It is important to remember that Windows NT accounts each have a unique identifier, called a Security ID, or SID. In most places where account details are kept, such as access control lists, it's actually the SID that is stored. An example is the list of users that are allowed to access a directory. The SIDs, not the user names, are stored in that list. When an account is deleted and then re-created, the new account (even if its name and other characteristics are identical to the old account) will have a new SID. The old SID is not automatically removed from all the places it is stored, and the old SID is not automatically replaced with the new one in those places. For this reason, if an account is accidentally removed, you cannot restore access to the same resources merely by recreating the account with the same characteristics. Instead, you must add permissions for the new account at each resource that the removed account was permitted to use.

14 Part 1: The SMS Security Environment 8 Tokens Within all processes, Windows NT has threads that keep track of programs that are running. All processes have at least one thread, and they might have more to simplify the synchronization of concurrent operations that a program might need to perform. Multiple threads also allow a process to run on more than one central processing unit (CPU) at a time. A process always has a token associated with it, and a thread might also have a token (if the application requires that the thread have its own token). When a process is created and its credentials are authenticated, a token is created that includes the account s security details. Windows NT checks security frequently, but reauthenticating credentials each time would be very time consuming. To simplify the process, tokens are used for security checks. Tokens can always be trusted because they are used only within a computer and can be created only by the operating system. When a process creates a thread, it might supply credentials, have them authenticated, and thus get a unique token for the thread. The advantage of each thread having its own token is that it has its own unique security context. If one thread has its security compromised, it cannot affect its peer threads because they do not run in the same security context. Access Control Entries and Access Control Lists Access control lists (ACLs) contain access control entries. Each access control entry specifies a user or group that can access the object, and the kind of access the user or group is permitted. Windows NT uses a wide variety of objects. Objects is a word with many meanings, but for the purposes of this paper objects means Windows NT elements (such as files, processes, and internal data structures) that can have an ACL. Rights, Permissions, and Privileges Windows NT rights are given to accounts, and they allow processes created for those accounts to perform specific functions on a computer. Typical rights include the ability to shut down a computer or to run programs as services. The ability to use these rights, as granted to the account, is stored in the token when the process (and token) is successfully created. Permissions are held by objects, such as files, and they are used when the Windows NT security subsystem must determine whether a process is allowed to access an object for the kind of access the process is requesting. Windows NT compares the user name and domain (or computer name), or the groups the user is in, (as stored in the token) with the object's access control list. If a match is found, then Windows NT determines whether the kind of access requested is permitted. Privileges are a combination of rights and permissions granted to users or groups. Privileges is a term used to refer to the security rights and permissions a user has - it is not a Windows NT element.

15 SMS 2.0 Security Essentials 9 Network Security Computers running Windows NT do not trust tokens from other computers, because the other computers might not be running a valid version of Windows NT (for instance, they could be running an operating system that only looks like Windows NT, or that has been hacked so that tokens are given privileges they are not authorized to have). Whenever a computer attempts to connect to another computer, it must provide credentials that can be authenticated against a security database, in the same way that credentials are authenticated during process creation. When a process provides credentials for a network connection, it is common for the process to provide the credentials that were used when the process was created. However, it is equally valid for the process to provide alternate credentials. Providing alternate credentials allows the process to run with one set of privileges and to connect to another computer with a different set of privileges. In fact, a process can use one set of credentials to connect to one computer, and a different set to connect to another. However, a computer can only use one set of credentials to connect to another computer, even if different processes are trying to connect to that computer. The ability of a process to use one account for itself and another for its network connections allows greater control of security, because the account that specifies the privileges for the process can be limited to a specific computer (or limited in other ways), but the account that specifies the privileges for the network connection can be shared among multiple computers. The shared account, which many computers will be able to use, cannot run any dangerous programs on other computers because it does not have of the necessary privileges. SMS frequently takes advantage of a process s ability to use one security context for itself and another security context for its network connection. This is why SMS has some accounts for connections and some to run services. A computer might use accounts from both sets concurrently. Windows NT Authentication Windows NT authentication is performed for process and thread creation and when connecting to other computers. Authentication problems are most often seen when a computer connects to other computers. When a user runs a Windows NT process that attempts to connect to a share on another computer running Windows NT, the computer serving the share must be confident that the user is who they claim to be. With that confidence, the computer can then ensure that the user is allowed the requested access level, and it can provide the requested data.

16 Part 1: The SMS Security Environment 10 There are four steps in the process of authentication, which are also illustrated in Figures 1.1 and 1.2: 1. When the connection to the share is made, the computer initiating the connection includes in the request the user name, password, and domain name that the user supplied when logging onto the computer. If the user is logged on locally to the computer, using a local computer account, the domain name is replaced with the computer name. The user can override these values if he or she specifies a "connect as" string when making the connection request. The computer receiving the connection request compares the domain name with the name of its security database. The security database name on a domain controller is the domain name. The security database name on any other Windows NT-based computer is the computer name. If the names are the same, then the local copy of the database is used. On a domain controller, the database is the domain database. 2. If the names do not match, and if the computer is not a domain controller, then the computer passes the request to a domain controller. 3. The domain controller then compares the requested domain name with its domain name. If the names are the same then the domain controller attempts to authenticate the request. If the names still do not match, then the domain controller looks through its list of trusted domains. If it finds a match, it passes the request to a domain controller for that domain. Figure 1.1 Windows NT authentication steps

17 SMS 2.0 Security Essentials A further extension of the authentication process is the use of guest privileges. If guest access is enabled and the user name specified in the request is not found in the security database, then the connection is authenticated as a guest access. This authentication occurs at either the computer offering the share or at the domain controller (steps 1 to 2 in Figure 1.1 and 1.2), but not until the last possible step in your environment has been attempted. Guest access can be enabled at the computer providing the share, the computer's domain, or a trusted domain. If guest access is enabled at the computer's domain or a trusted domain, then the account must be global, not local. Guest access is not enabled by default for Windows NT, and it is usually discouraged. Guest privileges can be limited to specific resources, but it is easy to make a mistake that permits guests to access resources that were not intended for guest access. Pass-Through Authentication Occasionally, the domain specified in the connection request is not the name of the computer being connected to, is not the name of the domain it is in, and is not the name of a trusted domain. In this case, Windows NT tries one last method to authenticate the request. Windows NT tries to find the user name on the computer offering the share, and if the user name exists, then Windows NT compares the user name s password with the provided password. If the two match, then the request is authenticated. This corresponds to step 4 in Figures 1.1 and 1.2. Step 4 of Windows NT authentication is often referred to as pass-through authentication, but pass-through authentication actually also includes the parts of authentication where the details are checked locally and passed to domain controllers (steps 1 to 3). Step 4 of passthrough authentication could be called domain-less authentication.

18 Part 1: The SMS Security Environment 12 Figure 1.2 Pass-Through Security Flow

19 SMS 2.0 Security Essentials 13 Domain Models Windows NT domains are a flexible means of organizing computer security. There are three classic domain models: The single domain model is simple, but its size cannot be increased beyond approximately the range of 40,000 accounts, which can mean 15,000 end-users. The single master domain model can scale higher, because it separates accounts into separate domains, depending on whether they are for users and services or for computers (to allow inclusion in the domain). User and service accounts go in a master domain, which is often called an account domain for this reason. Computer accounts are put in resource domains, which trust the master domain, and therefore allow access to users who have been authenticated by the master domain. The single master domain model is limited to approximately 30,000 end-users. The single master domain model also provides flexibility in administration, so that local administrators or administrators in business units can add computers to domains even though they might not have the privilege to add user accounts to the account domain. Note that users on computers in the resource domains can log onto either the master domain or the resource domain (or onto the local computer). The computer in the resource domain is always authenticated as being a valid member of the resource domain, but the user can be authenticated as a valid member of either the master domain, the resource domain, or the computer itself. The accounts that the user has in each case are different from each other, but they are all equally valid at the computer. This point is important in order to understand that the membership of the computers in the master domain is not important in consideration of the use of user accounts from either the master or resource domains the user accounts can be used from either. The multiple master domain model does not have a limitation with regard to scalability, and it also allows organizational units to manage user accounts for themselves, while not being able to manage other units' user accounts. However, the multiple master domain model does generate additional network overhead, because there are relatively large number of trusts involved. Figure 1.3 shows the usual Windows NT domain configurations where SMS can be used.

20 Part 1: The SMS Security Environment 14 Figure 1.3 Windows NT Domain Models

21 SMS 2.0 Security Essentials 15 Other Windows NT Security Features In addition to the authentication, access control, and domain management features, Windows NT also has security features for auditing, profiles, system security policies, and impersonation. These are important features for ensuring that your company's security policies are adhered to and for using Windows NT security. If you understand these features, you can use them effectively with SMS to maximize security. Auditing Windows NT can log specific security events in its security log. You can use this powerful tool to watch how a computer is being used, which can help you with troubleshooting problems and in watching for attacks. Windows NT can watch actions such as logging onto the computer, opening files, or using security rights. These actions can be security-related problems if they are done in violation of your security policies. The Audit Policy of your Windows NT computer determines which events appear in the security log. If you are not selective in what you audit, your log files will fill, leading to the loss of newer entries and making it difficult to find events other than auditing events. You can enable auditing for system-wide events as well as for file and object access. To enable auditing for system-wide events, use User Manager or User Manager for Domains. From the Policies menu, select Audit, and then select Audit These Events. You can then choose to audit the success or failure of the following events: Logon and Logoff File and Object Access Use of User Rights User and Group Management Security Policy Changes Restart, Shutdown, and System Process Tracking. The default configuration is Do Not Audit. By default, security events are not recorded in the security log. Windows NT allows you to audit File and Object Access. Before you configure your files, directories, and printers for auditing, be sure you enable auditing on your system, choosing to audit at least File and Object Access. Auditing files and directories on your NTFS partitions allows you to track usage, identify who performed various actions, and hold users accountable for their actions. To enable auditing of particular files or directories, use File Manager. From the Security menu, select Auditing. Add the users and groups that you want to monitor. Select the types of access you want to audit. Possibilities include success or failure on Read, Write, Execute, Delete, Change Permissions, and Take Ownership. To audit printer access, use Print Manager. From the Security menu, choose Auditing. Add the users and groups you want to monitor, and then select the types of access you want to audit. You can then choose to audit the success or failure of Print, Full Control, Delete, Change Permissions, and Take Ownership.

22 Part 1: The SMS Security Environment 16 Profiles A Windows NT 4.0 User Profile describes the Windows NT configuration for a specific user, including the user s environment and preference settings. For example, a profile includes those settings and configuration options that are specific to the user such as installed applications, desktop icons, and color options. This profile is built in part from System Policy information (for example, those things that a user has access to and those things that the user can and cannot change) and in part from permitted, saved changes that a user makes to customize his or her desktop. The effect of profiles is changes in settings, directories, and files on the client computers. Profiles are created when a user first logs onto a computer. When accounts are removed, the corresponding profiles should be removed as well, but this is not done automatically. If the administrator removes an account, then he or she must also manually remove the profile (in the System control panel). SMS accounts will have profiles, like any other accounts, after the account is first used on each computer. System Policies A System Policy is a set of registry settings that define the computer resources available to a group of users or to an individual. Policies define the various aspects of the desktop environment that a system administrator needs to control, such as which applications are available, which applications appear on the user s desktop, which applications and options appear in the Start menu, who has permission to change attributes of their desktops, and so forth. System policies are a powerful security mechanism because they can restrict the users' ability to install untested and unauthorized software that could compromise security in many different ways. System policies are relevant to SMS because the SMS client components must be installed. Also, SMS runs additional programs as part of its normal operations or when they are distributed by administrators. Therefore, system policies must not be so restrictive that SMS cannot perform its functions. Impersonation An important aspect of communication between servers and clients is the ability of a server to determine whether to service a client s request. Many services run in a highly privileged security context and therefore have far more privileges and abilities than a typical client that is requesting service. An example of this is a network file service running on server. This service would have full access to all files on the server, but users that request access to files on the server will have limited access. The service will carry out a client request only if the client has sufficient access rights to the requested files. There are two methods for determining whether a client has sufficient access rights for an operation: an access check by the server or an access check by the service. The brute-force method builds into the service the logic of doing authorization checks for client access. The service uses authorization information from a separate authorization file to determine if the client has sufficient rights to perform the requested operation.

23 SMS 2.0 Security Essentials 17 Windows NT provides a way for services to determine client authorization by using a feature called impersonation. Impersonation is based on temporarily changing the security context of the service to match the client before the service attempts to access a resource. Windows NT implements the access check on a resource automatically when the service attempts to open the system resource. Using impersonation and system-level access verification simplifies service development and uses Windows NT access control effectively. NetWare Security SMS has strong support for Novell NetWare environments and uses NetWare security effectively. However this is a large subject to explain properly, and it is best explained with an understanding of SMS security (discussed in Part 2, "The SMS Security Model", of this technical paper), so it is discussed in detailed in its own part of this document (Part 3, "Novell NetWare in the SMS Security Model"). SQL Server Security SMS 2.0 uses Microsoft SQL Server to store its database of inventory and SMS configuration data. SMS can use either version 6.5 or 7.0 of SQL Server. Version 7.0 is generally easier to use, but if you have upgraded from version 1.2 of SMS or if you have a considerable investment in version 6.5 of SQL Server then you might not want to upgrade it at this time. Generally both versions of SQL Server have the same security issues, but the terminology is different, and there are subtle differences between the two. SQL Server 6.5 SQL Server 6.5 offers three security models for authenticating connection attempts: Standard security The SQL Server system administrator defines SQL Server logins with passwords in SQL Server and then associates the logins with users in individual databases. SQL Server logins are separate from Windows NT user accounts. Integrated security The SQL Server system administrator defines logins for those Windows NT user accounts that are allowed to connect to SQL Server. By default, all domain administrators are granted sa-level security. Users do not have to specify a separate login and password when they connect to SQL Server after they log on to the Windows NT network. When they attempt to connect, the SQL Server Net-Library attempts a trusted connection to SQL Server. If the user s Windows NT account is one that the system administrator specified to SQL Server, the connection succeeds. Mixed security The system administrator can define both SQL Server logins and Windows NT accounts as SQL Server logins. Users with valid Windows NT accounts can connect by using trusted connections; other users can connect by using standard security with the SQL Server logins.

24 Part 1: The SMS Security Environment 18 Only the named pipes or Multi-protocol Net-Libraries support integrated security and trusted connections, and Multi-protocol is not supported by SMS. Integrated security offers several benefits: SQL Server passwords do not need to be stored in the application (such as SMS). Passwords are never present in the SQL Server Tabular Data Stream (TDS) packets (TDS is SQL Server's application-level protocol). Integrated security is easy to administer because the system administrator can use the SQL Security Manager utility to create SQL Server logins from existing Windows NT accounts. SQL Server 7.0 In SQL Server 7.0, the Security Wizard replaces SQL Security Manager. The term integrated security is replaced by Windows NT Authentication and is available over all network libraries. SQL Server Authentication, previously called standard security, is present for backward compatibility and for Windows 95 and Windows 98 environments. Its use is discouraged for servers in an enterprise environment. Mixed security is not an explicit option in SQL Server 7.0. Windows NT Authentication is always available. SQL Server Authentication can be enabled and disabled. The effect of mixed security is achieved by enabling SQL Server Authentication. Roles replace the SQL Server 6.x concept of groups. Roles resemble Windows NT 4.0 security and are group accounts that have members. Permissions are assigned to roles using GRANT, REVOKE, and DENY statements. DENY is a new permission that resembles Windows NT permissions. DENY explicitly denies permission on an object and takes precedence over all other permissions. WMI Security SMS uses Windows Management Instrumentation (WMI) as a standardized management interface. SMS uses WMI on clients for hardware inventory collection and Health Monitoring, on servers as an interface to the SMS database, and on consoles as an interface to the SMS database. WMI is also used for storing some configuration data, such as that used by Network Trace. WMI supports full security for the Microsoft Windows NT /Microsoft Windows 2000 operating system, and limited security for Windows 95/98. WMI security authenticates a user's logon information both for the local computer and for remote access. WMI grants a validated user some form of controlled access to the entire Common Information Model (CIM) repository. In its current release, WMI does not provide security for system resources such as individual classes and instances. However, for the version of WMI included with Windows 2000, administrators can use WMI to control global permissions on namespace operations, such as limiting the access of some users to read-only operations on SMS data. The version of WMI included with SMS 2.0 for installation on computers running Windows NT 4.0, Windows 95 or Windows 98 only allows control of access to WMI, not access to namespaces within WMI.

25 SMS 2.0 Security Essentials 19 Each WMI namespace has its own security descriptor (SD), which allows the namespace to have its own security settings. Like the Microsoft Windows NT file system (NTFS), inheritance might be used to simplify the administration of security. Each access control entry (ACE) in the namespace SD has a flags field, which indicates what inheritance, if any, is to be performed. For example, if container inheritance is allowed, then the ACE of the namespace SD is inherited by child namespaces. The SD is constructed when a connection to the namespace is first made. The SD is constructed from the ACLs of the namespaces in the inheritance chain, as modified by the inheritance bits of each namespace. By default, the owner will be the local administrator account, and the local administrators group has rights to all operations, including remote access. The security descriptor is also used to control access to WMI services. The SD is a standard Windows NT security descriptor, and it contains an access control list (ACL), a list of access control entries (ACEs). Each ACE grants permission to execute a restricted operation, such as allowing logons, remote access, method execution, and writing to the CIM Repository (the WMI database). The WMI SDs are stored in the CIM Repository. On Microsoft Windows NT /Windows 2000 platforms, there is no distinction between local and remote access. However, with a remote connection, users can specify a user name and password, replacing the current user name and password. With a local connection, users cannot override the current name and password. On Windows 95 and Windows 98 platforms, local users are considered administrators and are granted full rights. There is no authentication. Remote users, however, are validated using instances of WMI system classes. Administrators can use the WBEMperm.exe to set permissions for WMI users on computers running Windows NT Server, and can use WMI Control on computers running Windows 2000 Server. DCOM Security DCOM is used as the primary protocol for WMI communications. Because WMI uses its own security model, it does not rely on DCOM security. WMI security is namespace oriented, rather than component oriented as DCOM is, and so DCOM security would not serve WMI's needs. But, if DCOM security is broken, then WMI security will be broken, and then SMS will be broken. For this reason it might be appropriate for an SMS administrator, to be aware of DCOM security. Microsoft's distributed COM (DCOM) extends the Component Object Model (COM) to support communication among objects on different computers on a LAN, a WAN, or even the Internet. With DCOM, an application can be distributed to locations that make the most sense for the application. DCOM handles low-level details of network protocols. Using networks for distributing an application is challenging not only because of the physical limitations of bandwidth and latency, but also because it raises new issues related to security between and among clients and components. Because many operations are physically accessible by anyone with access to the network, access to these operations has to be restricted at a higher level.

26 Part 1: The SMS Security Environment 20 Without security support from the distributed development platform, each application, like WMI, would be forced to implement its own security features. A typical feature would involve passing a user name and password (or public key) usually encrypted to a logon method. The application would validate these credentials against a user database or directory and return a dynamic identifier for use in future method calls. On each subsequent call to a secure method, the clients would have to pass this security identifier. Each application would have to store and manage a list of user names and passwords, protect the user directory against unauthorized access, and manage changes to passwords, as well as deal with the security hazard of sending passwords over the network. A distributed platform, like DCOM, must provide a security framework to safely distinguish different clients or different groups of clients so that the system or the application has a way of knowing who is trying to perform an operation on a component. DCOM uses the extensible security framework provided by Windows NT. Windows NT provides a set of built-in security providers that support multiple identification and authentication features, from traditional trusted-domain security models to massively scaling public-key security features that are not centrally managed. A central part of the security framework is a user directory, which stores the necessary information to validate a user's credentials (user name, password, public key). DCOM's Component-Oriented Security DCOM can make distributed applications secure without any security-specific coding or design in either the client or the component. Just as the DCOM programming model hides a component's location, it also hides the security requirements of a component. The same (existing or off-the-shelf) binary code that works in a single-computer environment, where security might be of no concern, can be used in a distributed environment in a secure way. DCOM achieves this security transparency by letting developers and administrators configure the security settings for each component. Just as the Windows NT File System lets administrators set ACLs for files and directories, DCOM stores access control lists for components. These lists merely indicate which users or groups of users have the right to access a component of a certain class. These lists can easily be configured by using the DCOM configuration tool (DCOMCNFG) or programmatically using the Windows NT registry and Win32 security functions. Whenever a client calls a method or creates an instance of a component, DCOM obtains the client's current user name associated with the current process (actually the current thread of execution). Windows NT guarantees that this user credential is authentic. DCOM then passes the user name to the computer or process where the component is running. DCOM on the component's computer then validates the user name again using whatever authentication feature is configured and checks the access control list for the component (the first component run in the process containing the component. For details, see the "DCOM Architecture" Technical paper, available on TechNet and the Microsoft web site.) If the client's user name is not included in this list (either directly or indirectly as a member of a group of users), DCOM merely rejects the call before the component is ever involved. DCOM is built on lower levels of network protocols, namely the remote procedure call (RPC) and named pipes protocols. Each of those levels can have security features as well. However, those facilities are not used with SMS or WMI.

27 SMS 2.0 Security Essentials 21 Physical Security Software security is critically important to SMS security, but without appropriate, basic, physical security, SMS can still be vulnerable. SMS is designed on the premise that client computers might not be physically secure, and therefore SMS clients have no functionality that can be used to compromise SMS security. CAUTION This discussion presumes that client computers are used by users without elevated privileges on other computers. Privileged users with sufficient knowledge can easily turn any client computer into a console, and if their privileges allow them to attach to a site server, they will then have full access to the SMS system. Also, site server and console computers are often client computers, but for the purpose of this discussion they are not considered to be client computers. An SMS Administrator console, when connected to an SMS site server, can be used inappropriately to the detriment of SMS itself or to the computers it manages. Therefore SMS Administrator consoles must always be physically secured while the user is logged on. Ideally, SMS Administrator consoles will be in a locked room protected from unauthorized access. However, if this is not possible, they must be secured when staff are not physically present. This can be done by having Windows NT lock the workstation, or by using a secured screen saver that activates soon after user input stops. An SMS site server is also at risk if it is not physically secured while an administrator is logged onto it and while it is not guarded. Not only do site servers have an SMS Administrator console, but they also have the setup program required for site resets. Security Policies and Procedures Documented policies and procedures are beneficial for any system, but they are especially appropriate for computer security systems. By documenting your company's computer security policies and the procedures to be used, all relevant staff and managers can have an opportunity to review those policies and procedures in a systematic way. This will ensure that any missing details are added, any weak points are strengthened, and any unnecessary parts are removed. All staff also have the opportunity to be fully aware of the policies and procedures, so that there can be no question in the future about whether an abuse of a system is due to ignorance. Policies and procedures must be developed for each organization individually because every organization has different risks, technologies, personnel and cultures. Therefore it is very unlikely that the policies and procedures for one organization would be wholly appropriate for another organization.

28 Part 1: The SMS Security Environment 22 Typically, security policies address issues such as who is allowed access to various resources, how security will be reviewed and enforced, and how the organization will respond to security abuses and breaches. Security procedures outline how someone requests, obtains, and is actually granted access to a system, how systems are monitored, how security is configured, how to react to a security breach, etc. Security procedures must be consistent with the security policies. Formal security policies and procedures serve a variety of functions: By providing a checklist for procedures, including system checks, they ensure that ongoing security functions are always performed completely. By allowing all staff to know what the consequences are to security indiscretions, staff cannot claim ignorance if they do anything unacceptable. By anticipating security events and the appropriate reactions, they expedite the reaction, ensuring that any damage done is minimal. By being well documented, all interested parties have full opportunity to ensure that the policies and procedures are reasonable and complete. SMS security policies must be developed in consideration of broader company security policies. They must also consider the particular issues and risks that a computer management system introduces. They must reflect your company's tolerance for security risk, which is often governed by the nature of your company's business and its culture. The "Planning and Implementation Considerations" section in Part 4 of this paper outlines some relevant issues. SMS security procedures must be developed to implement the SMS security policies, but they must include technical details as discussed in this document and the SMS 2.0 Administrator's Guide.

29 SMS 2.0 Security Essentials 23 Part 2: The SMS Security Model SMS includes extensive security features at various levels. These security features use the security environment that SMS works within, as described in Part 1, The SMS Security Environment, and provide additional security to control SMS-specific functions. This part of this technical paper describes SMS security model, including: SMS security elements general SMS security principles SMS Object Security SMS accounts and groups SMS connectivity SMS feature-level security Site setup Site reset CAUTION Windows 95 and Windows 98 are not considered to be secure operating systems. They do not have many of the Windows NT security features, such as the ability to run programs in different security contexts, the NT file system (NTFS), a local security database, security auditing, or the ability to authenticate accounts other than during log on. All activity on Windows 95 and Windows 98-based computers is done in the context of the logged on user. For these reasons, the client side of the SMS security model does not apply to Windows 95 and Windows 98-based computers. Elements of SMS Security The following are the elements of SMS security that collectively ensure that SMS can be used only by authorized staff: Technology security (Windows NT, DCOM, WMI, SQL Server) and security processes (security policies and procedures and physical security) that, as discussed in Part 1, provide a secure environment for SMS. Component security, using a variety of accounts, so that each part of SMS is individually secured. Component security has two elements itself: The security context in which components run. The security context that components use to access other computers. SMS server security (shares, directories, registry entries, etc.), so SMS cannot be manipulated indirectly. Console security, so that only authorized administrators can use and configure SMS through its intended interfaces. In most cases, console security also applies to tools that are developed with the SMS Software Development Kit (SDK). Object security, so that SMS administrators can manipulate only sites, packages, advertisements, and other SMS objects that they are authorized to manipulate. In most cases, object security also applies to tools that are developed with the SMS SDK.

30 Part 2: The SMS Security Model 24 Feature security, so that each feature is only used by authorized administrators and users can access only files they are authorized to access. Setup and site reset security, so that authorized administrators can control security as systems are set up and so that they can manage the critical administrative accounts. These SMS security elements are discussed throughout this paper. As you are reviewing SMS security, be sure that you understand each of these elements, have configured them properly, and have appropriate policies and procedures in place for them. Security Principles The following principles are general themes concerning how SMS security is implemented and best used. Some principles lead to best practices, included in Part 4 of this technical paper. Principle 1: All SMS account passwords are encrypted, either by Windows NT or SMS. Also, account passwords that SMS creates are randomly generated. Implications for administrator: Encryption of all SMS passwords and random generation of SMS-created passwords maximizes security because it results in very strong passwords that are not exposed. Best Practice: For this reason, and to minimize the potential for account lockouts, always leave the accounts' Password never expires option enabled for SMS accounts, and do not change the passwords on SMS-managed accounts Principle 2: SMS 2.0 provides many more accounts for site and client functions than does SMS 1.2. For some site and client functions, you can use optional accounts. Implication for administrator: You can use these additional accounts to increase security by granting privileges on a more granular basis, thus minimizing the risk to all SMS processes if the security of a single account is breached. However, these additional accounts also increase the administrative workload required to plan for and manage security-related tasks. Best Practice: Create and specify accounts in addition to those created by SMS Setup, to minimize the use of the SMS Service account. Following are optional accounts that you can specify in place of the SMS Service account, to maximize security: Site System Connection (Windows NT, NetWare NDS, or NetWare Bindery) SMS Site Address Client Connection (Windows NT, NetWare NDS, or NetWare Bindery) SMS Windows NT Client Software Installation SMS Client Remote Installation Principle 3: SMS security management involves trade-offs. Greater security requires greater administration. Implication for administrator: To effectively balance security with administration, it is important to understand key security decision points and how to implement those decisions in SMS. For example, which accounts are required and which can you specify on an optional basis for greater security? Which directory permissions can you change without disrupting SMS functionality?

31 SMS 2.0 Security Essentials 25 Best Practice: Same as Principle Principle 4: The higher the privileges of an SMS account and the greater the number of processes accessed by the account, the more important it is to limit physical access to the computer the account runs on or is used from. Implication for administrator: When you plan the physical location of site server, client access points (CAPs,) distribution points, and logon points, consider the accounts running on each computer and the privileges granted to those accounts. For example, if your CAPs and logon points are located in a smaller branch office with minimal security, take additional steps to restrict physical access to those computers. Best Practice: Restrict physical access to the site server computer and the computer with SQL Server. Also, limit access to the SMS Service account and the SQL Server account to as few administrators as possible. It's important to follow these precautions because the SMS Service account and the SQL Server account have site-wide access. By restricting access to these accounts, you minimize the number of times you must change SMS passwords to provide the appropriate level of security Principle 5: Manual changes made to accounts through the SMS Administrator console will not automatically be made in the security systems for Windows NT, SQL Server, NetWare NDS, or NetWare bindery. The same principle applies to accounts that are manually specified in SQL Server, NetWare NDS, or NetWare Bindery. General implications for administrator: If you manage an account manually in the SMS Administrator console, you must also manage it in Windows NT User Manager for Domains, SQL Server, NetWare NDS, or NetWare Bindery. You must manage the following accounts in both the SMS Administrator console and in Windows NT User Manager for Domains: SMS Service SMS Site Address Software Metering Service Site System Connection (Windows NT) Client Connection (Windows NT) SMS Windows NT Client Software Installation SMS Client Remote Installation You must manage the following accounts in both the SMS Administrator console and in SQL Server: Site Database Software Metering Database

32 Part 2: The SMS Security Model 26 You must manage the following accounts in both the SMS Administrator console and in NetWare NDS or NetWare bindery: Site System Connection (NetWare NDS, NetWare Bindery) Client Connection (Netware NDS, NetWare Bindery) Principle 6: SMS requires NTFS partitions. General implications for administrator: When you design your sites, be aware that CAPs, logon points, and distribution points require NTFS partitions so that Windows NTFS security can be used to secure the SMS file structure from unauthorized users. Best practice: Wherever SMS files are installed, use NTFS security to maximize security Principle 7: Any computer management solution, such as SMS, will require significant privileges on most (or all) of your computers. Therefore, if the security of your computer management solution is compromised, the security of all your computers might be compromised. General implications for administrator: Take SMS security seriously, and review this and related documentation closely Principle 8: Strong security will be more effective at preventing security breaches than weak security, but it is also more likely to prevent authorized access and activities. General implications for administrator: If you need to implement strong security, be sure that you understand the relevant security technologies well and how your users and systems work. You can then adjust your security settings so that the authorized users and systems can work properly, while unauthorized activities are blocked. This technical paper will help you to achieve the level of expertise necessary to set security correctly in every situation. SMS Object Security SMS generally relies on other technologies to enforce security. As an example, SMS sets security on Windows NT shares and then relies on Windows NT to authenticate accounts and allow only correct accounts to access the shares. SMS enforces security when SMS objects are being accessed. The SMS Provider compares the user who is accessing the objects to the SMS security rights, to determine if the user has permission to access or change the objects. SMS Provider enforces SMS object security when SMS objects are accessed through either the SMS Administrator console or programs written with the SMS SDK. The Security Rights console item of the SMS Administrator console allows you to set permissions on object classes and instances. By default, only three accounts are granted permissions to all objects in the SMS Administrator console: The local system account (NT Authority/System). The user account that was logged on when SMS Setup was run The SMS Service account.

33 SMS 2.0 Security Essentials 27 You must explicitly add other accounts and grant them permissions to SMS object types by using the Security Rights console item in the SMS Administrator console. Users who do not have permissions for various object type classes or instances will not see those objects in their SMS Administrator console. Users who have partial permissions for SMS Administrator console items will see only those items for which they have permissions. With SMS 2.0 Service Pack 1 (and later), the SMS Administrator console includes contextsensitive menu options to clone specific accounts or to manage users (which includes adding, removing, or modifying all rights for a specific user). These options greatly simplify security rights management. You can use six SMS classes (object types) to give administrators access to console items in the SMS Administrator console: Table 2.1 SMS Classes for Granting Security Rights Object class SMS_Advertisement SMS_Collection SMS_Package SMS_Query SMS_Site SMS_StatusMessage Console item Advertisements Collections Packages Queries Sites Status Messages You can configure security for SMS object types at either the class level or the instance level: Class level This level grants users permissions for all object types in a specific class for example, all packages or all collections. Instance level This level grants permissions for a specific instance of an object type, such as the All Windows 95 Systems collection or the New York City site collection. In both cases, however, you grant or deny permissions on a per-windows NT user or usergroup basis. Note If a user is granted class security rights to an SMS security object and is also granted conflicting instance security rights to a specific SMS security object, SMS reconciles the class and instance security rights to grant the highest level of permissions. For example, if the user is granted full permissions to all packages (class security rights) and is also granted no permissions to a specific package (instance security rights), the class security rights granted to the user will override the instance security rights, and the user will be granted full permissions to all packages. You can grant these security rights to a single user or to user groups within a domain. For example, you can specify that all packages can be edited by members of the Domain Users group. Or you can specify that specific users can edit only the packages that they create. You can allow an administrator to manage all collections or just one. For each security object or object type, you can grant a number of different permissions. This granularity gives you greater control over who can access SMS object types and who can access specific information in the SMS site database.

34 Part 2: The SMS Security Model 28 Object Permissions For each class or instance, you specify permissions such as Create, Administer, or Delete Resource. Some permissions are specific to an object type. For example, the Distribute and Advertise permissions only apply to package object types. Note that resource permissions are handled with collection object type classes and instances. Table 2.2 describes each permission and the security object types for which they are available. Table 2.2 Object Type Permissions Permission Allies to Grants the Ability to Administer Advertise Create Delete Delete Resource Distribute All security object types Collection object type class and instances All security object types All security object types and instances (except status message instances) Collection object type class and instances Package object type class and instances Administer all security object types. Assign or remove any user security rights for a class of objects or for individual object types in that class to yourself or to any other user. There must always be at least one account with Administer rights on any object. You cannot remove the last Administrator, nor can you change your own Administer rights. You must explicitly grant other permissions appropriate to the object type. Advertise to a collection. This permission does not grant the ability to create advertisements that requires Create permission on the advertisement object type. Create an instance of an object type. Delete an instance of an object type. Delete a resource from a collection. Send packages to distribution points.

35 SMS 2.0 Security Essentials 29 Table 2.2 Object Type Permissions (continued) Permission Allies to Grants the Ability to Modify Modify Resource Read All security object types and instances (except status message type and instances) Collection object type class and instances All security object types and instances (except status message instances) Read Resource Collection object type class and instances. Use Remote Tools View Collected Files Collection object type class and instances Collection object type class and instances Modify an instance of an object type. Modify a resource in a collection. View an instance and its properties. Read a resource in a collection. Use Remote Tools on a resource. View the files collected from a client. For each object type, there must always be at least one account with Administer permission. This approach prevents administrators from being locked out of an SMS system. As a result, it is not possible to delete the final user on a particular object type with the Administer permission. Also, you cannot delete your own Administer rights on an object. Note Granting the Administer permission to a user does not automatically give the user Create, Modify, or Delete permissions for that object type.

36 Part 2: The SMS Security Model 30 Users who create an object are automatically assigned Read, Modify, and Delete permissions for that object type instance. For information about how to configure security rights, see the SMS 2.0 Administrator's Guide, Configuring Site Security section in Chapter 8, Configuring SMS Sites, or see SMS Help. Consider how granting permissions to various user groups in your organization can address their specific needs. For example, if your help desk technicians have a user group, you can grant that group Use Remote Tools permission for Collections. If users who are not SMS administrators want to view and query inventory collected from clients, you can grant those users Read permission to Collections and Queries, along with Read Resource permission to Collections. Tip To maximize security, grant permissions to each administrator carefully at the instance level, unless they require permissions at the class level. Create a collection of the resources that each administrator manages and grant permissions only to that collection. As a result, each administrator sees only those security objects to which access is granted. For mid-level security, have your administrators log on to the SMS Administrator console remotely. To minimize administrative overhead, give all administrators or some administrators full control of all objects in the SMS site database. The easiest way to do this is to create or use a group that has the correct permissions. Then, as you add administrators to the site, you can simply add them to the group. Accounts and Groups For improved security, the SMS 2.0 security system uses multiple accounts for different site and client functions. You can use these additional accounts to avoid granting domain administrative access across the network. By granting privileges on a more granular basis, you minimize the risk to all SMS processes if a single account s security is breached. For example, in SMS 1.2, the SMS Service account (a member of the Domain Administrators group) was used to install software on Windows NT clients who do not have local administrative rights. In SMS 2.0, you can specify that these operations be performed by SMS client installation accounts, which have lower level rights than the SMS Service account. The greater number of accounts available with SMS 2.0 security increases the complexity of account planning and management. To effectively plan and manage SMS 2.0 security, it is essential to understand the role of each SMS 2.0 account.

37 SMS 2.0 Security Essentials 31 Accounts and Account Roles The accounts described in this document might often be better referred to as account roles. This distinction can be important, because the user names for the accounts are often only suggestions and thus you might use other user names. Also, you can use a single account for multiple roles. An example is using the SMS Service account for site-to-site communications, site server communications, remote client installation, or other roles, in addition to running the server services. Using the SMS Service account in all these roles is acceptable under some circumstances, such as small deployments where ease of administration is more important than tight security. For troubleshooting, planning, security analysis, and other areas, it is important to be clear that roles are still distinct from the accounts that serve those roles. When SMS documentation refers to an account it is often referring to the account role. You might not be using a unique account in that role, but there are still unique considerations for that account role. The Accounts Keep in mind that SMS Setup creates some of these accounts automatically; others you must specify manually. Some accounts are required for site functionality; others are recommended for greater security. Finally, the accounts created during SMS Setup provide minimal security. Depending on your domain model and security needs, you might want to specify additional accounts to maximize security. After you decide what accounts you want to use in your site, you must have a clear understanding of how to configure those accounts. SMS accounts are actually Windows NT, SQL Server, or NetWare user accounts that are used by SMS processes. Therefore, each account that you can create or modify manually must first be created or modified in Windows NT, SQL Server, or NetWare. Then you can create or modify the same account in the SMS Administrator console or through the SMS Setup Wizard. If you modify an account only in the SMS Administrator console, you are only modifying the object that contains the information SMS has about the account. You are not modifying the Windows NT, SQL Server, or NetWare account itself. Table 2.3 provides a convenient reference list of all the SMS accounts. Table 2.4 provides a summary of all the accounts with details about their purpose, whether they are created automatically and whether they are optional or required. In Part 4, Considerations, Practices and Procedures for Planning, Implementing, and Using SMS Security, you will learn how to maximize security in your site, best practices for managing accounts (including password changes), and procedures for creating and modifying SMS accounts that can be managed by an administrator.

38 Part 2: The SMS Security Model 32 Table 2.3 SMS Accounts List Account Name SMS Service SQL Server SMS Site Address SMS Server Connection Netware NDS Site System Connection NetWare Bindery Site System Connection Windows Networking Site System Connection SMS Logon Service SMS Remote Service (CAP) SMS Remote Service (SQL Monitor on separate server) Software Metering Service Client Services (DC) Client Services (Non-DC) Client User Token SMS Client Connection SMS Windows NT Client Software Installation SMS Client Remote Installation logged on user SMS Provider Impersonation Client Configuration Manager (CCM) Boot Loader (Non- DC) CCM Boot Loader (DC) Netware NDS Client Connection NetWare Bindery Client Connection Software Metering SQL Server Crystal Info Reports Crystal Info Service Software Metering Test note: sc=site code, dc=domain controller name, xxxx=unique number, starting at 0000 User Name SMSService (might vary) sa (might vary) administrator's choice SMSServer_sc administrator's choice administrator's choice administrator's choice SMSLogonSvc SMSSvc_sc_xxxx SMSSvc_sc_xxxx SWMAccount SMS&_dc SMSCliSvcAcct& SMSCliToknAcct& SMSClient_sc administrator's choice administrator's choice varies greatly SMSProvider_sc SMSCCMBootAcct& SMS#_dc administrator's choice administrator's choice sa (might vary) administrator's choice InfoService ABCTest

39 SMS 2.0 Security Essentials 33 Table 2.4 SMS System Accounts Overview Account Account Type Function Created automatically? Required? SMS Service (SMSService) Site server The site server services run under this account. Yes. Yes. The default account used by site server services to manage Windows NT-based site systems (that is, create shares and directories on the site systems, set directory permissions, copy files, install services, and verify that the services are running). SQL Server (sa) SQL Server Provides SMS services access to the SMS site database. SMS Site Address Site server Allows connection to another site (such as parent and child sites). Yes, by SQL Server, when SQL Server is installed. No. Yes. Yes, for parent-child sites, but SMS Service account can be used for this purpose. SMS Server Connection (SMSServer_sitecode) Server connection Provides SMS services running on remote site systems (such as logon points) access to the site server. Yes Yes Also used by the SMS Provider to gain access to SMS directories on the site server, including the PDF store. NetWare NDS Site System Connection Site system connection In NetWare environments, used by site server services for managing NetWare NDS site systems. No. Yes, for NetWare NDS site systems.

40 Part 2: The SMS Security Model 34 Table 2.4 SMS System Accounts Overview(continued) Account Account Type Function Created automatically? Required? NetWare Bindery Site System Connection Site system connection In NetWare environments, used by site server services for managing NetWare bindery site systems. No. No, but recommende d for greater security. If not specified, or not valid in the bindery, the SMS Service account is used. Windows Networking Site System Connection Site system connection Used by site server services for managing Windows NT site systems. No. No, but recommende d for greater security. If not specified, the SMS Service account is used. SMS Logon Service (SMSLogonSvc) Remote site system service The account the NT Logon Discovery Agent runs under on Windows NT logon points Yes, when you enable the Windows Networking Logon Discovery method. Yes, for Windows NT logon points SMS Remote Service (CAP) (SMSSvc_sitecode _xxxx) Remote site system service Used to run the SMS Executive service on Windows NT CAPs other than the site server Yes, when you assign the CAP role to a Windows NT site. Yes, for Windows NT CAPs not on the site server. SMS Remote Service (SQL Monitor on a separate server) (SMSSvc_sitecode _xxxx) Remote site system service Used to run the SQL Monitor when SQL Server is not on the site server. Yes, when you have SQL Server on a separate computer. Yes, for SQL Monitor on a separate server.

41 SMS 2.0 Security Essentials 35 Table 2.4 SMS System Accounts Overview(continued) Account Account Type Function Created automatically? Required? Software Metering Service (SWMAccount) Remote site system service Software metering services run under this account. Yes, when you assign the software metering role to a site system. Yes, for software metering servers Client Services (DC) (SMS&_domain_ controller_name) Client service Used to run the SMS Client Service on domain controllers. Yes. Yes. Client Services (Non-DC) (SMSCliSvcAcct&) Client service Used to run the SMS Client Service on non-domain controllers. Yes. Yes. Client User Token (SMSCliToknAcct&) Client service Used to create user tokens on client computers. Yes. Yes. SMS Client Connection (SMSClient_sitecode) Client connection Provides Windows NT computers with access to CAPs and distribution points. Yes. Yes, for Windows NT clients.

42 Part 2: The SMS Security Model 36 Table 2.4 SMS System Accounts Overview(continued) Account Account Type Function Created automatically? Required? SMS Windows NT Client Software Installation Client installation Provides a security context for certain advertised programs running on Windows NT clients. This account is recommended for use when network resources not on the distribution point must be accessed. No. No, but recommende d for greater security. If this account is not specified but a program is told to run with it the program will fail to execute. The default is to not to use this account, in which case the program will execute using either the logged on user account or the Client User Token account. SMS Client Remote Installation Client installation Can be used by Client Configuration Manager to install SMS client software on Windows NT computers. No. No, but recommende d for greater security. If not specified, the SMS Service account is used.

43 SMS 2.0 Security Essentials 37 Table 2.4 SMS System Accounts Overview(continued) Account Account Type Function Created automatically? Required? Logged on user User Might be used during client installation and other steps. Used for all purposes on computers using Windows 95 or Windows 98. SMS Provider Impersonation (SMSProvider_ sitecode) Server Connection Used by the SMS Provider to gain network access to site server resources. Used when SQL Server is not installed on the site server (the site server does not perform the site database server role). Yes, if SQL Server is not installed on the site server. Yes, if SQL Server is not installed on the site server. CCM Boot Loader (Non-DC) (SMSCCMBootAcct&) Client service Provides SMS with access to install CCM Boot Loader on non-domain controllers. Yes. Yes. CCM Boot Loader (DC) (SMS#_domain_ controller_name) Client service Provides SMS with access to install CCM Boot Loader on domain controllers. Yes. Yes. NetWare NDS Client Connection Client connection Provides NetWare NDS computers with access to Novell NetWare-based CAPs and distribution points. No. Yes, for Netware NDS clients. NetWare Bindery Client Connection Client connection Provides NetWare bindery computers with access to Novell NetWare-based CAPs and distribution points. No. Yes, for Netware Bindery clients. Software Metering SQL Server SQL Server Provides SMS services access to the software metering database. No. No. Crystal Info Reports Reporting Used to run reports. No. No, but recommende d as a best practice Crystal Info Service Reporting Used by the Crystal Info service. Yes Yes Software Metering Test Software Metering Used by Software Metering to test for administrative privileges. Then immediately deleted. Yes. Yes, but just temporarily. Although each SMS account performs specific functions, accounts can also be grouped logically, by the related functions they perform. Those account groups are discussed in the following section.

44 Part 2: The SMS Security Model 38 Site Server Accounts The site server accounts are used by the core functions of SMS sites. There are two types of SMS site server service accounts: SMS Service and SMS Site Address. The SMS Service account is required to run site services. The SMS Service account is the default account that most of the site server services use on Windows NT site systems. The following site server services use this account: SMS Executive SMS Site Component Manager SMS SQL Monitor SMS Site Backup SMS Client Configuration Manager Crystal Info for SMS (if Crystal Info for SMS is installed) If you do not create optional accounts, the SMS Service account will also be used as the Windows Networking Site System Connection account, the Windows NT Client Software Installation account, and the SMS Client Remote Installation account. In addition, you could use the SMS Service account as your SMS Site Address accounts and as your Crystal Info Reports account. However, it is best to avoid using the SMS Service account for these roles, in order to minimize security risks and to ease administration, as discussed elsewhere in this paper. The SMS Site Address accounts are used by SMS sites to connect to other sites. Server Connection Accounts These are the accounts that SMS services running on remote site systems (such as logon points) use to connect to the site server, or that the site server uses to connect to SQL Server. Specifically, these accounts are used by the following remote services: SMS NT Logon Discovery Agent Inbox Manager Assistant SMS Provider All of the SMS site server components will use the SQL Server accounts to connect to SQL Server. There are two accounts in the SMS Server Connection account group: SMS Server Connection SMS Provider Impersonation

45 SMS 2.0 Security Essentials 39 Note When setting up Systems Management Server 2.0 Service Pack 1 (or later) site servers, the SMS Server Connection account is created in the same domain as the site server. In SMS 2.0 (without the service pack), this account was created in the same domain as the SMS Service account. If an SMS 2.0 site is upgraded with Service Pack 1 (or later), the SMS Server Connection account location will be unchanged and will remain in the same domain where the SMS Service account was created for the site. This change in behavior allows SMS sites to be set up even if the administrator doing the setup does not have privileges in the master domain. Site System Connection Accounts Services that run on the site server use site system connection accounts to connect to site systems. Except for the NetWare NDS Site System Connection account, these accounts are optional. There are three site system connection accounts: NetWare NDS Site System Connection NetWare Bindery Site System Connection Windows Networking Site System Connection Site systems will use the SMS Service account if it is available. In order for the Site System Connection accounts to be used, not only must the accounts be available to the site systems, but also the SMS Service account must be unavailable. This can cause a problem if the SMS Service account does not have administrative rights on the remote site systems but can still connect to the systems. In that case, the site server would not be able to manage the systems. SQL Server Accounts SMS sites require the SQL Server account group to connect to the SMS databases. The Software Metering SQL Server account is optional, because you can choose not to use Software Metering or you can choose to use the SQL Server account in its place. You can create the Software Metering SQL Server account if you are using software metering in your site and you want to enhance security by using an account other than the SQL Server account. There are two accounts in the SQL Server account group: SQL Server Software Metering SQL Server Remote Site System Service Accounts Site system services (other than those running on the site server) run under remote site system service accounts. These accounts are created automatically when required. There are four SMS remote site system service accounts: SMS Logon Service SMS Remote Service (CAP) SMS Remote Service (SQL Monitor on separate server) Software Metering Service

46 Part 2: The SMS Security Model 40 Client Service Accounts The SMS client service accounts are used by SMS client services or client components. There are five client service accounts: Client Services DC Client Services Non-DC Client User Token CCM Boot Loader (Non-DC) CCM Boot Loader (DC) The client service accounts are all managed by SMS and have strong passwords. The accounts are created locally, and therefore these accounts are unique on each client. The exception to this occurs when the domain controllers are clients, in which case the local security database is the domain database. In this case, the accounts include the server name in the account name, in order to keep them unique. The client service account passwords are set when the client is installed. The CCM boot loader account passwords are set when the accounts are created, and the CCM boot loader accounts will be deleted when the client is successfully set up. The client service account and CCM boot loader account passwords are not recorded by SMS. The Client User Token account password is reset every time the client is rebooted, which includes changing the password to a new strong value and restoring the default permissions and rights. The Client User Token account password is not recorded by SMS, except for clients that are domain controllers, in which case the password is stored securely at a central location. Client Connection Accounts Client connection accounts allow the clients to connect to CAPs, even if no user is logged onto a client or if a user without privileges to the CAPs is logged on. SMS client connection accounts must not have any access rights to the client computer and must not be members of any groups on the client. There are three client connection accounts: SMS Client Connection NetWare NDS Client Connection NetWare Bindery Client Connection Client Installation Accounts Client installation accounts can be used to install software on Windows NT-based clients that don t have local administrative rights. There are two types of SMS client installation accounts: SMS Client Remote Installation SMS Windows NT Client Software Installation

47 SMS 2.0 Security Essentials 41 As of SMS 2.0 Service Pack 2, multiple SMS Client Remote Installation accounts can be used. If you have Windows NT clients that are not members of domains and therefore can't authenticate domain accounts, you can use accounts that are defined on the clients themselves. If you set up a standard account on each computer for administrative purposes, all with the same password, then you can define an SMS Client Remote Installation account as "%machinename%\account". Reporting Accounts There are two reporting accounts used by Crystal Info for SMS (Crystal Info): The Crystal Info Service account The Crystal Info Reports account The Crystal Info Service account is used on SMS Administrator consoles to run the Crystal Info service. The Crystal Info Reports account is used when running the reports to connect to the SMS database. An SMS administrator's account can be used in this role, but you can also create an account for this purpose. Software Metering Test Account This group has only one account: The Software Metering Test account This account is only used for internal privilege testing and is a temporary account. Access Account Lists Unlike the SMS system accounts, SMS access account lists are not used by SMS processes and they do not store passwords. Instead, these accounts list the user accounts and group accounts that have access to specific SMS objects. When you add or delete an entry from the list, you are not adding or deleting the user account or group account itself. The entries correspond to accounts that already exist, so by adding or deleting an entry, you are specifying whether an existing user account or group account has access to SMS. Table 2.5 provides a summary of the two SMS access account lists created by SMS. Table 2.5 Overview of SMS Access Account Lists SMS Access Account List Name Description Are any user or user group accounts listed by default? Are any accounts in the list required? Package Access Accounts User accounts and group accounts with access to package source files on distribution points. Yes: Administrators, Guests, and Users Yes: Administrators Remote Tools Permitted Viewers User accounts and group accounts who can remotely access Windows NT clients (note that you must also create a security right to use Remote Tools on specific collections and then assign that right to a user account or a group account). Yes: Administrators No

48 Part 2: The SMS Security Model 42 Groups SMS has two Windows NT groups that it uses for SMS-specific purposes: SMS Admins A local group that provides its members with access to the SMS Provider, through WMI. Access to the SMS Provider is required for viewing and modifying SMS security objects and data in the SMS Administrator console. By default, members of the SMS Admins group on the local computer or members of the local Administrators group have WMI access. SMSInternalCliGrp A global group created on domain controllers to contain the Client User Token account (SMSCliToknAcct&) and the Client Services DC (SMS&_dc) account. Under Windows NT security, domain accounts must be made members of a user group. The SMSInternalCliGrp user group enables the Client User Token account and the Client Services DC account to run, but it does not grant these accounts rights that they do not require. Connectivity As discussed in Part 1, "The SMS Security Environment", user accounts are used for several purposes - to log onto computers, to run processes (including services), and to connect to remote resources. By using accounts for each of these operations, computers ensure that only authorized access is given in each circumstance. In addition, the operating system has the ability to keep a log of activities performed with each account, allowing for accountability. Server Connectivity SMS servers must connect with resources (shares or WMI connections) on other computers in order to transfer data within a site or between sites, or to manage clients. Figure 2.1 illustrates the connections, and also includes the use of the service accounts. Figure 2.1 is intended to be used as a convenient reference. The numbers on the arrows and services correspond to the numbers in the list of accounts.

49 SMS 2.0 Security Essentials 43 Figure 2.1 SMS 2.0 Server Connectivity

50 Part 2: The SMS Security Model 44 Client Connectivity SMS client computers connect to SMS servers for various reasons and use accounts for different functions. The use of the accounts is discussed in detail in the previous section and is illustrated broadly in Figure 2.1. Client connections to servers are shown in more detail in Figure 2.2, which indicates the specific client agents and components that use each account.

51 SMS 2.0 Security Essentials 45 Figure SMS 2.0 Client Connectivity

52 Part 2: The SMS Security Model 46 Console Connectivity The SMS Administrator console is generally reliable and easy to start. However, it is crucial that you apply security to SMS Administrator consoles in order to ensure that only authorized staff can use them. The SMS Administrator console is perhaps the easiest path for destructive input to SMS. In addition, if it does not start successfully for authorized staff, troubleshooting can be difficult because the means by which the console connects to the SMS site database is not obvious. Figure 2.3 shows how the SMS Administrator console connects to the SMS site database. There are three scenarios to be considered, depending on whether SQL Server is running on the SMS site server, and, if not, whether SMS Provider is running on same server as the SQL Server or the site server. Specifically, the three scenarios are: 5. SMS and SQL Server on the same server 6. SMS and SQL Server on separate servers, with the SMS Provider on the SMS server 7. SMS and SQL Server on separate servers, with the SMS Provider on the SQL Server server In all cases, the SMS Administrator console must be directed to the site server, and the site server has data in WMI that the SMS Administrator console uses to find the SMS Provider. Figure 2.3 shows that the SMS Administrator console must pass the following security checks: 1. The administrator must be able to log onto a Windows NT-based computer and be able to start the SMS Administrator console (or must be able to install it on a Windows NTbased computer and then start it). By default, this level of security is granted to everyone with a valid domain or local account on Windows NT-based workstations and to administrators on Windows NT-based servers. On SMS primary site servers, the user must have at least local administrator rights in order to access the console files, which are in the SMS directory tree. 2. The SMS Administrator console must be able to connect to the SMS site server, passing Windows NT networking, RPC, and DCOM security. By default, this level of security is granted to everyone. The console will be connecting by using the console user's credentials. 3. The SMS Administrator console must be able to connect to the SMS classes in WMI on the SMS site server. This connection is usually made possible by giving the user membership in the SMS Admins group, which has WMI access granted when SMS is setup (confirmed by using the WBEM Permission Editor (Wbemperm.exe). Membership in the local Administrator's group will also allow the account to connect to WMI. On computers running Windows 2000, WMI Control would be used instead of the WBEM Permission Editor. 4. If SMS Provider is on a separate SQL Server, then steps 2 and 3 must be possible on that server as well. 5. SMS object security rights must be available to the administrator. These are SMS-specific security rights that allow the user to view or manipulate SMS objects, such as collections, advertisements, and site settings. 6. SMS Provider must be able to connect to the SQL Server database. Usually this connection is in place already. If SMS Provider is on the SMS site server, then SMS Provider will also have to pass Windows NT security. This access is provided using the SMS Service account for the network connectivity, and the SQL Server account for the SQL Server connectivity. For this step to be successful, SQL Server must be running properly.

53 SMS 2.0 Security Essentials 47 Figure 2.3 SMS Administrator Console Connectivity

54 Part 2: The SMS Security Model 48 Feature-Level Security The SMS 2.0 Administrator's Guide and the SMS 2.0 Resource Guide discuss using SMS features and the significant security issues related to them. In addition, SMS Help contains detailed instructions on how to work with SMS feature-level security, including an overview of security rights and configuration. This section discusses additional security details for the SMS features. SMS Administrator Console Security SMS object security, as discussed earlier in the section "SMS Object Security", is central to SMS Administrator console security. The only additional security issue is that anyone using the SMS Administrator console must be able to access the files on which the console is based. These files are kept in the SMS directory tree on SMS site servers, and that directory tree is secured so that only users with administrator-level privileges can access it. In order to avoid giving SMS Administrator console users this level of privilege, they should use the console on computers other than the site server, where the files are kept in a nonsecured directory. The "SMS Administrator Console Connectivity" section earlier this document discusses how the SMS Administrator console connects to the relevant SMS servers. Part 5, "SMS Security Troubleshooting", includes a section on troubleshooting console connectivity. SMS Reporting Security Chapter 19, "Creating Administrative Reports", of the SMS 2.0 Administrator's Guide contains information about using Crystal Info for SMS for SMS reporting. It includes details for running sample and custom reports. There are a few key security details to remember when using Crystal Info for SMS: The service account being used to run Crystal Info on the site server (typically the SMS Service account) must be able to impersonate the Crystal Info Report account (typically an SMS administrator account) on the computer running SMS Provider. (See the "Impersonation" section in this document for information about impersonation for more information.) Typically, SMS Provider runs on the SMS site server, but it might be on the computer running SQL Server (if SQL Server is not on the site server and you chose to put the SMS Provider on the SQL Server server). In order to do the impersonation, the service account must have the Act as the operating system right, and it must have that right on the computer that has SMS Provider. Part 4 of this document "Planning, Implementing, and Using SMS Security" includes a detailed procedure for ensuring that these settings are correct. The Act as the operating system right is not necessary when the SMS Service account itself is used as the Crystal Info Report account (which is specified on the Account tab when you schedule each report using the Schedule Report dialog box). However, using the service account in this way is not encouraged, because it requires giving the password out to all who run reports. Using any account this widely complicates the account s password change cycle.

55 SMS 2.0 Security Essentials 49 The Crystal Info Report account must have rights to SMS data. You can do this by using the techniques discussed in the previous section. Log on with the report account and use the SMS Administrator console to verify that report account has been set up properly. The Crystal Info Service and Crystal Info Report accounts are not reset by a site reset. The Crystal Info for SMS services on the site server will use the SMS Service account by default, and the SMS Service account is often used as the Crystal Info Report account (because it has all the necessary privileges), but these reporting roles are not considered core account roles for the SMS Service account. Therefore, site reset does not reset the reports' details of the SMS Service account. You must reset the details manually. To avoid the need to reset the details manually when changing the SMS Service account password, use other accounts for these roles. When you use Crystal Info for SMS on a computer other than a site server, the InfoSentinel service is run using an automatically created SMS account with a user name of InfoService. As with all accounts created automatically by SMS, this account has a strong password and no maintenance is necessary for this account. If the SMS Provider is run on the site server, and Crystal Info is also run on the site server, then all reports are run using the Info APS service account, which by default is the SMS Service account. Any account specified on the Accounts tab of the Schedule Reports dialog box is not used. Because of this, users without rights to SMS objects can generate reports on those objects. To avoid this problem, do not install Crystal Info on the site server. Only install Crystal Info on SMS Administrator consoles. By default, the Crystal Info services on a site server (Info Agent, Info Sentinel, and InfoAPS), are installed to run using the SMS Service account. If a different account is used to run these services, the account must have the Log on as a service and Act as part of the operating system rights, and must be a member of the Domain Administrators group. You can use other reporting systems for SMS. Any system that is based on the WMI open database connectivity (ODBC) driver uses the same type of security that the SMS Administrator console uses. The considerations and procedures that apply to SMS Administrator console security also apply to other kinds of reporting. Reporting based on direct access to SQL Server uses SQL Server security. Note that this does not include SMS object security. Details and procedures for taking advantage of SMS reporting security are discussed in Part 4, "Planning, Implementing, and Using SMS Security", of this document. Remote Tools Security Remote Tools have two levels of security the collection level and the Permitted Viewers list level. The collection level allows flexible enforcement of remote control security so that you can tailor it to your needs. The Permitted Viewers list is a secondary level of security that provides a final check before you permit someone to remotely control a client. The following information clarifies some points about remote control security: The Permitted Viewers list is intentionally ambiguous because it is checked at the client, and the site server might not have the same domains available as the client. However, the list must be clear at the client. Therefore, it is appropriate to include a domain name, unless ambiguity is intended (such as if any member of the local "Administrators" groups must always be allowed to remotely control each client).

56 Part 2: The SMS Security Model 50 The permitted viewers are resolved to SIDs when the remote control agent is started on the client. The names are resolved to local accounts, if appropriate, then domain accounts for the domain on which the client computer is installed, and finally for trusted domains of the client's domain. Groups are considered to be accounts, for this purpose, so they are resolved in the same way as user accounts. Members of global groups that are members of local groups listed in the Permitted Viewers list are not enumerated, and thus members of global groups are not permitted viewers unless they are otherwise permitted viewers. As an example, if a user is a member the Domain Administrator's group, and the Domain Administrator's group is included in the local Administrator's group, the user will not be able to control the client unless the user s account or group is specifically included in the permitted user list. For this reason, if you want all domain administrators to have remote control of clients, be sure you specifically include the Domain Administrators group in the Permitted Viewers list, rather than rely on its inclusion in the local Administrator's group. If you want anyone to be able to remotely control the clients, then an asterisk ("*") can be specified in the Permitted Viewers list. Local administrator rights are not required for a user to be able to use Remote Tools. If the collection and Permitted Viewers list security is met, the Remote Tools user can use Remote Tools on the client. The SMS 2.0 Administrator's Guide erroneously states that local administrator privileges are required. You can control Windows NT remote tool security settings by manipulating appropriate registry entries and stopping and restarting the SMS Remote Control Agent. For complete control of Remote Tools security, it is important to ensure that remote registry editing and remote service control are properly secured. Refer to Windows NT documentation for details on these Windows NT issues. Entries are written to the Windows NT event log on the client computer when a Windows NT Remote Tools session is started and completed. When initiating a remote control session, if the client cannot authenticate the account that is attempting the remote control, either as an account or as a valid entry in the Permitted Viewers list, then the connection is rejected. For example, a client might not be able to authenticate the account when the remote control user is from a nontrusted domain. However, a dialog box will be displayed, allowing the administrator to enter credentials (user name, password, domain (or the local computer name). If those credentials can be resolved as valid, then the administrator will be allowed to remotely control the client. There is a two-minute time-out during which administrators who are attempting to use Remote Tools do not need permission from the end-user to perform additional Remote Tools tasks. If one administrator ends the sessions with the client, another administrator could start a session within this time-out and would not require permission from the user, even if the policy is set to ask permission from the user. However, the administrator must still pass the collection-level security and Permitted Viewer list security on the client computer.

57 SMS 2.0 Security Essentials 51 When programs are started on client computers with the Remote Execute functionality of SMS Remote Tools, the programs run in the security context of the administrator remotely initiating the programs, not in the context of the user who is logged on at the time. If the administrator has administrative privileges on the client computer, then the user can use that program with administrative privileges. For instance, with User Manager, users can add users and change privileges on their computer even though typically could not do this. Similarly, the Remote Tools file transfer is done by using the privileges of the administrator who invokes the function. When you use the command-line interface to run remote control (Remote.exe), the computer specified is always resolved to a resource ID in the SMS_R_System class. SMS object security is then scanned to determine if the administrator has the right to remotely control this resource. Any differences in the ability to remotely control a computer by using Remote.exe with different parameters will depend on the ability of SMS to resolve the address supplied, rather than on differences in the application of security controls. A best practice for using Remote Tools is included in Part 4, "Planning, Implementing, and Using SMS Security", of this document. Chapter 15 of the SMS 2.0 Administrator's Guide has more information about SMS Remote Tools security. Chapter 9, "Remote Tools for the Advanced User," of the SMS 2.0 Resource Guide containsadditional details, including how to give special settings to specific computers, such as servers. Software Distribution Security Details and procedures for taking advantage of SMS software distribution security are discussed in Part 4, "Planning, Implementing, and Using SMS Security", of this document. The following discussion provides an overview of some important software distribution security concepts. Windows NT-based clients can run programs in two security contexts on the client: a loggedon user context or a service context. By default, SMS will try to install all software in the context of the logged-on user. If the user is not expected to have sufficient rights, the SMS program can be designated by the administrator as requiring administrative rights and SMS will provide sufficient rights. To access distribution points, SMS clients first look for an existing connection to the package's share on a distribution point. If they find that connection, they use it regardless of what credentials were provided. If SMS clients do not find an existing connection to the server and share, they attempt to connect using the current security context. In this case, Windows NT uses the context of any other connection made to the server. After the SMS client has tried all options for connecting to the distribution point, the client will attempt to connect to all SMS Client Connection accounts available for the site. Advertisements that are intended to run in the context of the logged-on user only have the privileges of the user, and they connect to the distribution point using the user's credentials. Advertisements that require administrator privileges run in a "pseudo-service" security context with the Client User Token account, if the user does not have administrative privileges. The Client User Token account is dynamically added to the local Administrators group as needed (and then removed when the task is completed) and has the Act as part of the operating system right.

58 Part 2: The SMS Security Model 52 The purpose of the SMS Windows NT Software Installation account is to allow a program to run on clients and to also have access to specific non-sms networks. When defining the advertising program properties, the administrator must designate that the SMS Windows NT Client Software Installation account be used for installing the package. Administrators must specify a Windows NT Software Installation Account that: has access to the necessary non-sms network resources has access to the SMS distribution point share and directories for the package is in a domain trusted by the client machine To maximize security, the SMS Windows NT Client Software Installation account must not be granted any rights on client machines, either directly or through group membership. The SMS client components grant certain user rights and membership in the local Administrators group to the SMS Windows NT Client Software Installation account when a client runs a program that is designated as requiring administrative rights. This membership and the user rights are removed when the program finishes running. Other software distribution security points are: You cannot run the Create Package from Definition Wizard if you do not have modify rights for the Sites class. The Software Distribution Wizard will not work with restricted security. Advertise rights for the Collections object is required. Status Subsystem Security To view SMS status information, you must have the read SMS security right to the Sites and Status Message objects in SMS object security. Query Security When you run queries, you must have Object rights on the objects included in the query. In addition, when you create a query, Values on the Criteria tab of the Query Statement Properties dialog box returns no data if you do not have Read and Read Resource rights to the Collections class. Network Monitor Security In unscrupulous hands, Network Monitor s powerful functionality could be dangerous. Consider carefully when to use Network Monitor in your system, where to install it, and who will have access to it. Even if you decide not to take advantage of the troubleshooting features of Network Monitor, consider installing it on a computer in each of your subnets. The new Monitor Control Tool that ships with Network Monitor 2.0 includes the Security Monitor, which you can use to watch for unauthorized data-capture activity. You can specify the MAC address of computers whose network data you want to capture, and you can force unauthorized instances of Network Monitor 2.0 to stop a data capture. You can also run other monitors to detect potential security risks, such as frames that originated outside of your network (events that might signify an Internet break-in attempt) or half-open connections on your Web servers.

59 SMS 2.0 Security Essentials 53 SMS Installer Security SMS Installer allows you to create packages for installing software or files, or for making other system changes. SMS Installer-based packages can be very powerful, but they also introduce some security concerns: SMS Installer scripts are compiled before they are distributed, and when compiled are almost impossible for people to read.for this reason, administrators sometimes include passwords for administrative accounts or include other sensitive details in their scripts. In order to facilitate migrating SMS Installer scripts to Windows Installer (a Windows 2000 feature), Microsoft has released a utility called the Installer Step-Up Utility (ISU). This utility allows a user to extract a compiled SMS Installer package, recreate the original script and data files, and then convert the script to produce a Windows Installer script. During the process, account passwords and other details can be revealed to the user. Also, because SMS Installer packages do not encrypt text values when they are compiled, passwords and similar details can be viewed even without ISU. Passwords (and accounts) would typically be put in scripts for services that are created as part of a package and for auto-logon after a reboot that occurs in the middle of a package installation. Another SMS Installer script issue is that you might not always want users to know everything that is occurring during an installation. For instance, confidential information (such as the name of the payroll server, for instance) might be hidden in obscure registry entries or hidden files. If users can read the script, they can find out where confidential information is stored or even access the information directly, and then concentrate a security attack at a specific target. Another risk is that administrators other than yourself will extract a script, change details, and then recompile the script with unauthorized changes. These changes could constitute a Trojan horse attack, or they could compromise security. For instance, if an administrator did not agree with an anti-virus package that someone had compiled with aggressive security settings, that administrator could easily reduce the settings to be less secure. The original administrators and corporate management, would be confident that strong security was in place, when in fact security has been weakened. These risks also exist for your original copies of the SMS Installer scripts, unless you have taken measures to secure the locations of the scripts. Because SMS Installer was not intended to be secure, there are no simple methods to avoid these risks. The only solutionis to encrypt the relevant details securely, and possibly to use other techniques for security, such as using C programs instead.

60 Part 2: The SMS Security Model 54 Software Metering Security Software metering servers will interrogate domain controllers to get user group membership details. When software metering servers are set up with the default Software Metering Service account, the interrogation will fail unless the software metering server is a domain controller, because the Software Metering Service account is created as local administrator account only. In order to avoid this problem, the Software Metering Service account must be made a member of the Domain Administrators global group in the account domain, using User Manager for Domains. If company policies do not allow you to create an account in the account domain, then let the domain administrators enter the account name and password in the SMS Administrator console. Use the SMS Administrator console to change the Software Metering Service account password, not User Manager. The SMS Administrator console changes the password value for both SMS and the domain. If there is more than one software metering server at your site, change the password on the Software Metering Service account by cycling the account. First, copy the current Software Metering Service account to a new account, using a different name (such as SWMAccount2), and set a new password on that account. The Software Metering Service account name and password can then be changed in the SMS Administrator console. After sufficient time has passed for all the software metering servers to receive the new account details, the original account can then be deleted from the domain, using User Manager for Domains. Site and Domain Models Windows NT domain models can complicate SMS security. Organizations use domains in a variety of ways, and SMS is usually deployed on all computers, and thus, on all domains. SMS is flexible and works with the various domain models, but it might not be obvious how to configure SMS in each domain configuration. This section discusses the issues that the various domain models raise for SMS. Specific solutions and relevant practices are included in Part 4, "Planning, Implementing, and Using SMS Security," of this document. It is critical to understand both how accounts work at a low level and how domain models work, in order to understand the domain-related issues. Part 1, "The SMS Security Environment", of this document discusses those concepts.

61 SMS 2.0 Security Essentials 55 SMS Domain Issues This section outlines SMS issues in relation to domains and provides some common scenarios. These examples are offered to help you understand the important issues so that you can design a successful architecture. There are a limited number of models for deploying Windows NT domains, but SMS can be deployed in each model in a variety of ways. This leads to many different combinations of SMS domain models, each with a different set of SMS domain issues. For this reason, it can be difficult to outline SMS security solutions for all domain models. However, the same issues occur repeatedly, and with a good understanding of the SMS security model, you can address the issues effectively. The complications that domain models raise for SMS are as follows: Are user accounts, client computers, or SMS servers in the same or separate domains? Any possible combination of accounts, computers, and servers can be used in any of the domains. In the simplest situation, user accounts, client computers, and servers are all in the same domain. But in some scenarios it is desirable to have user accounts in an account domain, client computers in a resource domain, and servers in another resource domain, or variations on this combination. Are different domains used at each site? Or the same account domain might be used across all the sites the organization is located in, but each site has its own resource domain. What are the implications of domains that span sites? The option of putting the SMS logon points in the account domain or keeping them in a resource domain (possibly in a resource domain exclusively for SMS servers). How can SMS enumerate users and user groups if an SMS site server is not in the account domain? Whether the domains have trusts among them, if applicable. If not, then pass-through authentication will be required in some circumstances. Whether the SMS accounts shall be put in the account domain or the resource domains, if applicable. Whether multiple sites are in the same domain. Whether SMS administrators have the required privileges to create accounts in the domains where they intend to place SMS servers. If it is not possible for the SMS administrators to get the necessary privileges they will have to choose another domain (such as a resource domain).

62 Part 2: The SMS Security Model 56 The single domain model introduces no complexities to SMS, because all clients, servers, and accounts are in one domain. In the single master domain model, the most common issue arises when the CAPs are in a resource domain and the site server is in the master domain. The users log on using accounts from the master domain, but by default, the CAPs in the resource domain give access only to users in the local Users group. The local Users group includes the global Domain Users group of the resource domain, but that is not adequate to give access to the users because they are members of the global Domain Users group of the account domain. The multiple-master domain model does not introduce any more known additional complexities than the single master model introduces. General SMS Domain Solutions In order for SMS to work successfully in your domain configuration, you must review the SMS accounts and how they are used for SMS connectivity (discussed in the Part 2, "The SMS Security Model"). The computer at the end of each connection must be able to find an account and authenticate it, to provide access to the computers that need to connect to it For example, all CAPs must be able to authenticate the SMS Service account, or Windows Networking Site System Connection account, if they are used. If CAPs are provided in multiple resource domains, then the account cannot exist in any single resource domain unless all resource domains trust each other, or unless non-domain authentication is used. If non-domain authentication is used, all domains must have the same user name and password for the account. Because those approaches would impose network or maintenance overhead that is unacceptable to most administrators, the most appropriate solution is to ensure the SMS Service or connection account is in an account domain that all resource domains trust. SMS Security Architectures To underscore the points made in the previous sections, the following sections outline some common deployment scenarios for SMS. Further implications for your SMS architecture, depending on how you implement the various domain models, are discussed in Part 4, Planning, Implementing, and Using SMS Security, of this document. These architectures serve only as examples they are not a complete list of all possible architectures. SMS in the Master Domain When both the SMS servers and SMS accounts are in the account (or master) domain, the effect is the same as using SMS in a single domain.

63 SMS 2.0 Security Essentials 57 SMS Accounts in the Master Domain The single master domain model is common for large organizations. The multiple master domain model can also be used in much the same way as the single master domain model. In these models, accounts are placed in the master domain (or domains), which might be called the account domain. The resource domains only contain computers and default domain accounts. A common domain configuration includes SMS servers located in the resource domains with the client computers. The SMS accounts, if possible, are in the account domain, to be consistent with the security model and to simplify the design of the SMS architecture. This architecture works well because all computers trust the account domain and can authenticate the accounts. The only problem, as discussed in the previous section, is that by default, the CAPs in the resource domains give access only to the resource domain users. The solution is to manually add the master domain's global Domain Users group to the CAPs local Users groups. The weakness with this architecture is that if the SMS accounts are compromised, they are compromised for all domains. SMS in a Resource Domain Some organizations might want to use resource domains to organize computers. For example, you could put accounting and engineering computers in separate resource domains. In such situations, the SMS servers might not belong in a particular domain and could all be put in a resource domain of their own. You can use this resource domain scenario if the master domain is administered by a different group than the SMS administrators, and if the company policy is that no one, other than the master domain administrators, can have privileges in that master domain. This scenario works as long as you include the master domain Domain Users group in the local Users group of the CAPs. This allows all users (who use accounts from the master domain) to access the CAPs, regardless of which domain their computers are in. If the master domain domain controllers cannot be used as SMS logon points, then you could put the logon points in a resource domain (or multiple resource domains). In this case, the logon scripts on the master domain can be directed to run the appropriate files from the logon points in the resource domain.

64 Part 2: The SMS Security Model 58 SMS in Multiple Resource Domains SMS allows multiple resource domains in the same site when the SMS site server is in the master domain. However, a common architecture is to have an SMS site server in a resource domain and place CAPs and distribution points in peer resource domains with client computers. This architecture introduces four additional issues: CAP and distribution point setup CAP and distribution point communication with the site server remote client installation client connections to domain controllers If you want to use the SMS Service account in multiple domains, the easiest method is to create it in the master account domain. Alternatively, the master domain administrators can create it in the master domain. If logon points are not included in the master domain, then the SMS Service account does not need administrative privileges in the master domain. However, the SMS Service account must have administrative privileges in the resource domains in which SMS servers are located; you can do this by adding it to the Domain Administrators groups in the resource domains. Another method is to create identical SMS Service accounts in the resource domains, each with the same user name, password, and group memberships. If the master domain administrators create the SMS Service account in the master domain for you because you do not have privileges in the master domain, then you could have a problem when you set up sites. By default, SMS Setup checks the SMS Service account to verify the password and to ensure that it has the correct privileges. This is not necessary in this case, so when running the SMS Setup program you should include the /NoAcctCheck switch. With the same or equivalent SMS Service accounts available in all the resource domains, the SMS site server can set up the CAPs and distribution points in the resource domains. The SMS site server can also create logon points. The same issues apply to the Windows Networking Site System Connection account. For Windows NT remote client installation, SMS uses the SMS Client Remote Installation account, if it is defined and valid at the client. If it is not defined or not valid at the client, SMS attempts to use the SMS Service account in all relevant domains. SMS first tries the SMS Service account, as defined on the site server. If that fails, SMS tries the service account without specifying a domain. If that fails, SMS then looks in each known domain to find any other domains with that service account name. SMS 2.0 Service Pack 2 allows SMS Client Connection accounts to connect to domain controllers in the domain to which client computers belong. This use of the SMS Client Connection accounts ensures that Windows NT Client Software Installation privilege verification does not cause an account lockout. To allow this use of the SMS Client Connection accounts, the domain controller in your clients domain must recognize at least one of your SMS Client Connection accounts as a valid account. If your site server is in a resource domain that is not trusted by the clients domain, then by default your clients will not have a valid client connection account for the domain controllers in your clients domain. In that case, you must create an account in a domain that is trusted by the clients domain (or create the account in the client domain itself) and then add that account to list of SMS Client Connection accounts.

65 SMS 2.0 Security Essentials 59 Users in Untrusted Domains If users log onto a domain that does not trust the domain that the site servers are in, then the accounts that are used for client access must be set up for using domain-less authentication, (the fourth step of pass-through authentication. (Pass-through authentication is discussed in Part 1 of this document.) The accounts that clients use to run services do not have this requirement for domain-less authentication because they are only used locally. The accounts that might require domain-less authentication are: User accounts The Client Remote Installation account (which also requires local administrative privileges) or the SMS Service account (if the Client Remote Installation Account isn't defined), unless the users have sufficient privileges on their computers to allow the installation of the SMS client The Client Software Installation account The Client Connection account(s). You can have multiple Client Connection accounts, so you could use one that is valid for clients in each domain to talk to CAPs in their domains. Sites in Untrusted Domains Another scenario is to have multiple untrusting domains, each with SMS site servers and their respective clients, and then set up the sites in a hierarchy. In this situation, the sites must be able to communicate with each other by using domain-less authentication.you can do this by using the SMS Site Address account that the sender is set up to use. The SMS Site Address account can be a separate account that is used for senders (or for sending only between these sites), or it can be an account also used for such purposes as the SMS Service account. In any case, that account must be set up for domain-less authentication, which means that it must have the same user name and password at both the source and the destination. Multiple Sites in a Single Domain Domains commonly span multiple physical sites, as might be the case with a company that has locations around the world and has a single domain so that users can readily move between sites. However, SMS sites must correspond directly with physical sites, so it is not unusual for a domain to be used by multiple SMS sites.

66 Part 2: The SMS Security Model 60 Site Setup You might need to specify the details for SMS accounts during site setup, for an example, when you are minimizing the number of accounts that SMS uses. The following sections describe how to specify the details for the SMS accounts when you are setting up a site. If you need to reset a site, run the setup program with the same command line as the initial installation, to manually specify the accounts. If you do not manually specify the accounts, the default server connection and client connection accounts are created. To change the password for the default server or client connection account, run the setup program with the same command line as the initial installation, this time specifying the new passwords. This installation method supports passwords no more than 14 characters long. CAUTION The initialization file, or any batch file with the command-line options, will display the passwords for these default server and client connection accounts in plain text. Therefore, it is important to restrict access to these files. The Windows NT system directory has restricted access, but you must take extra precautions if these files exist outside of that directory. Setup Command-Line Options SMS Setup has command-line options for specifying the client connection and server connection accounts. The accounts must exist and have the proper rights. When you manually specify the accounts, the setup program will not create the default server connection and client connection accounts. The syntax of the setup command is as follows: setup /ServerAccount <domain>\<account> /ServerPassword <password> /ClientAccount <domain>\<account> /ClientPassword <password> For example, when installing a site, you might want the setup program to use MyDomain\SMSServerAcct (password Elvis1) as the server connection account and MyDomain\SMSClientAcct (password Elvis2) as the client connection account. You can invoke the Setup program using the following syntax: setup /ServerAccount MyDomain\SMSServerAcct /ServerPassword Elvis1 /ClientAccount MyDomain\SMSClientAcct /ClientPassword Elvis2 However, to use the command-line arguments, you must be able to specify the setup command. Therefore, you cannot specify a created server and client connection account for remote secondary site setup, which uses a setup command that you cannot specify.

67 SMS 2.0 Security Essentials 61 Setup Initialization File Options To specify accounts for a remote secondary site setup without, you can create an initialization file called SMSAccountSetup.ini in the %Winnt%\System32 directory of the targeted secondary site server. The file lists the server and client account information in the following format: [ServerAccount] Name=SMSServer Password=Elvis1 [ClientAccount] Name=SMSClient Password=Elvis2 When the setup program is started, it reads the SMSAccountSetup.ini file from the %WINNT%\system32 directory. The accounts specified in the initialization file will be treated the same as the /ServerAccount and the /ClientAccount command-line arguments and the default server connection and client connection accounts will not be created. CAUTION On computers running Windows NT or Windows 2000, non-administrative users can, by default, read files in the System32 directory. By default they cannot log onto Windows NT or Windows 2000 servers, so the SMSAccountSetup.ini file will be secured in that way. However, if you let non-administrative users log onto SMS servers, they could read this file. To prevent this, adjust the security on this file by removing the Everyone permissions on it on Windows NT servers. On Windows 2000 servers. remove the Users and Power Users permissions on this file. Site Reset SMS site reset stops the core SMS site services, deinstalls them, and then reinstalls them. This can be done: to repair a damaged site server. to make account or password changes effective. to force the site to use a different SQL Server database name or SQL Server server, or a different SQL Server security mode. If there has been a change to the accounts used by the SMS components, site reset ensures the account details used by the SMS components are correct.

68 Part 2: The SMS Security Model 62 The exact effect of site reset depends on how the site reset is initiated and which options are selected: Site Reset From The Console Is triggered when the site accounts are updated in the SMS Administrator console from the Accounts tab in the Site Properties dialog box. This reset does not affect accounts other than the SMS Service or SQL Server account information, if changed. Hierarchy Manager deinstalls and reinstalls the Site Component Manager, and passes an updated site control file to it. The Site Component Manager then does the usual site reset deinstall and reinstall of local services that use the SMS Service account, effecting the following services: SMS_Site_Component_Manager SMS_Executive (only on the site server itself) SMS_Site_Backup SMS_SQL_Monitor (only on the site server itself) Site Reset From Setup Is triggered when the Setup option Modify or reset the current installation is selected, causing the setup wizard to run. Site reset will deinstall and reinstall all SMS services that use the SMS Service account, including those on the site server, the site's CAPs, and the SQL Server server. Thus the following services are affected: SMS_Site_Component_Manager SMS_Executive (on the site server or component servers) SMS_Site_Backup SMS_SQL_Monitor (on the site server or component server) If changes are specified when using the setup wizard, the site reset will change SMS Service, SQL Server, or Software Metering SQL Server account information stored in SMS. Also, site reset will point the site to a new database name or SQL server if this is specified in the setup wizard, or it will change the SQL Server security mode if it is changed. If no changes are specified in the setup wizard, then passwords for the component server service accounts used by Inbox Assistant and SMS SQL Monitor are automatically changed by Site Component Manager during the initial site shutdown, while setup is still running. The sequence for each component on a component server is: SMS component shutdown is completed SMS components are flagged for reinstallation SMS Remote Service account is recreated Setup shuts down the services, changes the SMS Server Connection account password, installs the Site Component Manager, and then passes it an updated site control file. With SMS 2.0 Service Pack 2, at this point in the cycle a popup is displayed allowing you to skip changing the SMS Server Connection account password. You would skip this change if account lockout is enabled and you want to avoid the risk of locking out the SMS Server Connection account. You can then choose the best time to reset the SMS Server Connection account, independent of other reset requirements.

69 SMS 2.0 Security Essentials 63 Site reset also will recreate the SMS Server Connection account if necessary, but because the new account has a different SID, it will not have the same access to the resources as the old account. Giving full permissions to the new account on the SMS directory tree will allow the SMS servers to connect to the SMS site server properly. SMS 2.0 Service Pack 2 allows a message to appear halfway through site reset indicating that SMS Setup can reset the SMS Server Connection account. If SMSAccountSetup.ini specifies passwords for the SMS Server Connection accounts, they will be used to reset the account. Otherwise a random strong password is generated for the default SMS Server Connection account (SMSServer_sc). If you have account lockout enabled, then resetting the account could result in its being locked out. This would happen if an SMS server attempts to connect to the site server before the changed password for the SMS Server Connection account is propagated to all SMS servers. Therefore, you might prefer to reset the account during a quiet period for the site rather than doing it when the message appears during reset. You should also watch the SMS Server Connection account and unlock it if it becomes locked out. Site Reset from Preinst.exe Is triggered when the command PREINST /STOPSITE is executed. This reset is very similar to the reset initiated by SMS Setup, except that the password for the SMS Server Connection account is not modified because that functionality is part of setup itself, not part of Site Component Manager. However, like the site reset initiated by running setup, passwords for the accounts used by remote Inbox Assistant services on CAPs and remote SMS_SQL_Monitor services are changed. It is important to remember that site reset does not manage the default SMS Client Connection account. The original site setup will create the SMS Client Connection account, but after that it must be managed through the SMS Administrator console, and a site reset is not required to implement any changes. Site reset also will not change any of the other site or client accounts, or set a trigger for them to be changed or updated. Most of the rest of the accounts are managed through the console. The SMS 2.0 flow charts included in the Systems Management Server 2.0 Resource Guide include some of the details for these processes. Details and procedures for using site reset are included in Part 4, Planning, Implementing, and Using SMS Security, of this paper.

70 Part 3: Novell NetWare in the SMS Security Model 64 Part 3: Novell NetWare in the SMS Security Model This part explores Novell NetWare security and how SMS works with it to extend the SMS security model in environments with Novell NetWare. Portions of this discussion are based on the technical paper available at You can refer to this paper for details about version compatibility, logon scripts, internal details of SMS support for NetWare, procedures for deploying SMS with NetWare, relevant troubleshooting procedures, and known issues. This part of the document includes: an overview of Novell binder and bindery emulation an overview of Novel Directory Services an overview of NetWare NDS rights SMS security requirements in an environment that includes Novell NetWare Novell Bindery and Bindery Emulation NetWare 3.x servers are called bindery servers. Bindery servers do not have a Directory Service that ties them all together. Each server is a stand-alone server and maintains its own database of users (the bindery). A bindery emulation server is a NetWare 4.x server emulating a bindery (3.x) server. Bindery emulation is a mode of Novell Directory Services (NDS) by which older applications that require the Bindery can communicate with Netware NDS. Novell Directory Services All NetWare 4.x servers on the same network have information about all network resources on that network because they all use the same Directory. NetWare NDS creates a single, unified network by providing a single point for accessing and managing most network resources. The Directory is composed of objects, properties, and values. The network administrator does not need to know which NetWare server provides a particular resource. Each network resource has an entry in the Directory Service with a unique name. When a user requests the resource by this unique name, any NetWare 4 server on the same network can connect the user (granted that he has rights to that resource.)

71 SMS 2.0 Security Essentials 65 NDS Objects NDS represents each network resource as an object in the Directory. An object is a unit of information about a resource, comparable to a record in a conventional database. Each NDS object consists of categories of properties (information), which can be recorded about the resource. The same types of objects have the same properties; different types of objects might or might not have the same properties. A property value is the data within a property. For example, a printer is represented as a printer object. The properties associated with the printer object include name, description, and location. The values for each of these properties for a specific printer could be Color Printer, PostScript, and Room 305, respectively. NDS objects are divided into three classes or types: root, container, and leaf. The Root Object The Root object represents the highest level in the directory tree. The Root provides access to different objects. The network administrator can grant rights to the entire directory tree from the Root. Each directory can have only one Root. The Root object is a placeholder; it contains no information. The Root object cannot be deleted, renamed or moved. Square brackets ( [] ) are mandatory when referring to this object. It must appear as [Root]. Container Objects Container objects hold, or contain, leaf or other container objects, as listed in Table 3.1. The container objects are used to logically group and organize the objects of your Directory. They can be used to represent countries, companies, departments, areas of responsibility, workgroups, or shared resources as required. Leaf Objects Leaf objects represent network resources, such as users, groups, organization roles, printers, print servers, print queues, NetWare servers, and NetWare volumes.

72 Part 3: Novell NetWare in the SMS Security Model 66 Directory Tree Structure The directory tree is the hierarchical structure that stores and organizes objects in the directory. It is composed of the Root and container objects. The directory tree structure is similar to the tree structure found in the MS-DOS file system. The top of the tree is called the Root. Container objects, analogous to directories, are placed in the Root or in other containers. Leaf objects, analogous to files, are placed within containers. The directory tree structure differs from the MS-DOS file system structure because different Novell Directory Services (NDS) container objects have restrictions on where they can be placed and what can be placed in them. Each class of container object has different rules that define what it can contain and where it can be located in the directory tree, as listed in Table 3.1. Each class has different properties. Table 3.1 Novell NetWare Container Object Location and Rules Container Object Can Exist in Can Contain Example Country Root Organization Alias Organization Root Organization Unit Country All leaf objects Organization Unit Organization Organization Unit Organization Unit All leaf objects US FR Microsoft UCLA Accounting ITG The rules limiting what a container can hold and where it can be held force specific directory tree structures. Table 3.2 illustrates these rules with three possible directory tree structures. Table 3.2 Novell NetWare Container Object Rule Examples Root Organization Leaf Objects Root Organization Organization Unit Leaf Objects Root Country Organization Organization Unit Leaf Objects

73 SMS 2.0 Security Essentials 67 Accessing NDS To access a network resource, such as a network printer, the user must request the object by its NDS object name. NDS (or more specifically whichever NetWare server responds to the request) locates the requested object in the directory. It also checks the directory to verify that the user is a valid user and has rights (permissions) to use the object. Based on the property values in the object, NDS locates and connects you with the resource. A multiple-container Directory tree (as opposed to a single container Bindery system) probably has the greatest impact on how network resources are accessed for the following reasons: Objects are not in a single container. NDS does not search the entire Directory tree to find an object. NDS requires precise information to find the correct object. You, or your workstation, must provide NDS with the correct object name so it can locate the object in the Directory tree. You can provide this information using either of the following: Distinguished name Relative distinguished name To understand the difference between distinguished name and relative distinguished name, you must be familiar with the terminology associated with the naming objects. The following subsections explain NDS object-naming terminology. Common Name A leaf object s common name is the name shown next to the leaf object in the Directory tree. A common name is a local name for the object. It does not contain any position information. Context Context is an object s position in the Directory tree. It is a list of the container objects leading from the object to the Root. (Locating an object through context is similar to locating a file using the Directory path). Distinguished Name An object s distinguished name is a combination of its common name and its context. For example, in the figure above, the distinguished name for the User object JohnDoe in the Organization Unit XYX Corp in the Organization ABC is as follows:.cn=johndoe.ou=xyz.o=abc The distinguished name for the User object JohnDoe in the Organization ABC is as follows:.cn=johndoe.o=abc A distinguished name starts with a leading period. The objects in the name are separated by periods; similar to the back slash used in DOS paths. Trailing periods cannot be used in a distinguished name.

74 Part 3: Novell NetWare in the SMS Security Model 68 NetWare NDS Rights Netware NDS rights consist of directory, file, object, and property rights. Rights are granted to user objects, and give the user object access to or control of the other objects. Directory Rights Directory rights apply to the directory in the NetWare file system to which they are assigned, as well as to all files and subdirectories in that directory, unless redefined at the file or subdirectory level. Directory rights, listed in Table 3.3, are a part of the file system, and they are not assigned to NDS objects within the directory just to directories themselves. However, a user object can be granted directory rights to a directory on a volume. For example, the user object JohnDoe could be granted permissions to a specific directory on a server volume. Table 3.3 Directory Rights Right Supervisor (S) Read (R) Create (C) Write (W) Erase (E) Modify (M) File Scan (F) Access Control (A) Description Grants all rights to the directory, its files, and subdirectories. Users with this right can grant other users rights to the Directory, its files, and subdirectories. Grants the right to open files in the directory and read the contents or run the programs. Grants the right to create new files and subdirectories in the directory. If Create is the only right granted to a user for the directory, and no other rights are granted below the directory, a drop box directory is created. In a drop box directory, you can create a file and write to it. After the file is closed, however, only a user with more rights than Create can see or update the file. You can copy files or subdirectories into the directory and take over ownership of them, but other users' rights are revoked. Grants the right to open and change the contents of files in the directory. Grants the right to delete the directory, its files, and subdirectories. Grants the right to change the attributes or name of the directory and of its files and subdirectories, but does not grant the right to change the contents of the directories, files, and subdirectories. (Changing the contents requires the Write right.) Grants the right to list the directory and its files with the DIR or NDIR directory commands. Grants the right to change the user assignments and the Inherited Rights Filter of the directory and of its files and subdirectories.

75 SMS 2.0 Security Essentials 69 File Rights File rights, listed in Table 3.4, apply only to the file they are assigned to. A trustee can also inherit rights to a file from the Directory above the file. Table 3.4 File Rights Right Description Supervisor (S) Grants all rights to the file. The Supervisor file right can not be blocked with an Inherited Rights Filter. Users who have this right can also grant other users any rights to the file and can change the file's Inherited Rights Filter. Read (R) Create (C) Write (W) Erase (E) Modify (M) File Scan (F) Access Control (A) Grants the right to open and read the file. Grants the right to create a file and to recover a file after it has been deleted. Grants the right to open and write to an existing file. Grants the right to erase (delete) the file. Grants the right to change the attributes and name of the file, but does not grant the right to change its contents. (Changing the contents requires the Write right.) Grants the right to see the file with the NDIR Directory command, including the Directory structure from that file to the root Directory. Grants the right to change the trustee assignments and the Inherited Rights Filter of the file.

76 Part 3: Novell NetWare in the SMS Security Model 70 Object Rights Object rights, listed in Table 3.5, apply to NDS objects. Object rights do not affect the properties of an object (see Property Rights later in this section). A trustee can inherit rights to an object from the object above it. Table 3.5 Object Rights Right Supervisor (S) Browse (B) Create (C) Delete (D) Rename (R) Description Grants all access rights. A trustee with the Supervisor object right also has unrestricted access to all properties. The Supervisor object right can be blocked by an Inherited Rights Filter below the object where the Supervisor right is granted Grants the right to see this object in the directory tree. Grants the right to create a new object below this object in the Directory tree. Rights are not defined for the new object. This right is only available on container objects because noncontainer objects can't have subordinate objects. Grants the right to delete the object from the Directory tree. Objects that have subordinate objects can't be deleted (unless subordinate objects are deleted first). Grants the right to change the name of the object.

77 SMS 2.0 Security Essentials 71 Property Rights Property rights, listed in Table 3.6, apply to the properties of an NDS object. Rights can be assigned to all properties or to selected properties. Table 3.6 Property Rights Right Supervisor Read Compare Write Add or Delete Self Description Grants all rights to the property. The Supervisor property right can be blocked by an object's Inherited Rights Filter. Grants the right to read the values of the property. Compare is a subset of Read. If the Read right is given, compare operations are also allowed. Grants the right to compare any value to a value of the property. With the compare right, an operation can return True or False, but you can't see the value of the property. The Read right includes the Compare right. Grants the rights to add, change, or remove any values of the property. The Write right includes the Add or Delete Self right. Grants a trustee the right to add or remove itself as a value of the property. The trustee cannot affect any other values of the property. This right is only meaningful for properties that contain object names as values, such as group membership lists or mailing lists. The Write right includes Add or Delete Self. SMS Security Requirements Novell NetWare server security must be set up with specific rights and must use specific accounts in order for SMS to work successfully with Novell NetWare servers. Rights Granted to Client Access Points, Distribution Points, and Logon Points Windows NT server site systems have rights granted for the local Users, Guest, and Administrators groups. Novell NetWare site systems do not have rights set using these groups but instead, are granted rights as: NDS client access points and distribution points Rights are granted to the container object in which the specified volume resides. You can create a volume alias in whichever container object the user objects reside. For NetWare NDS Logon Points The rights are granted to the container object specified for script modification. Users in the container objects to which the rights are granted inherit the necessary site system directory rights. This is done because there is no well-known system user groups on NetWare NDS like Everyone (which is all users, whether authenticated or not).

78 Part 3: Novell NetWare in the SMS Security Model 72 For NetWare bindery client access points, distribution points, and logon points Directory permissions are granted to the Everyone group. In NetWare 4.x bindery emulation, you must create the Everyone group before you create the site system in order for rights to be granted. The specific permissions provided by the general permissions (full, change, and read) are different between Windows NT and NetWare bindery and NetWare NDS servers, as listed in Table 3.7. Table 3.7 Comparison of Directory Permissions Platform Full Change Read Windows NT Administrator Read (R), Write (W), Change (X), Delete (D) Read (R), Change (X) NetWare bindery Supervisor (S), Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F), AccessControl (A) Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F) Read (R), FileScan (F) NetWare NDS Supervisor (S), Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F), AccessControl (A) Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F) Read (R), FileScan (F) The default rights for Novell NetWare-based SMS client access points are listed in Table 3.8. Table 3.8 Novell NetWare-based SMS Client Access Points Directory Windows NT Administrators Windows NT Guests Windows NT Users NetWare Bindery Everyone CAP_xxx Full Change Change Read Read NetWare NDS OU CCR.box Full Change Change Change Change Clicomp.box Full Read Read Read Read Clidata.box Full Read Read Read Read Clifiles.box Full Read Read Read Read DDR.box Full Change Change Change Change Inv.box Full Change Change Change Change Offerinfo.box Full Read Read Read Read Pkginfo.box Full Read Read Read Read Sinv.box Full Change Change Change Change Statmsgs.box Full Change Change Change Change

79 SMS 2.0 Security Essentials 73 The default rights for Novell NetWare-based SMS logon points are listed in Table 3.9. Table 3.9 Novell Netware-based SMS Logon Points Directory Windows NT Admin Windows NT Everyone Bindery Everyone NDS OU SMSLOGON Full Read Read Read CONFIG Full Read Read Read DDR.BOX Full Change Change Change SITES Full Read Read Read X86.BIN Full Read Read Read The default rights for Novell NetWare-based SMS distribution points are listed in Table Table 3.10 Novell NetWare-based SMS Distribution Point Container Objects Directory Windows NT Admin Windows NT Guest Windows NT User Bindery Everyone NDS OU SMSPKGC$ Full Read Read Read Read <package> Full Read Read Read Read Connection Accounts Connection accounts are those specific accounts that Systems Management Server Components use to communicate with Netware NDS or Netware Bindery Servers in order to configure CAPs, distribution points, and logon points. There are two types of connection accounts: site system connection accounts and client connection accounts. Site System Connection Accounts The site server communicates with other site systems through site system connection accounts. A site system connection account is a Windows NT or NetWare user account that the site servers use to communicate with site systems. The type of site system (Windows NT, NetWare 3.x or NetWare 4.x) determines how SMS connects from the site server to the site system. SMS supports only one site-system connection account to each NetWare NDS tree per SMS site. It is possible to add multiple NDS site-system connection accounts. However, SMS only attempts to use the first NDS site-system connection account that matches the tree name specified in the site system configuration dialog boxes. Novell generally discourages using multiple trees in a single organization, but if this configuration does exist, SMS allows a single site-system connection account per tree. When you create an NDS user account that will be used as the site-system connection account, you must assign appropriate permissions to the user account by using the NWAdmin or Netadmin utilities provided with NetWare. For more information about using these Novell utilities, refer to the Novell product documentation.

80 Part 3: Novell NetWare in the SMS Security Model 74 You can create an NDS User account that has the Security Equal to property set to the Admin user of your tree. This is the simplest method, because the Admin user has full rights to all objects of the NDS tree. If this is not feasible or if you do not want to do this for security reasons, you can assign the individual rights required by a site-system connection account: The account specified must be a trustee and have Read, Write, Create, Erase, Modify, File Scan and Access Control rights to the Root directory on volumes that are to be CAPs, logon points, or distribution points. The specified account must have Read and Write rights to the Login Script property of all container objects specified in NetWare NDS Client Logon Installation and NetWare NDS Client Logon Discovery. This security configuration is unnecessary unless you choose to have SMS automatically modify any container login scripts. The specified account must be able to assign file and directory rights to the parent container object of each volume that is to be a CAP and a distribution point. The specified account must be able to assign file and directory rights to the specified volume for each logon point and for each container object specified as a logon point. Note When you run Microsoft Windows NT 3.51 as an SMS client, you must be logged onto Windows NT and NetWare NDS with a single account that has whatever rights the client connection account requires. NetWare NDS Site Systems If the site system is a NetWare NDS volume, SMS attempts to connect to it using the following methods: 1. If a service connection to the NDS system exists, SMS attempts to use it. The SMS service ignores any user connections and only uses an existing connection that has been established by another SMS service. Only existing service connections created by SMS_Executive components from the same site server are recognized. 2. If the credentials of the existing connection are insufficient (for example, if the account does not have permission to create or delete files on the site system), then no other connections are attempted using any site system s accounts. A credentials conflict results when another component of the SMS_Executive tries to connect to the same resource with a different account. 3. If no connection to the NetWare NDS system exists, the SMS service attempts to connect using a NetWare NDS site system connection account. There can only be one NDS site system connection account per tree, per site server. It must have the required permissions to all NDS site systems specified by that site. 4. If the NDS Site System connection account has a tree name that does not match the tree name specified for the site system that is being created or updated, SMS attempts to use the next site system connection account in the NDS site system connection accounts list until it finds one with the same tree name. 5. If all of these attempts fail, SMS makes no further connection attempts, and the connection process fails. Use the SMS Status Manager to obtain more information about the connection failure.

81 SMS 2.0 Security Essentials 75 NetWare Bindery Site Systems If the site system is a NetWare bindery server, Systems Management Server attempts to connect to it using the following methods: 1. If a service connection to the bindery server exists, SMS attempts to use that connection. The SMS service ignores any user connections and uses only an existing service connection established by another SMS service. 2. If the account credentials are insufficient, (for example, if the account does not have Supervisor permissions to the bindery server), no further attempts are made. 3. If a connection to the bindery system does not exist, the SMS service attempts to connect through a NetWare bindery site system connection account. There can only be one site system connection account per bindery server, per site server. This account must have adequate permissions to all site systems specified on a bindery server by a particular site. There can be multiple bindery site system connection accounts but only one per Bindery server. 4. If the attempts to connect using the site system connection accounts fail or if there are no site system connection accounts, the connection is attempted with the SMS Service account. 5. If all of these attempts fail, SMS makes no further connection attempts, and the connection process fails. View the Status Manager for more information about the connection failure. Client Connection Accounts A Windows NT client connection account is a Windows NT or NetWare user account that Systems Management Server client services can use to contact client access points and distribution points. The type of site system determines how SMS attempts to connect from the client to the site system. NetWare NDS Site Systems If the client is running Windows NT, and if the site system is a NetWare NDS server, SMS attempts to connect to the site system using the following methods: 1. If a service connection to the NDS system exists, SMS attempts to use the connection. Only existing connections from the SMS client service are used. 2. If a connection to the NDS system does not exist or if the existing connection s account has insufficient permissions, no further connection attempt is made. A credentials conflict results if SMS tries to use another account to connect to the resource. 3. If SMS fails to connect with the NetWare NDS client connection accounts, it attempts to connect using the SMS Client User Token account. 4. If these attempts fail, SMS makes no further connection attempts, and the connection process fails. If the client is running an operating system other than Windows NT, SMS attempts to connect to the site system through the account of the user who is currently logged on. If this attempt fails, SMS makes no further connection attempts, and the connection process fails.

82 Part 3: Novell NetWare in the SMS Security Model 76 NetWare Bindery Site Systems If the client is running Windows NT, and if the site system is a NetWare bindery system, SMS attempts to connect using the following methods: 1. If a service connection to the bindery system exists, Systems Management Server attempts to use that connection. 2. If there is no service connection to the bindery system, or if the existing connection s account has insufficient permissions, the SMS client service attempts to connect through the NetWare bindery client connection accounts. If more than one of these accounts exists, and if the permissions of one account are insufficient, SMS attempts to connect through the other accounts. 3. If the attempts to connect through the NetWare bindery client connection accounts fail, SMS attempts to connect to the account that the SMS client service runs under. This account is created automatically when the SMS client software is installed on the client. 4. If all of these attempts fail, SMS makes no further connection attempts, and the connection process fails. If the client is running an operating system other than Windows NT, SMS attempts to connect to the site system using the account of the user who is currently logged on. If this attempt fails, SMS makes no further connection attempts, and the connection process fails.

83 SMS 2.0 Security Essentials 77 Part 4: Planning, Implementing, and Using SMS Security This part of the paper builds on your understanding of the SMS security model and its security environment by considering specific practices and procedures that maximize security and help you avoid security-related problems, such as account lockouts. This part includes: planning and implementation considerations SMS account considerations SMS security best practices standard procedures for effective management of SMS security Planning and Implementation Considerations Before you implement Systems Management Server, it is recommended that you do an indepth analysis of your environment and determine how you will use SMS. Give particular consideration to issues that could affect security. This includes analyzing the security risks that might be relevant to SMS, and assessing the organizational and technical environment that SMS will run in. Organizational Issues The following organizational issues set some of the context for your SMS security planning. Analyze your environment in relation to each of these issues and document the results for discussion and future reference. Domain model Which domain model is your organization using or planning to use? What are the specific details of the domain implementation, especially in terms of the number of domain controllers and the network links that connect them? Configuration of SQL Server, WMI, DCOM, and NetWare security Which security options are you using for each of these technologies, beyond the default options?, What specific configuration settings are applied? Location of SMS site servers Are your SMS site servers located on domain controllers or on member servers? Do they have fast and reliable network links to the domain controllers? Client lockdown level Are your client computers locked down so that end-users cannot adjust their configuration or access files in specific directories? What are the specific details of your organization s lock down policy for clients? Account policies Are user accounts locked out if too many incorrect passwords are tried? Must the passwords be changed on a regular basis? There are several account policy options available, and many can be relevant to SMS security, as will be discussed later in thissection.

84 Part 4: Planning, Implementing, and Using SMS Security 78 Simplicity How important is simplicity to your organization? It is preferable to keep computer operation and support costs low, and to minimize the challenges presented to your technical staff. Yet strong security can add complexity and additional work. You will have to develop a satisfactory compromise between simplicity and strong security. Sensitivity to risk How important is it to your organization that security not be breached? Sensitivity to risk can be influenced by a variety of factors, such as dependence on computers, the nature of the data being stored, and the general corporate culture. Nature of risks You need to become familiar with the nature of potential risks to your organization and their possible source. Will security attacks come over the network? Will they be sophisticated? Persistent? And when would they be most likely to occur? Control of accounts Do corporate policies require that passwords be changed on all accounts on a regular basis, or are other account details predetermined? Are there any exceptions? Recovery What approach will your organization take if SMS must be rebuilt due to hard disk failure or other failures? Will you restore SMS from backups, or will you rebuild the site? Administrator organization How are the computer administrators organized? Are they centrally organized, with a common reporting structure, or are there groups of administrators located throughout the organization who might have different work methods? These factors canl affect where you place SMS site servers and accounts and whether you have to secure SMS against other administrators or not. General SMS Security Planning You must consider the following issues in detail in order to ensure that your implementation includes all steps that might be required for a successful deployment. The following sections discuss these issues in depth. Domain model Where will the SMS computers and accounts be located? Account management Which SMS security account will you use and how will you use it? This issue will be dependent on your need for security, but it will be tempered by your need for simplicity. Pass-through security In some environments it might be necessary to use account pass-through security with SMS. Policies and procedures As discussed in Part 1, "The SMS Security Environment," SMS security policies and procedures must be formalized. The best practices and standard procedures presented in this paper are a good starting point for these policies and procedures.

85 SMS 2.0 Security Essentials 79 SMS Accounts in the Typical Domain Models The domain model you use is central to SMS security planning, and affects the possibilities available for placement of the SMS accounts. This section lists the three domain models that are typically seen in larger organizations, and the considerations involved in the placement of the client accounts and the site system accounts. The three domain models to be considered are: Single domain model Master domain model Multiple master domain model After an SMS server is installed in a domain, it cannot be moved to a different domain without first deinstalling it from the original domain and reinstalling it in the new domain. For this reason, your security planning must be completed before implementing any SMS servers. In the following sections, it is assumed that the Domain Admins global group is a member of the local Administrators group and that the Domain Users global group is a member of the local Users group. Single Domain Model or SMS in the Master Domain SMS security must be set up correctly in a Windows NT single domain (SD) by default. Figure 4.1 shows SMS in the single domain model. When SMS site servers and accounts are put in the master domain of the master domain model, SMS behaves the same as the single domain model. The only additional step is to add the Domain Admins groups of the master domain to the local Administrators groups of the computers in the resource domain (which is commonly done when setting up computers in a resource domain). This will allow clients to be remotely installed, if necessary. Figure 4.1 SMS in the single domain model

86 Part 4: Planning, Implementing, and Using SMS Security 80 Client Accounts Users must be able to access the CAPs. When a low rights user is logged on to a client computer running Windows NT, a Client Configuration Request (CCR) is created. The client computer uses the logged-on user s context to connect to the CAP so it can write the CCR to the Ccr.box directory. By default, the User and Guest accounts both have Change rights to this directory. The SMSClient_sc account must have CHANGE access to the CAP share and its directories. By default, the User and Guest accounts have Change rights to both the CAP Share and NTFS permissions on Domain Controllers and member servers. Site Systems Accounts The SMS Service or the SMS Client Remote Installation account must have access to the ADMIN$ share on the client computer running Windows NT. When a low rights user is logged on, the Client Configuration Manager (CCM) on the site server must connect to the client s ADMIN$ share to copy files and to create and start SMS client accounts. The Client Configuration Manager uses one of the following accounts to connect: The SMS Client Remote Installation account If this account has been created, it is used first when attempting to connect to the ADMIN$ share on the client computer running Windows NT. This account must have local administrator rights on the client, which can be done by adding the account to the SD\Domain Admins global group. The domain administrators group is in the local Administrators group on the client by default. Otherwise, the account can be directly added to the client s local Administrators group.

87 SMS 2.0 Security Essentials 81 The SMS Service account This account must have administrator rights on the client. By default this account is a member of the SD\Domain Admins group, which is in the local Administrators group on the client. The SMSServer_sc account connects to the site server to copy files from the remote site system inboxes to the inboxes on the site server. By default the SMSServer_sc account has access to the site server. SMS in a Resource Domain SMS security is set up by default in the master domain (MD), but must be configured for the resource domain (RD). Figure 4.2 shows SMS in the master domain model, with the SMS accounts in the master domain. Figure 4.2 SMS in the single domain model with accounts in the master domain. Client Accounts The logged on user must have access to the CAP. When a low rights user is logged on to client computer running Windows NT, a CCR must be created. The client computer uses the logged-on user s context to connect to the CAP so it can write the CCR to the Ccr.box directory. By default, the User and Guest accounts both have Change rights to this directory. The MD\Domain Users group must be added to the local Users group in the resource domain and to the local Users group on every CAP installed on a member server in the resource domain for users logging into the account domain (such as ClientA in Figure 4.2) to access the CAPs in the resource domain. Users logging onto the resource domain (as ClientB might do) cannot access CAPs in the master domain unless the Guest account is enabled.