次の方法で共有

Tips, Tricks & Hints for Native Mode and Internet-Based Client Management - Part 2 of 3

  • [アーティクル]

This is the second part of my round-up to date of FAQs and gotchas for native mode and Internet-based client management that I hope will help you be successful with these features.

Tips, tricks and hints covered:

Part 1 of 3

  • You can’t run a native mode client on Windows 2000
  • Don’t install clients using auto-site assignment and specify the Internet-based management point
  • You can’t use a single Internet-based management point for multiple primary sites

Part 2 of 3

  • “We have a security policy that no traffic from the DMZ is allowed towards servers on the intranet. Is there an IBCM design that supports this?”
  • Certificate configuration for Internet-based site systems on the intranet that only manage mobile device clients
  • The option “Specify or modify a DNS suffix for site assignment” has nothing to do with site assignment
  • The behavior of CCMFIRSTCERT=1 (option “Select any certificate that matches”) is changing in SP1

Part 3 of 3

  • CRL complications for Internet-based client management
  • “Can you update the step-by-step to include ….?”

“We have a security policy that no traffic from the DMZ is allowed towards servers on the intranet. Is there an IBCM design that supports this?”

I’ve seen this question asked in a variety of ways, but it boils down to asking what options are available in the design of Internet-based client management to help mitigate Internet traffic posing a risk to your intranet.

There isn’t a simple answer to this question, especially as it’s phrased above because it depends exactly on what is meant by “no traffic from the DMZ is allowed towards servers on the intranet” – so you have to get really specific. Do they mean no traffic is allowed between these two networks at all, or do they mean that servers on the intranet must not accept connections that are initiated from the DMZ?

If the first option, then you have to put the whole hierarchy in the DMZ, so that it looks like this: https://technet.microsoft.com/en-us/library/bb632624.aspx. This might be suitable if you only need to manage Internet-only clients (they never connect to the intranet and do not need the full Configuration Manager feature set). However, most customers want to manage clients when they move between the intranet and Internet, and want the ability to manage all their clients from a single point (the central site in the hierarchy). If you need a refresher on which features are not supported for Internet-only clients, see Overview of Internet-Based Client Management.

If the second option, or if you can convince your security team that the business benefits of this design outweigh the security risks, then you can split your Internet-based site between the DMZ and intranet, using the configuration in this diagram: https://technet.microsoft.com/en-us/library/bb694250.aspx.

There are 9 supported designs for Internet-based client management, and after you have determined whether you need to support both Internet and intranet clients, it then comes down to weighing pros and cons. The bad news is that there is no single solution that will suit everybody because higher security comes at the cost of more configuration and possibly more servers. The good news is that you have design options to give you room to negotiate. You need to sit down with your security folks and work out the best business solution after weighing the pros and cons – or get a consultant in to help with this. You can use the topic Determine Server Placement for Internet-Based Client Management to help with the choices and perhaps print out the diagrams so that the network connections for each are clearly identified.

Certificate configuration for Internet-based sites on the intranet that only manage mobile device clients

Configuration Manager mobile device clients, unlike Configuration Manager client computers, cannot support the configuration “Internet or intranet management”. That is, they don’t behave as intranet clients when they are on the intranet and automatically behave as Internet-based clients when they are on the Internet. If you want to manage mobile device clients over the Internet, then even when they connect to the intranet they behave as if on the Internet and communicate with the Internet-based management point (configured for device management) and Internet-based distribution points.

Because the Internet-based site systems only support connections for Internet clients, they need a certificate that specifies the Internet FQDN - even though the servers are in the intranet. We’ve had reports that this is tripping up some customers who expect the FQDN in the Subject name to be the intranet FQDN because the site system is in the intranet. However, the FQDN to use isn’t dependent on the server location, but on the type of client connection that the site system is configured to use.

The option “Specify or modify a DNS suffix for site assignment” has nothing to do with site assignment

OK, strictly speaking this isn’t a native mode or Internet-based option – this option is mode independent. But I’ve had at least one person assume that the reference to DNS was linked to Internet-based client management, and that they needed to specify this for assigning a client to an Internet-based site. And I know lots of customers who have been confused by this option, so adding this to my native mode & IBCM list gives me an opportunity to get this off my chest: This option does not do what it says on the tin.

