Lotus Notes AdminP operations using Tivoli Identity Manager

IBM Tivoli Identity Manager

IBM® Tivoli® Identity Manager (ITIM) provides an adapter for IBM Lotus® Notes® system. The adapter provides a wide range of functions related to the lifecycle of Lotus Notes accounts. Most noticeable among these are Lotus Notes AdminP Operations. The Lotus Notes AdminP Operations are used to handle events such as department transfer, name change and certificate expiring. This article provides an overview of the customizations and the processes involved in these operations.

Krishnan Venkitasubramanian, Software Engineer, WSO2 Inc

Krishnan VenkitasubramanianKrishnan is a Software Engineer in the Tivoli Services Team of IBM India Software Labs. Krishnan works in a customer-related role, participating in both pre-sales and post-sales activities of various Tivoli Products.



21 October 2008

Introduction

ITIM Adapters allows users to provision identities to many different systems, such as operating systems, data stores and other applications. ITIM is a provisioning platform that centralizes and automates the lifecycle management of user's access rights on various end systems.
More information about ITIM can be found at the following location "IBM Tivoli Identity Manager".

Lotus Notes Adapter

The Lotus Notes Adapter is the interface used by ITIM to connect to systems running the Lotus Domino® Server (Domino Server). The Lotus Notes Adapter must be installed on a machine where the Domino Admin Client is installed. Once the Adapter is installed and configured, ITIM manages the lifecycle operations for the Lotus Notes accounts on the Domino Server. The lifecycle operations include Add, Search, Delete, Modify, Suspend and Change Password account related functions.

AdminP
The Administration Process, or AdminP, is a Domino Server task that helps minimize the number of changes required when Domino users are modified. Rather than edit the Domino Directory directly, the administrators create change requests that go into a secure database called Administration Requests Database (admin4.nsf). The AdminP process checks the database for any changes and batches these changes for execution on a schedule. It is therefore designed to have the least impact on the system's performance. Tasks that can be performed by the AdminP includes certifying a user, adding a user to a group, removing a user, renaming a user, removing a mail file, deleting a database replica, deleting a server, recertifying a server, among many others.

Modify operation
The Lotus Notes Agent supports wide range of modifications to the Notes account ranging from modifying User ID, Full Name and ID File Path etc. The most widely used among these are the AdminP Operations that handle functions like department transfer, name changes and certificate expiry etc. This article describes in detail the three most frequently used functions among these: department transfer, name changes and recertification. It also briefly discusses other functions such as New Replica, Move Replica, Delete ACL and Delete in NAB.

Architecture

Figure 1 shows the Tivoli Identity Manager and Domino server logical architecture.

Figure 1. Architecture
Sample figure containing an image

The architecture consists of the ITIM Server, the agent server and Domino servers 1, 2 & 3. The agent server consists of the Lotus Notes agent and the Domino Admin client. The Domino server, server1 is the primary administration server for the particular domain and processes all the administration requests for a particular domain.

  • The Lotus Notes service on the ITIM server interacts with the agent server.
  • The Lotus Notes agent uses the Domino admin client to communicate with the Domino server for AdminP operations.
  • The ID's are created based on the identity policy, password policy and provisioning policy entitlements defined on the ITIM server.

AdminP operations

The Lotus Notes agent executes the AdminP commands to handle operations like recertification, renaming, department transfer etc. The AdminP tab of the Notes account form lists the AdminP commands that are supported by the Notes profile.

Figure 2 shows the Notes account form that lists the AdminP commands.

Figure 2. AdminP commands list
Sample figure containing an image

On specifying the AdminP command name, the agent will use only the required attributes for each AdminP command and perform the modify function on the Lotus Notes accounts.


Rename function

The rename function helps rename all references to a particular account in the Domino server.
For example, in a cluster of Domino servers as shown in Figure 1, the AdminP rename function helps rename a particular account in all the Domino server's, server 1, 2 and 3.
The values of attributes required for the AdminP rename command can be defined manually using the ITIM GUI. These values are specified in the AdminP Tab of the Notes Account form.

Figure 3 shows the values that are defined for the AdminP Rename function.

Figure 3. AdminP rename function
Sample figure containing an image

