Do you find the Support WebCast transcripts helpful?
Let us know!

Note: This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Barbara Lamkin: Hello and welcome to the Microsoft Support WebCast. We'd like to thank all of you for joining us today. Our topic will be "The Systems Management Server 2.0 Security Model." Our presenter will be Wally Mead. I'm Barbara Lamkin, and I'll be your host for today's session.

We will start the session with Wally's presentation and follow that up with a question-and-answer period when the presentation is finished. We do only answer questions submitted during the live broadcast.

The Q&A portion of Support WebCast is intended to encourage further discussion of the Support WebCast topic. However, one-on-one product support issues are outside the scope of what we are able to address during the Support WebCast. If you need technical assistance, please submit an incident on the Web or call Microsoft Product Support Services and speak to a support professional.

I would like to now take a moment to introduce Wally. Wally Mead is a Program Manager in the SMS products group, specializing in SMS training for the SMS JDP program. Wally has been with Microsoft for over eight years in the training group, PSS, and now in the product group. He began working with SMS prior to the version 1.0 release in 1994. Thank you for joining us, Wally. Please begin.

Wally Mead: Thank you, Barb. Welcome to you all. I hope you find information that's worthwhile for you in today's session.

First off, I want to mention that some of these slides will be duplicate slides. If you've been coming to these sessions for awhile, back in January we had a session titled Systems Management Server 2.0 Security (http://support.microsoft.com/servicedesks/webcasts/wc012500/wcblurb012500.asp). Some of these slides will be a carryover from that presentation, and from last month's session on WMI and how SMS uses it (http://support.microsoft.com/servicedesks/webcasts/wc092600/wcblurb092600.asp). However, this will be primarily new information for you on the SMS 2.0 security model, tying in some of those previous slides.

On our agenda for today (slide 2), what we want to cover is, first off, an overview of SMS 2.0 security concepts. What are some of the prerequisites you need to know before you can successfully administer and support an SMS site, as far as the security model goes? Then we'll talk about the different levels of SMS 2.0 security. What are the different aspects of the security process for SMS? Then we'll talk a little bit about configuring SMS 2.0 security. Finally, we'll finish up with a discussion of some of the security features. Features in this context means why some things are required that aren't necessarily self-explanatory. Why do you have to have certain rights in the SMS Administrator console to perform certain functions? We'll look at some of those.

First off, let's go over a security overview (slide 3). You've heard me say this in other presentations as well: desktop management systems are very complex and very powerful. Because of that fact, it's very important for you, the administrator, to have a good security system in place. SMS, as one of those desktop management systems, being very complex and powerful, does touch a lot of your network infrastructure. Because of the fact that SMS does involve so much of your network infrastructure, it's important that you understand its security system, and the related security systems that SMS relies on, to be able to effectively manage the system.

You, as an administrator, must go through a balancing act to determine how much time you want to put into the SMS security system, as opposed to your need to improve the security system, or to increase the level of security that SMS 2.0 provides by default. SMS 2.0, by default, ships in what we call a minimum-security mode. It's the default mode of SMS.

In this mode, SMS provides minimum security. We do things such as create security rights for the user who installed SMS when you installed your site server. That one user or administrator is the only person who's allowed to do SMS administration, by default. You have a single person performing all administrative tasks, so it's easy for administration. You don't have to worry about creating security rights or worry about any other users.

We also create a number of accounts. We'll discuss accounts a little bit later on. Those accounts, in a lot of cases, are administrative accounts, some in the local SAM of the server, some in a domain environment, from the domain database.

If you're using the default mode of SMS, you're using the default accounts, which have a lot of administrative accounts, and a single user doing administration. If that's the level of security you want for SMS, then you can configure SMS to provide greater security. You can go all the way up to what we might call a maximum security mode; but again, that requires a lot more administrator attention or overhead for you to maintain that system and initially configure it.

If you want to improve your SMS security or make it a more secure environment, you can give your SMS administrators the minimum rights that they need to perform administration. Again, by default, you have a single account that has rights to everything. If you want to have people performing some aspect of SMS administration, you might create a security right for that user account, or maybe a group, and give them security rights to the objects that they need to have access to. Then you create additional security rights for different users or groups to perform the administration in SMS that they need, or that they require access to.

You also might want to use some of the optional SMS accounts. Again, by default, there is a set of accounts that we use. In some cases, there's an administrative account that reaches across the network, the SMS Service account. If you don't want to expose the SMS Service account across the network, you can create optional accounts, keeping the SMS Service account local to the site server itself. Again, that requires that you create an additional account in your Active Directory™ or in your Windows NT^® domain, and you need to configure SMS to use that optional account.

You can also install your site server on a member server. Installing it on a member server, as opposed to a domain controller, can help create local accounts, as opposed to the number of domain accounts we create. Again, that can help with your security mode by having local administrative accounts, as opposed to domain administrative accounts.

Let's talk about a couple of the security prerequisites (slide 4), or things that you really need to understand fairly well if you want to understand the SMS security system. First off, to properly manage SMS security, you the administrator must understand a number of different security concepts for things outside of SMS itself.

You need to understand Windows NT security. The aspects we're talking about there are accounts, processes, privileges, permissions, rights assigned to those accounts, and how those flow down to processes. You need to understand the different and various Windows NT domain models, because SMS can work in all the different domain models. You need to understand how accounts are validated in those different domain models, whether you're using pass-through authentication, or whether you're using trust relationships and validating your account in a master domain.

You need to understand SQL Server™ security, Windows Management Instrumentation security, as well as DCOM Security. SMS uses all those different technologies under the standard SMS layers themselves. So, in all those different areas of accounts, processes, privileges, authentication levels, and so on, SMS uses standard client/server communications. We use shared resources or share names. We use RPC connections. We use anonymous connections for some instances of all those different processes and tasks. You just need to make sure you understand those different topics, and aspects of security outside the SMS environment, because SMS does use all these different areas of security. It relies on a number of them.

If you're not really familiar with these different areas, there are a number of resources (and I'll point them out to you at the very end of the presentation) that you can use to improve or increase your knowledge on these different areas.

In this presentation, I'm not going to talk very much about SMS accounts. That's an entirely different topic. Yes, it does rely on security, and it looks at the accounts, but there are too many accounts to talk about in a single 45-minute or 1-hour presentation. I just have three different slides on accounts. I'm going to go through some of the highlights on the accounts.

