NWCredentials - how does this work with Deployment Solution (DS) jobs?

book

Article ID: 180772

calendar_today

Updated On:

Products

Deployment Solution

Issue/Introduction

 

Resolution

If you see in the logs a request to get NWCredentials, this is, literally, what it looks like - a request to connect to a server using stored network (NW) credentials.

What credentials?

Very simply, the credentials indicated on the "Symantec Management Agent Settings - Global" policy page under Authentication.

On this page, you can either specify specific credentials, or you can use the Application Credentials, otherwise known as the AppID.  The App ID is stored on the main page of the Notification Server Settings policy page.

The most important things related to this we should remember are: 1) With DS jobs, there is at this time no way to over-ride these credentials.  A request has been made to modify things, but in DS 7.0, 7.1, and 7.2, there is no way around this, other than custom scripted jobs (more on this later).  2) Remember that we connect to the task server to which the client is assigned in DS 7.0 and 7.1.  In DS 7.2 we modify things a bit to look for the closest package server (more research is needed to know if the NWCredentials issue changes in 7.2).  That means that the Deployment share on the Task Server must be accessible using these credentials.

Scenarios to be aware of:
In Figure 1 below, we've built an environment with possible scenarios where problems may occur with this issue.

  1. There is a known issue that has been reported to Dev and is recorded here: TECH183436  The issue though is limited and does not affect everyone, so please review the remainder of the information here prior to reviewing that other KB.
  2. If the NS is in a Workgroup (#1) then all Site Servers will need to have a local account to match the security credentials on the NS and utilize Pass-through authentication.  This applies to the Site Servers in the domain(s) (5,6,7,8) and outside the domain(s) (#4).  
    1. A domain account may not work correctly due to how domain credentials are passed differently from local accounts.  
    2. NOTE: For those Site Servers on a DC (see #5,8), most likely, you'll get failure in the logs because DC's don't support local account creation.
  3. If the NS is in a domain (#2) and a domain account is used, then clients will have easy access to all the site servers in that domain as well as those on a DC (#5).
    1. If a local account is used, then the same rules apply as in #1 above.
    2. For access to Site Servers outside the domain, a trust should be used (see #3).
    3. If a Trust is not available, then pass-through authentication accounts will be required in the other domain.
      1. It is highly likely in this case that a DC in the other domain will fail as a DS Site Server (see #8)
    4. Site Servers in a workgroup will always need to have a local account that mirrors the passwor authentication.

Attachments