This option is used only with DNS publishing for the default management point. Clients find their default management point after site assignment, which is why this option is unrelated to site assignment (so if your client fails to assign correctly, don’t waste time trying different values for this option).

If you are using DNS publishing as the means by which clients find their management points, then you have to specify the DNS suffix in this value for the client – even if the client is in the same domain as the management point. Additionally, you must install them using direct site assignment. For more information, see the following topics:

The F1 help accurately describes what this option does. However, not everybody uses the F1 help and even if you do, I know it’s confusing to read an explanation that doesn’t seem to match with what you’re seeing in the UI. In the majority of cases, the confusion doesn’t stop anything working. But when something else isn’t working, or you’re trying to make design decisions, I know it’s very frustrating to be lead down the wrong path by confusing UI text. If I could go in and make a change to this UI text myself, I would – but on balance, it’s probably a good thing that I can’t!

The behavior of CCMFIRSTCERT=1 (option “Select any certificate that matches”) is changing in SP1

If a Configuration Manager client has more than one suitable certificate for native mode, you can use the configuration above to select any certificate. This isn’t the most reliable configuration option (so it’s not enabled by default) because the client might pick a certificate from a CA that isn’t trusted by the native mode site systems – and communication will fail. But a number of native mode customers have used this option successfully without having the complication of identifying and configuring a suitable certificate selection criteria.

Then we discovered a potential problem when using native mode and NAP with IPsec enforcement. IPsec enforcement also uses PKI certificates that include client authentication and the FQDN of the client computer – but these certificates have a very short validity period. This makes them unsuitable to be used for native mode communication if they are selected with the CCMFIRSTCERT option.

To better support native mode in a NAP-enabled environment, the behavior of CCMFIRSTCERT is changing in SP1 so that instead of selecting a valid certificate at random, a valid certificate with the longest validity period is now chosen. If this still results in a choice of multiple certificates (they have the same validity period), then one of them is chosen at random. This makes it very unlikely that a NAP IPsec certificate with a short validity period will be chosen for native mode.

The documentation has been updated with this change of behavior, and you’ll see it listed in the documentation library that accompanies the SP1 beta 1 release, in the topic “What’s New in the Configuration Manager Documentation Library for January 2008”.

Chances are, this change won’t affect you – but it might under the following circumstances:

If you were using this option and then upgrade the client to SP1 - there’s a good chance a different certificate will be selected. If your native mode site systems trust all the certificates that your clients have installed, this won’t be problem. The new certificate selection will happen automatically and without noticeable impact. However, if a certificate is now selected that comes from a CA untrusted by the native mode site systems, client communication will fail until you do one of the following:

  • Delete the certificate that isn’t trusted by the site system – on the assumption that it’s not needed for something else outside Configuration Manager!
  • Configure the site systems to trust the CA (for example by adding the CA to the CTL or by installing the root CA) – on the assumption that the CA is trusted and suitable for native mode.
  • Configure a certificate selection criteria using a string or attributes to uniquely identify the certificate that should be used for native mode. If you need help with this, see Determine If You Need to Specify Client Certificate Settings (Native Mode). If you define this on the Site Mode tab and you’re publishing to Active Directory Domain Services with Configuration Manager 2007 schema extensions, clients that can access site information from Active Directory Domain Services will be automatically reconfigured. But for clients that this doesn’t apply to, you will have to reinstall them. Client push will automatically include this configuration, but if you’re installing manually, you will need the client installation propery CCMCERTSEL. For more information, see How to Specify the Client Certificate Selection Criteria. Test and make this configuration change before upgrading the native mode client to SP1.

 

If you were not using this option and then upgrade a native mode client to SP1, and plan to use NAP with IPsec enforcement – you will probably need to use this configuration option. Don’t make the configuration change before upgrading the native mode client to SP1 in case an unsuitable certificate is selected. But do bear it in mind and factor it into your testing when you do upgrade to SP1.

 

- Carol Bailey

This posting is provided “AS IS” with no warranties and confers no rights.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    This is the final part of my round-up to date of FAQs and gotchas for native mode and Internet-based