The Rename AdminP command requires the following attributes to be passed to ITIM as part of the account modify operation.

  • ernotesAdminPrequest : Rename
  • ernotesAdminPfirstname=AdminP First Name (Optional Attribute)
  • ernotesAdminPmiddilename=AdminP Middle Initial(Optional Attribute)
  • ernotesAdminPlastname=AdminP Last Name
  • ernotesorigcertifier=Original Certifier of user[Absolute path of cert file]
  • ernotesorigcertpasswd=Original Certifier Password
  • ernotesnewcertexpirydate=Certificate expiration date for AdminP(Optional Attribute)
  • ernotesAdminPorgunitname=Org Unit Name(Optional Attribute)

The values of the attributes required for AdminP rename function can also be defined using a script node, in modify operation workflow of the Notes Account.
The location of the modify account workflow of Notes Account is Configuration->Entities->NotesAccount->DefineOperations->modify. At this location click on "modify" to open the Define Workflow editor.

Figure 4 shows the Define Workflow Editor window.

Figure 4. Define Workflow Editor
Sample figure containing an image

The first step involved in constructing the workflow for rename function, is to detect any changes to the 'lastname' of the user. If the change involved is ascertained to be a change in the 'lastname', we go ahead and define the attributes required for the rename function and invoke the AdminP rename command to rename all the references of the particular user in the Domino Servers.

Figure 5 shows a sample Lotus Notes Modify Workflow constructed for the rename function.

Figure 5. AdminP Rename Function Workflow
Sample figure containing an image

The workflow consists of:

  • CheckRename script node that checks for any changes in the lastname of the user.
  • Rename script node that defines the values for AdminP Rename command.
  • ModifyAccount extension node that performs the AdminP Rename function.

A sample code for the CheckRename script node is given below.

var acct = account.get();
var modify = acct.getChanges();
if ((modify != null) && (modify.length) > 0)
{
for ( var i=0; i<modify.length;i++ )
{
var temp = modify[i].attr;
if ( temp == "ernoteslastname" )
{
accountmodify.set("true");
}
else
{
accountmodify.set("false");
}
}
}

The above code checks for any changes to the lastname of the user.
If lastname change occurs, then "accountmodify" value is set as true and the transition lines pointing from the 'CheckRename' script node checks for this value.

  • If 'true', then the workflow proceeds to the Rename Script Node where we will define all the attributes required for the AdminP rename function.
  • If 'false', then the operation is treated as a normal modify operation and proceeds to complete after performing the required modify account operation.

Figure 6 shows the property of the transition line from the 'CheckRename' script node to the 'Rename' script node.

Figure 6. Transition line properties
Sample figure containing an image

The 'Rename' script node in the workflow, defines the values of the attributes required for the AdminP rename function.
A sample code for the rename script node is given below.

var acct= account.get();
var person= owner.get();
var lastname= person.getProperty("sn")[0];
var id = acct.getProperty("ernotesaddcertpath")[0];
var certpwd = "passw0rd";
acct.setProperty("ernotesAdminPrequest", "Rename");
acct.setProperty("ernotesAdminPlastname", lastname);
acct.setProperty("ernotesorigcertifier", id);
acct.setProperty("ernotesorigcertpasswd", certpwd);
account.set(acct);

The 'ModifyAccount' extension node performs the modify account operation.

Figure 7 shows the properties of the 'ModifyAccount' extension node.

Figure 7. Modify account extension node property
Sample figure containing an image

Recertify function

All the Notes ID's of users have an expiration date associated with them, which is used to manage the time when an ID will no longer be able to access the Domino server.
To extend the expiration date on a Notes user ID, the ID needs to be recertified. The AdminP recertify command is used by the Notes Adapter to satisfy this request.

The recertify AdminP command requires the following attributes to be passed to the Notes agent as part of the account modify operation.

  • ernotesAdminPrequest : Recertify
  • ernotesorigcertifier=Original Certifier of user[Absolute path of cert file]
  • ernotesorigcertpasswd=Original Certifier Password
  • ernotesnewcertexpirydate=Certificate expiration date for AdminP(Optional Attribute)

The attributes required for recertify operation for individual accounts can be defined manually using the ITIM GUI. Figure 8 shows the values that are defined in the Notes account form for the AdminP recertify function.

Figure 8. AdminP recertify function
Sample figure containing an image

