So long, NAA

This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.

This post covers retirement of Network Access accounts (NAA) in the internal Microsoft environment, aided by simplified authentication to Management Point and Distribution Points in the form of Enhanced HTTP and related access scenarios.  

 

Network access accounts have been used for several years now in current and past releases of Configuration Manager, as service accounts used by clients to get content from Distribution PointsConfigMgr Consultants and Support Engineers can likely recite in their sleep the standard best practices of configuring a low rights service account for the NAA and not using the same account for Client Push purposes.  

 

The arrival of Enhanced HTTP was well received by our ops teams as it brought with it the prospect of dropping the NAA in favor of token-based authentication. In a zero-OSD, all Autopilot world, this became one less credential to manage/rotate in our Key Vaults and yet another site-specific setting to no longer configure. It is important to mention this is a secondary benefit, as the ability to secure client communication without the overhead of PKI certs is the core value add of E-HTTP, amongst other benefits. Note: our colleagues on the dev team did caution us about “Run from DP” scenarios in legacy Packages likely not functioning with the absence of the NAA, but as we mainly leverage Applications which use download/execute by default – this was not of much concern.  

 

The docs team has documented in detail the workflow a device follows to authenticate via Azure AD user or device token. But what about devices that cannot leverage AAD/PKI? This scenario is also supported by E-HTTP and the 2002 build extended this further by introducing the concept of an added Management Point issued token that a client can also use for CMG communication. This token can also be bulk provisioned for devices with no corporate network connectivity. 

 

In classic 95/5 (80/20 for Sysadmins :) ), the prospect of NAA removal after enabling E-HTTP in our environment required some validation to ensure that even a pure Workgroup device would not be affected 

 

In a lab enabled for E-HTTPwith two Site Systems: 

MP1 (MP with ConfigMgr SSL Binding) 

and MPDP(PKI based HTTPS MP/DP) 

we see even during client setup (ccmsetup.log) that with no PKI cert, the Workgroup client gets site configuration/DP information from MP1 and uses token-based authentication against the MPDP2 (HTTPS) to get content.  

 

We install the client on the device using this command: ccmsetup.exe SMSSITECODE=CM1 /mp:MP1.sccmtest.loc SMSMP=MP1.sccmtest.loc 

 

Examining log snippets, we see the following: 

CCMSetup.log:

 

Sending location request to 'MP1.sccmtest.loc' with payload '<SiteInformationRequest SchemaVersion="1.00"><SiteCode Name="CM1"/></SiteInformationRequest>' Host=MPDP2.sccmtest.loc, Path=/CCMTOKENAUTH_SMS_DP_SMSPKG$/CM100002, Port=443, Protocol=https, CcmTokenAuth=0, Flags=0x11304, Options=0xe0

 

Post client install, we see in ClientIDMgrStartup.log completion of client registration and indication that the self-prove token is now available. This is the build 2002 feature mentioned above: 

 

[RegTask] - Client is registered. Server assigned ClientID is GUID:A-B-C-D-E. Approval status 1 Updated registration hint. Self-prove token is renewed.

 

In ClientLocation.log, we see the client also rotating over to the HTTPS Site System (MPDP2), despite the absence of a local PKI certAt this point the client retrieves the CCM Token:   

 

Getting CCM Token from STS server 'MPDP2.sccmtest.loc' Getting CCM Token from https://MPDP2.sccmtest.loc/CCM_STS Host=MPDP2.sccmtest.loc, Path=/CCM_STS, Port=443, Protocol=https, CcmTokenAuth=0, Flags=0x11204, Options=0x5c0

 

CCM_STS.log on MPDP2 shows entries indicating validation of the PreAuth/SelfProve token: 

 

Incoming request URL: https://MPDP2.sccmtest.loc/CCM_STS Validated PreAuth SelfProve token. UniqueId: GUID:A-B-C-D-E. ClientKey: XYZ Validated CCM Auth header for client 'GUID: A-B-C-D-E’ Created SCCM token from self-prove pre-auth token

 

Now for a Content Requestperhaps for Software Center based app install. CAS.log on the client displays the various DP URLs returned: 

 

Download started for content Content_8811d5c2-6028-4c53-bc15-032c212bc676.1 Location update from CTM for content Content_8811d5c2-6028-4c53-bc15-032c212bc676.1 and request {B10D4C07-1B97-4EDB-9A95-D3ACF97FC97A} Matching DP location found 0 - http://MPDP2.sccmtest.loc/sms_dp_smspkg$/content_8811d5c2-6028-4c53-bc15-032c212bc676.1 (Locality: SUBNET) Matching DP location found 1 - http://MPDP2.sccmtest.loc/nocert_sms_dp_smspkg$/content_8811d5c2-6028-4c53-bc15-032c212bc676.1 (Locality: SUBNET) Matching DP location found 2 - https://MPDP2.sccmtest.loc/ccmtokenauth_sms_dp_smspkg$/content_8811d5c2-6028-4c53-bc15-032c212bc676.1 (Locality: SUBNET)

 

And ContentTransferManager.log shows client switching over to the correct HTTPS URL and using the CCM token: 

 

CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} (corresponding DTS job {A14CFFE4-C27E-4DB1-B2EB-B9FE4C043994}) started download from 'http://MPDP2.sccmtest.loc/SMS_DP_SMSPKG$/Content_8811d5c2-6028-4c53-bc15-032c212bc676.1' for full content download. CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} switched to location 'https://MPDP2.sccmtest.loc/CCMTOKENAUTH_SMS_DP_SMSPKG$/Content_8811d5c2-6028-4c53-bc15-032c212bc676.1' CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_MANIFEST CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_PROCESSING_MANIFEST CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_PREPARING_DOWNLOAD CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_DATA CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} successfully processed download completion.

 

Note that in this scenario as well, the PKI based HTTPS DP is used. So, there you have it – evidence that the client leverages E-HTTP at the start and can then even communicate with PKI based Site Systems via token-based authentication.  

 

The inner workings are likely best left for discussions with the dev team at an upcoming AMA/conference, but the log snippets and the previously documented workflow essentially reveal the CCM Token to be the primary identity token for the client. The device/user could present either AAD, bulk registration or self-prove/PreAuth token to the MP and get back the CCM token. Any other content access tokens can be acquired thereafter. 

 

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.