NAC SCCM/WSUS intergration

[alan_fisher]

Hi,

I'm looking for some information on integrating our current NAC infrastructure with our SCCM software updates.  We have NAC polling Windows Update and this works ok, but this does not allow us to poll for 3rd party updates that are published to WSUS/SCCM.

Has anyone accomplished this? If what can you explain what was done to make this work?

our Goal is to have NAC Check our Local SCCM/WSUS database (which has 3rd Party updates published to it), and determine if it is clean or not, and trigger the SCCM agent to remediate it!

[LawrenceGarvin]

It can be done, Alan, but you might find the implementation with the NAC infrastructure to be easier to do using a standalone WSUS server, rather than ConfigMgr. In order to implement remediation with the ConfigMgr/SUP infrastructure, the NAC client will need to have a working ConfigMgr agent installed, and be configured to communicate with the SUP, a Management Point, and a Distribution Point... all accessible within the NAC framework.

Alternatively a standalone WSUS server, which can be configured with only those updates relevant to the NAC policies, would not require accessiblity to the remainder of the ConfigMgr infrastructure (i.e. MP, DP). However, would still be challenged if the client connecting thru the NAC is, already, a ConfigMgr client (because that client will be configured to use the SUP).

In the end, if you need to support both CM-enabled and non-CM-enabled clients within the NAC, you'll likely need both capabilities.

[patrickbolt]

Lawrence,

I'm struggling with the same problem. Would I be able to work around this issue by simply approving updates on my existing WSUS server that are relevant to the NAC policies ? We're using group policy to disable automatic updates on our clients so I'm thinking that should prevent any issue with the clients updating from SCCM and WSUS. Will this cause any problems with SCCM?

Any insight you can provide would be greatly appreciated.

[LawrenceGarvin]

Not really, Alan.

If the client is configured as a Configuration Manager client, and Software Updates is enabled, the client will [a] scan the WSUS Server to determine needed updates, and [b] try to get those updates from a Configuration Manager Distribution Point, and [c] try to report patch status back to a Configuration Manager Management Point.

Even if the client were not configured as a Configuration Manager client, messing with approvals on a CM Software Update Point is a risky business.

[patrickbolt]

Lawrence,

NAC is totally new to me so please excuse my ignorance. Does the NAC agent get its compliance information from WSUS or is it just comparing what is approved on the WSUS server to what is installed on the client? If it's the ladder then my thought was to keep the Configure Automatic Updates GPO setting disabled and approve the updates relevant to the NAC policies on the WSUS server simply for the purpose of allowing the NAC agent to check compliance. If the NAC agent determines it is out of compliance we will then trigger the SCCM client to perform a software update scan. Does that make sense?

[LawrenceGarvin]

The GPO setting is really irrelevant. The only reason this setting is disabled in normal ConfigMgr environments is to suppress the WUA's desire to reboot the client after updates are installed. It has zero impact on how the client scans for, or gets, updates.

So, presuming for the moment all you're interested in is compliance testing, then I'll also point out that approvals on the WSUS Server (aka SUP) are also irrelevant. The only reason for approving an update on a WSUS server is so that the client can get the update via self-service.

Which, then, brings us to your idea of "triggering the CM client to perform a software update scan(sic)". First, at that point, the Software Update Scan has already been performed ... if the WUA talked to the WSUS server. BUT.. a necessary component of completing the Software Update Scan is that the CM Agent must communicate with the Management Point (MP) to report that client state. (See original point about complications using CM with NAC.)

Finally, let's back up to the beginning, and remember what the purpose of implementing NAC in an enterprise actually is. First, to ensure that clients are compliant with required security policies. Second, to allow that *client* to be able to remediate those non-compliant conditions as rapidly as possible so that the client can continue to access the environment remotely.

If you tell a user attempting to make a remote connection that "uh, your system is not compliant, so we're going to have to (manually) go launch this Configuration Manager Software Updates task -- which could take as much as 24 hours to successfully complete...."  ....

It may work from a technological viewpoint, but I'm doubtful that it will be acceptable as a business solution. (It also implies that somebody will need to be monitoring that patch compliance state information 24x7, unless you have limited hours on your remote access capabilities.)