This chapter provides definitions of access management concepts and terms used in this manual:
- access controls
-
In ID-Synch, access controls define which
requesters,
authorizers, and
recipients can view and modify
user attributes.
- accounts
-
An account is the collection of data used by a system to identify
a single user, authenticate a user and control that user's access
to resources.
ID-Synch can build its own database of user accounts during
nightly update.
See also: types
- account attributes
- See target attributes.
- account groups
-
ID-Synch uses account groups to configure ways to
manage membership of corresponding groups on certain target systems.
Requesters and authorizers can add or remove users from groups using the
New account request module (nph-idr.exe) and Account management console (nph-ida.exe).
- administrators
-
In ID-Synch, administrators are ``super-users'', also known as
console users.
See also:
- system administrators
- target administrator
- security administrator
- agent
-
An agent is a software component that allows an access management
system to create, update or delete accounts on a managed system,
and that allows an authentication management system to set or validate
passwords or other authenticators on a managed system.
Agents may be installed on the access management or authentication
management server itself, or on the managed system.
Agents installed on the ID-Synch server are sometimes
called remote agents, because they use a remote administration
software protocol understood by the managed system. Conversely,
agents installed on the managed system are sometimes called local
agents.
- attributes
- In this manual:
- Request attributes are
used to gather information about a user when a change request is submitted.
The term attributes used by itself refers to request
attributes.
- Target attributes are used
by ID-Synch to define accounts on a target system.
- authentication
-
Authentication is any process by which a system verifies the
identity of a user who wishes to access it. Users may authenticate with
credentials.
- authorizers
-
An authorizer is a person whose approval is required
before a request can be acted on.
In ID-Synch, authorizers are users who can receive e-mail notification
of an account creation request, and grant permission for ID-Synch to
create the accounts.
Authorizers can also be login ID approvers.
- automated administration
-
Also referred to as automatic access management, automated administration
allows ID-Synch to modify an existing system of record, note changes,
and automatically create users, modify existing users, or submit
workflow change requests.
- central user administration
-
ID-Synch empowers global security administrators to manage
accounts and users on any system from any location, using a web console.
Account administration can also be delegated to local IT resources and
managers. See delegated user administration.
- console
-
A console is a part of the ID-Synch software that is used
by administrators (known as console users)
to configure ID-Synch or to manage users and accounts on target systems.
ID-Synch includes two consoles:
- Central console (nph-psa.exe)
- Account management console (nph-ida.exe)
Throughout this manual, consoles are identified by their descriptive
name followed by their executable name in parenthesis.
- console users
-
In ID-Synch, console users are "super-users", sometimes known as administrators,
who can access one or both of the administration consoles.
Console users in ID-Synch do not have to be real users. That is, they do not need
to be end users with accounts on target systems, and may be accounts
set up specifically for an administrative function.
- credentials
-
A user's credentials to a system consist of a unique user ID and
an authenticator. In most cases, the authenticator is a password.
- customizable user interface
-
ID-Synch's web user interface can be customized to integrate with
existing systems or company styles by changing its appearance,
extending functionality with plug-ins, or modifying program behavior.
- delegated user administration
-
Organizations can allow designated
managers or IT administrators to manage a subset of the user
population, across a subset of target systems. Filter plug-in programs
control which users and systems the designated
administrators can manage.
ID-Synch can also be used for central user administration, in which a core group of security administrators
manage all users on all systems.
- dependencies
-
Dependencies tell ID-Synch to verify that a user has an account on one system
before it creates a new account for the same user on another system.
You can define these dependencies based on:
- Business rules (e.g., you may require that all users must have
a mainframe ID)
- Technical requirements. (e.g., a Windows NT account must exist before a
Microsoft Exchange account can be created)
- disabled accounts
-
An account is disabled in the event that some administrator or
access management process, presumably with suitable authorization,
actively sets a flag to prevent further logins to that account.
Most systems differentiate between disabled and
locked accounts.
- inventory
-
Inventory refers to physical assets that can be provisioned to users.
ID-Synch can be used to provision SecurID tokens,
access badges, and other devices associated with security access.
It can be integrated with an asset management system to provision
office furniture, PCs, telephones and other equipment. Individual items
are referred to as inventory objects.
- inventory manager
-
When an account request includes the provisioning of inventory objects,
an assigned inventory manager
receives an e-mail requesting that the provisioned object be
delivered to the user. A user must be defined as an authorizer in
ID-Synch to be assigned as an inventory manager for a
location.
- location
-
Set up location values to help you define, search for, and select
templates, roles, inventory, and account groups.
For example, you may want to assign accounts, account group membership, or
inventory to users based on their physical location, or on a district for
which they are responsible.
You must define locations to set up inventory objects.
See also: types
- lockout
-
Some systems monitor failed authentication attempts, and
if too many attempts to log on with a single account
are detected, the account is locked.
Intruder lockout may be triggered by users who persistently
mistype their own passwords (e.g., with the Caps Lock or Num Lock
key depressed).
Intruder lockouts mean that authentication to the affected
account is impossible, but the account is not intentionally
disabled by an administrator.
Most systems differentiate between locked and
disabled accounts.
- managed system
- See target system.
- modules
-
A module is a part of the ID-Synch software that can be deployed
independently of other modules, and provides a specific set of functionality.
Modules are used by end users. ID-Synch components used for administrative
purposes are called consoles.
Modules can be accessed from a web browser at an address ending in their
executable name. For example, assuming the ID-Synch server is called
password, then the Central console (nph-psa.exe) is accessed at:
http://password/idsynch/nph-psa.exe.
Throughout this manual, modules are identified by their descriptive
name followed by their executable name in parenthesis.
- nightly update
-
ID-Synch can maintain a database
of users and accounts automatically. This database is regenerated
nightly using the PSUPDATE batch file, which is
run by the task scheduler service.
This is sometimes referred to as psupdate, nightly batch processing,
nightly processing, or nightly automation.
- orphan account
-
An orphan account is an account belonging to a previous user who has left
the organization.
- password
-
A password is a secret word or code, which users must supply
during a login to demonstrate that they are, in fact, the person they
claim to be. A password is one-half of a typical set of credentials used
in authentication. The other half is the user ID.
- password policy
-
A password policy defines what constitutes an acceptable password,
and how passwords should be managed.
Password policy consists of
password rules,
such as minimum length, use of dictionary words, mixed letters and
digits, etc. It also includes policies concerning how and when to
change passwords, or provides policies to discourage
writing down or sharing passwords.
- password rules
-
Password rules are applied to the composition of a password to ensure that
the password is difficult to guess.
- plug-in program
-
A plug-in program is software developed independently
of ID-Synch, which may be invoked by ID-Synch to validate or
acquire information, or to alter its own behavior.
- plug-in point
-
A plug-in point is a set of conditions that cause ID-Synch
to invoke a plug-in program. Plug-in points may be
enabled, disabled, or configured within ID-Synch.
- pseudo-attributes
-
A pseudo-attribute is defined in ID-Synch to compose values or set
flags on a target. For example:
- Active Directory targets use two attributes to control user groups.
Requiring users to set both of these is difficult and error prone.
For ease of use, ID-Synch handles both of these attributes with
the _groups attribute.
- ID-Synch uses the pseudo-attribute _accountDisable
on Windows NT, which stores this information in a bitmask.
This makes configuration of individual attributes easier.
See also: target attributes.
- psupdate
- See nightly update.
- recipient
-
The recipient is the person whose access privileges change once an access
change request is approved and fulfilled.
- regular expressions
-
Regular expressions are a powerful mechanism for extracting patterns out of
text strings. See HERE for more information.
- request attributes
-
Request attributes are used in ID-Synch
to gather information about a user when creating a new account.
Some attributes, such as first and last name, are standard.
You can define extra request attributes, for example, to gather human
resource information such as date of birth, or social security number.
Information for request attributes can be supplied by requesters,
or by plug-in programs
that automatically retrieve and/or validates information, such as an
employee ID, from a database.
Request attributes can be required or optional, and can be included or
excluded from the information sent via email-request to authorizers.
For example,
social security numbers may be required, but they are confidential
so are excluded from the information being sent.
Users may be able to view and modify attributes depending on
configurable access controls.
In this manual, when the term attributes, used by itself, refers
to request attributes.
- requester
-
A requester is a person who submits an access change request.
The change may be to alter the requester's own access to
systems, or to alter another user's access privileges.
- restricted values
-
Request attributes can have restricted values.
This means that users choose a value from a drop-down list on the
New account form. The values can be configured manually or determined
by a plug-in.
- roles
-
ID-Synch uses roles to allow users to
set up or request user accounts based on a group
of templates.
You can group the templates according to your organization's needs.
For example, you can create roles to reflect:
- Job functions -- such as administrative assistant or manager.
- Departments -- such as marketing, development, or support.
- sub-roles
-
Sub-roles are roles within other roles. Rather than adding
templates one by one, you can add a sub-role to include
a groups of templates.
- super-roles
-
Super-roles are roles that include
sub-roles.
- security administrator
-
A security administrator is a person who manually administers
user access rights to systems. A workflow system may call on
a security administrator to fulfill an approved request on
systems where automated administration agents are not available
or have not been configured.
- service
-
ID-Synch uses service programs to interact with databases,
target systems, and other programs.
For example, the PSSCHEDULER service is used to
initiate scheduled jobs, including nightly update tasks.
- standard user ID
-
In some environments users may have standard user IDs, which are
expected to be the same on every system.
- system administrator
-
A system administrator is a user with absolute control over a
managed system. The system administrator may install any or all
software on the managed system, can create or delete other users on
that system, etc.
- target administrator
-
ID-Synch uses a designated account (for example psadmin) on
each target system to create and manage accounts. This account is known as
a target administrator in ID-Synch. It is not necessarily a real
user.
- target attributes
-
Target attributes are used in ID-Synch to set
attributes for a given account on a specific
target system. For example, target attributes set the user's
surname (sn) in Active Directory, their user ID (uid) in LDAP, or their
full name (full_name) in Windows NT.
ID-Synch ships with common actions that should be performed on all
target attributes.
The most common action is to copy the value of the attribute from the template
account to the newly created account. You can override these values by
replacing them, setting them to a specific value, or ignoring them.
Target attributes also contain directions for setting
account attributes in terms of
request attributes.
For example, if you know the value of the request attribute LAST_NAME, you can set the surname (sn) account attribute in Windows 2000 to the
value.
See also: pseudo-attributes.
- target system
-
ID-Synch manages accounts on shared computer systems, referred to as
target systems.
- templates
-
ID-Synch uses templates to automatically create new accounts based on the
parameters of pre-existing accounts.
Combine 2 or more templates to create roles for more flexibility.
- template account
-
A template account is an account created on a managed system specifically
as a definition of how a particular type of account should be created
in the future. Template accounts represent classes of users, and are not
normally used by real users.
- types
-
Set up type values to help you define, search for, and select
templates, roles, inventory, and account groups.
For example, you may want to assign template accounts or roles to
users based on the kinds of rights allowed, or by seniority, or term of
employment. You may want to set up types for inventory items such as
computers, furniture, telephones, or security devices.
You must define types to set up inventory objects.
- users
-
Users, for the purposes of this manual, are owners of a Profile ID, with
accounts on a target system.
- user ID
-
On most systems, accounts are uniquely identified by a short
string of characters. This is called the User ID, login ID or
login name.
- utility
-
ID-Synch uses utility programs, usually Win32 executables,
to perform specialized functions.
List utilities are used during the nightly update process to gather
information about target systems and users.
- workflow
-
In this manual, workflow refers to the authorization workflow for
access change requests.
ID-Synch empowers users to submit requests to create, modify, or
terminate systems access.
ID-Synch'S workflow system is used to:
- Identify the people whose authorization is required to make a change.
- Ask the authorizers to approve a change request.
- Accept feedback from the authorizers.
- Trigger an automated action
OR,
Report on the results of the authorization process.
Alternatively, ID-Synch can submit requests automatically by monitoring
changes to an existing system of record. See automated
administration.
|