Help-Site Computer Manuals
  Algorithms & Data Structures   Programming Languages   Revision Control
  Cameras   Computers   Displays   Keyboards & Mice   Motherboards   Networking   Printers & Scanners   Storage
  Windows   Linux & Unix   Mac






  use Tivoli::AccessManager::Admin

  my $pd = Tivoli::AccessManager::Admin->new( password => 'N3ew0nk' );

  my (@users,$resp);

  # Lets see who is there

  $resp = Tivoli::AccessManager::Admin::User->list( $pd, pattern => "luser*", maxreturn => 0 );

  print join("\n", $resp->value);

  # Lets search by DN instead

  $resp = Tivoli::AccessManager::Admin::User->list( $pd, pattern => "luser*", maxreturn => 0, bydn => 1 );

  print join("\n", $resp->value);

  # Lets create three new users, the easy way

  for my $i ( 0 .. 2 ) {

      my $name = sprintf "luser%02d", $i;

      $resp = Tivoli::AccessManager::Admin::User->create( $pd, name => $name,

                                 dn => "cn=$name,ou=people,o=rox,c=us",

                                 sn => "Luser",

                                 cn => "$name",

                                 password => 'neeWonk');

      $users[$i] = $resp->value if $resp->isok;

      # Mark the account valid

      $resp = $users[$i]->accountvalid(1);

      # But force them to change the password on login

      $resp = $users[$i]->passwordvalid(0);


  # A slightly different way to create a user

  push @users, Tivoli::AccessManager::Admin::User->new( $pd, name => 'luser03',

                                    dn => 'cn=luser03,ou=people,o=rox,c=us',

                                    sn => 'Luser',

                                    cn => 'luser03' );

  $resp = $users[-1]->create( password => 'Wonknee' );

  # Oops.  That last one was a mistake

  $resp = $users[-1]->delete;

  # Oops.  Deleting luser03 was a mistake.  Good thing we didn't remove her

  # from the registry

  $resp = $users[-1]->userimport;

  $resp = $users[-1]->password("Fjord!");

  # Nah.  Delete luser03 completely.

  $resp = $users[-1]->delete(1);

  # Hmm, lets put luser00 in a few groups

  $resp = $users[0]->groups( groups => [qw/sheep coworker/] );


the Tivoli::AccessManager::Admin::User manpage implements the User portion of the TAM API. There is a fair amount of overlap between the Tivoli::AccessManager::Admin::User manpage and the Tivoli::AccessManager::Admin::Context manpage. Since I am a lazy POD writer, I will refer you to that FM when appropriate.


new( PDADMIN[, name => NAME, dn => DN, cn => CN, sn => SN] )

Creates a blessed the Tivoli::AccessManager::Admin::User manpage object. As with everything else, you will need to destroy the object if you want to change the context.


An initialized the Tivoli::AccessManager::Admin::Context manpage object. This is the only required parameter.

name => NAME
The user's name, aka, the userid. If this parameter is provided, new will try to determine if the user is already known to TAM. If the user is, all the fields ( cn, sn and dn ) will be retrieved from TAM.

dn => DN
The user's DN. If this value is provided (but name is not), new will look to see if the user is already defined. If the user is, the other fields (name, cn and sn) will be retrieved from TAM.

cn => CN
The user's common name. Nothing special happens if you provide the cn.

sn => SN
The user's surname. There is nothing special about this parameter either.


A fully blessed the Tivoli::AccessManager::Admin::User manpage object, with an embedded context.


Class methods behave like instance methods -- they return the Tivoli::AccessManager::Admin::Response manpage objects.

list(PDADMIN [,maxreturn => N, pattern => STRING, bydn => 1])

Lists some subset of the TAM users. There is no export available -- it would quickly become gruesome with all the other module's lists.


A fully blessed the Tivoli::AccessManager::Admin::Context manpage object. Since this is a class method, and the Tivoli::AccessManager::Admin::Context manpage objects are stored in the instances, you must provide it.

maxreturn => N
The number of users to return from the query. This will default to 0, which means all users matching the pattern. Depending on how your LDAP is configured, this may cause issues.

pattern => STRING
The pattern to search on. The standard rules for TAM searches apply -- * and ? are legal wild cards. If not specified, it will default to *, which may cause issues with your LDAP.

bydn => 1
Changes the search from UID to DN. Do be aware that this will return all the inetOrgPerson objects in the LDAP, not just the TAMified users.


The resulting list of users.


All of the methods return a the Tivoli::AccessManager::Admin::Response manpage object. See the documentation for that module on how to coax the values out.

The methods, for the most part, follow the same pattern. If the optional parameters are sent, it has the effect of setting the attributes. All methods calls will embed the results of a 'get' in the the Tivoli::AccessManager::Admin::Response manpage object.

create( password => 'password'[, sso => 0|1, nopwdpolicy => 0|1, groups => [qw/list of groups/][, name => NAME, dn => DN, cn => CN, sn => SN] )

Crikey. That's an awful number of options, isn't it? create, as you might suspect, creates a user in TAM. You can call create instead of new and retrieve the the Tivoli::AccessManager::Admin::User manpage object out of the Response object.


password => 'password'
The new user's password. This is the only required parameter.

sso => 0|1
Controls if the user is created as a GSO user. It defaults to false.

nopwdpolicy => 0|1
Determines if the password policy is ignored when the user is created. Defaults to false -- which is to say the default password policy will be enforced.

groups => [qw/list of a groups/]
A reference to an array containing the list of groups to which the user will be added upon creation. Defaults to the empty list.

name => NAME
dn => DN
cn => CN
sn => SN
These are the same as defined in new and each one is required only if you did not provide it to new or if you are calling create instead of new.


The success or failure of the operation if new was used, the new the Tivoli::AccessManager::Admin::User manpage object if not. If the name, the DN, the CN and the SN are not present, you will get an error message.

userimport([name => NAME, dn => DN, groups => [qw/list of groups], sso => 0|1)

``TAMifies'' an existing user in the LDAP. I would have loved to simply name this import, but that had some very unfortunate side affects. As with create, you can call this method to initialize the the Tivoli::AccessManager::Admin::User manpage object.


name => NAME
The user's ID. This is optional if you provided it to new.

dn => DN
The user's DN. This too is optional if you provided it to new.

groups => [ qw/ list of groups/ ]
The groups the imported user is to be granted membership.

sso => 0 | 1
Import the user as a GSO user or not. Defaults to ``not''.


The success of the operation. If you called userimport instead of new, you will get the the Tivoli::AccessManager::Admin::User manpage object.


Deletes the user from TAM.


  1. | 1
  2. Controls deleting the user from the registry. This is an optional parameter and will default to 0.


The result of the operation

groups([ remove => [qw/list of groups/], add => [qw/list of groups/] ] )

Adds the user to the listed groups, removes them from another list or simply returns the user's groups.


add => [ qw/ list of groups/ ]
The list of groups to which the user will be added.

remove => [ qw/ list of groups/ ]
The list of groups from which the user will be removed. If both the add and the remove tag are provided, the removes are processed first.


The user's group memberships after the removes and adds are processed. If some of the specified groups do not exist, they will be listed in the error message from the the Tivoli::AccessManager::Admin::Response manpage object and the iswarning flag will be set. I wish I had a better way of returning interesting error info.

accountvalid( 0|1 )

Marks the user's account valid or not


  1. |1
  2. 0 sets the account invalid, 1 sets it valid.


1 if the account is valid, 0 if not.

password( STR )

Changes the user's password to the specified value


The new password


The success of the operation. Kindly note that there is no get password function

description( STR )

Changes the user's description to the specified value


The new description


The user's description.

passwordvalid( 0|1 )

Marks the user's password valid or not


  1. |1
  2. 0 sets the password invalid, 1 sets it valid.


1 if the password is valid, 0 if not.

ssouser( 0|1 )

Marks the user as a GSO enabled user.


  1. |1
  2. Disable or enable GSO for the user, respectively.


1 if the user is GSO enabled, 0 otherwise.


Returns true if the user is known to TAM.


Returns the user's ID, if known.












These are identical to the same named functions in the Tivoli::AccessManager::Admin::Context manpage. See that very fine manual for documentation. I will repeat one caveat here. If you perform a get on a non-existent user, the functions will not return an error. No idea why not.


The interface to accexpdate blows chunketh. It needs to become significantly smarter -- I want it to be able to accept: 10 days from now ( which would be 11/27/2004 as of this note ) 11/27/2004-12:00:00 86400 * 10 1101588906 and each one of those should do the same thing.


See the Tivoli::AccessManager::Admin manpage for the list. This was not possible without the help of a bunch of people smarter than I.


Should list return a list of names, or a list of the Tivoli::AccessManager::Admin::User manpage objects?


Mik Firestone <>


Copyright (c) 2004-2011 Mik Firestone. All rights reserved. This program is free software; you can redistibute it and/or modify it under the same terms as Perl itself.

All references to TAM, Tivoli Access Manager, etc are copyrighted, trademarked and otherwise patented by IBM.