For a large number of ID's manually entering the values using the ITIM GUI would be very time consuming and a overhead on the efforts required by the administrators. As recertification of ID's is a commonly recurring event, the number of ID's to be recertified everyday would be large. In this scenario we could use a lifecycle rule to automate the recertification process. For this, we will first create an operational workflow, that will handle the account recertification request.
To create the workflow, login to the ITIM GUI and navigate to configuration -> Entities -> NotesAccount -> Define Operations. Here add a new operation called 'Recertify'.

Figure 9 shows the define new operation window.

Figure 9. Define operations
Sample figure containing an image

After adding the new operation called 'Recertify', click on "Recertify" to start building the workflow.

Figure 10 shows a sample workflow constructed AdminP recertify function.

Figure 10. AdminP recertify function - modify workflow
Sample figure containing an image

The workflow consists of:

  • Manager_Approval node that sends a notification to the manager of the account owner, seeking his approval to certify the continued use of Notes account by the user for business purposes.
  • Recertify script node that defines the values required for the AdminP recertify command.
  • AdminPRecertify extension node that performs the AdminP recertify function.

The recertification process starts with the approval from the manager of the account owner. This approval is processed using the 'Approval' node.

Figure 11 shows the properties of the 'Manager_Approval' node.

Figure 11. Approval node properties
Sample figure containing an image

The transition lines starting from 'Manager_Approval' node checks for the approval/rejection of the request by the manager.

Figure 12 shows the properties of the transition line from 'Manager_Approval' node to the 'End' node.

Figure 12. Transition line property
Sample figure containing an image

The "Condition'" attribute of transition line from 'Manager_Approval' to the 'End' node is set as "Rejected" and of that from the 'Manager_Approval' to the 'Recertify' node is set as "Approved". In the workflow, if the manager approves the request, the flow moves to the "Recertify" script node where the values required for the AdminP recertify function are defined.
A sample script to define the required attributes for AdminP Recertify function is given below.

var acct = account.get();
var person=owner.get();
var id = acct.getProperty("ernotesaddcertpath")[0];
var certpwd = "passw0rd";
var newDate =new Date();
var curDate = newDate.getDate();
var curMonth = newDate.getMonth()+1;
var curYear = newDate.getFullYear();
curYear = curYear + 2;
var expDate = curMonth + "/" + curDate + "/" + curYear;
acct.setProperty("ernotesAdminPrequest", "Recertify");
acct.setProperty("ernotesnewcertexpirydate",expDate);
acct.setProperty("ernotesorigcertifier", id);
acct.setProperty("ernotesorigcertpasswd", certpwd);
account.set(acct);

Once the attribute values for the recertify function is defined, the workflow moves on to 'AdminPRecertify' extension node. Here the recertification of the account is done using modify account extension. The properties of the 'AdminPRecertify' node is same as is shown in Figure 7.

The workflow that recertifies the account is now ready for use. To invoke the workflow from the lifecycle rule, the property of this workflow has to be set as non-static.
To set the property to non-static click on the "Properties" button in the define workflow window.

Figure 13 shows the 'Properties' button in the define workflow window.

Figure 13. Define workflow properties
Sample figure containing an image

After clicking the "Properties" button, change the 'Operation Type' to "Non-Static". Now 'Save' and close the workflow.

Figure 14 shows the 'Operation Type' set to "Non-Static".

Figure 14. Operation type
Sample figure containing an image

Once the workflow is defined, we go ahead and define the lifecycle rule that will call this workflow. To define the lifecycle rule login to the ITIM GUI and navigate to Configuration -> Entities -> NotesAccount -> Define Operations.

Figure 15 shows the 'Define Lifecycle Rules' window.

Figure 15. Define lifecycle rules
Sample figure containing an image

Here click on "Define Lifecycle Rules". This will open the new lifecycle rule window. In the 'General' tab of the new lifecycle rule window select the workflow that we created earlier i.e. 'Recertify' and give the rule name as 'Recertify'.

Figure 16 shows the 'General' tab of the Lifecycle rule.

Figure 16. Lifecycle rule general properties
Sample figure containing an image

Now go to the 'Event' tab and provide the 'Entity Filter' information. The 'Entity Filter' is used to select the entities to which this lifecycle rule applies based on some condition.
A sample lifecycle rule filter is given below.

