Management of account defaults on a service

You can define default values for account attributes either on a service or on a service type.

Note: In previous versions of IBM Verify Identity Governance, account defaults were specified with provisioning policy. Account defaults differ from a provisioning policy. Account defaults do not define the set of users who are allowed to have accounts or what attribute values are compliant. Defaults define the default values for a new account. The change of account default configuration does not affect the compliance status of user accounts. A service might be granted for a subset of users (for example, users who belong to specific organization roles). In this case, these global account defaults might be duplicated in multiple provisioning policies that are specific for each role. By using account defaults, you avoid duplicated configurations.
The following list highlights the differences between the use of account defaults and provisioning policies:
  • Like "default" provisioning parameters, account defaults specify the default values for account attributes during provisioning.
  • Unlike "default" provisioning parameters, account defaults are not scoped by membership. They apply to all users.
  • Unlike "default" provisioning parameters, account defaults do not have implications on compliance. A value specified as an account default is not automatically treated as an "allowed" value.
  • Values that are specified as account defaults do not occur within the entitlement parameter list. They are entirely independent from provisioning policy.
  • Provisioning parameters take precedence over account defaults. Specifically, mandatory and default provisioning parameters override an account default for the same attribute.

Here is an example to illustrate the differences. In this example, we want to define default values and compliance around the "Local Groups" attribute of WinLocal accounts.

In one case, Case A, we define the default value as a provisioning parameter. In the other case, Case B, we define the default value as an account default.
  • Case A:
    Default provisioning parameter
    Guests
    Allowed provisioning parameter
    Print Operators
  • Case B:
    Account default
    Guests
    Allowed provisioning parameter
    Print Operators

In both cases, its clear that Print Operators is an allowed value for the attribute. It is also true that in both cases the default value for the attribute is Guests. The difference is that defining the value of Guests as a provisioning parameter in Case A makes Guests an allowed value. An account with Local Groups = Guests is compliant. In Case B, an account with Local Groups = Guests is not compliant because account default values do not have any implications on compliance.

Consider the following tips for using Account Defaults instead of Provisioning Policy:
  • Use account default to set up default account values for attributes that do not affect security concerns. Use provisioning policy to set up account attribute constraints for security compliance. Avoid using the same attributes for both purposes.
  • Use default parameters in provisioning policy to set up default values for security sensitive attributes. The defaults can be automatically given to a user when the account is created.
  • Use allowed parameters or exclude all but the wanted parameters in provisioning policy to grant access privilege to a user.
  • Use mandatory parameters in a provisioning policy to support "required" (must have) access privilege for a user. IBM Verify Identity Governance ensures that these values are set for new account. The values are out to an existing account when policy enforcement is set to correct and alert.