Secondary Account Management with NetIQ IDM

Update to Secondary Account Management Connector
Belkast is pleased to announce an update to SAML. This new release greatly improves the Connector performance over previous releases. Below are some example statistics.

1st User created at 20150910062757Z
200th User created at 20150910063704Z
09 mins 07 seconds to do 200
Trace level 3 and log to file
A User every 2.735 seconds

800th User created at 20150910065353Z
1000th User created at 20150910065812Z
04 mins 19 secs to do 200
Trace level not set and not logging to file
A User every 1.295 seconds

Delete 1000 Secondary Accounts
Trace level not set and not logging to file
18 mins
A User every 1.08 seconds

One of our new offerings is the Secondary Account Management (SAM) Solution. The SAM Solution implements a 1..n relationship (or parent -> child) solution for linking Primary and Secondary accounts in your NetIQ eDirectory Tree. With the Belkast solution:

  • Secondary accounts are identified and linked to their owner’s Primary account.
  • Secondary accounts are governed by an identity lifecycle – with options to remove, reassign, or transfer the access and privileges.
  • Secondary accounts may be managed through authoritative source events on the Primary account – and through workflow / lifecycle processes.


The solution we have developed is truly unique and is based on the standard NetIQ Identity Management product; the following capabilities have been implemented:

Account Management
A Secondary Account can be transferred from one owner to another, either automatically or manually. The automatic Use Case is when the owner, or Primary Account, is Terminated. This termination can be configured to happen when, for example, the Primary Account goes to an EmployeeStatus of X or D or No Longer Employed. The lookup table can be configured to define what a termination actually is. The manual Use Case is when the Trigger attribute is updated with transfer-account|<account-type>|<account-name>|<new-owner>

When a Secondary Account is transferred, there are a few things that can happen…and they can all be configured per ‘account-type’:

  • Data can be copied from the new Owner to the Secondary Account
  • If desired, a new password can be assigned to the Secondary Account
  • If desired, an expiration date can be assigned to the Secondary Account; this logic is driven off data present on the new owner

All of these events can be configured in a lookup table row assigned to each ‘account-type’.

SAML can be configured to work with or without the NetIQ User Application Resource Model. If you don’t have the User Application, no problem. Just flip a GCV and the SAML Connector will take care of the rest.

In the situation where the User Application is not being used, SAML will replicate the content of the nrfAssignedResources attribute, thereby ensuring that there are no code changes to be made when changing to a non User Application model.

To create a new Secondary Account, you can use assign a resource to a User from within the User Application. Because the outcome of the User Application resource assignment is an update to the Trigger attribute, you can also just update the Trigger attribute directly on the User Object.

The format of the value to insert in the Trigger attribute is assign-resource|<account-type>|<account-name>For the account-name portion, you can supply your own value or use [] to generate a name based on the setting int he lookup table for the account-type.

Either of these two methods will result in the creation of a Secondary Account.

To delete a Secondary Account, either revoke the Resource from within the User Application (with the correct settings present in the lookup table), or just delete the Secondary Account using an LDAP browser.

However, please note that the revocation results in the deletion, the disabling, or the transferring of the Secondary Account based on the lookup table settings.

When the Primary User Account is terminated, SAML really comes in to its own. The trigger which kicks off a termination is based on an attribute change; for example, employeeStatus changing to INACTIVE or termination date gaining a value.

Based on the settings in the lookup table, the Secondary Accounts owned by the Primary Account will be Disabled, Transferred, or Deleted.

When a Secondary Account is Transferred, you can configure SAML so that the data from the new Owner is copied over to the Secondary Account.

Data Flow
A value in the main lookup table is assigned to each ‘account-type’, with the value pointing to a child lookup table. This gives SAML the flexibility to share data synchronisation models between multiple types of Secondary Account. Attribute synchronisation can be configured for:

  • Primary account -> Secondary account
  • Secondary account -> Primary account
  • Secondary account <-> Primary account
  • Attribute reset