(&(ernotescertexpirydate>=${system.date-0})(eraccountstatus=0))

Figure 17 shows the 'Event' tab of the lifecycle rule.

Figure 17. Lifecycle rule event properties
Sample figure containing an image

The lifecycle rule checks the certificate expiry date against the system date. If the certificate expiry date is greater than or equal to the system date, then the recertify operation workflow that we defined earlier is called. The recertify operation workflow in turn invokes the AdminP recertify function and recertifies the account if the manager approves the particular request.
The lifecycle rule can be scheduled to be run daily at a specified time, ensuring that the recertification of all ID's occurs automatically and without any delay.


MoveUserInHierarchy and MoveComplete functions

Of the Notes AdminP functions, MoveUserInHierarchy and Move user complete are used whenever transfer of users happen.

The transfer of user is executed using the following AdminP commands
1. MoveUserInHierarchy
2. MoveComplete

The MoveUserInHierarchy command requires the following attributes to be passed to ITIM as part of the account modify operation.

  • ernotesAdminPrequest : MoveUserInHierarchy
  • ernotesorigcertifier=Original Certifier of user[Absolute path of cert file]
  • ernotesorigcertpasswd=Original Certifier Password
  • ernotesnewcertexpirydate=Certificate expiration date for AdminP(Optional Attribute)
  • ernotesAdminPcertifier=Org Unit Certifier ID

The MoveComplete command requires the following attributes to be passed to ITIM as part of the account modify operation.

  • ernotesAdminPrequest : MoveComplete
  • ernotesnewcertpath=Path of new Certifier of user[Absolute path of cert file]
  • ernotespasswdnewcert=New Certifier Password

Example
Let us take an example of a user getting transferred from HR to Finance in an organization structure as shown in Figure 18.

Figure 18. Organization structure
Sample figure containing an image

The original certifier of the user is /HR/IBM and the new certifier is /Finance/IBM. For the movement of user in hierarchy, the MoveUserInHierarchy and MoveComplete AdminP commands are to be executed. This involves defining the values of attributes that are required in each of these AdminP functions. This can be achieved by defining these values in the Notes account modify operation workflow which is located at Configuration->Entities->NotesAccount->DefineOperations->modify.

Figure 19 shows a sample workflow constructed for the movement of users in Domino hierarchy.

Figure 19. AdminP move user in hierarchy workflow
Sample figure containing an image

The workflow consists of:

  • IsMoveHierarchy script node that determines whether the operation involves a move in user hierarchy.
  • MoveInHierarchy script node that defines the values of the attribute required for AdminP 'MoveUserInHierarchy' command.
  • ModifyAccount extension node that performs the AdminP 'MoveUserInHierarchy' function.
  • MoveComplete script node that defines the values of the attributes required for AdminP 'MoveComplete' command.
  • ModifyComplete extension node that performs the 'ModifyComplete' function.

The 'IsMoveInHierarchy' script node checks whether the modify operation is a change in user's hierarchy.
A sample code for the 'IsMoveInHierarchy' script node is given below.

var acct = account.get();
var Notesowner=acct.getProperty("ernotesowner")[0];
var currentCert="";
var newbunit=person.getProperty("businessunit")[0];
var certid="";
var certpwd="";
var certify="";
var movehier=false;

Notesowner = Notesowner.toLowerCase();
activity.auditEvent("Owner: " + Notesowner);
if (Notesowner.indexOf("/ou=hr/o=ibm") != -1)
{ currentCert = "HR"; }
else if (Notesowner.indexOf("/ou=finance/o=ibm") != -1)
{ currentCert = "Finance"; }
certify = currentCert;
if (currentCert=="HR" && newbunit == "Finance")
{certify = "Finance" ;  movehier = true; }
else if (currentCert=="Finance" && newbunit == "HR")
{ certify = "HR"; movehier = true; }
if (movehier == true)
{
   MoveinHier.set("true");
   CertiFier.set(certify);
}
else
{
   MoveinHier.set("false");
}

