For software distribution to occur in Microsoft System Center Configuration Manager 2007, Configuration Manager 2007 creates a package, program, and advertisement. If the package contains source files, the administrator must copy the package to a distribution point. By default, the access control lists (ACLs) on the file are set to allow Administrators Full Control and Users Read access. It is possible to change the package access, but you should understand how Configuration Manager 2007 attempts to access the packages in various scenarios so that you can reduce the chance of allowing unauthorized users access to restricted packages or denying valid users access to packages they need to get their jobs done.

Before reading these scenarios, you must be familiar with basic Windows concepts such as users, groups, ACLs, and forest architecture. You should also be familiar with the concepts of software distribution described in Software Distribution Overview.

This topic contains the following common scenarios:

These scenarios do not contain examples of roaming between sites. Package access still follows the same process whether the client is roaming or not. For more information about roaming, see Example Roaming Scenarios for Configuration Manager: Simple and Example Roaming Scenarios for Configuration Manager: Complex.

Hierarchy Used in All Scenario Examples

The following diagram shows one Configuration Manager site with six different domains and an Internet-based user.



graphic showing hierarchy for the example

Advertisement Configured to Run from the Distribution Point

Todd receives an advertisement configured to run from a distribution point. The management point returns SJC-DP1 in response to the content location request.

When an advertisement is configured to run from the distribution point, the file access is always over server message blocks (SMBs), even in native mode, and Windows authentication is used instead of certificate authentication.

Todd is in a trusted domain in the forest, but he is in a different domain than SJC-DP1. Whether Todd can access the package depends on whether the administrator has configured the local, domain local, universal, or global groups to permit resources in dev.corp.contoso.com to access the server in corp.contoso.com. Todd's access also depends on the Package Access Accounts configured by the Configuration Manager 2007 administrator to automatically set the ACLs on the package directory.

If Todd's computer account and his user account cannot access SJC-DP1, Todd might still access the package if the administrator has configured a Network Access Account and if the Network Access Account has permissions to the package directory based on the Package Access Account configuration, either directly or through group membership.

Note
There is no need to add the Network Access Account as a Package Access Account because it is a member of Users and therefore included by default. Also, restricting the ACLs of a package to only the Network Access Account does not prevent any client from accessing the package because Configuration Manager 2007 clients can request use of the Network Access Account when necessary.

Accessing the Package from a Different Domain

Referring to the flowchart in Package Access Flowchart When Running from Distribution Point, the following process is used to evaluate Todd's access to the package.

Is program configured to run with admin rights?

No.

Do package permissions allow logged-on user access?

No. The administrator has neither added the dev.corp.contoso.com Domain Users group to the local Users group on SJC-DP1 nor configured any other group access that would allow Todd's user account to have direct access.

Is there a Network Access Account configured?

Yes. Todd's administrator has created an account in the corp.contoso.com domain and configured it to be the Network Access Account in the Configuration Manager 2007 console.

Do permissions allow the Network Access Account access to the package directory?

Yes. Todd's administrator has not modified the default Package Access Accounts, so the ACLs on the package directory allow Users Read access and Administrators Full Control. The Network Access Account is a user in the corp.contoso.com domain.

Tom's computer uses the Network Access Account to connect to SJC-DP1 for purposes of running the package.

Is this a Windows Installer package? (Is the installation file in .msi format?)

Yes. The application is an internal application, and the internal development team created a Windows Installer package.

Do package permissions allow Todd-PC$ to access the package directory?

No. The administrator has not configured any groups or Package Access Accounts that would allow Todd-PC$ to access SJC-DP1.

Is there a Network Access Account configured?

Yes.

Do permissions allow the Network Access Account access to the package directory?

Yes. The Network Access Account has already been able to connect to the package shared folder on SJC-DP1, but because the installation file is a Windows Installer file, the Configuration Manager 2007 client assumes that the installation will require Administrative rights on Todd-PC. When the program runs, any actions that require administrative rights will connect to the distribution point using the Network Access Account. On Todd's computer, the program runs under Todd's user account, because the program was not configured to run with Administrator rights.

Todd successfully installs the package.

Accessing the Package from the Same Domain

If Cliff tries to run the same advertisement with his account in corp.contoso.com, he does not need the Network Access Account. The Configuration Manager 2007 client components connect to SJC-DP1 using his own user account, and if there are actions that require elevation, the client connects using the Cliff-PC$ account.

Accessing the Package from a Trusted Forest

If April tries to run the same advertisement with her account in treyreasearch.net, she will have a similar experience. Even though there is a forest trust between corp.contoso.com and treyresearch.net, the administrator must either configure appropriate access using groups and Package Access Accounts or configure a Network Access Account; otherwise, April cannot access the package.

Accessing the Package from an Untrusted Forest

