You would like to have more information on the Provision CR Credentials option. This option specifies whether to automatically provision connection request credentials for CPEs.
If 'Provision CR Credentials' set to Enabled, the CWMP Server (ACS server) will check to see if SPRT_NC_CPE.NC_CPE_CONN_REQUEST_PASSWORD is set each time the device sends an Inform message. If it is not set, then the ACS will automatically set the username and password, and update the database with that information. It does this without needing to define a service or template to set the CR credentials. One benefit of this option is that the provisioning of those credentials happens during the initial session before any policies are invoked, so a connection request is not required in order to start the session. One of the downsides is that the ACS picks the username and password. The username is set to the same as the Unique ID of the device in Service Gateway, which is OUI-ProductClass-SerialNumber, and the password is randomly generated.
There are two other options that may be of interest to you:
- The first one is called 'Reprovision CR Credentials on Failure'. If this option and the 'Provision CR Credentials' option are both set to Enabled, then if the device reports an authentication error when trying the connection request, Service Gateway will set a flag in the database (SPRT_NC_CPE.NC_CPE_ACS_CR_REPROV_FLAG), and the next time the device sends an Inform, the ACS will automatically reprovision the CR credentials on the device. The important point here is that it is on the next Inform message from that device. The reprovisioning does not happen right away.
- The other option that may be helpful here is called 'Reprovision Connection Request after Firmware Upgrade'. Just like the name suggests, if both this and the 'Provision CR Credentials' option are set to Enabled, then Service Gateway will set the same flag that was described in the previous paragraph, causing the ACS to reprovision the CR credentials with the next Inform from the device. In this case, however, that next Inform should be the BOOT Inform after the device applies the firmware upgrade.
The original approach to auth provisioning, before we added this "automatic provisioning" feature, was to use a Service and provision the settings using the Synchronize Configuration policy action. But with that scenario, it was possible for the device to end the session with the CWMP server before the Synchronize Configuration policy action ran, meaning that any attempt by SG to issue a Connection Request to that CPE to start a new session would be rejected by the device, and we would have to wait for the next Inform from that device before attempting to set those credentials again, hoping that the Synchronize Configuration policy action would run while the session was still active. So the automatic provisioning gets around this by sending the necessary RPCs to the device right away.
The main drawback to the automatic provisioning approach is that it applies to all devices, regardless of type, so there is no way to configure this for a particular set of devices.
Using a server, with the Synchronize Configuration policy action, is a lot more flexible in the sense that you can target a specific subset of devices, but has the drawback that I mentioned above, particularly for the Connection Request credentials, if the CPE closes the current session before the policy action runs.