The 'MoveinHier' value is set to true/false depending on whether the operation is a movement of user in the organizational hierarchy. The transition lines from this node checks for the value of 'MoveinHier', and decides the flow.

  • If 'true', then the workflow moves to the MoveInHierarchy Script node.
  • If 'false', the operation will be treated as a normal modify operation and workflow proceeds to complete after performing the required modify account operation.

For setting the properties of the transition lines refer to Figure 6 in the previous section.

In the MoveInHierarchy script node, we define the values for the attributes required by the 'MoveInHierarchy' AdminP command.
A sample script for the 'MoveInHierarchy' node is given below.

var acct = account.get();
var hrcertid = "C:\\ID\\HR.id";
var hrcertpwd = "password";
var fincertid = "C:\\ID\\Finance.id";
var fincertpwd = "password";

var newDate =new Date();
var curDate = newDate.getDate();
var curMonth = newDate.getMonth()+1;
var curYear = newDate.getFullYear();
curYear = curYear + 2;
var expDate = curMonth + "/" + curDate + "/" + curYear;
var certify = CertiFier.get();
acct.setProperty("ernotesAdminPrequest", "MoveUserInHierarchy");
acct.setProperty("ernotesnewcertexpirydate",expDate);
if (certify == "HR") {
   acct.setProperty("ernotesorigcertifier", fincertid);
   acct.setProperty("ernotesorigcertpasswd", fincertpwd);
   acct.setProperty("ernotesAdminPcertifier", "OU=HR/O=IBM");
}
else if (certify == "Finance") {
   acct.setProperty("ernotesorigcertifier", hrcertid);
   acct.setProperty("ernotesorigcertpasswd", hrcertpwd);
   acct.setProperty("ernotesAdminPcertifier", "OU=Finance/O=IBM");
}

account.set(acct);

The next step involves the modification of the account attributes. This is done using the 'ModifyAccount' extension node.

Figure 20 shows the properties of the 'ModifyAccount' extension node.

Figure 20. Modify account node properties
Sample figure containing an image

Once the move in hierarchy is complete the next AdminP command to execute is the MoveComplete command. This command requires some attributes to be defined which is defined in the 'MoveComplete' script node.
A sample script for the 'MoveComplete' node is given below.

var acct = account.get();
var hrcertid = "C:\\ID\\HR.id";
var hrcertpwd = "password";
var fincertid = "C:\\ID\\Finance.id";
var fincertpwd = "password";

var certify = CertiFier.get();

acct.setProperty("ernotesAdminPrequest", "MoveComplete");
if (certify == "HR") {
   acct.setProperty("ernotesnewcertpath", hrcertid);
   acct.setProperty("ernotespasswdnewcert", hrcertpwd);
}
else if (certify == "Finance") {
   acct.setProperty("ernotesnewcertpath", fincertid);
   acct.setProperty("ernotespasswdnewcert", fincertpwd);
}

account.set(acct);

Once the attributes are defined, the workflow moves to the 'ModifyComplete' extension node and completes the AdminP operation. The properties of the 'ModifyComplete' node is same as shown in Figure 20.
The user is now transferred from the HR organization unit to the Finance organization unit in the Domino server.


New replica function

The NewReplica AdminP function allows us to create a new replica of a database on another server.
To illustrate this, let us take the example of a Lotus Notes deployment consisting of an administration server and three domino servers as part of this domain.

Figure 21 shows the Domino server logical architecture.

Figure 21. Domino architecture
Sample figure containing an image

The deployment shown in the above figure consists of four Domino servers. The Domino administration server at the top and Domino Servers 1, 2, & 3 as part of the domain.
Server 1 and 2 have Lotus applications running on them and server 3 acts as the replica server for both server 1 and 2. Server 3 consists of replicas of all Lotus functions running on server 1 and 2. This provides high availability of all Lotus functions deployed on server 1 and 2. For such a Lotus deployment, it becomes necessary that all Lotus databases that are created in any of the servers 1 or 2 have to be replicated to server 3.

The New Replica AdminP command allows us to create a replica of the database on a different server than the primary server.
The New Replica AdminP command requires the following attributes to be defined.

  • ernotesAdminPrequest : NewReplica
  • ernotesAdminPdbtitle=Database Title (new Database)
  • ernotesdestdbpathAdminP=Destination Database Path (relative to data directory)
  • ernotesdestdbserverAdminP=Destination Database Server
  • ernotessrcdbpathAdminP=Source Database Path (relative to data directory)
  • ernotessrcdbserverAdminP=Source Database Server Name