It was in February of this year we did a WebCast on the SMS accounts (http://support.microsoft.com/servicedesks/webcasts/wc020300/wcblurb020300.asp). That's still available, and it's archived at the normal location for you to review.

First off (slide 5), some of the SMS account basics: SMS uses a number of different accounts for security. Those of you who were around for SMS 1.2, you know the accounts that SMS used. Primarily, it had a single account, the SMS Service account, which was used for just about everything in SMS.

One of the things customers told us they wanted us to improve on in SMS 2.0 was security. One of the ways we chose to do that was by not just using a single account for everything, but instead using multiple, different accounts for specific purposes to try and improve security. You don't have a single account that does everything, the SMS Service account, as you did in SMS 1.2. We still have the SMS Service account, and it still is used for a number of different tasks, but it's not the single account for everything, now.

Some of those accounts are domain-level accounts. Some of those accounts are local SAM accounts in a Windows NT client or in a Windows NT member server that's running in the site system. By using these different accounts and segmenting the accounts for a specific task, we do improve the security aspects of SMS, because you have one account, that's a local administrator account, to perform some function. But that account is not used to transfer data across the network, nor is that account used for any other purpose. If that one account happens to be compromised, due to lack of physical security, or whatever the problem is, it's again a local account that's being compromised, and possibly not a domain-level account.

Generally, your administrative-level accounts are only used locally. The example I just gave, with a remote client access point, the remote service account that's used to start the SMS Executive on a remote CAP, it's an administrative-level account in that CAP. However, that account is used just to start up the SMS Executive, and when it has data to transfer to the site server, or it needs to retrieve data or configuration information from the site server, it doesn't use that account. It uses a different account, which is a user-level account, to transfer data or access resources across the wire. So again, we're improving security by using local administrative accounts on the box, but domain user-level accounts across the network.

A couple of specifics (slide 6) on the accounts I want to talk about — SMS manages the accounts itself, so the accounts that SMS creates on its own are accounts that we manage. With those accounts, we don't really want you going in there and performing any manual administrative tasks. SMS, when it creates accounts, and when it creates those passwords for those accounts, uses strong passwords. So, we go beyond what the standard password filter rules are, creating passwords that are extremely strong.

We don't want you to go in there and attempt to manage our account. For any account that SMS creates automatically, during SMS setup, or when you install a specific site system — so any of those accounts we create — we don't want you managing it. We don't want you going in there and changing the password. We don't want you going in there turning off the check box for Password never expires. We don't want you going in there and setting our accounts to expire. If you do, the account will expire, and so will the password, and you won't know what the password is. You have to reset the password. Then you have to get that password change out to all of your site systems, or the clients, or whatever is appropriate. That isn't always as easy to do as you might think it is, to get everything back up and running properly.

Generally, the rule of thumb is, if the account is an account that we automatically create during SMS setup, and it's not one that's exposed to you, the administrator, where you can designate the name or password, just leave that account alone and let us manage it on our own. If it is an account that we do expose to you in the SMS Administrator console or in SMS Setup program, such as the SMS Service account or the SQL Server account and so on, those are accounts that you do have control over. You can specify the account name or the account password and change it if you need to.

Generally, the server type accounts are more controllable by administrators than are the user or the client type accounts. You can use optional accounts instead of the standard SMS Service account. When the site server needs to access your remote logon point or a remote CAP, you can use the SMS Site System Connection account, as opposed to the SMS Service account. That's an account that you can control.

We mentioned earlier that to improve your security, you can install SMS on top of a member server instead of a domain controller. That way you'll be creating local accounts, as opposed to domain-level accounts. You can do that for a site server, a SQL Server computer, the client access point, a software metering server, and component servers. Obviously, with logon points, you can't do that. You can install distribution points on member servers, but again, there are no accounts there, because there are no SMS processes or services running there.

The last slide on accounts I want to talk about is on SMS account lockouts (slide 7). Basically what I want to do is quickly cover what the different areas of account lockouts were, but emphasizing that all of these account lockout problems were solved with Service Pack 2. If you've upgraded your sites to SMS 2.0 Service Pack 2, you should not be experiencing these account lockout issues anymore.

The first account lockout issue is the SMS Service account. That one is normally locked out when you had the site server attempt to remotely install the SMS client software on a Windows NT or Windows^® 2000 client computer. This was caused by the account, in this case the SMS Service account, not being valid as an administrator on the remote Windows NT or Windows 2000 client. We would switch the domain context, from what we initially tried, to a resource domain context. We would continually switch the domain context for the SMS Service account to whatever resource domains we could find.

In this case, if you had Account Lockout policy enabled, it could lock out the SMS Service account, which is not a good thing to do for an SMS site environment. We solved that in Service Pack 2, because we don't do domain context switching anymore when we're remotely pushing out the SMS client software through CCM.

The SMS Server Connection account was usually locked out by a site reset. You ran a site reset, which would automatically change the account password. Let's say you had a client access point that was offline during the site reset process, it would not be notified of the new password for the SMS Server Connection account. When it came back online and attempted to access the site server, it would know an old password for that account, which obviously would not be correct anymore. Which would, again, if you had Account Lockout policies enabled, result in that account being locked out, which would be the new account with the new password, so no other sites systems could talk to your site server anymore.

In Service Pack 2 we do not reset the SMS Server Connection account password by default. Instead, we present a dialog box to you asking you if you want us to reset the account. The default answer is no, so you would physically have to click the Yes button to have us reset the account password.

The SMS Client Connection account was usually locked out by a site reinstall. You had a site installed. You deinstalled your site, but you left your clients alone or left the clients installed. Then you reinstalled the site with the same site code. The clients would be aware of the SMS Client Connection account with the old password. When you reinstalled it, you generated a new password for that account, which your CAP now knows about. The clients know the account with an old password. The CAP knows that same account with the new password, thus your clients can't talk to the CAP. This is resolved by having your client hit an SMS logon point. So just run the SMS logon script or Smsman.exe, connect up to a logon point, and that would reset that account information at the client.

To prevent this, you manually create an SMS client connection account in the SMS Administrator console, which is an account that you would create, so you would know the account name. You would know the password. Then, when you reinstall your site, you just re-create that same account and password inside SMS, and then your clients would still have that old information to talk to the new client access points.

Lastly, the SMSCliToknAcct&. The SMSCliToknAcct& issues are generally caused by hardware inventory, and occasionally by software distribution. We solved those in Service Pack 2 from the hardware inventory side by not having hardware inventory run under the context of the SMSCliToknAcct& anymore. Instead, in Service Pack 2, on Windows NT clients or Windows 2000 clients, hardware inventory runs under the context of the local system account and not the SMSCliToknAcct&. You shouldn't be experiencing account lockouts for that account anymore.

That's it on accounts. If you have further questions on accounts, you can submit them later on in the Q&A session, or, again, you can go back to the February WebCast that we did on SMS 2.0 accounts (http://support.microsoft.com/servicedesks/webcasts/wc020300/wcblurb020300.asp).

The next level of security I want to talk about is physical security (slide 8). This should be something that you all understand. However, we find a number of customers who don't provide physical security for their SMS servers. Your SMS servers absolutely have to have physical security implemented. They need to be locked in a server room where standard users don't have access to the physical box. Any time a physical server is left exposed to a user, the user could restart the computer. The user could power off the computer and power it back on. They could pop a CD in or floppies and reinstall a new operating system. They could blow away the old account information by blowing away the SAM when you reinstall the new OS or whatever. The box is compromised by being out in the open. You need to make sure that it's physically secure so that users don't have access to the box.

When you're doing SMS administration, you want to make sure that you're not doing your SMS administration at the site server itself. You want to be doing your administration from a remote SMS Administrator console. The site server admin consoles are locked down by NTFS, because the MMC files necessary are in the appropriate SMS site server directory of SMS\Bin\I386, which is locked down to no user access. You could give any user NTFS permissions to that directory; by default it's just administrators. But generally, it's recommended to go to a remote Windows NT computer or Windows 2000 computer, install the remote admin console and related utilities, and do your administration from that level.

The next level of security is the file system security (slide 9). I just have one slide on this, because we discussed this fairly well in January. I just want to recap it quickly.

NTFS is required for the vast majority of our site systems. NTFS-level security is what's going to lock out inappropriate users from accessing SMS functions on most of our site systems. The site server itself is locked down through NTFS. Both the SMS server itself, as well as the share name and directory used for intersite communications, which is SMS_site as a share name and the \SMS\Inboxes\Despooler.box\Receive directory, those are all locked down through NTFS. Basically users have no access at all to the site server directory structure.

CAPs require NTFS and we lock down the CAP, its ten directories. Five of those are read only for users. And on five of those, users have write permissions. However, the big gotcha there is that the CAP directories are locked down to local users from the domain that the CAP is a member of. If your CAP is in a resource domain, and your user accounts are in a master domain, by default your users would not have access to the client access point. You would need to ensure that your domain users group from your master domain or accounts domain has been added to the local users group in the CAP itself, in the CAP or in the CAPs domain itself. Other than that, we lock that down pretty well.

Logon points again are locked out through NTFS. Users do have the ability of writing to the Ddr.box directory if you're doing logon discovery. Otherwise, it's just read permissions to the directory that they usually need reconfiguration information from. And some locations on the logon point they have no physical access to at all.

Distribution points are locked out according to the policies that you set when you create a package. When you create a package, you can set your access accounts and what security permissions you want appropriate users or groups to have to those files on that distribution point. You set that on a package-by-package basis.

As we've discussed before, we do not provide any security for software metering, by default. If you do install on an NTFS partition, you can modify the default security permissions through NTFS to lock it down, so that users can't maliciously corrupt the data on the software metering server. Again, we discussed that back in January, in the SMS security presentation we did then.

One slide I have added here is "Troubleshooting SMS NTFS Security Issues" (slide 10). We do a good job of locking down our site systems to the NTFS level, but how do you troubleshoot to determine whether or not a security problem is related to the NTFS layers? That's primarily done through log files. If you have appropriate auditing enabled, then you can look at the Windows NT event system. However, that's not enabled by default, so you wouldn't have access to that. Primarily you're going to be looking at log files through SMS.

The different areas of log files you want to look at are from the site server to site systems. I list for you on the slide all the different log files you want to look at: Inboxmgr.log from the site server to CAPs; Distmgr.log from the site server to distribution points; NT_logon.log for the SMS Windows NT logon server manager setting up logon points; Licsvccfg.log and Licsrvc.log for setting up the software metering servers, and pushing data down to the software metering servers, or retrieving data from the software metering servers; Sitecomp.log for physically installing and setting up component servers on the SQL Server computer, the site server, client access points, and so on; then Sender.log for communications between SMS sites — so, a parent site sending data down to a child site, or a child site forwarding data up to the parent site.

You could view Ccm.log for site server to client issues. If you're having issues with installing clients for which the logged on user is not a local administrator, and the SMS site server needs to help out, you can look at the Ccm.log for any NTFS or security-related issues.

For a client to access the appropriate site systems, you would look at the install logs, which would be Wn_logon.log or Wnmanual.log or Wnremote.log. Those would give you any "out of disk space" or "access denied" error conditions. Ccim32.log and Cqmgr32.log are for the client accessing client access points. Ccim32.log is looking for agents to install or configuration parameters for those agents; Copy Queue Manager is for copying data files from the client up to the client access point. Smsapm32.log, as well as the three "Odp" logs, are all for software distribution — looking for advertised programs, and finding the actual programs themselves, and running those. Then there's Liccli.log for software metering.

Those are just some of the log files you want to look at if you think an issue you might be having is related to security. Unfortunately, you do have to go down to the log file level in a lot of cases. You would have to enable logs on your site server. Client logs are enabled by default, again.

Next let's switch gears and we'll talk about site database security (slide 11). Once you get past this physical security, the next layer is NTFS security. After that, it's access to the site database itself. There are three different layers here. You have WMI or the SMS Provider access. You have SMS Object security. And you can create custom SMS Administrator consoles.

The first we'll talk about is SMS Provider access (slide 12). The SMS Provider controls who has access to what SMS objects in the SMS site database, and what actions those users or administrators can perform on those objects. We'll discuss how you set that, as far as the SMS security rights, in later slides.

There are three different ways to provide a user access to WMI, Windows Management Instrumentation. If you have access to WMI, then you would have the appropriate access to the SMS Provider. The first way is by placing that user or global group in the SMSAdmins local group. On your site server, you'll have a group created called SMSAdmins. All you have to do is take the account that you want to give access to the SMS Provider, and place that account inside the SMSAdmins local group. It's not really SMS administrator. It's really titled SMSAdmins.

You just take the user account or the global group, drop it in that account, and that gives them all the rights they need to connect up to the SMS Provider, which means they can connect up to the SMS database. That does not mean they can perform any functions inside the SMS Administrator console at all. It doesn't mean they can see any objects at all. It just means they can physically connect up through the site server to the SMS database. What that means is that when they try to launch the SMS Administrator console, they should be able to connect to the site database. It doesn't mean they can perform any admin functions, but they can connect.

The next way is by manually providing permissions through one of two utilities. The first utility is Wbemperm.exe. Wbemperm.exe is a utility that was used in Windows NT 4.0 environments. In a Windows NT 4.0 site server, you would use Wbemperm.exe and assign the rights of Execute Methods and Write Instance to your appropriate account. Those are the exact rights that are assigned to the SMSAdmins local group, Execute Methods and Write Instance inside the SMS Administrator console.

In Windows 2000 environments, Wbemperm.exe is no longer a utility that you can run manually. Instead, Wbemperm.exe is now called WMI Control, and it's in your Administrative Tools directory. It's in Administrative Tools, Computer Management, and then you have WMI Control.

One of the issues with Windows 2000 is that you automatically have access to WMI, because Windows 2000 is so intertwined around WMI, and it uses it for many different purposes, whereas Windows NT 4.0 did not; you don't necessarily have to provide security rights or access to WMI. Because by default, the Everyone group has WMI permissions, because any logged on user or internal account needs to have access to WMI for a lot of functions in Windows 2000 to operate. The only thing you might have to do in Windows 2000 is assign the remote enabled option. That is not selected by default; where it is selected, it's designated for the SMSAdmins local group.

The third way is to make that user a local administrator, which obviously may not be something you want to do. You're giving them more rights than they necessarily need to have. Any access through the SMS Provider to the SMS site database is logged in the Smsprov.log. This is one log file that is enabled by default, so you don't have to enable the Smsprov.log. It is enabled by default for you. You'll see any access any user tries to perform through the provider, down to the SMS site database. It will even show you user name, the domain name, or the context that was used.

The SMS Provider can reside in two different locations (slide 13). It can reside on the site server computer, or it can reside on your SQL Server computer. That's your choice. If you're using a remote SQL Server for installing SMS, we'll ask you when we detect the remote SQL Server, where do you want the SMS Provider to be installed. Generally, we recommend it to be on the SQL Server computer, but again, that's your choice.

Once installed, the SMS Provider can be moved from one remote SQL Server computer to another remote SQL Server computer. However, it cannot be moved from a remote SQL Server computer back to the site server. We currently don't allow you to move the SMS Provider back to the site server if it's installed on a remote box.

The logged-on user does require access to the SMS Provider. For the SMS Provider itself, that's WMI rights, which means just use the SMSAdmins group. That's the easiest way of giving a user WMI rights or the SMS Provider rights. Just drop them into the SMSAdmins local group.

The logged-on user also needs Windows NT rights, remote procedure call rights, and DCOM security rights, which by default Everyone (the group Everyone), does have rights to. You shouldn't have an issue, unless you go in and try to lock your environment down. If you try to lock the environment down and start removing rights from those different areas, then the logged-on user may not be able to access the SMS Provider.

WMI security (slide 14): WMI, as we talked about last month, is used for many different tasks in SMS: hardware inventory on 32-bit clients, Health Monitor, the Network Monitor Control Tool, the SMS site database access, which is what we're discussing here, Network Discovery, Network Trace, as well as the SMS Service Manager — they all use WMI for some different aspects of their inter-operation.

WMI 1.1, which ships with SMS 2.0, does not provide namespace security. In other words, by default, all users have full permissions to all namespaces with WMI 1.1.

WMI 1.5, which ships by default with Windows 2000, does provide security on namespaces. You can designate, on a per-namespace basis, what security rights you want to have — who can access what functions in that namespace. You can set some namespaces to be read only for users.

That just gives you a little more flexibility. It's not as important for SMS, because again, we control things through the SMS Provider. But for other WMI utilities you might create, or for access to the same repository, you may want to restrict some of your namespace rights.

For example, a user is sitting at the remote admin console and they try to launch their SMS remote admin console. They're unable to connect the SMS site database. How do you go about troubleshooting that? Is that a security-related error? How you might troubleshoot that? We discussed this a little bit last month. You could use either Wbemtest.exe or CIM Studio (slide 15), either one of those two utilities. Wbemtest.exe has the advantage that it comes with WMI, so when you installed WMI, either through SMS or through Windows 2000, Wbemtest.exe was provided. It basically uses the SMS Provider to duplicate any SMS Administrator console tasks. Just about anything you can do inside the SMS Administrator console, you can accomplish the majority of those same tasks through Wbemtest.exe. It's a good way of testing whether or not you have connectivity. It'll show you what data is available in SQL Server itself.

CIM Studio has the advantage that it's much more of a graphical interface, and it's much easier for you to find the data you're looking for, just by expanding the namespace, expanding the different classes, and looking at the attributes and the properties and so on. It's an easier method of gaining access to the data. It goes through the same process as Wbemtest.exe. It's just that it's not installed by default. It is a piece of free software you can download from the Web site that I've listed on the slide for you (http://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/MSDN-FILES/028/000/015/topic.xml).

Then what you would do is connect to the SMS Provider to find out where it's installed. You'd connect to your provider\root\sms, and find where the provider is located. Once you've done that, you can connect to the specific SMS site database, which would be your providercomputer\root\sms\site_sc (whatever your site code is).

When this remote admin console is trying to connect to your SMS Provider, it has to verify where the provider is (slide 16). It checks the registry key on the admin console. It looks at HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\AdminUI\Connection. It will specify the site server's name. Then we connect to that site server. We connect to the \root\sms tree through WBEM. Go through WMI. We go to the \root\sms tree and we basically run a query.

If you have Wbemtest.exe up and running, or CIM Studio, you could run the same query. The query would basically run a select * from SMS_ProviderLocation where providerforlocalsite = True, and you run that query. That will return the location of the site code for this provider. So if the provider is running locally, it'll come back and say True, and it'll tell you what the appropriate site code is. That's what the SMS Administrator console is attempting to connect to. Then it will connect to the specific namespace, \root\sms\site_sc.

One issue that we talked about last month is that you may get multiple instances returned if you reinstalled your site with the new site code, because WMI will remember your old site code, and it will also understand your new site code, and it may connect up to the wrong site code. You can go to that location and remove or delete the instance of the old site code. Then you'll be able to connect up to the proper site code.

For security, how do you verify the user account (slide 17)? How do you verify the account that you're logged on as to see what security rights it has within the SMS site database? The first thing you would do is connect up to the provider computer to \root\sms\site_sc. Connect up to that namespace in Wbemtest.exe or in CIM studio. Then to verify the logged-on user account, in other words, to see what account the provider thinks you're logged on as, you would click the Execute method button. You would go to the SMS_identification, click OK, and select GetCurrentUser, which is the default. Then click Execute.

Once that comes back, it'll tell you that it was executed successfully. Click the Edit Out Parameters button, and then Show MOF. That will come back and it will display what the provider thinks you are, as the logged-on user. It'll tell you what the logged-on user account name is. This is the account that needs SMS security rights. Whatever account is returned by this procedure, here is the account that needs to have security rights, in order to administer any functions in SMS.

Well, users can also be members of groups. How do you verify what the group memberships are? On the next slide (slide 18), we talk about verifying group membership, because you can set security rights, not only on individual accounts, but also on groups. To verify what groups the logged-on user is a member of, at least for what the SMS Provider thinks, you go to the same namespace, \root\sms\site_sc. You click Execute method, select SMS_SecuredObject, or you type in SMS_SecuredObject and click OK. In the drop-down list, you select RefreshNTGroupMembership and execute that method. Again, you select Edit Out Parameters, and then click Show MOF, and it will show you the listing of all the user groups that the logged-on user account is a member of — administrators, domain admins, SMSAdmins, domain users, users; whatever those groups are, it'll come back and show you all those groups.

The logged-on user will have access, or inherent security for whatever security rights are set for these groups that have been returned in this query as well. You have permissions for the logged-on user account we looked up in the previous slide. You would have any security rights that would be appropriate for the logged-on user for its group membership, according to this slide. You would look at the security rights that you have for the user account, as well as the group membership.

You'll take those security rights and you'll apply those or see what's available for the SMS security objects themselves. SMS security objects are how you control who has access to what in the SMS database, as far as the objects, and who can perform what type of operations on those different SMS objects. You do this through SMS security rights.

There are two different types of SMS security rights you can apply (slide 19). One is called a Class right, and the other one is called an Instance right. A Class right means all instances of a specific class. There are six different classes: Advertisements, Collections, Packages, Queries, Sites, and Status Messages. So a class right for Packages would say that this user or account (again it could be a group account) has specific security rights for all packages. You get to set whatever those security rights are.

An Instance right says this account user or group account has these specific permissions to this one specific package — not all packages, but a single instance of a package. You can set rights on all entities of a class, or a specific entity of a class — Class rights or Instance rights.

Rights in SMS are additive. So, when we looked at the user account a couple slides ago and then the user group membership in the previous slide, you would take the security rights from all those groups that the user would be a member of, as well as individual rights, and add them together, and you would get all those rights. It's not like NTFS, where you get whatever the union is, or the most restrictive rights. In SMS they're additive, you get a combination of all the rights that you would have from all different security objects.

There are three different methods to assign those rights. You can use the Manage SMS Users Wizard. You go to Security Rights, All Action menus and All Tasks, and you have Manage SMS Users. That allows you to browse and select from the list of users, copy your clone rights from one user to another user, remove rights, and so on. It's a GUI interface for assigning rights.

You can manually create rights, which is to select SMS security rights in the admin console (Action, New), and then assign a Class right or an Instance right. You can do that.

Or, when you're creating any object in SMS, or any object that's already been created, such as a package, a collection, or an advertisement, you'll have a set of tabs that are available. One of those tabs is called Security. You can go to the Security tab and create additional Class rights for that class — Collections, Packages, or Advertisements, whatever it is you're looking at. Or you can set Instance rights for accounts for this one specific instance of that class. You can set your rights that way.

SMS security rights are how you control who has what access to objects in the site database and what actions they can perform. You set those through the SMS Administrator console, and you can view those through the admin console. However, let's say you can't access the admin console. If you can't access the admin console, again you're not sure where the security problem lies. What you might want to use, again, is Wbemtest.exe or CIM Studio to verify what security rights you have assigned to specific objects (slide 20).

How you would do that, again, is by connecting to your providercomputer\root\sms\site_sc namespace. Then, to verify the security rights, you would run two different queries. The first query you would run is the first sub-bullet: select * from sms_UserInstancePermissions. That will show you all the user Instance rights that have been created.

Then you could run select * from sms_UserClassPermissions. That will show you all the class rights that have been created. It shows you the appropriate account, where there's a user or a group account that has rights. It will show you what the object key is. It might say, object key equals = 1. Then it might say administrators. Then it might give you the appropriate instances.

To see what the individual rights or permissions are, you would double-click on that instance, and then when you're scrolling through the list of parameters or values, you would see Permissions. You get the permissions. It will be some value like 15. You would write down what 15 is. Then you list all the different user instance permissions and class permissions that are available for the user, or the user group membership, and figure out what all the permission rights are listed for each of the individual objects.

If you want to see what the object keys are, then you run the next query: select * from sms_securedobject. That will show you what all the object keys are. It will say 1 is collections, 2 is packages, and so on.

Then you cross-reference the permissions from the user instance permissions and the user class permissions with the appropriate object keys. Then you add up all those values. Then you would look and see what values those equate to, as far as SMS security rights. Basically, what you're getting is the accounts that have specific security rights you're seeing through Wbemtest.exe or through CIM Studio.

What rights are available and the security permissions are shown on our next slide (slide 21). I have listed for you the actual SMS security permissions. I gave you an example where object key = 1, this account might have permissions of 15. Look at this slide and note the different values listed, all the security rights, that would add up to a 15, which would be Distribute, Delete, Modify, and Read. That would come out to the value of 15. This user would have Distribute, Delete, Modify, and Read rights on this collection.

This is a cross-reference for you, as far as what the different permissions are, if you need to run the query from the previous page, finding your appropriate user account or user group accounts. Then double-click on the instance. Look at the permissions that will be returned as a numeric value, and then look at this page to find out what those values are. That will tell you what rights this account has to the appropriate object keys inside the SMS database. That will let you figure out whether or not, when a user cannot launch the SMS Administrator console and connect with the database successfully, you should try it through Wbemtest.exe. If they can connect, but they can't see packages, you could look in Wbemtest.exe yourself and see what rights that user has. Or if you can connect to the site database, obviously that's going to be a little bit easier, just looking at the security rights in the SMS site database. By going through Wbemtest.exe, you're going directly to the site database through the SMS Provider. That's how you can validate what security rights you have assigned.

Next, we want to talk about some of those security rights issues, or what people sometimes call "features" (slide 22). Here are some things in the admin console that aren't necessarily intuitive, but things that you have to accomplish in order to have the appropriate actions to be able to be performed.

For example, the first one: in order for a user to see advertisements in the admin console — so you're sitting at the SMS Administrator console, you want to view the advertisements — in order to view the advertisements you have to have class Read rights to both packages and collections. If you think about it, if you can visualize, or if you're looking at an SMS Administrator console right now, click on Advertisements, and what you see in Advertisements is the package that's being advertised, a program from that package, as well as the collections to advertise to. In order to display the advertisement information, you have to be able to read the information from the packages, as well as the collections.

The next one is documented in Q259861, which I have listed for you in the slide, some queries don't show the results properly, unless the user has class rights to some specific collections. Any time a collection is using any classes other than the standard Discovery and Inventory classes, the user who is trying to run that query has to have appropriate Read Resource rights to the appropriate collection, in order to display those results.

For example, if you're trying to run a query to display software inventory information, you have to make sure that the user has appropriate rights to software inventory. Or, if you're trying to display a query that searches for all users in a specific user group, you've created a query for that. You need to make sure that your user has Read and Read Resource rights to the User Groups collection. If not, what you have to do is just make sure when you run those queries, that you create those queries and designate them as collection-limited queries, and just specify a collection the user would have appropriate rights to, to be able to read from.

The next one is, to use the Distribute Software Wizard, the user must have Class Read and Advertise rights to Collections. You want to use the wizard to help automate software distribution. In order to perform software distribution using the wizard, you need to make sure that the logged-on user, through either the User account, or group membership, has Class Read and Advertise rights to collections. That's the process you go through in the software distribution or the Distribute Software Wizard. As you're distributing advertisements, you're advertising to members of collections.

One thing that confuses people is if you go into the admin console and create a brand new Instance right for a user, and that user has no other rights to the SMS system at all for that class. So, let's say you're going to create an Instance right for a single user or group account to a specific package, and that account does not have any other Class rights to packages. What will happen when you create the User Instance right, an Instance right for that account, is it will actually create a Class Instance right for that same class, but it will have it listed as no permissions. That's just the standard byproduct of the SMS security environment, the way it's designed right now. You'll find a lot of additional security rights created that have Class rights for some class with no permissions listed, and it will actually say no permissions instead of listing the appropriate permissions, because it didn't have any. That's just so that if a user is assigned Class rights through some other membership, and those were removed, they still do have Class Instance rights, along with the instance itself.

A few more security-related issues in the next slide (slide 23). To use the Create Package from Definition Wizard, it requires that you have rights to the Sites class. We have listed here Modify rights to the Sites class. My guess is it would probably work with Read rights to the Sites class. This doesn't really seem logical. It's just the way that the wizard is currently designed, the way that the wizard finds the appropriate package definition files. How it does so is by reading some files that require additional permissions, which is done through the Sites class. It's reading some additional files that require Class rights. For the Sites class, you need Modify rights to use the Create Package from Definition Wizard.

To view status messages, you need to have Read rights to both Sites as well as status messages. It makes sense for the status messages, but you also need Read rights to the Sites object.

Then creating and running queries. When you're creating a query, one of the options is saying IP address or IP subnet must be equal to, and then you type in the value that you're searching for. There's a Values button on that page in the dialog box. In order for that Values button to retrieve any data for you, you have to have Read and Read Resource rights to the appropriate collection, whatever the appropriate class is that you're creating the query on: Users, User Groups, or System. To create that query and use the Values button to display a list of potential values for you, you have to have the appropriate Read and Read Resource rights to the type of collection.

Those are just a few security issues. We'll have a couple more coming up fairly quickly as we close off the presentation, for the Windows 2000 security issues we've found so far.

The next thing we'll talk about is custom SMS Administrator consoles (slide 24). I want to caution you that even though I have this in the security presentation, creating a custom MMC console is not really security. It's not going to provide a high level of security at all. However, it kind of fits in with the security scheme and the concept of security. So, when you create a custom MMC console for SMS, what you're doing is creating a custom snap-in for the SMS site database that only displays certain nodes in the custom MMC.

Take, for example, Collections. You might create a custom MMC console that when it's opened up, all it displays from the site database is Collections. It doesn't show queries. It doesn't show advertisements. It doesn't show packages, or it doesn't show SMS Tools or security rights, or anything else. All it would show is Collections. That would do, it would give the user or the administrator just the view of what they need to have the view for. If my user can only administer from some aspect of collections, give them a custom admin console that just shows them collections. Don't show them packages. Don't show them advertisements. Don't show them queries. Don't show them things that they have no rights to.

First off, giving them more things than they have rights to can confuse the administrator, and it can also give them an idea that they can do some exploration here, and maybe they can find some packages, queries, and other things. It might get some users in the mode of exploration, or some people might call it hacking — trying to get in there and gain access to packages and things that they don't have rights to. Create a console for them that just shows them the objects that they have rights to, then that's all they would have the ability to look at.

Now you still need to create SMS security rights, so that account still needs to have appropriate security rights to collections. Maybe you give them Read and Read Resource rights to view the members of the collection, as well as to view the discovery or inventory details of a resource in that collection. You still need to create the SMS security rights to give them permissions to that resource, or restrict what permissions they have on that resource.

When you do create your custom console, you can create as many as you want to. You create the console. You might want to save it as Sms.mfc, which is the default SMS Administrator console name, and then copy that to the appropriate administrator's Windows NT or Windows 2000 computer to the \SMSadmin\Bin\I386 directory. If you copy Sms.mfc, the customer one you've created to their \Bin\I386 directory, when they go to Start, Programs, Systems Management Server group and start the SMS Administrator console, it'll start up this custom console for them. All they'll see is the custom console you've created and whatever rights they have or whatever objects you've created in that console. Again, that can help limit their view of the SMS environment and help deter exploration. But it's not a very secure environment. Really, the security is down on the SMS security rights, controlling who has access to what.

The SQL Server account (slide 25) — we talk about the SQL Server account here in security because this is what the SMS services use when they need to access the SQL Server database itself. When your SMS services need to go to the SMS site database and access data, they're going through this SQL Server account. The SMS services themselves don't go through the SMS Provider, because they're controlled services. We know exactly what they're doing, so we have them go directly to SQL Server for better performance.

The account that's used here depends on the SQL Server security mode that you have implemented. If you've implemented standard security, or in SQL Server 2000, it's called Windows Only, then you might be using sa as your account. In fact, sa would be the default account when you tell SMS to use standard security when it integrates with SQL Server. If you've gone to an integrated or a mixed mode, then when you tell SMS to use integrated security, your SQL Server allows Windows NT authentication or mixed-mode authentication, or Windows Only, as it's called in SQL Server 2000. Standard security is called SQL Server Security.

Then, you're going to use your SMS Service account as the account that's used to talk to the SQL Server database itself. This is created and specified during setup, so when you run SMS Setup to install your site server, you designate what type of security you want to use — standard security, being sa or some other SQL Server account, or integrated security, being that your SQL Server needs to be configured in a mode that allows Windows NT or Windows 2000 user accounts to be authenticated and used.

You can also change it by doing a site reset. If you're currently set in standard security mode and you want to go to integrated mode, make sure SQL Server is set to accept Windows NT or Windows 2000 accounts. Then you run an SMS site setup and tell SMS to use integrated security when it interfaces with SQL Server.

One thing you need to be careful of is whatever accounts you use here, whatever type of security system, you want to make sure you do not restrict the account permissions for this account. Some people have taken away admin rights to whatever the SQL Server account is — either the SMS Service account on the SQL Server computer, or the sa account, or they've removed named pipe permissions. They've restricted that account from running named pipes. That's how we do some of our notification processes, is through named pipes. If you restrict admin rights or take away named pipe permissions for the SQL Server account, then SMS doesn't work properly. You need to make sure you have those rights enabled: admin rights to the SQL Server, as well as named pipe rights.

Getting down toward the very end (slide 26), "Windows 2000 Specific Issues." Here are four different issues that we've encountered so far with running Windows 2000 and SMS together, so installing the SMS environment in a Windows 2000 environment. I have each of the KB articles listed for you, so you can research these further.

The first one is Q271724, "SMS May Time Out Attempting a PDC/BDC Resynchronization in a Large Windows 2000 Active Directory Environment." Basically what that means is when we discover your domain controllers, we're going to try and set them up as SMS clients, provided they're within the site boundaries. When we do that, we create a bootstrap account in that domain. When we do that, we force the account synchronization. Basically we force the domain database to be synchronized to all the BDCs, because you may be working on a BDC.

In some cases, that process takes a long time, when you slow ranks and you have a lot of different domain controllers to synchronize, and the SMS processes don't wait long enough. When we time out, the operation would fail. We would then retry the operation again a little bit later on, maybe five minutes, maybe an hour later, depending on how many times it's done. Then we do the exact same thing again: cause another resynchronization event to occur, and a build up of profiles. That's discussed in Q271724.

The next one is Q263398, "Systems Management Server Services May Reinstall Repeatedly." This has happened with customers who have set up a Windows 2000 policy and one of their security policies has removed the Logon as a Service right from the SMS environment. The SMS services need to log on with an account. So if that account has been removed from the log on as a service right or had that right taken away from it, then the SMS services can't log on. Then the site component manager or Windows NT logon server manager will deinstall the servers and try to reinstall the servers. Again, if we can't set that log on as a service right, we can't install properly, so we just continually keep trying to reinstall that component.

The next one is Q266712, "Security Based on Global Groups Fails in Windows 2000 Domains." This generally boils down to the pre-Windows 2000 compatibility group and that you've removed the group Everyone from that group. When you remove the group Everyone from the pre-Windows 2000 compatibility group, by default SMS accounts aren't added there. We used the Everyone group. When you remove the Everyone group, then that removes the SMS access. That's documented in Q266712.

Lastly, Q242022, "DCOM on Microsoft Windows 2000 Does Not Support Any Datagram Protocols (UDP)." The scenario here is that you have an SMS Administrator console installed in a Windows 2000 computer, trying to connect up to the site server, which is on a Windows NT 4.0 platform. What happens is in Windows 2000, TCP/IP is set to your default protocol for DCOM in Windows 2000. However, in Windows NT 4.0, it's not set to the default protocol. What you need to do, and it's documented in Q242022, is go to DCOMCNFG/Default Protocols on your Windows NT 4.0 site server and set Connection-oriented TCP/IP as your top-level protocol. So just move Connection-oriented TCP/IP to the top of the list, and then you'll be able to connect up fine.

Lastly, additional resources (slide 27). At the very beginning of this presentation, we discussed some of the prerequisites, things that you need to know as an administrator to successfully administer your SMS environment. If you're not really up to speed on some of these other things, such as Windows NT security, SQL Server security, WMI, or DCOM security, here are some of the additional resources you can go to.

The best resource for you would be the "SMS Security Essentials" white paper. The SMS Security Essentials white paper is available on the SMS 2.0 SP2 CD, as well as on the Microsoft Web site: http://www.microsoft.com/smsmgmt/techdetails/secessentials.asp. We do recommend you go to the Web site, as opposed to relying on the document on the CD, because obviously a CD is read-only media and it can't be updated. Whereas on the Web site, as new information is learned, or the product changes, the document will change, and you'd obviously have an updated document up there. This document is close to 200 pages in length, and it gives you a lot of the background information you need to properly support an SMS environment for security. It does discuss SQL Server Security and DCOM security and WMI security. It discusses Windows NT, accounts, processes, and threads, and the inheritance there, as well as rights, permissions, privileges, and so on. That's a good resource.

It will also point you to other resources, such as the Windows NT Resource Guide, the Windows 2000 Resource Guide, SQL Server resources, and so on.

With the Systems Management Server 2.0 Administrators Guide, again, you want to use the online version of that guide, because it has been updated, whereas the hard copy has not been updated.

The Systems Management Server 2.0 Resource Guide is an absolute must have if you're an SMS Administrator. You need to have that.

The best place to go for information is the Systems Management Server Web site, which is http://www.microsoft.com/smsmgmt/. That's where you'll find product information. That's where you'll find about updates to the product, like Service Pack 2, or when Service Pack 3 will become available. It'll be announced up there; there are white papers such as the SMS Security Essentials white paper; product downloads, like the Web patch for Service Pack 2, and so on. Then there are the appropriate newsgroups on msnews.microsoft.com, and microsoft.public.sms, and the various newsgroups that are available for different topics in SMS itself. So, there are a lot of different resources for you to go through and look at for gearing up on security.

With that, I'll turn it back over to Barb and she'll get us into our Q&A session.

Barbara: All right. Thank you so much for that presentation, Wally.

We do have quite a few questions already submitted today. Our first one is asking about the sender address being the only domain user. If the sender address account to a secure site is only a domain user, when trying to delete the site, the account fails to do so. However, this is stated in the security white paper that it can be a domain user account and will work. Is this resolved?

Wally: If the SMS Security Essentials white paper does state that you can delete a secondary site with a domain user account, that is an error. You can use a domain user account as your site address account for all functions to a secondary site, with the exception of deleting the secondary site. If you want to de-install the secondary site, that account does need to be an administrator. Because what we do is we connect to the root share of the drive that SMS is on and kick off the SMS bootstrap program to do a site de-install. Obviously, to connect to the \root\share name, it has to be an administrative account.

If that does state that, then that is an error. I'll tell the author of that paper. I'll see if I can find it in there myself. If it is in there, I'll tell the author that that is incorrect, because it does need to be an administrative account to de-install a secondary site remotely.

Barbara: Excellent answer. Thank you, Wally. Our next question is about security for Remote.exe. How does the security validation for remote tools differ between the admin console and running Remote.exe at a command line? Specifically, what is the database in the "database could not be found" message that comes up when attempting to run Remote.exe?

Wally: When you're trying to run Remote.exe, first off, there are numerous, different levels of remote control permissions that we didn't talk about in this security environment. The first thing is we have to validate that the user that's trying to run, in this case Remote.exe, has permissions to do this to the Collections class. In the Collections class, either to the specific instance of a collection or the class for collections, you need to have Read, Read Resource, as well as Use Remote Tools rights. The database that's being discussed here is the SMS site database itself when you're at a command prompt; you're trying to run Remote.exe.

We do connect up to the SMS site database to validate that you, the users, has permissions to use Remote Tools on the collection that this client has permissions to (through the IP address, or the NetBIOS name you're trying to specify through Remote.exe). If you do have permissions, then you launch the Remote Tools window. Then, when you try to take remote control of a client, you go to the next level of remote control security, which is the Permitted Viewers list. The client would validate that you are a member of an account that has remote control permissions. If not, it'll pop up the Security Credentials dialog and ask you for an account that has the ability of remotely controlling it. But the database being discussed in this specific question would be the SMS site database.

Barbara: All right. More good information. Our next question has a subject line of "Client Connection Accounts." It's a little bit long. Let me go ahead and start: We currently have all clients able to use a backup client connection account if needed. Then, if a secondary site is de-installed and reinstalled, and our usual backup accounts are immediately added when the site is up, the client receives a new backup account at the next verify cycle. However, the native client connection account now has a new password. Will the clients ever receive this new password setting for the native connection accounts, once successfully able to use the backup account to receive site setting changes? Does that make sense?

Wally: Yes. What will happen is, when you reinstall your secondary site, and you manually re-create the client connection account for that secondary site that was already downloaded to the clients, the clients will then connect to the CAP at the appropriate CCIM maintenance interval, either the 23-hour maintenance interval that happens by default, or the next time you restart your client computer or the SMS client servers, or you go to the Control Panel and do an update configuration. Any of those would connect that client back up to the client access point. When the client connects to the client access point, it will download all the appropriate client connection account information. This would include the new password for the old standard SMS client connection account, which by default is \sms\client_sc.

Once your CAP has been updated, the next time the client does its CCIM maintenance cycle, it should download the proper credentials for all the SMS client connection accounts — the ones you've built in, if you've added any new ones, as well as the ones that we build in ourselves. Yes, that should be updated automatically.

Barbara: Excellent information. Our next question is: Why doesn't Microsoft support direct access of SMS data using SQL Server utilities?

Wally: The reason we don't support direct access of SMS data through SQL Server utilities is that by going directly to SQL Server, you are bypassing all the SMS security. When you go through the SMS Provider, you're using the Provider, which is then validating the security rights the user has to those different objects. If you bypass that, and you go directly to SQL Server, then you are not using that security system, and the user could do whatever they want, which may include the ability to modify our data. We don't want that to happen at all. That's the reason we don't support any users going directly to SQL Server to gain access to any SMS data.

The proper method of gaining access to SMS data is through the SMS Administrator console, through using a WBEM ODBC driver, which is used with Crystal Reports, or you can use it with Microsoft Access, or any other ODBC-enabled application. In the resource kit or the support bundle on your SMS 2.0 CD, there are some utilities, like SMS Extract, that use WMI calls directly to the SQL database through the SMS Provider, because again, they're WMI calls, and extracting some of our queries. Either direct calls through WMI, which would then go through the SMS Provider, or WBEM ODBC, as well as in the next release of software, at some point we'll have some SQL Views available. Using Views through SQL Server, which are read-only environments, allows you to access our data but does not allow you to change anything.

The real reason is security. You lose security, and any utilities you might write may be obsolete in the next release of software. As you may have noticed, we've changed our schema in just about every release of SMS we've done. If you write a utility to a specific table or schema, it may change. Going to the published interfaces is the recommended way, because those utilities would still work in future versions.

Barbara: Wonderful information again. Our next subject is the SMSCliToknAcct&. The question is: What's the latest on this? I'm seeing problems which I'm told are because the Open.wav and Close.wav files aren't on my system.

Wally: Yes. We've talked about, not this specific issue, but how Service Pack 2 has resolved the SMSCliToknAcct& lockout issues. We did resolve all the SMS-related SMSCliToknAcct& lockout issues. However, what we're finding is some of the third-party audio driver manufacturers are going out across the network, looking for Open.wav and Close.wav files. When they do that, somehow they're hooking the SMSCliToknAcct&. We don't know how they're doing it, or why they're doing it, but they're using our account to go across the network looking for these utilities.

It's totally SMS unrelated. However, they are doing so, and when they're doing so, they're causing a lockout of that account, because the account on one Windows NT client is going to have a different password than any other Windows NT client, as well as a different password than the SMSCliToknAcct& in the domain, because your domain controllers are clients. They have different accounts, so you get locked out. It is purely a driver issue. I've heard of some Compaq drivers that have the problem, among others, but it is a third-party driver issue. It is not an SMS issue, which is kind of strange, when it's our account that's being locked out, but it is actually their issue.

Barbara: Our next question has also about the SMSCliToknAcct& lockouts. I think you've touched all aspects, but I'd like to just be sure. We were having consistent SMSCliToknAcct& lockouts with SP1. We have since upgraded to SP2, but unfortunately we continue to have regular SMSCliToknAcct& lockouts. Can you offer any suggestions for troubleshooting this, or should I be calling into PSS? It sounds to me like you've covered all of those areas.

Wally: Yes. You probably do need to contact PSS and open up a case with them to see if it is some new issue that we're not aware of. To my knowledge, we're not aware of any SMS-related SMSCliToknAcct& lockout issues, as of SP2. It's possible that some of your clients haven't been upgraded to SP2 yet, and so they're still running some of the SP1 code, which means that the hardware inventory processes aren't using that account, which will lock out.

You might want to, if you have the ability, take a network monitor or some other network traffic analyzer and monitor the traffic on your network as you start up a system. See if during the system startup it goes out and looks for Open.wav or Close.wav across the wire. If so, it's hooking the SMSCliToknAcct&, and then it's that same issue we just discussed, where their driver is hooking our account, for some reason.

I believe it is due to the fact that they're using WMI to make these calls, and it's hooking through that method, maybe. But that would be the thing to track, as a way of checking to see if that's what the problem is, by using network monitor and hooking it there. Other than that, yes, contact PSS so they can do some troubleshooting. It's entirely possible that it is an SMS-related issue, but as of yet, since SP2 has been out, which was the middle of June 2000, I've not heard of one case where SMS is causing the SMSCliToknAcct& lockout. There's a possibility, but most likely it's the audio driver symptom again.

Barbara: Wonderful information. Our next question is: What ways are available to reduce the number of accounts that SMS creates?

Wally: Boy, this is a long, complicated answer. We talked about it a little bit in the February WebCast on accounts, but to reduce the number of accounts, the methods are only available if you have multiple SMS sites in a single domain. If you have a single domain, you can have multiple SMS sites in that single domain. What you can do to reduce accounts would be to share a common SMS Server Connection account for all the sites in that domain, as well as sharing a common SMS Client Connection account for all the sites in that domain. Instead of each site creating their own SMS Server Connection account and each site creating their own SMS Client Connection account, you can share a single account for all those sites. That's one method.

Outside of that, for most of the other accounts that are built in, you don't have a lot of control over them, and there's not a lot of ability to reduce the client service accounts for domain controllers. The only way to reduce the number of those accounts is by not allowing your domain controllers to become SMS clients, which you can do through a registry setting on the site server, to tell the site server not to push out the SMS client software to the domain controller. However, if you do that, then you lose the ability to have hardware inventory read domain controllers. You lose the ability to perform remote software distribution, such as upgrading service pack levels of the operating system, or remote control abilities to the domain controller. There are a lot of advantages to having SMS client software on a domain controller.

Outside that, there are not a lot of other things you can do. There is a section in the security essentials white paper on controlling the SMS accounts. There are a couple of topics in there for reducing accounts, which primarily get into the server connection account and the client connection account. There are not a lot of other accounts you can reduce, unfortunately. We are aware of that. In future versions, we're trying to work through ways of still having good security, but not having as many SMS accounts. Look for that in the future. Other than that, look at the security essentials white paper for a couple of other ideas.

Barbara: Excellent. Our next topic is asking about logs not being initiated automatically during site set up. The question is: If we are to use the logs to primarily troubleshoot site system setup security issues, then why doesn't Microsoft enable logging by default, instead of having to institute the use of a Dialme.sms type file on site servers? Otherwise, there are no logs to look at if you run into problems.

Wally: The first thing I'll say is that we do not want you using the file specified in this question. We don't want you using it. It was really implemented for testing and for PSS to get log files set up automatically for you. I would caution you not to get in the habit of implementing this file to turn on logging. The reason is because the next release of software may not use this file, and you may expect log files to be turned on, and they won't be.

The proper way of enabling log files is install your site server, go to SMS Service Manager inside the admin console, select your site code, and select all the components that turn on logging. That's the proper way. That works in Service Pack 2. Yes, there are some issues in prior releases where you couldn't connect, like in RTM code, it didn't work very well. But in SP2 and SP1, it works fairly well, and that's the proper way of doing so.

The other supported method of enabling logging, which is not this file method, is to create a registry script and use a registry script that will just go through and update the registry file itself and turn on logging. I believe there are some registry scripts floating around different places to do that.

Now the reason why we don't turn on logging by default is that for those customers who don't have the ability to get high-powered site server hardware, by enabling logging on lower-end hardware, it can definitely degrade your site server performance. When I was talking to the developer about this years ago, he stated that in the hardware that was available at that point in time, by enabling logging and having all the log files turned on and by default, the server log files can grow to a megabyte in size before they roll over and create another megabyte of backup data, and that could affect the performance of the site server components. He said it could affect it by up to 10 percent. You wouldn't want your site server performance being downgraded or affected by any percentage, let alone 10 percent, depending upon the hardware you have.

Now if you have some current hardware, PIII 600s, or something higher than that with 512 MB or RAM or a 1 GB of RAM, you probably won't notice the impact of having logging enabled. It probably won't be an issue at all. However, if you look at the SMS box itself, and if you look at the system requirements, I believe it says something like a Pentium 90 with 64 MB of RAM. If you're trying to run SMS on a Pentium 90 with 64 MB of RAM, and then you turn on logging, you will definitely notice the impact on logging at that point. That's why we don't turn them on by default.

You would use the SMS Service Manager to turn on logging, or a registry script. That would turn on logs when you needed them.

Now the other nice thing about SMS is if you need log files to troubleshoot some issue, then SMS generally retries all processes at some period of time. Even if you don't have logging turned on right now, and then you find some error, you can turn on logging and then either force SMS to re-create the issue or try the problem again, or SMS will do it on its own. You will have the same thing logged. That's one of the advantages of SMS. Even if you don't have logs turned on by default, you can turn them on, and you will be able to see the information that you need.

Barbara: Wonderful information. Moving on, the next question is: What rights are required for WMI access?

Wally: To give somebody rights to WMI, the easiest way, again, is to drop them in the SMSAdmins local group. That's absolutely the easiest way of doing so. If you do that, then there's nothing else you have to do, and they have the rights to WMI or SMS Provider, and then you can set up your SMS security rights.

Outside of that, if you want to use Wbemperm.exe or WMI control in Windows 2000 to set your rights, then for Wbemperm.exe what you need to do is give them the access of Execute Methods. It's Execute Methods, and then you need to have Write Instance. There's an option there called schema access level. Under schema access level, you set Write Instance.

For Windows 2000 and WMI control, all of your rights are basically set by default for the Everyone group, so it's not as big of an issue, other than Remote Enable. For somebody coming in remotely, if they don't have the ability of remotely connecting up to the SMS Provider, you would just have to select the remote enable. However, in Windows 2000, the rights are set by default; it actually sets a lot of different rights, such as Execute Methods, Full right, Partial right, Provider right, and so on. What you would have to have for Windows 2000 and WMI control is Execute Methods, Provider right, Enable Account, and Remote Enable. Those again are set by default for you for the SMSAdmins local group. Just run SMS, drop the account in there, and you're all set.

Barbara: All right. Our next question is about Wbemperm rights for MMC. This one asks: Could you please repeat the two rights granted in Wbemperm.exe to allow connecting an MMC to a site database? One was Execute Methods, but I didn't catch the second.

Wally: Yes. It was what I just covered. These two questions are basically the same. The two rights for Wbemperm.exe specifically in a Windows NT 4.0 environment are Execute Methods, then you go to the Schema Access Level, which is a drop-down list, and you select Write Instance. Execute Methods and Write Instance. If you forget, the easiest thing to do is just look at the rights for SMSAdmins, because SMSAdmins by default is going to be added to there. When you look at Wbemperm.exe, you'll see SMSAdmins. Just open it up and look at its properties and you'll see Execute Methods. Under Schema Access Level, it's Write Instance. You do those, and you're all set.

Barbara: Great. Our next question is about a connection to site server. Is there any way possible to connect an admin console to a site server in an untrusted domain? I am unable to make this work. Both domain admin user names and passwords are identical. SQL Server 7.0 can connect just fine. However, SMS 2.0 can't. Any information that you might have would be appreciated.

Wally: If your administrator account is fine, then you should be set. What you need to have is a logged on user. If you're at the admin console connecting up to a site server in an untrusted domain — so the logged on user account would have to be a valid administrator account in the remote site or have SMSAdmins rights, as well as whatever the rights you want inside the SMS Administrator console. But we do this all the time in the classroom environment, we just have everybody log on to the administrator, and then they're able to connect up to somebody else's site.

Again, your logged-on user account needs to be a valid administrator or have the appropriate rights in SMSAdmins. In our case, we use Administrator in the classroom environment. Administrator is a local administrator account, obviously. It would pass through it. It does require local administrator rights, which gives it WMI rights automatically. You are able to connect.

If you're saying both domain admin users names and passwords are identical, that means the logged-on user account is identical. Then that should be all you need, provided, again, you do have the remote access. As long as the admin account can locally open up the SMS Administrator console, it should remotely, unless there's something under the covers that's causing the validation not to occur.

You might want to try remotely connecting to Admin$ and verify that you can connect as an admin. Maybe the account name is correct, but the account is not an admin in the remote site, or maybe it's already connected as a user account, and then you don't have admin permissions because of credentials conflicts. Those are the only things I can think of off the top of my head, because we do it all the time in our classroom, and it works perfectly for us.

Barbara: All right. That sounds good. Our next question is about SQL security. The question is: What is the recommended level of SQL security? Is it to leave it as the defaults?

Wally: That totally depends on you as an administrator and your theory on security. The default is for SMS to use standard security. Standard security is recommended if you're more concerned about security. If you're concerned about security and controlling who has access to what in SMS, then standard security has an advantage, because you can control the user logon IDs and specifically what access they have inside SQL Server, because you're creating the SQL logon IDs and specifying what the user is and who they can access as.

Integrated security is the recommended mode in most cases, because it's easier on the administrator. You don't have to go into SQL Server and create SQL logon IDs and control those logon IDs and their rights. If you're an administrator for Windows NT or Windows 2000, your administrator is SQL. If you're a user in Windows NT or Windows 2000, you're a user in SQL Server. SQL Server just inherits whatever rights you have as a standard user.

For ease of use, integrated security is recommended. For more controlled, secure environments, standard security is recommended. It goes down to what your requirements are. As a general rule in our documentation, you'll see that we state integrated security is recommended. Again, that's because of ease of administrative use. There's less intervention in that environment. But if you want to go with standard security, there's nothing at all wrong with that, other than the fact that you have to be more concerned about logon IDs and who can do what. Other than that, it's your choice.

Barbara: Excellent. Thank you. Just a quick note here, if you do have suggestions for topics for future Support WebCasts, you can send those to us using the feedback@microsoft.com alias, and be sure to include "Support WebCast" in the subject line.

Moving on to our next question, the question is: How can SMS Server Manager be used to manage secondary sites installed on domain controllers where the SMS admin is not a domain admin?

Wally: You've got a secondary site that's installed on the domain controller, but the SMS Service account is not a domain admin. That's fine, provided this is a Windows NT 4.0 environment. On Windows 2000, we do not support the SMS Service account not being a domain administrator. So, in a Windows 2000 environment, we do require the SMS Service account to be a domain admin. But in a non-Windows 2000 environment, in other words Windows NT 4.0, we do support local administrator accounts.

Again, it doesn't have to be a domain admin in this case. It could be a local administrator. It's the logged-on user account that you're going to set up and use for permissions down to connecting up through service manager down to that remote site server. Your logged-on user account needs to have rights to connect up to the WBEM database, or basically some repository at the secondary site server, and being able to validate the security rights that that user does have access to the Sites class. You don't have to be a domain admin.

You do have to be a local admin to be able to connect up through WMI to a secondary site, however. You do need to have A local administrator account. You'd have to have an account at your primary site that would be a local administrator to the secondary site that you could log on as. Then that account would have to have rights to the Sites class for that secondary site. That does work.

In one of my training courses, I wrote a lab on using SMS Service Manager to connect to (we used primary sites in the class instead of secondary sites) a child site with those environments, working with different logged on user IDs and basically making it a remote administrator — not domain admin, but local admin, and using it remotely. Then we give it Modify rights to the Sites class, and you're able to connect to be able to see the services, the servers, and then control the threads, as well as logging at that secondary site server. Basically, the account needs to be a local administrator and then have rights to the Sites class at that secondary site.

Barbara: Thank you very much, Wally. The next question is: Is it possible to move the SMS Provider from one computer to another?

Wally: Yes. You can move it from one remote SQL Server computer to another remote SQL Server computer. However, you cannot move the SMS Provider from a remote SQL Server computer back to the SMS site server. Once it's installed on a remote SQL Server computer, you can't move it back to the site server, currently. However, if you go tell SMS, "I don't want to use SQL Server A, I want to use SQL Server B," then we'll automatically de-install the SMS Provider from SQL Server A and reinstall it over on SQL Server B. We just don't allow you to move it back to the site server, once it's been installed remotely.

Barbara: Moving on to the next question, it is about SMS queries and collections. After I upgraded from SMS 2.0 SP1 to SP2, my custom collections broke. I noticed a difference in the query languages between my custom collections and the canned collections. I have always used the wizards to create the collections. If I redo the collections, they once again work. What changed to break these custom collections?

Wally: Honestly, I have no idea. I have never heard of this occurring before, where when just upgrading from SP1 to SP2 your custom collections broke. I have not heard of that. I know we redo some stuff in the site database, but I've not heard of that causing any problems with the query language or anything else with the queries. Honestly, I have absolutely no idea for you why that broke. I'd have to go talk to somebody and see if anybody else had ever experienced that before, because I've never heard of that before.

Barbara: This sounds like it might be more a support issue, so I would recommend to this customer that they go ahead and call Product Support Services or initiate an incident on the Web and talk to the Product Support Professionals to get an answer to that.

Moving on to the next question, it's about account domain. Do you need an SMS Service account set up in both a resource domain and an account domain if all SMS servers are in the resource domain? In other words, can I eliminate the account domain SMS account?

Wally: When you install SMS 2.0, you're allowed to specify the domain and the name of the account that you want for your SMS Service account. Most people do put that in their Accounts domain, because they want the accounts primarily created and managed in one location. However, you should be able to put your SMS Service account in your Resource domain and then have all your accounts there.

When you run setup, it automatically detects what domain you're in. It detects your resource domain, and it should place that account in that resource domain itself. So if you're set up in that environment now, you should be able to create an account in the resource domain to be your SMS Service account. Then run a site reset. The first option in the site reset is what your SMS Service account is. You should be able to go in and specify the appropriate properties there.

Yes, you should be able to have just an account in your resource domain, and not in the accounts domain, and work through that. Again, if it's a Windows NT 4.0 environment, you can make that a local administrator account, as opposed to a domain administrator account, if you're trying to improve the security there. Obviously, if you're on a domain controller, then it's going to be a local administrator in the domain anyway. But you still can move it from the Domain Admins group.

Barbara: All right. That sounds like a great answer. As we move on, our next question is about connecting the SMS Service Manager tool to an SMS secondary site. The specific question is: How can SMS Service Manager be used to manage SMS secondary sites installed on domain controllers where the SMS Administrator is not a domain admin?

Wally: Yes. It looks to be the exact same question. Again, the SMS Administrator doesn't necessarily have to be a domain admin. The logged on user account is what's used to connect through SMS Service Manager to the secondary site or the child site. This logged on user account needs to be an administrator, and have rights to the Sites class at the child site.

Barbara: Very good. This time their question is: Is there a way to avoid giving class rights when assigning Read and other rights to an instance, say a collection, for example?

Wally: When you create an Instance right to a Class object, such as a Collection, in this case, when you create an Instance right, we are going to automatically create a Class security right for you for that same class. You cannot prevent that from happening. We do create that for you automatically. Yes, we do understand that basically doubles the number of security rights that you create when you create Instance rights by creating Class rights of that same class for you, but giving no permissions. We do do that automatically. Like I said before, it's a standard byproduct of the security system. There's not much you can do about it.

We are looking at that. One of the things we're doing for the next release of SMS is performing something we call a security sweep, where we go through and look at all of the security-related aspects in the admin console and figure out what we can do to modify how SMS is currently designed from that aspect. That's one of the things they've talked about looking at. I don't know if they'll change that or not, but yes, we do understand that. You could probably go in there and delete that. I never tried going in there and deleting that class right that was created with no permission. I don't know that it would have any detrimental effect, but again, I haven't tried it. That may be something you'd want to test, and not do it as a general rule, until you can see if that causes any negative effects or not. We do create that class right with no permissions automatically for you.

Barbara: Good information. Our last question at this time is about restricting server accounts. Do you recommend restricting the SMS&_dc name to their respective servers to run the client services on them, due to the security risk of them being local admin accounts on those servers?

Wally: I guess I don't really understand the question, because that account, the SMS&_dc name account, is the client service account for a single domain controller. It is already restricted to a specific server. It's not allowed to be shared with any other server, or any other domain controller, because you don't know what the password is. So when we install the SMS client service on each individual domain controller, we create a separate client service account for that domain controller, with the syntax of SMS&_ and the domain controller name. If you have 100 domain controllers, you'd have 100 of those accounts, because each is a local administrator account, and we're trying to again separate the context of the SMS client functions from other computers and not cause problems, so we have separate client service accounts. They are already restricted to an individual server. There's nothing else for you to do with that, because it is already restricted.

Now if your question is can you use that same account for multiple computers, the answer is no, because of the fact that we randomly generate passwords for those accounts. You don't know what the password is. So you couldn't go in there and specify for two domain controllers to use the same SMS Client Service account for domain controller. So you couldn't do that.

Other than that, I guess I don't know what the issue is in the question, because we already do restrict it that way.

Barbara: If you do have additional questions, as I mentioned earlier, you can submit an incident on the Web to help you with specific troubleshooting issues.

That means that we have answered all of the questions that were submitted today. That is going to wrap up our session.

Again, I encourage all of you to submit your feedback to us. Let us know what you think about the program, this session, and the other sessions that you've seen. You can do so using the feedback@microsoft.com alias. Please include "Support WebCasts" in the subject line.

I want to thank all of you for joining us, and I do hope this information was useful to you. We hope you'll join us again in the near future. Thank you, and good-bye.