Management of account defaults on a service

We can define default values for account attributes either on a service or on a service type. In previous versions of IBM Security Identity Manager, 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, 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 Security Identity Manager 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.

• Add account defaults to a service
  We can add default values for attributes. When we create an account for this service, the default values are provided.
• Change account defaults for a service
  We can change the account defaults for a service instance.
• Remove account defaults from a service
  We can remove account defaults from a service instance.
• Using global account defaults for the service type
  Instead of adding account defaults to a service instance, we can use the global account defaults for the service type.

Parent topic: Services administration