The values of these attributes are defined in the Notes Account form of ITIM GUI.

Figure 22 shows the Notes Account form with the values defined.

Figure 22. AdminP new replica function
Sample figure containing an image

Move replica function

The move replica AdminP function is used to move the replica of a database from one Lotus Domino server to another.

Take the Domino architecture illustrated in Figure 21 and add a new Domino server, server 4 to the architecture. Here all the databases in server 1 will be replicated to server 3 and all databases in server 2 will be replicated to server 4.

Figure 23 shows the Domino server logical architecture after adding server 4.

Figure 23. AdminP move replica function
Sample figure containing an image

In our earlier example, all the replica of the databases present on server 2 were created on server 3. These databases, now needs to be moved to server 4 as per our new architecture. The 'MoveReplica' AdminP function helps us to move these databases to the new server i.e., server 4.
The MoveReplica AdminP command requires the following attributes to be defined.

  • ernotesAdminPrequest : MoveReplica
  • ernotesAdminPdbtitle=Database Title (new Database)
  • ernotesdestdbpathAdminP=Destination Database Path (relative to data directory)
  • ernotesdestdbserverAdminP=Destination Database Server
  • ernotessrcdbpathAdminP=Source Database Path (relative to data directory)
  • ernotessrcdbserverAdminP=Source Database Server Name

The attributes are defined in the Notes account form of the ITIM GUI.

Figure 24 shows the Notes account form with values defined for the AdminP move replica function.

Figure 24. AdminP move replica function
Sample figure containing an image

Delete in ACL function

Access control lists (ACL's) define what actions different types of Lotus Notes users are allowed to take when dealing with Domino server. They are the means by which access to and denial of services in Domino are controlled.
The DeleteInACL AdminP function is used to delete a user from the ACL of the administration server. The DeleteACL AdminP command requires only the "ernotesAdminPrequest" attribute to be defined. The value of the same is defined as 'DeleteInACL'.

Figure 25 shows the Notes account form for the AdminP Delete In ACL function.

Figure 25. AdminP delete in ACL function
Sample figure containing an image

Delete in NAB function

DeleteInNAB AdminP operation is used to deprovision a user from the Domino server and remove the user's entry from the Notes ID address book.
The Lotus Notes adapter allows user's ID file and password information to be stored in a database file called as Notes Address Book(NAB) or Shadow NAB. The Lotus Notes delete operation does not delete these information which is stored in the NAB database file. To delete this information from the NAB database file, the AdminP DeleteInNAB function is used.
DeleteInNAB AdminP request deletes the user's person document and user's mail file from all the email servers and replica servers.
It also

  • removes the user's entry from the shadow NAB(removing its User ID file and password)
  • removes user from the Domino groups it belongs to and
  • adds user's entry to the LogDB database(The name of this LogDB database is specified in the "Log DB" registry key)

To enable the DeleteInNAB function, the Execute AdminP Operation in the Registry settings of the Notes agent has to be set to "TRUE". Also, for deleting the user's mail file the registry key "Delete Mail DB" has to be set to "TRUE."
The DeleteInNAB AdminP command requires only the "ernotesAdminPrequest" attribute to be defined. The value of the same is defined as 'DeleteInNAB'.

Figure 26 shows the Notes account form for the AdminP delete In NAB function.

Figure 26. AdminP delete in NAB function
Sample figure containing an image



Defining values of attributes using JavaScript™ for new replica, move replica, delete ACL, and delete in NAB AdminP functions
The values of attributes required for the new replica, move replica, delete ACL, and delete in NAB AdminP functions can be defined in script nodes using JavaScripting. For examples on how to define the values of these attributes, refer to sample codes that were discussed earlier in this article.


Conclusion

Implementing the Notes AdminP functions in Lotus Notes provisioning using Tivoli Identity Manager can be challenging. This article helps reduce the complexity by giving an overview of the various factors involved in the Notes AdminP Operations.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Security

    Pragmatic, intelligent, risk-based IT Security practices.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Tivoli
ArticleID=343862
ArticleTitle=Lotus Notes AdminP operations using Tivoli Identity Manager
publish-date=10212008