If Torsten tries to run the package from adatum.com, he cannot be granted access using groups and Package Access Accounts because there is no trust between adatum.com and corp.contoso.com. In this scenario, if there is no Network Access Account with appropriate ACLs, Torsten cannot access the package.

Advertisement Configured to Download and Run from Cache

When advertisements are configured to download and run from the local cache on the client computer, several factors influence which account is used to download the package. However, the package always runs with either the Local System security context, if the program is configured to run with admin rights, or with the logged-on user's security context, regardless of the account used to download the program.

Important
Before you read this section, you should read About BITS-Enabled Distribution Points and understand the virtual directories created on Binary Intelligent Transfer Service (BITS)-enabled distribution points to support native-mode clients.

Accessing the Package from a Trusted Forest

Marcus has an advertisement to download a finance application and run it locally. Referring to the flowchart in Package Access Flowchart When Downloading from an Intranet Distribution Point, the following process is used to evaluate Marcus' access to the package.

Is the site in native mode?

Yes. All domains are in the SJC site, and the site is configured for native mode.

Is SJC-DP1 BITS-enabled?

Yes. The administrator has configured all distribution points in the SJC site to be BITS-enabled to improve download efficiency.

Does the client connect to the Windows authentication virtual directory (SMS_DP_SMSPKGE$) or the certificate authentication virtual directory (NOCERT_SMS_DP_SMSPKGE$)?

The client randomly selects the SMS_DP_SMSPKGE$ virtual directory.

Can the security context access the client certificate private key?

Yes. Marcus is logged on as a local administrator, so his user account can access the private key of the client authentication certificate.

Do package permissions allow the Internet Guest (IUSR) account access to the package directory?

No. By default the Internet Guest account would be a member of the Users group on SJC-DP1 and therefore could access the package. However, the administrator has changed the default Package Access Accounts. Users are not permitted to read the package directory on SJC-DP1, but members of the Finance domain local group are. The IUSR account is not a member of the Finance security group.

Note
Allowing anonymous access to package content is not considered a significant risk because the client must first be authenticated by a valid client authentication certificate before accessing the package content by using the IUSR account.

Is the program advertised to a user or a user group?

Yes. The advertisement is sent to a collection that contains only users in the Finance security group.

Do package permissions allow Marcus to access the package directory?

No. Even if there were groups configured to allow Marcus' account to be a member of the local Users group on SJC-DP1, the administrator has removed the ACL for Users. Marcus can access the package directory only if he is a local administrator on SJC-DP1 or if he is a member of the Finance domain local group.

Do package permissions allow the Network Access Account access?

No. The Network Access Account is not a member of the Finance group. If the administrator had violated best practices and added the Network Access account as a Package Access Account, Todd would be able to access the package even though he is not a member of the Finance group.

Do package permissions allow Marcus-PC$ to access the package directory?

No. Marcus-PC$ is neither an administrator nor a member of the Finance group.

Do package permissions allow the Network Access Account access?

Even though the Configuration Manager 2007 client has already attempted and failed to use the Network Access Account to reach the package directory, the client tries again.

If in native mode, have we already attempted to connect to the SMS_DP_SMSPKGE$ virtual directory?

Yes. The client randomly attempted the SMS_DP_SMSPKGE$ directory first. If the client had started with the NOCERT_ SMS_DP_ directory, the client would then attempt to authenticate the client using a certificate, which would succeed. Then the client would attempt to download the package by using the Internet Guest account, which would fail. The result is the same: Marcus cannot download and run the program.

Accessing the Package from the Same Domain

Cliff tries to run the same advertisement. Cliff is a member of the Global Finance Users group, which is a member of the Finance domain local group on SJC-DC1. Cliff's client randomly connects to the SMS_DP_SMSPKGE$ virtual directory and is authenticated using the client certificate. However, the IUSR account is not a member of the Finance group, so the client fails over to the NOCERT_ directory. Because the ACLs on the package directory allow Finance users Read access, Cliff is allowed to access the package.

Accessing the Package from a Different Domain

Todd fails to run the advertisement because he is not a member of the Finance group. When his client connects first to the NOCERT_SMS_DP_SMSPKGE$ virtual directory, his access fails because his account, the Network Access Account, and his computer account are not members of Finance. Even though Windows authentication failed, the client attempts access using the NOCERT_SMS_DP_SMSPKGE$ virtual directory with certificate authentication. However, IUSR is not a member of Finance, so Todd cannot access the package.

Accessing the Package from an Untrusted Forest

Torsten cannot be a member of the Finance group because there is no trust with the Adatum.com forest, so Torsten cannot successfully download and run the finance program. If the package truly should be restricted to Finance users, this is the desired result. If the administrator added IUSR to the list of package access accounts, Torsten would be able to access the package certificate using authentication and anonymous access.