Required attributes can be defined before a Secondary account is created. Similar to the built-in function veto-if-required-attribute-not-available, SAML uses a lookup table to determine whether an attribute is required before a Secondary Account is created. Attributes can be added and removed on-the-fly. The required attributes setting is per account-type
Default attributes can be assigned on the creation of a Secondary account (per account-type). This is simply a case of updating the relevant row in the lookup table. For example, you can assign one or more Entitlement values when a new Secondary Account is created.
Other Features
  • ‘Lock down’ of Secondary account request based on attribute data (Department, Job Code, etc.)
  • The Secondary account can be placed in a predefined Organisational Unit (per account-type)
  • The Secondary account can be assigned an expiration date (per account-type)
  • A Primary Account can have as many Secondary Accounts as the lookup table is configured to allow
  • A maximum number of Secondary Accounts can be defined (per account-type)
  • Secondary Accounts can be blacklisted: if account type A then not account-type B
Main Mapping Table defines critical logic
Column Name Sample Value
resource-name LSA-ACCOUNT-DEV
readable-description On selection, you will be assigned an LSA account in the Development environment.  There is no further information to be provided by you.  Once approved, the LSA account will have a name starting with DLSA and ending with your Corporate Key.
account-type LSA Development
object-location ING\Resources\Identities\Secondaries\LSA
attribute-map priv-attr
naming DLSA|$idamUidAlias$
naming-counter 01
naming-counter-max 99
event-on-term delete
event-on-revoke delete
manual-transfer-allowed true
manual-delete-allowed true
resource-assignment-on-create Account in AD IM
time-period-valid-for $$Extern:60
tenant-valid-for IM Europe
return-me true
supervisor-delete-allowed true
group-secondary-approval cn=CZ-ServiceDesk,ou=IDAMServiceDesk,ou=Non Connected System,ou=IDAM,ou=Services,o=ING
condition-for-term employeeType?No Longer Employed
'attribute-map' Mapping Table defines attribute synchronisation
Column Name Sample Value
attribute-name C
required-on-create true
default-value-on-create
add-on-create true
sync-to-primary false
sync-kept-independent
sync-kept-independent-override false
sync-on-merge true
return-me true
let-this-through
Mapping Table defines maximum and blacklist
Column Name Sample Value
account-type LSA Development
number-of-accounts-allowed 100
account-blacklist LS Development
Representation of Primary account data

The image below shows a representation of the data held on the Primary account. There are a couple of attributes on the Primary account that tie the data synchronisation together: There is a DirXML-Association value per Secondary account (not visible in the image) and there exists the Distinguished Name (DN) of the Secondary account in the idamSecondaryAccountDNs multi-valued attribute. You might also notice in the image that the nrfAssignedResources attribute has a couple of values – the number of values just happen to correspond with the number of Secondary accounts assigned to the Primary account.

Representation of Primary account data

Representation of Secondary account data

The image below shows a representation of the data held on the Secondary account. Once again, there is a DirXML-Association value linking the Secondary account with the Primary account (not visible in the image), there exists the Distinguished Name (DN) of the Primary account in the idamPrimaryAccountDN single-valued attribute, and the relevant value contained in the nrfAssignedResources attribute from the Primary account is also held on the Secondary account in the idamAssignedResource attribute.

Representation of Secondary account data

What makes this offering unique and a proper Solution is the fact that, as well as the SAM Connector code, we have also developed several sophisticated Roles Based Provisioning Module (RBPM) Workflow forms to facilitate the requesting and maintaining of Secondary accounts.

Request Form 1
Request Form 1

Request Form 1

Request Form 2
Request Form 2

Request Form 2

Email to Line Manager
Email to Line Manager

Email to Line Manager

Approval by Line Manager
Approval by Line Manager

Approval by Line Manager

Approval by Service Desk
Approval by Service Desk

Approval by Service Desk

Email is sent out when the request is approved

A further unique selling point is that all comments entered during the approval process are tracked. The comments can easily be reviewed in the email which is sent out when the approval process has completed.

Email is sent out when the request is approval

Email is sent out when the request is approval

Email is sent out when Secondary account is created
Email is sent out when Secondary account is created

Email is sent out when Secondary account is created

Your Name (required)

Your Email (required)

Size of company (required)

Reason for enquiring about SAML

Enter the following CAPTCHA
captcha