Important
In native mode, adding IUSR to the Package Access Accounts allows clients authenticated by certificates to bypass all other Package Access Accounts. In mixed mode, only Windows authentication is used, so adding IUSR to the Package Access Accounts does not allow clients to bypass all other Package Access Accounts.

Assume that the administrator creates a new advertisement for Microsoft Office 2003 but does not change the Package Access Accounts. The administrator also changes the Network Access Account in Active Directory Domain Services but does not reconfigure the account in the Configuration Manager 2007 console. When Torsten-PC attempts to run the advertisement, the following process is used.

Is the site in native mode?

Yes.

Is SJC-DP1 BITS-enabled?

Yes.

Does the client connect to the Windows authentication virtual directory (SMS_DP_SMSPKGE$) or the certificate authentication virtual directory (NOCERT_SMS_DP_SMSPKGE$)?

The client randomly selects the SMS_DP_SMSPKGE$ virtual directory.

Can the client be authenticated using a client certificate?

Yes. Torsten-PC has a valid client authentication certificate for native mode.

Do package permissions allow the Internet Guest (IUSR) account access to the package directory?

Yes. By default, the Internet Guest account is a member of the Users group on SJC-DP1, so it can access the package even though there is no trust relationship and the Network Access Account is not valid until the administrator configures the correct password. If Torsten's client had connected to the NOCERT_SMS_DP_SMSPKGE$ virtual directory first, it would have tried to authenticate Torsten by using Windows authentication. When that failed, it would have fallen back to the SMS_DP_SMSPKGE$ directory and would have been authenticated by the certificate.

Internet-Based Clients Running Advertisements

Internet-based clients can only download and run advertisements; they can never run them from the distribution point.

Intranet clients randomly select between the SMS_DP_ and NOCERT_SMS_DP_ virtual directories; then they fail over to the other virtual directory if the first one fails to provide authentication and access to download the content. Internet-based clients receive only the SMS_DP_ virtual directory on distribution points that are enabled to support Internet-based clients. If clients cannot be authenticated using a certificate, they cannot download the package. This is by design, to require certificate authentication for Internet-based clients.

If the logged-on user is an administrator, the user can access the local certificate store to present the client authentication certificate to the distribution point. If the program is initiated on a schedule, the program is initiated by the Local System account, which can access the local certificate store to present the certificate.

If the Internet-based client can present a certificate for native-mode authentication, the IUSR account must still have permissions to access the package directory or the program will fail.

Ed has an advertisement to download the corporate antivirus application and run it locally. The following process is used to evaluate Ed's access to the antivirus package. (See the flowchart in Package Access Flowchart for Internet-Based Clients.)

Is the site running Configuration Manager 2007 SP1 or later?

No.

Note
In Configuration Manager 2007 SP1 and later, advertisements can run without being scheduled, even if the logged on user is not an administrator.

Is the logged-on user a local administrator?

No. Following best security practices, Ed logs on as an ordinary user on his Windows Vista computer and uses User Access Control when he needs administrative access.

Is the program configured to run as a scheduled assignment?

Yes. The antivirus program runs weekly.

Because the program is scheduled, it runs within the Local System context. Local System has rights to access the private key of the client authentication certificate to prove its identity to the distribution point.

Is the private key authenticated?

Yes. The client authentication certificate is from a trusted CA.

Do package permissions allow the Internet Guest account access to the package directory?

Yes. The administrator has not changed the default Package Access Accounts. The package is downloaded using anonymous access.

Is the program set to run with administrative rights?

Yes. The administrator configures the program to run whether or not the user is logged on.

The program runs within the Local System security context.

Ed needs access to the finance application. He receives the advertisement to download the finance application and run it locally. The following process is used to evaluate Ed's access to the package. (See the flowchart in Package Access Flowchart for Internet-Based Clients.)

Is the site running Configuration Manager 2007 SP1 or later?

No.

Is the logged-on user a local administrator?

Yes. Ed has logged on as the local administrator to receive this package.

Because Ed is an administrator, he has rights to access the private key of the client authentication certificate to prove its identity to the distribution point.

Is the private key authenticated?

Yes. The client authentication certificate is from a trusted CA.

Do package permissions allow the Internet Guest account access to the package directory?

No. By default, the Internet Guest account would be a member of the Users group on IBCM-DP1, so it could access the package. However, the administrator has changed the default Package Access Accounts. Users are not permitted to read the package directory on IBCM-DP1, but members of the Finance domain local group are. The IUSR account is not a member of the Finance security group.
Important
Internet-based clients must use certificates to authenticate and then download the package using anonymous access, so Package Access Accounts cannot be used to restrict access based on user or group accounts.

Administrators have to consider the desired outcome when removing default Package Access Accounts on packages copied to distribution points supporting Internet-based clients. If the package should be restricted to members of the Finance group, Ed's failure to access the package is the desired result. If the Internet-based user must access the package, the Internet Guest account must have NTFS permissions to access the package source files.

See Also