This guide provides you with the information you need to administrate the NetIQ® Identity Manager Fan-Out Driver for Linux and UNIX.
The Fan-Out Driver supports multi-platform implementation of NetIQ Identity Manager 4.0, the comprehensive identity management suite that allows organizations to manage the full user life cycle, from initial hire, through ongoing changes, to ultimate retirement of the user relationship.
The library provides the following information resources:
Provides overview of Identity Manager and its components. This book also provides detailed planning and installation information for Identity Manager.
Provides information about designing, testing, documenting, and deploying Identity Manager solutions in a highly productive environment.
Describes how to administer the Identity Manager User Application.
Describes the user interface of the Identity Manager User Application and how you can use the features it offers, including identity self-service, the Work Dashboard, role and resource management, and compliance management.
Describes how to use the Designer to create User Application components, including how to work with the Provisioning view, the directory abstraction layer editor, the provisioning request definition editor, the provisioning team editor, and the role catalog.
Describes the Identity Reporting Module for Identity Manager and how you can use the features it offers, including the Reporting Module user interface and custom report definitions, as well as providing installation instructions.
Describes how to administer Analyzer for Identity Manager.
Provides information about administration tasks that are common to all Identity Manager drivers.
Provides implementation information about Identity Manager drivers.
We are a global, enterprise software company, with a focus on the three persistent challenges in your environment: Change, complexity and risk—and how we can help you control them.
In fact, of all the challenges you face, these are perhaps the most prominent variables that deny you the control you need to securely measure, monitor, and manage your physical, virtual, and cloud computing environments.
We believe that providing as much control as possible to IT organizations is the only way to enable timelier and cost effective delivery of services. Persistent pressures like change and complexity will only continue to increase as organizations continue to change and the technologies needed to manage them become inherently more complex.
In order to provide reliable control, we first make sure we understand the real-world scenarios in which IT organizations like yours operate — day in and day out. That's the only way we can develop practical, intelligent IT solutions that successfully yield proven, measurable results. And that's so much more rewarding than simply selling software.
We place your success at the heart of how we do business. From product inception to deployment, we understand that you need IT solutions that work well and integrate seamlessly with your existing investments; you need ongoing support and training post-deployment; and you need someone that is truly easy to work with — for a change. Ultimately, when you succeed, we all succeed.
Identity & Access Governance
Access Management
Security Management
Systems & Application Management
Workload Management
Service Management
For questions about products, pricing, and capabilities, contact your local partner. If you cannot contact your partner, contact our Sales Support team.
Worldwide: |
|
United States and Canada: |
1-888-323-6768 |
Email: |
|
Web Site: |
For specific product issues, contact our Technical Support team.
Worldwide: |
|
North and South America: |
1-713-418-5555 |
Europe, Middle East, and Africa: |
+353 (0) 91-782 677 |
Email: |
|
Web Site: |
Our goal is to provide documentation that meets your needs. If you have suggestions for improvements, click Add Comment at the bottom of any page in the HTML versions of the documentation posted at www.netiq.com/documentation. You can also email Documentation-Feedback@netiq.com. We value your input and look forward to hearing from you.
Qmunity, the NetIQ online community, is a collaborative network connecting you to your peers and NetIQ experts. By providing more immediate information, useful links to helpful resources, and access to NetIQ experts, Qmunity helps ensure you are mastering the knowledge you need to realize the full potential of IT investments upon which you rely. For more information, visit http://community.netiq.com.
Part I describes the concepts and facilities of the NetIQ® Identity Manager Fan-Out Driver. It includes the following chapters:
The NetIQ® Identity Manager 4.5 Fan-Out Driver is an identity provisioning solution, based on NetIQ eDirectory™, Identity Manager, and related technology.
With Identity Manager, you can manage the full user life cycle, delivering first-day access to essential resources, providing single login, and modifying or revoking access rights. Identity Manager also provides self-service features that enable users to maintain their own passwords and profile information.
By adding the Fan-Out Driver, you can use Identity Manager to fan out identity provisioning to hundreds of systems with minimal effort. You can centrally manage user accounts and have them automatically created, configured, maintained, and removed when appropriate. It uses extensible scripts to manage account rights, home directories, and other resources as well as the user definitions themselves. Meanwhile, system administrators for the individual platforms in your enterprise can retain control over their areas.
Changes and enhancements to the 4.0.2b release include:
Upgraded OpenSSL
FIPS 140-2 Compliance for 64-bit Linux
Support for 64-bit Solaris
Improved thread processing for lots of simultaneously connected clients
Better interoperability with SELinux
Updated iManager Fan-Out plugin for required TLS support
Miscellaneous bug fixes
Platform Certificate auto-renewal via command-line
Important Upgrade Information:
Due to OpenSSL secure negotiation improvements, core drivers must be upgraded to the latest release, 4.0.2b, before Platform Services are upgraded.
Due to FIPS requirements, the Fan-Out iManager plug-in must be updated to the most recent version, available on the NIdM_Integration_Module_4.0.2b_LinuxUnix.iso.
The Fan-Out Driver differs from other Identity Manager drivers in the following ways:
Fan-Out Scalability A single instance of the Fan-Out Driver can provision centrally managed account information to hundreds of dissimilar platform systems throughout your enterprise.
Scripts Fan-Out Driver scripts process data change events on all supported platforms. This enables platform system administrators to automatically manage local resources associated with accounts as well as the definitions of those accounts.
Authentication Redirection It supports the NetIQ Universal Password feature, which employs access to a central repository for login and password rules. This includes support of bidirectional password synchronization.
Application Programming Interface (API) An easy-to-use API enables programmers to extend applications from individual platforms to fully leverage eDirectory.
The Fan-Out Driver has two functional divisions.
Authentication Services Provides real-time Identity Vault (eDirectory) access for user authentication and related purposes.
Identity Provisioning Provides user and group management.
The Fan-Out Driver has two structural divisions.
The Core Driver Interfaces with eDirectory to provide Authentication Services (such as password verification) and provisioning events (such as Add User or Remove Group).
Platform Services Uses the Core Driver to bring common authentication and account life cycle management to a broad selection of supported platforms.
There are two structural divisions of the NetIQ® Identity Manager Fan-Out Driver: the Core Driver and Platform Services.
Figure 2-1 Fan-Out Driver Components
The Core Driver provides Authentication Services and information about changes to users and groups to target platforms that have been configured to run Platform Services.
The driver obtains and stores the information it uses in an eDirectory™-based “Identity Vault.” To access the Identity Vault, the Core Driver uses LDAP Services for eDirectory.
For ease of management, target platforms that share the same user and group population are grouped together into Platform Sets.
Communication between the driver components occurs through TCP/IP and is encrypted.
The driver includes a secure Web interface that works as an iManager plug-in for administration and monitoring.
The Core Driver records significant occurrences in an Audit Log, and each component writes an Operational Log. Each Core Driver component maintains performance statistics, which can be viewed in the Web interface.
The Fan-Out Driver includes an application programming interface (API). This allows programmers to extend applications to use Authentication Services, which allows them to take advantage of your existing eDirectory constructs.
Binary files, configuration files, and other files used by the driver components are stored in the ASAM directory in the file system of the host server.
Details about configuring and administering the Core Driver and Platform Services are provided in later sections of this guide. Other sections provide information about API development and driver system messages. Also be aware that this is one of three available administration guides for the Fan-Out Driver, each tailored to the range of platforms with which it can work:
Identity Manager Fan-Out Driver for Linux and UNIX Administration Guide
Identity Manager Fan-Out Driver for Mainframes Administration Guide (z/OS)
Identity Manager Fan-Out Driver for Midrange Administration Guide (IBM i, OS/400, i5/OS)
For information about eDirectory, see the NetIQ eDirectory Administration Guide.
The topics in this section describe the structure and function of the Identity Manager Fan-Out Driver.
The Core Driver can be further broken down into two main parts:
The Driver Shim
The objects that represent Core Driver properties and functionality in the Identity Vault (eDirectory)
The Shim is the installed driver software that provides authentication services, such as password verification, to target platforms. It provides identity provisioning events, such as add, modify, and delete, for users and groups, to target platforms. It also uses its Event Subsystem to retrieve events from Identity Manager. Finally, the Core Driver includes an imbedded remote loader that replaces the functionality of the standard remote loader used by Identity Manager.
The objects used in the Identity Vault to store Core Driver properties and functionality include:
The driver object, which stores configuration information about the Core Driver.
The ASAM System container object, which stores configuration and user management information for users connecting to other systems via the Fan-Out Driver.
A writable replica of the partition holding the ASAM System container must reside on the LDAP host server used by a Core Driver. A User object, configured during installation, is used by the driver to perform an LDAP Bind for access to eDirectory.
Figure 2-2 Core Driver
In summary, the Core Driver provides these functions:
eDirectory access to platforms for Authentication Services, such as password verification.
Provisioning events to Platform Services for the maintenance of local user accounts and groups.
The Web interface that you use to configure and manage the driver
Management of the objects inside the ASAM System container
An audit trail of significant occurrences
You can run multiple Core Drivers to provide redundancy for Authentication Services and Identity Provisioning functions.
One Core Driver is designated as the primary Core Driver. Other Core Drivers are secondary Core Drivers. Only the primary Core Driver listens for events from eDirectory. The primary Core Driver also serves the Web interface and provides environmental information during the installation process for other Core Drivers.
The software architecture of the Core Driver includes eight main components. Five of the components are collectively referred to as the Provisioning Manager:
Descriptions of each component in Provisioning Manager follows.
Object Services maintains the objects within the ASAM System container. Some of these objects store configuration information for the various driver components. Others represent users and groups of users that can be defined on target platforms. The object that contains these users and groups is called the Census.
Object Services on the primary Core Driver is notified by the Event Subsystem of events, such as add, modify, or delete, pertaining to users and groups of users in eDirectory. These events are used to maintain the Census.
To initially build and periodically ensure the integrity of the Census, Object Services examines specified portions of eDirectory for users and groups. This process is called a Trawl. You can use the Web interface to set the Trawl schedule. Only the primary Core Driver performs Trawls.
Census Search objects that you define using the Web interface describe which objects in eDirectory are included in the Census. Platform Set search objects that you define using the Web interface describe which users and groups are managed for a given set of platforms.
For more information about Object Services and the Census, see Section 2.3.3, Census Container. For more information about associating users and groups with sets of platforms, see Section 2.3.5, Platform Set Objects.
Event Journal Services receives provisioning events from Object Services and makes them available to sets of platforms according to the rules you specify. Event Journal Services ensures that provisioning events for a platform are delivered, even if the platform is not always available.
Platforms can periodically connect to Event Journal Services to receive provisioning events, or they can maintain a persistent connection and receive events as they occur.
By defining multiple Core Drivers to provide events to platforms, you can provide for improved availability.
Audit Services maintains the Audit Log and Operational Logs for a Core Driver.
Certificate Services mints the certificates used by Secure Sockets Layer (SSL) to authenticate and secure connections between the components.
Web Services provides the secure Web interface for monitoring and administering the Identity Manager Fan-Out Driver. The Web interface is provided through an iManager plug-in.
Authentication Services provides Platform Services with the time-critical interface to eDirectory. This interface is used for such functions as checking the passwords of users logging in to the platform. This interface is also used by the AS Client API.
By defining multiple Core Drivers to provide Authentication Services to platforms, you can provide for improved performance and availability.
Authentication Services supports platform communications using SSL and DES encryption.
The Event Subsystem uses Identity Manager to subscribe to eDirectory events and provides them to Object Services. Objects of interest must be replicated on the Core Driver server.
Identity Manager includes a software component known as the Remote Loader. It is used to interface with drivers on the various systems that can be connected to Identity Manager.
The Core Driver bypasses this component, using its own Embedded Remote Loader. The resulting tighter integration provides eDirectory, Identity Manager, and the Fan-Out Core Driver with greater individual resources and fault tolerance while maintaining a simple configuration
Platform Services enables a system to utilize the Core Driver functions. A platform can use Authentication Services for some or all users, and can use Identity Provisioning in maintaining some or all local user accounts and groups. For a complete account redirection solution, a platform can use the Name Service Switch and Platform Services Cache Daemon for some or all users.
Some types of platforms communicate with Authentication Services using SSL, and others use DES encryption. All platform communication with Event Journal Services uses SSL.
A platform that uses SSL-based communication must have a valid certificate to communicate with the Core Driver for most functions. A platform that uses DES encryption must use the same DES key as defined for it in the Core Driver configuration.
The Identity Manager Fan-Out Driver does not support authentication or password changes for eDirectory users who have a null password.
Figure 2-3 Platform Services
Management of users and groups on the platform is carried out by Receiver scripts, which are called by the Platform Receiver based on provisioning events obtained from the Core Driver.
The Platform Receiver connects to the Event Journal Services component of the Core Driver, requests provisioning events, and runs a script to carry out the appropriate platform-specific processing for the given type of event. The Platform Receiver provides failover support for connections to Event Journal Services if more than one Core Driver is available.
Receiver scripts are run by the Platform Receiver to process provisioning events.
The Identity Manager Fan-Out Driver provides a set of fully functional base scripts in the customary scripting language for each supported platform. You can extend these base scripts as appropriate for your needs.
The Receiver script functions are
Add User
Modify User
Delete User
Delete User Pending
Enable User
Disable User
Rename User
Add User to Group
Remove User from Group
Add Group
Modify Group
Delete Group
Delete Group Pending
Rename Group
Authentication redirection is handled by the Platform Services Process, which is called by the System Intercept. The Platform Services Process is also called by applications using the AS Client API.
Platforms that use password replication receive notification of password changes in eDirectory through the Platform Receiver and send notification of local password changes detected by the password change intercept to the Core Driver using the Platform Services Process.
Account redirection is handled by the Platform Services Cache Daemon, which is called by the Name Service Switch. Platforms that are configured for account redirection use a local memory cache pool for account records and retrieve all account and password information from this cache.
The Platform Services Process establishes and maintains connections to Core Drivers for Authentication Services, and provides load balancing and failover among them. These connections are used to provide Authentication Services to the platform.
The Platform Services Cache Daemon establishes and maintains a connection to a Core Driver and receives event data from Event Journal Services. This data is stored away in memory cache and used to supply account information to the Name Service Switch.
The AS Client API provides a programming interface to Authentication Services. It is furnished as routines that can be called from C and Java*. The AS Client API incudes functions to
Validate a user ID/password combination
Change a user's password, given the current password
Perform an administrative password reset
Obtain the fully distinguished name for a user ID
Determine if a user has Security Equal To a given object
Determine if an object has the specified effective rights to the specified attribute of a given object
Obtain a list of members of a group
Obtain a list of security equivalences for a user
Obtain the eDirectory Home Directory attribute value for a user
Determine if a given user is in the Authentication Services Include/Exclude list
For details about using the AS Client API, see Section V, API Development.
The System Intercept is called by the native security system for password verification and password change. Because passwords are checked using eDirectory or, on supported platforms, replicated from eDirectory, a user has the same password throughout the enterprise, regardless of the platform used.
System Intercepts are implemented using standard, vendor-provided mechanisms.
There are two methods for providing users with the same password across the platforms in your enterprise.
Password Redirection: Requests to check passwords are intercepted at the platform and redirected to objects in eDirectory. The end result is that the user has the same password on all systems.
Password Replication: Changes to passwords are intercepted and replicated between eDirectory and participating platforms. As with password redirection, the end result is that the user has the same password on all systems.
The following table shows the Authentication Services methods available for each platform OS type:
Table 2-1 Authentication Services by Operating System
Platform OS Type |
Authentication Services Method |
---|---|
z/OS |
Password redirection, Password replication (optional) |
IBM i (i5/OS and OS/400) |
Password replication |
UNIX |
Password redirection, Password replication (optional) |
Platforms that use password redirection employ a System Intercept to gain control when a password is to be verified. The System Intercept passes the request to Authentication Services, through the Platform Services Process. Authentication Services uses the Census to identify the User or Alias object in eDirectory that corresponds to the request. Then Authentication Services verifies the password using that object and returns the result to the platform.
The System Intercepts for z/OS* and UNIX systems store the password in the local security system upon a successful authentication or password change. For logins, if Authentication Services cannot be reached, the user's password is verified using the local security system.
Platforms that use password replication receive notification of password changes through the Platform Receiver.
The Core Driver is notified of changes to passwords as follows:
By ensuring that your eDirectory is configured to fully support Universal Password, the driver is notified of password changes in eDirectory.
The Password Validation Program Exit is installed on an IBM i (i5/OS and OS/400) system and captures password change information.
When Authentication Services receives notification of a password change, it verifies the authenticity of the notification and then stores the encrypted password. This is detected by the Event Subsystem, which generates the appropriate provisioning event to notify those platforms that are authorized to receive password information.
By default, passwords are converted to lowercase before they are sent to a platform.
Account Redirection: Requests for Posix user and group information are intercepted at the platform Name Service Switch and redirected to objects in eDirectory. This information includes loginName, uidNumber, gidNumber, gecos, homeDirectory, loginShell, groupName, memberUid and passwords.
You use the platform configuration file to specify Platform Services configuration information, such as
Which users are authenticated using Authentication Services and which users are authenticated using the local security system
Which user accounts and groups are managed using Identity Provisioning and which are managed locally
Information used to locate the Core Driver servers.
The Identity Manager Fan-Out Driver maintains objects in eDirectory with configuration information for the Core Driver and platforms as well as users and groups of users available to the platforms. These are stored in the ASAM System container.
You maintain configuration information by using the Web interface. Do not use any other method of changing objects in the ASAM System container unless advised by support personnel.
A writable replica of the partition holding the ASAM System container must reside on the LDAP host server used by a Core Driver.
The Core Driver processes perform an LDAP Bind as the ASAM Master User to gain access to eDirectory. The ASAM Master User object can be specified during installation.
The ASAM Master User must have Supervisor rights to the container in eDirectory that holds the users and groups that can be added to the Census. This is known as the User and Group Subtree. These rights are granted during installation.
To use the AS Client API to access objects outside of the User and Group Subtree, you must grant additional rights to the ASAM Master User.
You must grant the ASAM Master User Browse object rights and Compare property rights to any object that is accessed through the AS Client API.
You must grant the ASAM Master User Read property rights to any object whose Security Equals list or Group Membership list, or other attribute value is accessed through the AS Client API.
Configuration information for Identity Manager Fan-Out Driver components is stored in objects that correspond to them.
Audit Services object
Certificate Services object
Event Journal Services object
Object Services object
Web Services object
Event Subsystem objects
Authentication Services objects
UID/GID Set objects
Platform Set objects
Platform objects
Identity Manager Fan-Out Driver program component configuration objects list each of their host server network addresses. Before accepting a communication connection from another component, driver components verify that the connection originates from a network address listed in the corresponding configuration object.
Based on your specifications, Object Services maintains a Census of users and groups of users for use with target platforms. Users in the Census are represented by Enterprise User (eUser) objects. Groups of users in the Census are represented by Enterprise Group (eGroup) objects.
Object Services uses events from the Event Subsystem to maintain the Census. Object services of the primary Core Driver also periodically trawls eDirectory for information to ensure the validity of the Census.
Authentication Services uses eUser objects in the Census to locate the corresponding User objects in eDirectory for password verification and other functions. For information about associating eUsers and eGroups from the Census with sets of platforms for provisioning purposes, see Section 2.3.5, Platform Set Objects.
You use the Web interface to specify Census Search objects that identify the users and groups that are to be included in the Census.
Search objects can get Enterprise Users from
Specifically identified User objects
Group object membership
Organizational Role object occupant lists
Objects in containers (and subcontainers, to whatever depth you set)
Search objects can get Enterprise Groups from
Specifically identified Group objects
Group objects in containers (and subcontainers, to whatever depth you set)
Identity Manager entitlements
Dynamic groups use an LDAP search filter to define a set of rules that, when matched by eDirectory User objects, define the members of the group. Membership in the group is evaluated dynamically by eDirectory. There is no actual list of members for a dynamic group like there is for a static group.
Events involving users who are already in the Census that affect their membership in a dynamic group that is a Search object are seen by the Event Subsystem as they happen. This is because the Core Driver interrogates Search objects to discover if an event involving a given User object is of interest.
Events involving users not already in the Census and events involving the LDAP search filter of a dynamic group that is a Search object are not seen by the Event Subsystem. This is because there is nothing to drive the LDAP search. Such changes are not detected until the next Trawl is run.
Because Enterprise User objects and Enterprise Group objects share the same name space, their names must be unique. If a duplicate name is found based on your Census Search objects, the resulting Enterprise User or Enterprise Group object is placed in the Exceptions container rather than being made available in the Census. You can use the Web interface to review naming exceptions.
Enterprise User (eUser) objects reside in the Census container. An eUser object represents a single User object, or an Alias object that references a User object, in eDirectory.
An eUser object includes a reference to the User object or Alias object that it represents in eDirectory. The User object referenced by an Alias object is provisioned to platforms, not the Alias object itself.
Enterprise Group (eGroup) objects reside in the Census container. An eGroup object represents a group of users, and is based on a Group object, or an Alias object that references a Group object, in eDirectory. Enterprise Group objects must be based on static Group objects. Dynamic Group objects are not provisioned.
An eGroup object includes a reference to the Group object or Alias object that it represents in eDirectory. The Group object referenced by an Alias object is provisioned to platforms, not the Alias object itself.
Enterprise Group objects in the Census contain a list of the eUser objects that are represented in the corresponding Group object in eDirectory (but not any users that are not present in the Census).
You can choose to have Enterprise User and Enterprise Group objects whose corresponding User or Group object is deleted from eDirectory or is no longer covered by a Census Search object remain in the Census in an inactive state. Because Enterprise User objects relate to User objects in eDirectory through a globally unique identifier, this prevents another person from receiving access to resources as an unintended result of the reuse of the user name. Inactive users cannot authenticate through Authentication Services.
You can use the Web interface to specify a Delete Pending Duration. During this interval, eUser and eGroup objects whose corresponding User and Group objects have either been deleted from eDirectory or are no longer covered by a Search object are not deleted from target platforms. The results of a Delete User or Delete Group Receiver script can be difficult to reverse. Delete Pending Duration provides a grace period to allow recovery from a disastrous mistake affecting many users.
The Delete User Pending or Delete Group Pending Receiver script is called when a delete event becomes pending for a user or group. The Delete User or Delete Group script is not called until the Delete Pending Duration expires.
A Platform object represents a specific target platform that runs Platform Services.
Platform Set objects provide the relationship between Search objects and Platform objects. You can use Platform Sets to group together multiple platforms that share the same user and group population.
The following example illustrates how you can fan out your user and group population to platforms that are grouped into Platform Sets.
Table 2-2 Platform Set Example
Containers with Users |
OU=Students Henri Markus Rie |
OU=Faculty Carmen Eleu Mario |
OU=Staff Isabel Claire Kenji |
Search Objects |
OU: Students Include Users: Yes |
OU: Faculty Include Users: Yes |
OU: Staff Include Users: Yes |
Platform Sets |
Academic Search Objects: Students, Faculty Platforms: StudentDataServer, LabWorkstation1, LabWorkstation2, LabWorkstation3 |
Employee Search Objects: Faculty, Staff Platforms: BenefitsServer, EmployeeDataServer |
Everyone Search Objects: Students, Faculty, Staff Platforms: MailServer, LibraryServer |
Platforms |
StudentDataServer Platform Set: Academic Users: Henri, Markus, Rie, Carmen, Eleu, Mario LabWorkstation1 Platform Set: Academic Users: Henri, Markus, Rie, Carmen, Eleu, Mario LabWorkstation2 Platform Set: Academic Users: Henri, Markus, Rie, Carmen, Eleu, Mario LabWorkstation3 Platform Set: Academic Users: Henri, Markus, Rie, Carmen, Eleu, Mario |
BenefitsServer Platform Set: Employee Users: Carmen, Eleu, Mario, Isabel, Claire, Kenji EmployeeDataServer Platform Set: Employee Users: Carmen, Eleu, Mario, Isabel, Claire, Kenji |
MailServer Platform Set: Everyone Users: Henri, Markus, Rie, Carmen, Eleu, Mario, Isabel, Claire, Kenji LibraryServer Platform Set: Everyone Users: Henri, Markus, Rie, Carmen, Eleu, Mario, Isabel, Claire, Kenji |
In some cases, a system other than eDirectory might contain the users that you want to participate with the driver. There are tools, such as LDIF, that you can use to import these users into eDirectory.
If you cannot extract the passwords for the affected user accounts, you can use the driver Password Migration component. This component can help you accomplish a smooth transition to basing your user accounts in eDirectory. The Password Migration component is available only on z/OS platforms. For details about the Password Migration component, see the Identity Manager Fan-Out Driver for Mainframes Administration Guide.
This section presents some examples of processing to illustrate how the various components of the NetIQ®Identity Manager Fan-Out Driver work together. These examples do not exhaustively describe each detail involved in the processing, but give a representative account of the steps involved.
Use Figure 3-1 and Figure 3-2 for reference as you study the examples.
Figure 3-1 Driver Components
Figure 3-2 User and Group Population Information Flow
A user logs in to a platform.
The user enters user ID and password information in response to a login prompt from the operating system, and the System Intercept receives control.
The System Intercept calls the Check Password API function (unless the user is excluded from processing based on the specifications in the platform configuration file).
The Platform Services Process uses its load-balancing algorithm to select a Core Driver for Authentication Services. (Platform Services establishes a connection with each Core Driver for Authentication Services upon startup.)
The Platform Services Process makes a Check Password request to Authentication Services.
Authentication Services obtains from the Census the eUser object whose name matches the user ID. Authentication Services gets from that eUser object the distinguished name of the corresponding User object (or Alias object) in eDirectory™.
Authentication Services checks the password against the object in eDirectory that corresponds to the eUser.
If the password is not already present in the eUser object, Authentication Services stores the password there for the Provisioning Manager to use for password replication.
Authentication Services returns the result of the Check Password request to the Platform Services Process.
Authentication Services notifies Audit Services, which records the action in the Audit Log.
The Platform Services Process returns the result to the System Intercept.
The System Intercept returns the result to the local security system.
An administrator adds a new user to eDirectory. The user is covered by a Census Search object.
An administrator adds the new user to eDirectory.
The Event Subsystem receives the change and notifies Object Services.
If the user is covered by a Census Search object, Object Services of the primary Core Driver creates an eUser object for the user in the Census container, and associates the user with the Platform Set container objects whose Platform Set Search objects cover the user.
If the common name of the new user is the same as a name that already exists in the Census container, its eUser object is instead created in the Exceptions container, and the exception must be resolved by an administrator. For guidance in avoiding and resolving exceptions, see the Section II, Core Driver Administration.
Object Services notifies Event Journal Services.
When each Platform Receiver of the associated Platform Sets requests an event and this event is the next one for that platform, Event Journal Services obtains detailed information about the new user by reading its object from eDirectory and passes the provisioning event to the Platform Receiver.
If Event Journal Services cannot obtain the new user information yet because directory synchronization is not complete, the next event for the platform is processed and this one is tried again later.
Each Platform Receiver that receives the provisioning event checks to see if a user by that name already exists (unless the user is excluded from processing based on specifications in the platform configuration file).
If the user already exists, the Platform Receiver notifies Event Journal Services.
If the user does not exist, the Platform Receiver calls the Add User Receiver script, which adds the new user to the local security system and prepares it for use. The Platform Receiver then notifies Event Journal Services of the script outcome.
Event Journal Services notifies Audit Services, which records the action in the Audit Log.
Object Services of the primary Core Driver periodically performs a Trawl to verify the contents of the Census. A Trawl is also run to initially build the Census, or a part of it, whenever you use the Web interface to define a new Census Search object.
The following steps are performed for each Census Search object:
Object Services scans the Census Search object for users and groups.
For any user or group that does not have a corresponding eUser or eGroup in the Census container:
Object Services creates an eUser or eGroup object in the Census container, and associates the user or group with the Platform Set container objects whose Platform Set Search objects cover the user or group.
If the common name of the new user or new group is the same as a user or group that already exists in the Census container, the eUser or eGroup object is instead created in the Exceptions container, and the exception must be resolved by an administrator. For guidance in avoiding and resolving exceptions, see Section II, Core Driver Administration.
Object Services notifies Event Journal Services.
When each Platform Receiver of the associated Platform Sets requests an event and this event is the next one for that Platform, Event Journal Services obtains detailed information about the new user or group by reading its object from eDirectory and passes the provisioning event to the Platform Receiver.
If Event Journal Services cannot obtain the information yet because directory synchronization is not complete, the next event for the platform is processed and this one is tried again later.
Each Platform Receiver that receives the provisioning event checks to see if a user or group by that name already exists (unless the user or group is excluded from processing based on specifications in the platform configuration file).
If the user or group already exists, the Platform Receiver notifies Event Journal Services.
If the user or group does not exist, the Platform Receiver calls the Add User or Add Group Receiver script, which adds the new user or group to the local security system and prepares it for use. The Platform Receiver then notifies Event Journal Services of the script outcome.
Event Journal Services notifies Audit Services, which records the action in the Audit Log.
The following steps are performed for each user and group in the Census.
Object Services verifies that the user or group is still covered by a Search object.
If it does not, the same steps are followed as for Section 3.4, User Deleted from eDirectory or Section 3.5, Group Deleted from eDirectory.
Object Services verifies that the User object or Group object that corresponds to the user or group still exists in eDirectory.
If it does not, the same steps are followed as for Section 3.4, User Deleted from eDirectory or Section 3.5, Group Deleted from eDirectory.
A User object that is covered by a Census Search object is deleted from eDirectory.
An administrator deletes a user from eDirectory.
The Event Subsystem receives the deletion and notifies Object Services.
If the user is covered by a Census Search object, then Object Services takes one of the following actions based on configuration information that you have specified:
Object Services marks the corresponding eUser object in the Census as inactive. (Inactive users cannot authenticate through Authentication Services.)
or
Object Services marks the eUser object for deletion after the event has been processed by all associated platforms.
Object Services notifies Event Journal Services.
When each Platform Receiver of the associated Platform Sets requests an event and this event is the next one for that Platform, Event Journal Services passes the provisioning event to the Platform Receiver. When the last Platform Receiver of a Platform Set has received the event, the next Trawl removes the Platform Set association for the eUser (if you have defined your configuration to remove deleted users rather than mark them inactive).
Each Platform Receiver that receives the provisioning event calls its Disable/Delete User Receiver script to disable the user in the local security system or to delete it and clean up its resources (unless the user is excluded from processing based on specifications in the platform configuration file).
Event Journal Services notifies Audit Services, which records the action in the Audit Log.
If you have specified a Delete Pending Duration, Event Journal Services indicates to the Platform Receiver that a delete is pending for the user. When the Delete Pending Duration has expired, Event Journal Services delivers the delete event.
A Group object that is covered by a Census Search object is deleted from eDirectory.
An administrator deletes a group from eDirectory.
The Event Subsystem receives the deletion and notifies Object Services.
If the group is covered by a Census Search object, then Object Services takes one of the following actions based on configuration information that you have specified:
Object Services marks the corresponding eGroup object in the Census inactive.
or
Object Services marks the eGroup object for deletion after the event has been processed by all associated platforms.
Object Services notifies Event Journal Services.
When each Platform Receiver of the associated Platform Sets requests an event and this event is the next one for that platform, Event Journal Services passes the provisioning event to the Platform Receiver. When the last Platform Receiver of a Platform Set has received the event, the next Trawl removes the Platform Set association for the eGroup.
Each Platform Receiver that receives the provisioning event calls its Delete Group Receiver script to delete the group from the local security system and clean up its resources.
Event Journal Services notifies Audit Services, which records the action in the Audit Log.
If you have specified a Delete Pending Duration, Event Journal Services indicates to the Platform Receiver that a delete is pending for the group. When the Delete Pending Duration has expired, Event Journal Services delivers the delete event.
A user for which there is an eUser object in the Census is added to the member list of a Group object in eDirectory.
An administrator adds the user to the member list of the Group object.
The Event Subsystem receives the change and notifies Object Services.
Object Services notifies Event Journal Services.
When each Platform Receiver of the Platform Sets associated with both the eUser and the eGroup requests an event and this event is the next one for that platform, Event Journal Services obtains detailed information about the user by reading its object from eDirectory, and passes the provisioning event to the Platform Receiver.
If Event Journal Services cannot yet obtain updated user information due to incomplete directory synchronization, the next event for the platform is processed and this one is tried again later.
Each Platform Receiver that receives the provisioning event calls its Add User to Group Receiver script, which adds the user to the group in the local security system.
Event Journal Services notifies Audit Services, which records the action in the Audit Log.
Part II provides you the information you need to administer the Core Driver component of the NetIQ® Identity Manager Fan-Out Driver. It includes the following chapters:
This section helps you plan for your deployment of the NetIQ® Identity Manager Fan-Out Driver. If the Fan-Out Driver is new to you, read the information presented earlier in Section I, Concepts and Facilities before proceeding.
Major topics in this section include
There are a number of issues to resolve in planning for your deployment of the Identity Manager Fan-Out Driver. Considering these issues now will make your installation go more smoothly.
Decide how you will deploy the use of the driver throughout your enterprise.
Do you want to start with a small subset of your platform systems? Do you want to start with a small subset of your user community?
Platforms can operate with Include/Exclude lists to control which users the driver handles for authentication, and which users the driver defers to the native authentication mechanism. Platforms can also operate with Include/Exclude lists to control which user accounts the driver manages using provisioning events and which user accounts are managed locally. For more information, see Section III, Platform Services Planning.
Decide who will administer your driver configuration.
The Web interface is used to monitor and administer the driver. Make it available to these persons and ensure that they have the necessary rights to use it. For details about the rights needed for administrative functions, see Rights Required for Web Application Use
Decide which eDirectory™servers in your network will run Core Drivers.
A writable replica of the partition holding the ASAM System container must reside on the LDAP host server used by a Core Driver.
Each object that is covered by a Census Search object must be present in a replica (full or filtered) on the system that hosts the primary Core Driver.
Will you install additional Core Drivers to provide redundancy for Authentication Services?
The Platform Services Process includes load balancing and failover support to provide for continued processing should a Core Driver become unavailable.
Will you install additional Core Drivers to provide redundancy for Identity Provisioning?
The Platform Receiver includes failover support to provide for continued processing if the Core Driver it normally uses for Identity Provisioning becomes unavailable.
Decide where in your eDirectory tree the ASAM System container and ASAM Master User objects should go. Creating a special container for them is a good practice.
Make sure you set password policies appropriate for the ASAM Master User object.
For more information about requirements for the ASAM Master User, see Section 6.2.2, ASAM Master User Security.
Decide upon your Census parameters.
Which objects in your eDirectory tree will be used as the source of Enterprise Users and Enterprise Groups? This depends on how you place User and Group objects in your directory.
When do you want to run a Census Trawl? Because the Census is maintained in real time using provisioning events, Trawls are used primarily to verify the consistency of the Census. Once a day is reasonable for most cases.
Do you want Enterprise Users whose User objects have been deleted from eDirectory to be automatically removed from the Census? They can be removed after remaining inactive for a specified number of days, or you can choose to manage inactive users manually.
Do you want to delay user password expiration until the end of the day of expiration? This can result in smoother operation for users on platforms with third-party systems that cache and reuse passwords during the day.
Do you want to immediately delete users and groups from platforms when they are deleted from eDirectory or are no longer covered by a Search object, or do you want to provide a grace period to recover from accidental changes?
For information about setting these parameters, see Section 6.5.1, Configuring the Census.
How will you resolve naming exceptions?
For more information, see Section 6.5.14, Reviewing Naming Exceptions.
Decide which systems in your network will run Platform Services.
User names, passwords, and group names must conform to the character set and length restrictions imposed by the platform operating system in order to participate in Authentication Services and Identity Provisioning on that platform. Determine how you will handle those that do not meet the restrictions.
Decide how you will organize your Platform Sets. Each platform belongs to exactly one Platform Set. A Platform Set provides the relationship between a group of platforms and the Search objects that define their user and group population.
Users and Groups have the same UID number and GID number on each Linux/UNIX platform in a Platform Set.
What UID and GID numbers do you want to reserve for local administrator use on Linux/UNIX platforms?
Will you use the RFC2307 posixAccount and posixGroup auxiliary object classes for enterprise-wide UID and GID assignments?
Will any of your platforms use password replication? If so, you must ensure that the driver is notified of changes to passwords.
If your eDirectory is configured to fully support Universal Password, the driver is notified of password changes in eDirectory.
If you do not use Universal Password, you must install and configure the appropriate password intercepts.
For more information, see Section 4.3.2, Password Replication Requirements.
Platforms configured to use password replication do not normally receive provisioning events for user accounts until the passwords for these accounts are known to the driver.
The driver uses Universal Password to collect password information. Users must either change their passwords where these are installed and configured, or authenticate on a driver platform before they can be populated onto a platform that uses password replication (Permit Password Replication specified as Yes for the Platform object in the Web interface).
By planning a staged deployment of the Fan-Out Driver to the platforms in your enterprise so that most users have authenticated using other platforms first, you ensure the availability of these users to password replication platforms when you are ready to deploy the driver on them.
Consider how your own applications could benefit from the use of the Authentication Services (AS) Client API.
Using the AS Client API is simple and straightforward. For more information about using the Client API, see Section V, API Development.
Will any of your Platform Receiver scripts need attributes other than those configured in the driver by default?
For a list of the attributes configured by default, see Section 4.3.3, Core Driver Requirements.
To configure additional attributes, you must add them to the Event Subsystem Subscriber filter. For details about adding attributes to the Subscriber filter, see the Identity Manager Administration Guide.
The attribute names that you use in the Subscriber filter must be the eDirectory names.
Many factors affect the performance of the Identity Manager Fan-Out Driver. Performance is most critical for Authentication Services, such as Check Password and Get Context.
There are many relationships within the driver, and one or more of the factors described in the following sections can affect all of these relationships. Use the following as guidelines in planning and troubleshooting your Fan-Out Driver installation.
Acceptable Authentication Services performance is achievable using two or three low-end servers for Core Drivers. However, if your present network experiences problems, such as slow logins related to eDirectory, Fan-Out Driver operations will experience similar response problems.
For fault tolerance, your configuration should include Core Drivers running on several servers.
For fault tolerance, each Core Driver should use a different LDAP host server.
For optimal performance, each Core Driver and its LDAP host server should run on the same server.
Topics in this section include
Tuning eDirectory on your network is beyond the scope of this document. Much documentation on this subject is available elsewhere, including NetIQ Technical Information Documents (TIDs), which are available at the NetIQ Support Web site. The health and performance of eDirectory is critical to the ability of the driver to respond to Authentication Services requests and to deliver provisioning events in a timely manner. Therefore, the health and performance of eDirectory should be your starting point in doing any performance planning and troubleshooting with the driver.
Factors in driver performance relative to eDirectory include
The size of the eDirectory tree
Communication links between the LDAP host servers used by Core Drivers and servers holding replicas of the ASAM System container and other objects referenced by the driver
LAN traffic
Size of partitions containing relevant objects
Performance of CPU and disks in servers holding relevant replicas
Amount of memory in servers holding relevant replicas
The driver interfaces with eDirectory through LDAP. For LDAP tuning guidance, see the NetIQ eDirectory Administration Guide.
The Object Services component of the Core Driver is primarily responsible for maintaining the Census and other objects in the ASAM System container. Object Services receives provisioning events from the Event Subsystem, updates the Census as required, and passes the provisioning events to Event Journal Services. It is important for Identity Provisioning that the Core Driver be running at all times, but it is mostly a background process that does not require a great deal of processing power and is, for the most part, not a time-critical process.
Object Services performs Trawls to initially build and to verify the Census by performing a series of requests based on the Census Search objects defined in your configuration. For each Organizational Unit represented in the configuration, Object Services issues a single request to eDirectory to return all the objects contained in the given Organizational Unit.
Focus your Search objects to the specific directory locations of your users and groups rather than specifying a top level container object. This provides better feedback information during a Trawl and reduces the likelihood of an LDAP time-out because of slow servers or slow network links.
The Event Subsystem uses Identity Manager to provide events to Object Services. The Event Subsystem requires minimal processing power, but it does require replicas for all objects that are monitored. Network connectivity and eDirectory synchronization are the primary performance factors for the Event Subsystem.
For optimal performance, a writable partition of all replicas containing objects contained in the Census should reside on the same server as the LDAP host server used by a Core Driver. However, be aware that operations that lock the directory on the local server, such as running NDSRepair, sometimes delay requests or cause them to fail.
Event Journal Services waits for Platform Receivers to connect, then provides pending events and a snapshot of User and Group objects for processing. Network connectivity to the platforms, and proximity of the Core Driver to servers holding replicas of managed User and Group objects are the primary performance factors for Event Journal Services.
Platforms with very large numbers of managed users and groups should be connected to Event Journal Services with connections of adequate bandwidth to ensure that Full Sync Mode and Check Mode processing will complete within an acceptable time.
To reduce the number of concurrent connections that must be serviced by a Core Driver host, avoid using Persistent Mode on Platform Receivers.
Authentication Services is responsible for processing requests made by Platform Services.
For optimal performance, LDAP host servers used by Core Drivers should hold a writable replica that contains the User objects represented in the Census, and other objects that might be referenced often by Authentication Services.
Platform Services sends requests to the Core Driver. The systems on which Platform Services reside can be anything from a desktop workstation to a high-end mainframe system. The inherent performance of these systems is based on a number of factors, including
System load
The power of the system
Network traffic
Connectivity and bandwidth to the Core Drivers
The number of Core Drivers defined in the configuration
Consider each of these as you configure each platform and as you select the location of the Core Drivers.
The performance of the Platform Services / Authentication Services transaction is the most important performance relationship in the driver. The communication relies on the TCP/IP stack of the platform and Authentication Services server. TCP/IP configuration on the platform, the Authentication Services server, and the routers in between is the most important factor in the performance of servicing Authentication Services requests. Guidelines for configuring TCP/IP are beyond the scope of this section. Refer to appropriate NetIQ and platform operating system documentation and TIDs for further information.
Platform system planners should be aware of a mandatory three-second delay in reporting a bad password on a password check request. This delay is in eDirectory itself. It cannot be configured by the driver.
The system requirements for driver components are described in the following sections. Identity Manager Fan-Out Driver components do not require the systems they run on to be dedicated solely to them.
Topics in this section include
The installation and configuration of the driver requires a user with full administrative rights and privileges in eDirectory and on the target systems. You can grant more limited rights to other users to use the Fan-Out Driver Web interface for administrative functions. For details of rights needed for administrative functions, see Rights Required for Web Application Use.
If you use password replication, you must ensure that the driver is notified of changes to passwords.
If your eDirectory is configured to fully support Universal Password, the driver is notified of password changes in eDirectory.
When configuring the policy for Universal Password, be sure to select the option that allows administrative users to retrieve the Universal Password.
For information about installing and configuring the password intercepts, see Section IV, Platform Services Administration.
NetIQ Identity Manager.
NetIQ eDirectory versions supported by the Identity Manager version in use.
NetIQ iManager versions supported by Identity Manager version in use.
One of the following OS platforms, in a version supported by the Identity Manager and eDirectory version in use:
Windows
Linux
Solaris
TCP/IP network connectivity.
A writable replica of the partition that will hold the ASAM System container must reside on the LDAP host server used by the Core Driver.
Replicas (full or filtered) of objects that will be covered by a Census Search object (primary Core Driver only).
The Fan-Out Driver will be configured for the attributes in the following lists. If you use filtered replicas, include the attributes shown in the following lists. If you add other attributes to the Subscriber filter, you must ensure that they are also available in your filtered replicas.
Alias Attributes
Aliased Object Name
CN
GUID
User Attributes
CN
Group Membership
GUID
Login Disabled
Surname
ASAM-enterpriseUser Attributes
ASAM-addTime
GUID
Group Attributes
CN
GUID
Member
Organizational Role Attributes
CN
GUID
Role Occupant
HINT:iManager provides a wizard for setting up filtered replicas.
The workstations used to install, configure, and administer the driver must meet the following requirements.
TCP/IP network connectivity
The ability to run iManager
Connectivity to the Identity Vault (eDirectory) tree to be managed by the driver
If the installation computer runs UNIX, gzip and tar utilities
Connectivity to the file system of the computer that is to receive components being installed; if the installation computer is not the same as the target host, a drive must be mapped to the target host
For information about required systems and software, as well as supported platforms and operating environments, see the Identity Manager 4.5 Drivers Documentation Web site. From this index page, you can select a Readme file associated with the platform(s) for which you need Fan-Out Driver support.
Earlier sections of this Administration Guide identify two major parts of the NetIQ® Identity Manager Fan-Out Driver, which are the Core Driver and Platform Services. The Core Driver must be installed first.
Before beginning the Core Driver installation, you should complete the planning process described in Section 4.0, Core Driver Planning, and you should be familiar with the topics presented in Section I, Concepts and Facilities.
Topics in this section include
Please review this section carefully for a high-level overview of the tasks and considerations you will encounter during the installation of the Core Driver. This information will help you later as you determine which steps are relevant to your particular installation scenario(s).
Verify that you meet minimum system requirements. For details, see Section 4.3, Requirements.
Obtain the Core Driver distribution package for your target operating system from the NetIQ downloads site. In other words, you will need the package that is designed for the operating environment in which Identity Manager is running.
Always check the NetIQ Support Web Site for the latest support pack and product update information. Check the Release Notes and Readme files for the version you are installing for any special actions that might be required.
Topics in this section include:
The release of Identity Manager 3.6.1 ended support for NetWare. Therefore, if you wish to upgrade a Core Driver running in a NetWare environment, you will need to migrate to one of the other supported environments (Linux, Solaris, Windows).
You can do this by completing one of the following step-by-step installation tasks for upgrading a Core Driver, depending on your environment:
As you follow these steps, bear in mind that any information you provide about a Core Driver during this task should reflect the identity, settings and configuration of the Core Driver you are migrating from NetWare.
For additional information related to NetWare migration, see Migrating Certificate Authority.
If you meet one of the following conditions, you will need to install the LDAP Client SDK libraries prior to the Core Driver installation:
You are installing the 64-bit Linux Fan-Out Core Driver on a system running 32-bit eDirectory
You are installing the Core Driver on a Linux or Solaris system not hosting eDirectory
To install and configure the LDAP Client SDK:
Download the installation package labeled NetIQ Developer Site suitable for your system architecture.
from theInstall the package according to the instructions that accompany it.
Setup your runtime library path to include the newly installed files:
On Linux, you may modify your /etc/ld.so.conf to include the additional path. For example:
/opt/novell/ndk/novell-cldap-devel-2007.10.04-1linux64/lib64/
Alternatively, you can modify the LD_LIBRARY _PATH environment variable to include your path:
LD_LIBRARY_PATH=/opt/novell/ndk/novell-cldap-devel- 2007.10.04-1linux64/lib64/:$LD_LIBRARY_PATH export LD_LIBRARY_PATH
Be sure to modify your logon profile and Core Driver startup script to include this.
During software installation, you will be asked if you are establishing a primary Core Driver or adding a secondary Core Driver. Following are some guidelines for determining how to respond:
You must have one primary Core Driver. If you are installing a Core Driver for the first time, it will automatically be designated as the primary.
The primary Core Driver must have access to a read/write replica of the entire ASAM System container and all User and Group objects defined by the Census.
Secondary drivers can service authentication requests and deliver events to connected platforms but will not perform tasks such as trawls or update enterprise objects in the Census. Therefore, the primary Core Driver must be active and running in order to provide connected platforms with new provisioning information.
For additional information on assessing secondary driver requirements, see Section 5.4, Performance Tuning.
A Quick Start guide for installing the Fan-Out Driver is available for each target platform. Although this Administration Guide includes detailed procedures for all installation scenarios, you may find the Quick Start helpful in focusing on primary steps. The quick starts, listed below, are available at the Identity Manager 4.5 Drivers Documentation Web site.
Fan-Out Driver Installation Quick Start for Linux and UNIX Systems
Fan-Out Driver Installation Quick Start for Midrange Systems
Fan-Out Driver Installation Quick Start for Mainframe Systems
Be sure to pre-install the LDAP SDK Libraries if you meet one of the unique conditions discussed in Installing the LDAP Client SDK Libraries
During software installation, you will be asked if you are establishing a primary Core Driver or adding a secondary Core Driver. For guidelines, see Specifying Primary and Secondary Core Drivers.
To complete the Core Driver installation you will use one of two available application interfaces for configuration:
iManager Newer versions of this standard NetIQ Web interface include a Fan-Out Driver application plug-in for driver configuration. The Core Driver software includes a copy of this plug-in in case you have an older version of iManager. The installation instructions include steps for installing this plug-in after you have run the initial installation software.
Designer This interface, which comes as part of the Identity Manager 4.5 product, is an offline tool you can use to plan and model large deployments of the Fan-Out Driver. Designer includes its own Fan-Out Driver application plug-in, which is already installed as part of the Designer interface. For more information on Designer, see Section 6.4, Applications For Configuration.
Once you have installed the Core Driver and completed its initial configuration in iManager, you still won’t be able to test the installation until you have installed Platform Services on the system(s) you will connect to. This will involve an additional software installation and configuration on each of these systems. Therefore, you may want to preview Part IV of this Administration Guide, “Platform Services Administration,” for details about this additional process.
Installation of the Core Driver will create an ASAM directory in the file system on each server that includes any of its components. Access to each copy of this directory should be restricted to the driver itself and its administrators to ensure protection of sensitive identity information.
Following is a general overview of the process for installing the Core Driver.
NOTE:This section is provided to help you prepare for installation. More detailed instructions are provided later in Section 5.2, Step-By-Step Installation Instructions.
Read Section 5.1.1, Essentials and Section 5.1.2, Other Advance Considerations.
Know in advance which of the following installation scenarios you wish to perform:
New installation of a primary Core Driver running on Linux, Solaris or Windows
New installation of a secondary Core Driver running on Linux, Solaris or Windows
Upgrade of an existing Core Driver running in “Local” mode (default, not using Remote Loader) running on Linux, Solaris or Windows
Upgrade of an existing Core Driver running in “Remote” mode (already using NetIQ Remote Loader) running on Linux, Solaris or Windows
Upgrade of an existing Core Driver running on NetWare
Run the Core Driver installation program and respond to the prompts. This will install the Core Driver software components also known as the Driver Shim.
If required, install the iManager plug-in for the Fan-Out Driver Web application.
Using iManager and the plug-in, create objects in the Identity Vault to support the Core Driver. This includes importing an XML default configuration file that comes with the Core Driver installation software.
Populate your Census with the users and groups that you will use for your initial testing.
This includes defining Census Search objects and then running a Census Trawl. For details about this procedure, see Section 6.5.1, Configuring the Census.
Assign users of the Fan-Out Web program (in iManager) the rights they need.
For details, see Rights Required for Web Application Use.
Define the UID/GID sets that you will use for your initial testing. For details, see Section 6.5.9, Configuring Linux/UNIX UID/GID Sets.
Define the Platform Sets that you will use for your initial testing. For details, see Section 6.5.5, Configuring Platform Sets.
You must define at least one UID/GID Set before you can define a Platform Set.
Define the platforms that you will use for your initial testing. For details, see Section 6.5.6, Configuring Platforms.
Use iManager to start the Core Driver object in Identity Manager.
Use system tools to start the Driver Shim in the local operating environment.
Install and configure Platform Services to match the platforms you defined in iManager during the previous steps.
IMPORTANT:This step involves individual software installations and configurations on each system you will connect to with the Fan-Out Driver. For detailed information about this separate process, see Part IV of this Administration Guide, “Platform Services Administration.”
After testing, install additional Core Drivers for performance and redundancy according to the guidelines in Section 5.4, Performance Tuning.
Before the 90-day evaluation period expires, activate the Identity Manager Fan-Out Driver.
You can use the driver for evaluation purposes for 90 days. The driver will not work thereafter unless it has been activated. For details, see Section 5.3, Activating the Driver After Evaluation.
Fully deploy the Fan-Out Driver throughout your enterprise as you gain confidence and experience.
This section presents the various step-by-step tasks that can be combined to cover all Core Driver installation scenarios. The tasks are grouped first into four basic categories:
NOTE:Be aware of the following:
Identity Manager 3.6.1 does not support NetWare. Therefore, if you wish to upgrade a Core Driver running in a NetWare environment, you will need to migrate to one of the other supported environments. See Migrating From NetWare for more details.
Some of the configuration tasks discussed briefly in this section are covered again in more detail in Section 6.0, Configuring and Administering the Core Driver
Core Driver installation on Linux and UNIX begins with one of the following tasks, depending on your scenario:
To install a new Driver Shim on Linux or Solaris:
From your installation media, locate and execute the appropriate self-extracting installer:
sh linux_x86_coredriver.bin
sh linux_x86_64_coredriver.bin
sh solaris_sparc_coredriver.bin
NOTE:The x86 (32-bit) installer is compatible with both 32-bit and 64-bit versions of Linux. To use the x86_64 (64-bit) installer with the 32-bit Identity Manager engine, you must first install and configure the 64-bit LDAP SDK (see Installing the LDAP Client SDK Libraries).
Accept the license, select your installation directory and proceed to install the product files.
The installer will next assist you in configuring the Driver Shim. You will be prompted for the Remote Loader password, which is used to encrypt driver network communications. Enter a password and remember it, as you will use it when configuring the driver in iManager.
You will then be prompted for a Driver Object password. This is used to access the driver object in eDirectory. This password will also be used when configuring the driver in iManager.
The next entry you are asked for is the eDirectory server/port, so the installer can retrieve an SSL certificate from eDirectory using your SSL-configured LDAP server. Enter the DNS name or IP address of the LDAP server that the Core Driver Shim will use to communicate with. Typically, this will be
on port .When prompted for an eDirectory admin name/password, enter the eDirectory administrator’s ID in LDAP dot format (example:
, followed by the password.NOTE:The installer must get a successful directory connection in order to proceed. Consult your eDirectory LDAP documentation for troubleshooting.
When prompted for an ASAM System Container Context, specify the distinguished name (DN) of the container in which the organizational unit ASAM System should be created. The driver will store configuration and synchronization information in this container. Enter the DN in LDAP dot format. Example:
.NOTE:If you are adding a secondary driver, or upgrading a driver, the installer may detect your existing Fan-Out installation and prompt you to accept the discovered location.
You are next prompted for information about the Core Driver, beginning with a descriptive name and the network port it will use (default 3451).
For the Core Driver network address, select a DNS name or IP address for the Core Driver. If your system has multiple addresses, use one which other systems (platforms) can use to communicate with the driver.
The installer will then create the eDirectory objects and indexes needed to completed the configuration.
Immediately after installation, you may need to change the port setting for the Core Driver’s built-in remote loader. This is especially likely if you are also using the standard remote loader that comes with Identity Manager, since both versions of the remote loader use 8090 as their default port setting.
The port setting for the Core Driver’s built-in remote loader resides in the fanout.conf file, which is located in /usr/local/ASAM/data/.
Edit the following line in fanout.conf to reflect the desired port:
-connection "ca=/usr/local/ASAM/keys/ca.pem port=8090"
If this installation is a secondary driver, migrate the Certificate Authority from the primary system. For details, see Migrating Certificate Authority.
NOTE:If you have a firewall, be sure to add the Driver's network port (default 3451) to its open ports list.
At the completion of this installation task, go next to Section 5.2.3, Setting Up the Core Driver in iManager.
Upgrading a driver running in Local mode on your Linux or Solaris eDirectory server is the most common upgrade scenario. Once upgraded, it will run as a Remote Driver, with both the Driver object and Driver Shim integrated on the same physical host.
To upgrade a Driver Shim that is running in Local mode in Linux or Solaris:
Stop the Core Driver object in iManager.
From your installation media, locate and execute the appropriate self-extracting installer:
sh linux_x86_coredriver.bin
sh linux_x86_64_coredriver.bin
sh solaris_sparc_coredriver.bin
NOTE:The x86 (32-bit) installer is compatible with both 32-bit and 64-bit versions of Linux. To use the x86_64 (64-bit) installer with the 32-bit Identity Manager engine, you must first install and configure the 64-bit LDAP SDK (see Installing the LDAP Client SDK Libraries).
Accept the license, select the same installation directory as your previous installation (usually this is /usr/local) and proceed to install the product files.
The installer will next assist you in configuring the Driver Shim. You will be prompted for the Remote Loader password, which is used to encrypt driver network communications. Enter a password and remember it, as you will use it when configuring the driver in iManager.
You will then be prompted for a Driver Object password. This password will also be used when configuring the driver in iManager.
The next entry you are asked for is the eDirectory server/port, so the installer can retrieve an SSL certificate from eDirectory using your SSL-configured LDAP server. Enter the DNS name or IP address of the LDAP server that the Core Driver Shim will use to communicate with. Typically, this will be
on port .When prompted for an eDirectory admin name/password, enter the eDirectory administrator’s ID in LDAP dot format (example:
, followed by the password.NOTE:The installer must get a successful directory connection in order to proceed. Consult your eDirectory LDAP documentation for troubleshooting.
When prompted for an ASAM System Container Context, specify the distinguished name (DN) of the container in which the organizational unit ASAM System resides. You can find this information on the Provisioning Status Details page using the Fan-Out Driver Web application plug-in in iManager. Enter the DN in LDAP dot format. Example:
.When prompted whether to create a new Driver or upgrade an existing one, enter
to upgrade an existing Driver.When a list of drivers displays, enter the number corresponding to the Driver you plan to upgrade.
The installer will then generate an updated configuration file and install indexes needed to completed the configuration. (You may receive a warning message regarding indexes since they will already exist.)
Immediately after installation, you may need to change the port setting for the Core Driver’s built-in remote loader. This is especially likely if you are also using the standard remote loader that comes with Identity Manager, since both versions of the remote loader use 8090 as their default port setting.
The port setting for the Core Driver’s built-in remote loader resides in the fanout.conf file, which is located in /usr/local/ASAM/data/.
Edit the following line in fanout.conf to reflect the desired port:
-connection "ca=/usr/local/ASAM/keys/ca.pem port=8090"
NOTE:If you have a firewall, be sure to add the Driver's network port (default 3451) to its open ports list.
At the completion of this installation task, go next to Section 5.2.3, Setting Up the Core Driver in iManager, which includes the task for upgrading a Core Driver configuration
If you are running a Fan-Out Driver in Remote mode, you can upgrade the Driver Shim on the Linux or Solaris system and eliminate the need to run the NetIQ Java Remote Loader.
To upgrade a Driver Shim that is running in Remote mode in Linux or Solaris:
Stop the Core Driver object and the Remote Loader instance for the current driver in iManager.
Still in iManager, open the
, select the Fan-Out Driver instance and click . Make a note of the , and fields.Because you no longer need the standard NetIQ Remote Loader, you may disable or remove it as follows, depending on whether you have other Remote Drivers:
If you’re running other Remote Drivers on the system, simply remove the Fan-Out Driver instance by selecting it in the Remote Loader Console and clicking
.If you aren't running other Remote Drivers on the system, open
and run | ( on Windows Server 2008) to remove the NetIQ Identity Manager Connected System program.From your installation media, locate and execute the appropriate self-extracting installer:
sh linux_x86_coredriver.bin
sh linux_x86_64_coredriver.bin
sh solaris_sparc_coredriver.bin
NOTE:The x86 (32-bit) installer is compatible with both 32-bit and 64-bit versions of Linux. To use the x86_64 (64-bit) installer with the 32-bit Identity Manager engine, you must first install and configure the 64-bit LDAP SDK (see Installing the LDAP Client SDK Libraries).
Accept the license, select the same installation directory as your previous installation (usually this is /usr/local) and proceed to install the product files.
The installer will next assist you in configuring the Driver Shim. You will be prompted for the Remote Loader password, which is used to encrypt driver network communications. Enter a password and remember it, as you will use it when configuring the driver in iManager.
You will then be prompted for a Driver Object password. This password will also be used when configuring the driver in iManager.
The next entry you are asked for is the eDirectory server/port, so the installer can retrieve an SSL certificate from eDirectory using your SSL-configured LDAP server. Enter the DNS name or IP address of the LDAP server that the Core Driver Shim will use to communicate with. Typically, this will be
on port .When prompted for an eDirectory admin name/password, enter the eDirectory administrator’s ID in LDAP dot format (example:
, followed by the password.NOTE:The installer must get a successful directory connection in order to proceed. Consult your eDirectory LDAP documentation for troubleshooting.
When prompted for an ASAM System Container Context, specify the distinguished name (DN) of the container in which the organizational unit ASAM System resides. You can find this information on the Provisioning Status Details page using the Fan-Out Driver Web application plug-in in iManager. Enter the DN in LDAP dot format. Example:
.When prompted whether to create a new Driver or upgrade an existing one, enter
to upgrade an existing Driver.When a list of drivers displays, enter the number corresponding to the Driver you plan to upgrade.
The installer will then generate an updated configuration file and install indexes needed to completed the configuration. (You may receive a warning message regarding indexes since they will already exist.)
Immediately after installation, you may need to change the port setting for the Core Driver’s built-in remote loader. This is especially likely if you are also using the standard remote loader that comes with Identity Manager, since both versions of the remote loader use 8090 as their default port setting.
The port setting for the Core Driver’s built-in remote loader resides in the fanout.conf file, which is located in /usr/local/ASAM/data/.
Edit the following line in fanout.conf to reflect the desired port:
-connection "ca=/usr/local/ASAM/keys/ca.pem port=8090"
NOTE:If you have a firewall, be sure to add the Driver's network port (default 3451) to its open ports list.
At the completion of this installation task, go next to Section 5.2.3, Setting Up the Core Driver in iManager, which includes the task for upgrading a Core Driver configuration.
Core Driver installation on Windows begins with one of the following tasks, depending on your scenario:
To install a Driver Shim on a Windows System:
From your installation media, run the following command:
fan-out\IDMCoreDrivers\Win\win_x86_coredriver.exe
This x86 (32-bit) executable is compatible with both x86 and x64 versions of Windows.
Accept the license, select your installation directory and proceed to install the product files.
The installer will next assist you in configuring the Driver Shim. You will be prompted for the Remote Loader password, which is used to encrypt driver network communications. Enter a password and remember it, as you will use it when configuring the driver in iManager.
You will then be prompted for a Driver Object password. This is used to access the driver object in eDirectory. This password will also be used when configuring the driver in iManager.
The next entry you are asked for is the eDirectory server/port, so the installer can retrieve an SSL certificate from eDirectory using LDAP. Enter the DNS name or IP address of an eDirectory server, and the LDAP secure port (default 636). In the console window that appears, enter
to accept the certificate.NOTE:If you are running both eDirectory and Active Directory on the Windows server, you may need to change the LDAP ports of either eDirectory or Active Directory so that they do not interfere with each other. See your product documentation for more information.
When prompted for an eDirectory admin name/password, enter the eDirectory administrator’s ID in LDAP dot format (example:
, followed by the password.NOTE:The installer must get a successful directory connection in order to proceed. Consult your eDirectory LDAP documentation for troubleshooting.
When prompted for an ASAM System Container Context, specify the distinguished name (DN) of the container in which the organizational unit ASAM System should be created. The driver will store synchronization information in this container. This is usually the top-level organization in the tree. Example:
.You are next prompted for information about the Core Driver, beginning with a descriptive name and the network port it will use (default 3451).
For the Core Driver network address, select a DNS name or IP address for the Core Driver. If your system has multiple addresses, use one which other systems (platforms) can use to communicate with the driver.
The installer will then create the eDirectory objects and indexes needed to completed the configuration.
Immediately after installation, you may need to change the port setting for the Core Driver’s built-in remote loader. This is especially likely if you are also using the standard remote loader that comes with Identity Manager, since both versions of the remote loader use 8090 as their default port setting.
The port setting for the Core Driver’s built-in remote loader resides in the fanout.conf file, which is located in C:\Novell\ASAM\data\.
Edit the following line in fanout.conf to reflect the desired port:
-connection "ca=/usr/local/ASAM/keys/ca.pem port=8090"
NOTE:If you have a firewall, be sure to add the Driver's network port (default 3451) to its open ports list.
At the completion of this installation task, go next to Section 5.2.3, Setting Up the Core Driver in iManager.
You can upgrade a driver running in Local mode on your Windows eDirectory server. The upgraded Driver will run as a Remote Driver, with both the Driver objects and Driver Shim on the same system.
To upgrade a Driver Shim that is running in Local mode in Windows:
Stop the Core Driver object in iManager.
From your installation media, run the following command:
fan-out\IDMCoreDrivers\Win\win_x86_coredriver.exe
This x86 (32-bit) executable is compatible with both x86 and x64 versions of Windows.
Accept the license, select the same installation directory as your previous installation (usually C:\Novell\ASAM) and proceed to install the product files.
The installer will next assist you in configuring the Driver Shim. You will be prompted for the Remote Loader password, which is used to encrypt driver network communications. Enter a password and remember it, as you will use it when configuring the driver in iManager.
You will then be prompted for a Driver Object password. This password will also be used when configuring the driver in iManager.
The next entry you are asked for is the eDirectory server/port, so the installer can retrieve an SSL certificate from eDirectory using LDAP. Enter the DNS name or IP address of an eDirectory server, and the LDAP secure port (default 636). In the console window that appears, enter
to accept the certificate.NOTE:If you are running both eDirectory and Active Directory on the Windows server, you may need to change the LDAP ports of either eDirectory or Active Directory so that they do not interfere with each other. See your product documentation for more information.
When prompted for an eDirectory admin name/password, enter the eDirectory administrator’s ID in LDAP dot format (example:
, followed by the password.NOTE:The installer must get a successful directory connection in order to proceed. Consult your eDirectory LDAP documentation for troubleshooting.
When prompted for an ASAM System Container Context, specify the distinguished name (DN) of the container in which the organizational unit ASAM System resides. This is usually the top-level organization in the tree. Enter the DN in LDAP dot format. Example:
.When prompted whether to create a new Driver or upgrade an existing one, click
to upgrade an existing Driver.When a list of drivers displays, select the Driver associated with the system you are upgrading.
The installer will then generate an updated configuration file and install indexes needed to completed the configuration. (You may receive a warning message regarding indexes since they will already exist.)
Immediately after installation, you may need to change the port setting for the Core Driver’s built-in remote loader. This is especially likely if you are also using the standard remote loader that comes with Identity Manager, since both versions of the remote loader use 8090 as their default port setting.
The port setting for the Core Driver’s built-in remote loader resides in the fanout.conf file, which is located in C:\Novell\ASAM\data\.
Edit the following line in fanout.conf to reflect the desired port:
-connection "ca=/usr/local/ASAM/keys/ca.pem port=8090"
NOTE:If you have a firewall, be sure to add the Driver's network port (default 3451) to its open ports list.
At the completion of this installation task, go next to Section 5.2.3, Setting Up the Core Driver in iManager, which includes the task for upgrading a Core Driver configuration
If you’re running a Fan-Out Driver in Remote mode, you can upgrade the Driver Shim on the Windows system running the Connected System portion of the Driver.
To upgrade a Driver Shim that is running in Remote mode in Windows:
Stop the Core Driver object and the Remote Loader instance for the current driver in iManager.
Still in iManager, open the
, select the Fan-Out Driver instance and click . Make a note of the , and fields.Because you no longer need the standard NetIQ Remote Loader, you may disable or remove it as follows, depending on whether you have other Remote Drivers:
If you’re running other Remote Drivers on the system, simply remove the Fan-Out Driver instance by selecting it in the Remote Loader Console and clicking
.If you aren't running other Remote Drivers on the system, open
and run | ( on Windows Server 2008) to remove the NetIQ Identity Manager Connected System program.From your installation media, run the following command:
fan-out\IDMCoreDrivers\Win\win_x86_coredriver.exe
This x86 (32-bit) executable is compatible with both x86 and x64 versions of Windows.
Accept the license, select the same installation directory as your previous installation (usually C:\Novell\ASAM) and proceed to install the product files.
The installer will next assist you in configuring the Driver Shim. You will be prompted for the Remote Loader password, which is used to encrypt driver network communications. Enter a password and remember it, as you will use it when configuring the driver in iManager.
You will then be prompted for a Driver Object password. This password will also be used when configuring the driver in iManager.
The next entry you are asked for is the eDirectory server/port, so the installer can retrieve an SSL certificate from eDirectory using LDAP. Enter the DNS name or IP address of an eDirectory server, and the LDAP secure port (default 636). In the console window that appears, enter
to accept the certificate.NOTE:If you are running both eDirectory and Active Directory on the Windows server, you may need to change the LDAP ports of either eDirectory or Active Directory so that they do not interfere with each other. See your product documentation for more information.
When prompted for an eDirectory admin name/password, enter the eDirectory administrator’s ID in LDAP dot format (example:
, followed by the password.NOTE:The installer must get a successful directory connection in order to proceed. Consult your eDirectory LDAP documentation for troubleshooting.
When prompted for an ASAM System Container Context, specify the distinguished name (DN) of the container in which the organizational unit ASAM System resides. This is usually the top-level organization in the tree. Enter the DN in LDAP dot format. Example:
.When prompted whether to create a new Driver or upgrade an existing one, click
to upgrade an existing Driver.When a list of drivers displays, select the Driver associated with the system you are upgrading.
The installer will then generate an updated configuration file and install indexes needed to completed the configuration. (You may receive a warning message regarding indexes since they will already exist.)
Immediately after installation, you may need to change the port setting for the Core Driver’s built-in remote loader. This is especially likely if you are also using the standard remote loader that comes with Identity Manager, since both versions of the remote loader use 8090 as their default port setting.
The port setting for the Core Driver’s built-in remote loader resides in the fanout.conf file, which is located in C:\Novell\ASAM\data\.
Edit the following line in fanout.conf to reflect the desired port:
-connection "ca=/usr/local/ASAM/keys/ca.pem port=8090"
NOTE:If you have a firewall, be sure to add the Driver's network port (default 3451) to its open ports list.
At the completion of this installation task, go next to Section 5.2.3, Setting Up the Core Driver in iManager, which includes the task for upgrading a Core Driver configuration.
You will use the Fan-Out Driver’s Web application to complete the Core Driver installation. This application resides in recent versions of iManager as a standard plug-in. If your version of iManager does not include the plug-in, you can install it from the software that comes with the Core Driver.
NOTE:In addition to iManager, you can use Designer, an application interface that comes with Identity Manager, for setting up and modelling large deployments of the Fan-Out Driver. A Fan-Out Driver application plug-in is included as part of the Designer installation. For more information on using Designer, see Section 6.4, Applications For Configuration.
After you have installed or upgraded a Driver Shim, the installation process continues in iManager with the following tasks, depending on your scenario:
If your version of iManager does not include the plug-in or if you are not familiar with iManager, you can refer to two additional topics at the end of this section before starting:
Use iManager to configure a Core Driver in the Identity Vault (eDirectory). To import a Core Driver configuration:
Login to iManager for your tree and select the
task under on the left.Keep the Driver Set selection and, if this is a new Driver Set, select the server in eDirectory where the Driver will run.
From the Fan-Out-IDM3_6_0-V1.xml. If this file is not available, select and select the file rules\Fan-Out-IDM3_6_0-V1.xml under the directory where the Driver Shim is installed (C:\Novell\ASAM by default).
menu, selectEnter the following configuration fields. The installer will have filled in some of these fields:
: Enter a descriptive name.
: Choose the selection that corresponds to the activation you purchased. The Driver will operate in evaluation mode for 90 days if you don’t have an activation.
: Enter the DNS name or IP address and TCP port of your LDAP host.
: Enter the DNS name or IP address and TCP port used by the system where the Driver Shim runs.
: Enter an LDAP account that will be used to manage Driver information.
: Enter the passwords you entered when installing the Driver Shim.
Click
and add your ASAM Master User.Click
and add the admin user, the ASAM Master User and other high-privilege users to the list.Click
to complete the import.If you upgrade a Core Driver Shim, you also need to upgrade its configuration in iManager. To upgrade a configuration:
Login to iManager for your tree and select the
task under on the left.Select the Driver Set that contains the Driver to be upgraded.
Click
to keep the Driver Set selection.From the Fan-Out-IDM3_6_0-V1.xml. If this file is not available, select and select the file rules\Fan-Out-IDM3_6_0-V1.xml under the directory where the Driver Shim is installed (C:\Novell\ASAM by default).
menu, selectOn the next page, to the right of the
field, select the driver you wish to upgrade from the drop-down box.Enter the following configuration fields, consistent with your current installation. The installer will have filled in some of these fields:
: Choose the selection that corresponds to the activation you purchased. The Driver will operate in evaluation mode for 90 days if you don’t have an activation.
: Enter the DNS name or IP address and secure TCP port of your LDAP host.
: Enter the DNS name or IP address and TCP port used by the system where the Driver Shim runs.
: Enter an LDAP account that will be used to manage Driver information.
: Enter the passwords you entered when installing the Driver Shim.
On the next page, select
and click .Click
to complete the import.If necessary, apply any manual customizations.
NOTE:You must install the new version of the iManager Plug-in before using the Driver. See Installing the iManager Plug-In (If not Preinstalled).
If your installation of iManager does not display the Fan-Out Driver Configuration role (Roles and Tasks menu on the left), you can install the iManager plug-in manually.
To install the iManager plug-in:
Login to iManager as an administrative user.
Click the
icon at the top.Click
under on the left menu.Click
above the list of plug-ins.Select fan-out\iManagerPlugIn\FanOutWeb.npm from your installation media and click .
Check the box next to
and click above the list of plug-ins.Restart the Tomcat or Tomcat5 service on your iManager system, and exit and log back into iManager.
If the Fan-Out Driver Configuration role has not appeared, continue with the following steps.
Click the
icon at the top.Click
under on the left menu.Click the number under the
column in the table.Check the box next to
and click above the list.Click the
icon at the top.With the plug-in now installed, you can proceed to your next task.
NOTE:For additional information about using iManager with the Fan-Out Driver application plug-in, see Section 6.4, Applications For Configuration.
To use the iManager interface for setting up a Core Driver:
In iManager, select the
task under .Enter the DNS name or IP address and port of the system running the Driver Shim and click
.You may now use any of the items under
and in iManager.After the initial installation or upgrade of a Core Driver, other tasks that you may need to perform from time to time include the following:
If you have migrated your primary Core Driver from one system to another, or have added a new secondary Core Driver, you will need to physically copy the Certificate Authority files from your previous host system to your new host system. For example, in migrating from NetWare to another operating system, you must copy the Certificate Authority files from your NetWare system to your new system. These files are:
ASAM/data/CoreDriver/certs/ca_cert.pem ASAM/data/CoreDriver/certs/ca_key.pem ASAM/data/CoreDriver/certs/ca.pem
If you do not perform this migration, your new primary Core Driver system will generate a new Certificate Authority when it first starts up. This will invalidate any platform certificates that may have been signed using the previous Certificate Authority.
Both the Identity Manager Driver object and Driver Shim service must be running for the Core Driver to operate. To start the Core Driver:
In iManager, select the
task under .Select the Driver Set where the Driver is installed.
Click the status indicator (stop line) in the upper right corner of the driver icon, then click
.On the Driver Shim system, start the Fan-Out Driver as follows:
If the system is running Linux/UNIX, enter the following command:
/etc/init.d/asamcdrvd start
If the system is running Windows, open
and run > . Start the NetIQ IDM Fan-Out Driver service.To stop the Core Driver:
On the Driver Shim system, stop the Fan-Out Driver as follows:
If the system is running Linux/UNIX, enter the following command:
/etc/init.d/asamcdrvd stop
If the system is running Windows, open
and run > . Stop the NetIQ IDM Fan-Out Driver service.In iManager, stop the Driver in the Driver Set Overview.
If you want the Core Driver Shim (asamcdrv) to automatically start at system startup, you will need to configure the operating system startup routines. The asamcdrvd startup script for Linux automatically integrates with the Linux chkconfig utility. To set asamcdrvd to auto-start, enter the following command:
chkconfig asamcdrvd on
The Driver Shim can be reconfigured in a number of areas, as itemized below.
NOTE:Always be sure to stop the Driver Shim before starting any of these reconfiguration tasks as described in Stopping the Core Driver.
To re-run the installer’s configuration wizard in Windows, open
and run ( on Windows Server 2008). Click the button under . Then select from the dialog box that opens.You can use the installer to create a new installation, create a new driver or upgrade an existing driver. Note that the installer doesn't remember previously configured fields, so you'll have to enter the fields like you did on the first-time install.
To change the Remote Loader and/or Driver Object passwords:
If the system is running Linux or Solaris, enter the following command and select menu item 1:
/usr/local/ASAM/setup/fandrv-config
If the system is running Windows, execute the following command from the installation directory (C:\Novell\ASAM by default):
bin\CoreDriver\asamcdrv.exe -sp
To retrieve a new SSL certificate from eDirectory:
If the system is running Linux or Solaris, enter the following command and select menu item 2:
/usr/local/ASAM/setup/fandrv-config
If the system is running Windows, execute the following command from the installation directory (C:\Novell\ASAM by default):
bin\CoreDriver\asamcdrv.exe -s
To install or remove the Driver Shim service in Windows, execute the following command from the installation directory (C:\Novell\ASAM by default) using either the installService or removeService parameter:
bin\CoreDriver\asamcdrv.exe -parameter
For scaleability, you can install secondary drivers to handle platform synchronization and password requests. A system can run only one Driver Shim. See Section 5.4, Performance Tuning for more information on specifying secondary drivers.
To install a secondary driver.
On the secondary Driver Shim’s system, follow steps 1-7 under one of the following tasks, depending on your operating environment:
NOTE:In step 7, be sure to specify the container that holds the ASAM System Container.
You will be prompted to create a new Driver or upgrade a Driver. Click
to create a new Driver.Specify a distinct name for the Driver as well as its port.
Select the Driver’s network address.
When you are prompted whether to make the new Driver primary, click
to keep the Driver secondary.Once the Driver Shim is installed, import a new Driver following the steps in Importing a Configuration for a Newly Installed Core Driver. Be sure to use the XML configuration file generated for the secondary Driver.
Migrate the Certificate Authority from the primary system. For details, see Migrating Certificate Authority.
You can now run the secondary Driver as you would the primary Driver.
Depending on your configuration needs, you may decide to install a Driver Shim for a new primary driver.
NOTE:If the Core Driver you wish to make primary is already installed, you can use the
menu task in iManager to do this.Stop all Identity Manager Driver objects and Driver Shims. See Stopping the Core Driver.
Follow all the steps in the task, Installing Secondary Drivers, with the following exception:
In step 5, click
to make the driver primary.Start all Identity Manager Driver objects and Driver Shims. See Starting the Core Driver.
Identity Manager and Identity Manager drivers must be activated within 90 days of installation, or they shut down. You can activate Identity Manager products to a fully licensed state at any time.
To activate Identity Manager products:
Purchase the appropriate licenses.
Generate a Product Activation Request.
Submit the Product Activation Request to NetIQ.
Install the Product Activation Credential received from NetIQ.
For detailed information about completing these steps, see Activating Identity Manager Products in the Identity Manager Administration Guide, available at the NetIQ Identity Manager 4.5 documentation site.
The Fan-Out Driver provides a unique Identity Management solution by extending its services to many clients both simultaneously and among mixed environments. This section describes best practices for ensuring optimal performance in the Core Driver Shim’s ability to deliver this functionality.
Adding secondary Drivers can provide your Fan-Out platform clients with failover and load balancing. If you have multiple eDirectory servers and plan to deploy the Fan-Out Platform Services to many different systems, it’s recommended that you install and deploy the Fan-Out driver to more than one server.
The Fan-Out Platform Receiver, the component that connects to the Core Driver to receive events from Identity Manager, can be configured to run in five different operation modes (see Section 8.8.1, Modes of Operation). Three of these modes, in particular, may have an impact on the performance of the Core Driver Shim, as described in Table 5-1.
Table 5-1 Effect of Operation Modes on Core Driver performance.
Mode |
Function |
Effect on Performance |
---|---|---|
Persistent |
The Platform Receiver connects and remains connected to the Fan-Out Driver to receive events in real-time, which is desirable if it is necessary for your platform to receive events as they occur in the Identity Vault. |
Maintaining the open connection and its resources does carry an overhead in both memory and CPU usage for the Driver Shim. |
Polling |
The Platform Receiver connects to the Fan-Out Driver on configurable intervals to catch up on events since its last poll. |
Positive: Can allow the Driver Shim to release its connection and free up resources. Because each and every event will not be delivered to the Platform immediately, this mode will deliver a single event with all of the needed provisioning information to the Polling platform, making the delivery more efficient. Negative: Can also cause delayed event delivery and, depending on the polling interval, you may see the same memory issues if you have too many platforms connecting too frequently. |
Scheduled |
Very similar to Polling mode with one exception: it only runs once. Allows the system to decide when to launch the Platform Receiver using another facility, such as a cron. |
Can provide your systems with nightly or weekly updates and also allow you to stagger the event deliveries, which safeguards against overloading your Fan-Out Driver with too many requests at once. |
After you have installed the Core Driver of the NetIQ® Identity Manager Fan-Out Driver, use the information in this section for further configuration and administration.
Topics include
Before beginning, remember that the Fan-Out Driver includes two principal parts: the Core Driver and Platform Services. Information in this section focuses on the Core Driver’s configuration, and additional configuration will need to be performed on each platform.
Core Driver configuration information is maintained in the Driver object and in objects in the ASAM System container. The Core Driver installation process creates the initial configuration.
You use iManager to maintain the configuration information.
For information about managing the Driver object configuration parameters, see Driver Object Configuration Parameters.
For information about managing the objects in the ASAM System container, see Section 6.4, Applications For Configuration and Section 6.5, Management Tasks.
You also can use the Driver Shim configuration file to make setting about how the Core Driver communicates with Platform Services. For information about options in the fanout.conf file see Section 6.6, The Driver Shim Configuration File.
The Core Driver maintains configuration objects that represent each target platform for its own use in the ASAM System container.
Target platforms each obtain local configuration information from their respective platform configuration file. For more information about the platform configuration file, see Section III, Platform Services Planning.
System security is maintained through connection certificates between driver components and password-protected access to objects in NetIQ eDirectory™.
The connections between Core Driver components and between Event Journal Services and Platform Receivers use Secure Sockets Layer (SSL). Some types of the Platform Services Process use SSL for their connections to Authentication Services, and others use DES encryption. SSL connections are authenticated through the use of certificates.
The certificates used by the Identity Manager Fan-Out Driver are minted by the Certificate Services component of the Core Driver. When you install and configure a new component, you obtain a certificate.
Because platforms cannot examine the configuration objects for the Core Driver in the ASAM System container, Core Driver network address information is included in their certificates under the
field. This address is specified at installation time and must contain a reverse-lookup DNS record for the Platform Services components to establish trust to the Core Driver. If the address is not resolvable, the Platform Services installation will fail. Likewise, if the address associated with the Platform object does not have a reverse-resolvable DNS record, the Core Driver will not trust the Platform component and therefore will not establish an SSL connection.The Core Driver certificate is minted when you start the Core Driver for the first time. When you update network address information for a Core Driver, a new certificate is automatically minted for it. You must restart a Core Driver after changing its network address information in order for the new certificate to take effect.
Obtain a new certificate for a platform by starting the Platform Receiver with the appropriate command line parameter. For details, see Section IV, Platform Services Administration.
Identity Manager Fan-Out Driver components store their security certificates and related information in their certs directory. Ensure that access to the certs directory is restricted to the driver system itself and to its administrators.
Core Driver: asam\data\coredriver\certs
Platform Services: asam\data\platformservices\certs
The Core Driver performs an LDAP bind as the ASAM Master User to gain access to eDirectory. You must not place restrictions on the ASAM Master User object that would interfere with its use by the driver. Set maximum password length for the ASAM Master User to at least 32 characters. Disable intruder detection for the ASAM Master User object so that it cannot be disabled by someone without the appropriate rights.
The ASAM Master User must have Supervisor rights to the container in eDirectory that holds the users and groups that can be added to the Census. This is known as the User and Group Subtree. These rights are granted during installation.
To use the AS Client API to access objects outside of the User and Group subtree, you must grant additional rights to the ASAM Master User.
You must grant the ASAM Master User Browse object rights and Compare property rights to any object that is accessed through the AS Client API.
You must grant the ASAM Master User Read property rights to any object whose Security Equals list or Group Membership list, or other attribute value is accessed through the AS Client API.
Because the ASAM Master User is granted significant rights, you must ensure that its password remains secure.
The Core Driver obtains the password of the ASAM Master User from the Driver object. If your security practices prescribe periodic password changes, you can create a second User object to be used as an alternate ASAM Master User. Then you can swap back and forth between these User objects when it is necessary to change the password.
Use iManager to create a new User object. We recommend that you use the same directory context as the original ASAM Master User object.
Use iManager to assign the new User object Security Equivalence to the original ASAM Master User object.
Now you have two User objects with the necessary rights to act as the ASAM Master User.
The following procedure assumes you have created a second ASAM Master User object as described in the preceding section. It assumes one object is named ASAM1 and the other is named ASAM2. We also assume that ASAM1 is in use and that it is the one listed in the driver configuration parameters.
To change the ASAM Master User object to use a new password:
Use iManager to set the new password for ASAM2.
Update the Driver object for each Core Driver, specifying
for the Authentication ID, and the new password for the Application Password.In iManager, select
> .Locate the driver in its driver set.
Click the driver status indicator in the upper right corner of the driver icon, then click
.Click
> . and are located under the heading.Use iManager to change the password of ASAM1 to an undisclosed randomly chosen value.
ASAM2 is now the ASAM Master User, using a new password. The old password (of the ASAM1 user) can no longer be used.
NOTE:The Core Driver does an LDAP bind as the ASAM Master User upon startup. There is no need to restart the driver now. It will use ASAM2 the next time it is started.
You use the Web interface for most Core Driver configuration and administration tasks. For details about using the Web interface, see Section 6.4, Applications For Configuration.
The ongoing tasks of administering the driver can be grouped into the following categories.
Monitoring the operation of the Core Drivers
Monitoring the operation of Platform Services
Maintaining the Census
Reviewing your overall system management plan and making changes to the driver as appropriate
You can use the Fan-Out Driver Web application to view component status. For additional information, see Section 6.5.10, Displaying Component Status.
From time to time, depending on the size of the organization and the amount of activity, a system administrator should review the logs written by Core Driver components in order to check the health of the system. For example, you might want to investigate the cause of a large number of denied SSL connection requests. For more information about viewing logs, see Section 6.5.12, Viewing Logs.
The Fan-Out Driver also generates its own messages for purposes of monitoring and troubleshooting. These messages, which are documented in Section D.0, Messages. can also be redirected into your own custom programs and status documents to free your administrators from manual Fan-Out log-tracking.
NOTE:For more about the configuration parameter for using this capability, see Publish Fan-Out Log Messages.
It is a good idea to monitor the logs written by Platform Services. For details about these logs, see the administration guide for your platform operating system.
Administrative personnel should periodically use the Web interface to monitor naming exceptions and inactive users and groups. The frequency at which this is done is a function of the size of the organization being managed, the rate at which changes take place, and the rules in place within the organization concerning unique user IDs in eDirectory. If the organizational structure is appropriate, the same people who manage User objects also maintain the Census.
The actions taken depend on the policies of the individual organization. Some lines follow. For a review of the concepts, see the Section I, Concepts and Facilities.
A naming exception results if a new User object or a new Group object is encountered with the same name as an Enterprise User object or Enterprise Group object that is already in the Census. In an organization with a policy of unique usernames, this is generally the result of a mistake when adding a new user or group. In this case, the name of the new user or group should be changed to a unique name.
It is also possible that the new user or group was inadvertently added to the Census as a result of a mistake in changing the Census parameters so that the driver is now looking in unintended places for users or groups. In this case, correct the Census parameters.
It is also possible that a departmental administrator is attempting to breach security by taking the user ID of a previously existing user.
An inactive user or group is an Enterprise User or Enterprise Group whose corresponding User object or Group object has been deleted from the directory or is no longer covered by a Census Search object. Deletion of a user might be the legitimate result of someone leaving the organization. If this is true, the entry should be removed from the Census.
It is possible that the user or group has been inadvertently omitted from the Census as a result of a mistake in changing the Census parameters. If this is the case, correct the Census parameters.
You can use the Web interface to set Census parameters to automatically remove inactive users and groups from the Census if this is appropriate for your organization. For details, see Specifying Automatic Removal of Inactive Users and Groups.
Enterprise User objects in the Census relate to eDirectory User objects using a globally unique identifier (GUID). Identity Provisioning uses the GUID to prevent the reuse of a User object name from resulting in inappropriate access to the old user's accounts on Platform Systems. You must ensure that the deleted ID has been appropriately removed from all target platforms not managed by Identity Provisioning.
A user that is inactive or is not present in the Census, but does exist in eDirectory, is able to log in to eDirectory directly, but is not able to authenticate through the driver where the Enterprise User ID is required (such as is the case with z/OS or UNIX).
A user that is present in the Census but is not present in eDirectory is not able to authenticate through the driver.
NetIQ provides two application interfaces to support the installation and configuration of the Fan-Out driver:
iManager, which is a live Web interface for real-time administration
Designer, which is a planning tool for deployment modeling, testing and implementation
A Fan-Out Driver application plug-in exists for each of these interfaces.
In recent versions of iManager, the Fan-Out Driver plug-in comes installed as a standard feature. If you have an older version of iManager, you can use a copy of the plug-in that comes with your Fan-Out Driver software. To add it to iManager, see Installing the iManager Plug-In (If not Preinstalled).
In Designer, the plug-in is included as part of the Designer installation.
See the following topics for more about these two interfaces:
For detailed information about using iManager, refer to the iManager Administration Guide for your version of the product at the NetIQ Documentation site.
You configure and administer the Identity Manager Fan-Out Driver using iManager Roles and Tasks. The left side of the display lists actions you can take. Information pertaining to the action you select is displayed on the right side.
To use iManager and the Fan-Out Driver Web application, a user must have greater than normal user rights as shown in the following table.
Table 6-1 Web Interface User Rights
Function |
Rights |
---|---|
Log in and perform basic functions |
Read object rights to the ASAM System container |
Configure objects |
Read and Create object rights to the ASAM System container |
Start a Trawl |
Read and Create object rights to the ASAM System container |
To access the Web application, log in to iManager, click the Roles and Tasks icon at the top of the iManager screen, and click the desired Fan-Out Driver Configuration or Fan-Out Driver Utilities task.
To log out of the Web application, click the exit door icon at the top of the iManager screen.
Figure 6-1 Additional Information Icon
Additional information is available for the items and procedures in the Web application. To display this information, click the Additional Information icon.
Figure 6-2 List of Items
Many items in the Fan-Out Driver Web application are grouped into lists.
To add an item to a list, click the
button.To view or change the attributes of an item, click its name in the list.
To remove an item from a list, click the
button for that item. A confirmation page is displayed. Click to confirm removal, or click your Web browser’s button to abort.NetIQ Designer is a graphical user interface tool that allows you to model and deploy Identity Manager installations. Designer includes a Fan-Out Driver plug-in that enables you to configure Fan-Out data (such as Search Objects, Platforms, and Platform Sets) before deploying the Driver to eDirectory. With Designer you can also perform mass imports much more efficiently than with iManager.
Figure 6-3 Identity Manager Designer Interface with Fan-Out Driver Plug-in.
Refer to the Identity Manager 4.5 Documentation site for detailed information about using Designer.
To get started in using the Fan-Out Driver plug-in in Designer:
Create an Identity Vault and Driver Set.
Drag-and-drop a
from the section of the Palette from the right.Select the Fan-Out Driver configuration file and create the Driver.
Right-click the Driver line and select
.The plug-in application will open. Consult the Fan-Out Driver Plug-In section of the Designer online help for more information on modeling and deploying your Fan-Out Driver installation.
This section describes tasks you can complete in iManager, using the Fan-Out Driver Web Interface plug-in, to manage the Driver:
Configuring the Census includes the following tasks:
NOTE:Core Driver installation adds additional indexes for attributes of the objects added to the Identity Vault. Depending on the size of the existing directory tree, these indexes can take some time to bring online. Before you begin your first Trawl, verify that the indexes are in the online state as detailed in Section A.2, Core Driver Indexes.
Search objects specify how users and groups are selected from eDirectory to be included in the Census. For details about Search objects, see Section 6.5.8, Configuring Search Objects.
To update the Census after you make Search object changes, start a Trawl. For details about starting a Trawl, see Starting a Census Trawl.
To add a new Census Search object:
Click
> . The page is displayed.Click
> . The page is displayed.Specify the Search object distinguished name and attributes as desired, then click
.For details about Search object attributes, see Search Object Attributes.
To change a Census Search object:
Click
> . The page is displayed.In the list of Search objects, click the name of the Search object to modify. The
page is displayed.Update the attributes of the Search object as desired, then click
.For details about Search object attributes, see Search Object Attributes.
To remove a Census Search object:
Click
> . The page is displayed.In the list of Search objects, click the name of the Search object to be deleted. The
page is displayed.In the list of Platform Sets under
, click each button. The confirmation page is displayed each time you click a button. Click for each.Under the
heading, click the button. The confirmation page is displayed. Click .Object Services is notified by the Event Subsystem of events in eDirectory that affect the Census. Objects Services also periodically verifies the consistency of the Census by examining objects in the directory in a procedure known as a Trawl. Use the Web interface to specify the times when a Trawl runs.
Click
> . The page is displayed.Trawl times are listed (24-hour clock) under
. If no times are listed, Object Services does not automatically start any Trawls.Time of day values used by the driver are specified in Universal Time, formerly known as GMT, and commonly abbreviated as
.To add a new Trawl time, click
.To remove a Trawl time from the list, click its
button.You can choose to have Enterprise Users and Enterprise Groups whose corresponding User object or Group object is deleted from eDirectory or no longer covered by a Census Search object remain in the Census in an inactive state. This prevents another person from receiving access to resources as an unintended result of the reuse of a user name. Inactive users cannot authenticate through Authentication Services.
You can also specify that inactive users and groups be removed from the Census automatically during a Trawl after they have reached a given number of inactive days.
To specify inactive user and group options:
Click
> . The page is displayed.Inactive user and group options are listed on the
page under . Specify the action you want, then click .To view inactive users and groups, use the Section 6.5.13, Displaying Provisioning Details.
utility and specify > . For more information about using the Provisioning Details utility, seeYou can choose to delay the expiration of user passwords by Authentication Services from the exact date and time set for them in eDirectory until the end of the day (local time of the Core Driver host server) on which they expire. This can result in smoother operation for users on platforms with third-party systems that cache and reuse passwords during the day.
To specify password expiration options:
Click
> . The page is displayed.Password expiration options are listed on the
page under . Select the option you prefer, then click .You can use the Web interface to specify a Delete Pending Duration. During this interval, User and Group objects associated with a platform that have either been deleted from eDirectory or are no longer covered by a Search object, are not deleted from their corresponding platforms. The results of a Delete User or Delete Group Receiver script can be difficult to reverse. This provides a grace period to allow recovery from a mistake affecting many users.
The User Delete Pending or Group Delete Pending script is called when a delete event becomes pending for a user or group, but the Delete User or Delete Group script is not called until the Delete Pending Duration expires.
To specify when users and groups are deleted from platforms:
Click
> . The page is displayed.Deletion options are listed under
. Select the option you prefer, then click .Core Drivers provide the Web interface, perform Census maintenance functions, and provide Authentication Services and Identity Provisioning to platforms.
In iManager, select
> .Locate the driver in its driver set.
Click the driver status indicator in the upper right corner of the driver icon, then click
.In iManager, select
> .Locate the driver in its driver set.
Click the driver status indicator in the upper right corner of the driver icon, then click
.The Core Driver uses Driver object configuration parameters to identify the ASAM System container, the ASAM Master User object, an LDAP Services for eDirectory host server, and to obtain other related information. The Driver object is created during Core Driver installation.
To view and modify Driver object configuration parameters:
In iManager, select
> .Locate the driver in its driver set.
Click the driver status indicator in the upper right corner of the driver icon, then click E
.Click
> . Driver configuration parameters are located under the heading.Update the settings as desired. Then click
or . To end without saving any changes, click .Displays the name of this Driver object.
Specifies the IP address or DNS name and the TCP port of the LDAP Services for eDirectory host server that the Core Driver components use to access the ASAM System container. The LDAP host server must hold a writable replica of the ASAM System container.
The default is port 636 on the local host. For best performance, use the local host.
Specifies the fully distinguished name of the ASAM System container. The ASAM System container holds system configuration and operational objects.
Displays the Identity Manager integration modules that you have activated.
Enables/disables redirection of Fan-Out messages into your own custom programs and status documents to free your administrators from manual Fan-Out log-tracking.
Specifies the two-character ISO 639 language identifier for the language to be used by the Core Driver. The default value of Locale is en (English)
Specifies whether Event Journal Services changes password case when sending password replication information to Platform Receivers.
Password replication information is provided to the Core Driver from many different sources. Maintaining password case can be undesirable because some sources of password information present passwords in uppercase.
By default, Event Journal Services converts passwords to lowercase before sending password replication events to Platform Receivers.
Specifies the special password that is used with Password Migration on the z/OS operating system. Users with this password and with Login Disabled set are in the migration state. For more information about Password Migration, see the Identity Manager Fan-Out Driver for Mainframes Administration Guide.
Specifies the file path for the optional Password Change Validation Exit library. For information about the Password Change Validation Exit, see Section A.0, Core Driver Technical Notes.
Specifies the function name for the optional Password Change Validation Exit exported in the library identified by the Change Password Exit Library parameter. For information about the Password Change Validation Exit, see Section A.0, Core Driver Technical Notes.
Enables/disables whether Core Driver checks the platform’s certificate serial number against the serial number listed in the Core Driver configuration. This is a useful security measure to detect and reject certificates that may have been compromised.
Specifies timeout in seconds for the Core Driver to use when opening a network connection to another network system.
Specifies timeout in seconds for the Core Driver to use when reading data from a network connection. Higher timeout values can prevent premature disconnects.
Specifies timeout in seconds for the Core Driver to use when writing data to a network connection. Higher timeout values can prevent premature disconnects.
When the Core Driver’s Authentication Services resolves objects for platform authentication, this option allows Authentication Services to exclude objects that are not in the scope of the platform set.
When this option is set to
(default), Authentication Services will resolve requests against the entire Census. Setting this option to is useful if you intend to delete users after a specified duration in the Census and must immediately revoke access to a remote platform system that has been configured for authentication redirection.Descriptions for each attribute follow.
The Core Driver configuration must list all of the network addresses of the Core Driver's host server. Network address information for the host server is entered when the Core Driver is installed. You must update this information if the host server network address is changed or if an additional network interface is installed in the server.
One network address is designated as the default. Identity Manager Fan-Out Driver Core Driver components use the default address to connect to each other.
The platform configuration file used by a Platform Services component specifies the network address of each Core Driver that is used by that component. If you change the network address of a Core Driver that is specified in a platform configuration file, you must update that platform configuration file. For details about the platform configuration file, see Section III, Platform Services Planning.
If you change the network address configuration of a Core Driver, a new certificate is automatically minted for the Core Driver.
IMPORTANT:You must restart the Core Driver for the new certificate to take effect.
The TCP port number used by the Core Driver defaults to 3451. You can change the Core Driver TCP port number if necessary.
If you change a Core Driver TCP port number, you must also make the corresponding changes to each platform configuration file that references the Core Driver.
The TCP port number used by the Core Driver to communicate with Platform Services for z/OS and with NDS® Authentication Services (NDS-AS) version 3 Clients. The default is 2000.
Authentication Services maintains an encrypted cache of recent successful authentication requests to provide better performance for applications, such as Web servers, that make large bursts of requests to authenticate the same user in a short period of time.
You can specify the amount of memory that is allocated for this cache and the maximum length of time an entry is to be kept in the cache.
One Core Driver is designated as the primary Core Driver. Other Core Drivers are known as secondary Core Drivers. The primary Core Driver serves the Web interface and provides environmental information during the installation process for other Core Drivers. Only the primary Core Driver listens for events from eDirectory and performs Trawls.
In the Web interface, click
> . The page is displayed.Click
.Click
to confirm.Restart the previous and new Core Drivers. For details about this procedure, see Stopping a Core Driver and Starting a Core Driver.
Configure the iManager plug-in to use the new primary Core Driver. For details, see Section 6.5.3, Configuring the iManager Plug-In.
Before changing which Core Driver is the primary Core Driver, ensure that the proposed new primary Core Driver holds replicas of all objects covered by Census Search objects.
For step-by-step instructions to add a Core Driver, see Section 5.0, Installing the Core Driver.
In the Web interface, click
> . The page is displayed.Click the name of the Core Driver whose configuration you want to change. The
page is displayed.Specify attributes for the Core Driver as appropriate.
Remove the Core Driver from the platform configuration file of all platforms where it is present. For information about the platform configuration file, see the Section III, Platform Services Planning.
Stop the Core Driver.
For details, see Stopping a Core Driver.
Uninstall the Core Driver software and related files from the Core Driver host.
If the host server operating system is Linux/UNIX, delete the ASAM directory from the file system.
If the host server operating system is Windows, use
> .Remove the Driver object from Identity Manager.
In iManager, select
> .Locate the driver set for the driver, then click
.Select the Core Driver from the list and confirm its deletion.
In the Web interface, click
> . The page is displayed.Click the
button for the Core Driver to be removed. The confirmation page is displayed. Click to confirm.Audit Services writes operational and audit log messages for the Core Driver to the asam\data\coredriver\logs directory.
You can use the Web interface to view logs and to configure how messages are managed. For information about viewing the logs, see Section 6.5.12, Viewing Logs. For details about configuring the logs, see Section 6.5.4, Configuring Logs.
Each administrative user must configure the iManager plug-in to use the primary Core Driver.
In the Web interface, click
> . The page is displayed.Specify the DNS name or IP address of the primary Core Driver host server.
Specify the TCP port number for the primary Core Driver. The default is 3451.
Click
.Audit Services maintains the Operational Log and Audit Log files written by the Core Driver. You can use the Web interface to manage log files. You can choose to have log messages kept for a given number of days, or you can choose to have log messages kept permanently. You can also specify the components whose messages are written to the logs.
Click
> . The page is displayed.Select the option that you want for log retention.
Select the components whose messages you want included in the logs.
Click
.You can use the Web interface to view log messages. For more information, see Section 6.5.12, Viewing Logs.
The Log Configuration page is also used to configure debugging logging. For more information, see Section 7.1, Obtaining Debugging Output.
A Platform Set contains one or more Platform objects that share the same users and groups.
When you add a new Platform Set, you first need to give it a name and associate it with a UID/GID Set. If the Platform Set is for Linux or UNIX systems, you have the option of using Posix attributes instead of a UID/GID set.
You also may specify an Alternate Naming Attribute. When a user or group is provisioned to a Platform within this Platform Set, the Alternate Naming Attribute indicates the name that will be used. Then you add Search objects that describe what users and groups are provisioned to the platforms that belong to the Platform Set.
IMPORTANT:If you specify an Alternate Naming Attribute for a Platform Set, you must also include that attribute in the Subscriber filter.
After you have defined a Platform Set, you can create the Platform objects that represent its target platforms. For information about creating Platform objects, see Section 6.5.6, Configuring Platforms.
The Platform Set object's user and group population is described by one or more Search objects. For details about Search objects, see Section 6.5.8, Configuring Search Objects.
Descriptions for each attribute follow.
When you create a Platform Set, you specify a UID/GID Set that is used to assign UID numbers and GID numbers to Linux/UNIX platforms that are members of the Platform Set. You cannot change the UID/GID Set assigned to Platform Set after the Platform Set has been created.
Leave this option empty to use the posixAccount and posixGroup uidNumber and gidNumber attributes.
By default the name given to a user on each platform is the CN. By using the Alternate Naming Attribute, you also can indicate a name associated with each platform within the Platform Set. If you use this extra attribute in eDirectory, then each user or group must include a value for it.
IMPORTANT:If you specify an Alternate Naming Attribute for a Platform Set, you must also include that attribute in the Subscriber filter.
The content of an attribute that is designated as an Alternate Naming Attribute should be either a single value or multiple values of the form <platformset>:<name>.
The actual entry you make on the
window should reflect the attribute name used by LDAP. You can find this information under the LDAP group object for the server, which includes the mapping between eDirectory and LDAP attribute names.Upon creation, each Platform object is associated with exactly one Platform Set.
In the Web interface, click
> Sets. The page is displayed.Click
. The page is displayed.Specify an Alternate Naming Attribute if one should be used.
Type a name for the new Platform Set, select the UID/GID Set that is to be used by the new Platform Set, then click
. The page is displayed.Add one or more Search objects to describe the user and group population for the Platform Set. Click
> .For details about Search objects, see Section 6.5.8, Configuring Search Objects.
Add one or more Platform objects to describe the target platforms that constitute the Platform Set. Click
> to create a new Platform object and add it to the Platform Set.For details about adding Platform objects, see Section 6.5.6, Configuring Platforms.
In the Web interface, click
> . The page is displayed.In the list of Platform Sets, click the name of the Platform Set to modify. The
page is displayed.Update the attributes of the Platform Set as desired.
Remove all platforms associated with the Platform Set.
For information about removing a platform, see Removing a Platform.
In the Web interface, click Fan
> Sets. The page is displayed.Click the
button of the Platform Set you want to remove. The confirmation page is displayed. Click to confirm.A Platform object contains the configuration information the Core Driver uses to serve a platform for Authentication Services and Identity Provisioning. Additional configuration of Platform Services is performed on the platform. For detailed information about configuring and administering Platform Services, see the Section III, Platform Services Planning.
For platforms that may restrict password length or case sensitivity (mainframes, for example), the Authentication Mode can be used to allow case-sensitive, shorter passwords. This mode allows you to continue to use and enforce complex passwords in eDirectory while providing an authentication method for systems that do not or cannot adhere to the same password policies.
Check Passwords
Select
if you want the Core Driver to check passwords without considering case.Select
to enforce case sensitive passwords.Check only the first number of characters
Enter an integer, greater than or equal to 0, to indicate how many characters should be checked in the correct password. Examples:
If you select 8, the Core Driver will only check the first 8 characters of the password for validity.
Indicating 0 disables the entire Authentication Mode feature.
Descriptions for each attribute follow.
Each platform is a member of exactly one Platform Set. The Platform Set is used to associate users and groups with its member platforms. You specify the Platform Set that a platform belongs to when you create the Platform object. The Platform Set a platform belongs to cannot be changed after the Platform object is created.
You can specify whether or not requests from a platform for password replication information are honored. Enable this only for those platforms that need, and are trusted with, password information from eDirectory.
No: No password information is provided to the platform.
Yes: Password information is provided to the platform. No events for an account are sent to the platform unless password information for the account is available to the driver.
If Available: Password information is provided to the platform when it is available. Events for an account are sent to the platform even if no password information is available for the account. This setting can result in accounts being unprotected if it is used without password redirection.
After you enable password replication for a platform, you must restart the Platform Receiver if it is running in Persistent Mode or Polling Mode.
In order for password replication information to be available to a platform, the appropriate password change intercepts must be installed and correctly configured on all systems that can change passwords in eDirectory. For more information, see Section 4.3.2, Password Replication Requirements and the Section I, Concepts and Facilities.
The DNS name or IP address of the platform system. If the platform system has more than one network interface, list all of the network addresses.
Information about the DES key that is used to encrypt communications with platforms that use the DES interface is stored in the Platform Configuration object. The platform configuration file of platforms that use the DES interface must contain the same DES key as the Platform Configuration object or communication attempts fail.
When you change the DES key, the previous key is saved in the Platform Configuration object. You can specify a time interval during which communications using the old key are accepted from the platform system. Specify an interval that gives you enough time to update the platform configuration file with the new DES key.
In the Web interface, click
> . The page is displayed.Click
. The page is displayed.Type a name for the platform, select the Platform Set the new platform is to join, then click
. The page is displayed.Specify attributes for the platform as appropriate.
For details, see Platform Attributes.
Install the platform distribution package on the target server. For details, see Section IV, Platform Services Administration and the Quick Start for your platform operating system type.
In the Web interface, click
> . The page is displayed.In the list of platforms, click the name of the platform to modify. The
page is displayed.Update the attributes of the platform as desired. For details, see Platform Attributes.
Remove the driver installation from the platform system. For details, see Section IV, Platform Services Administration.
In the Web interface, click
> . The page is displayed.In the list of platforms, click the
button of the Platform object that you want to remove. The confirmation page is displayed. Click to confirm.Provisioning configuration involves three attributes.
Descriptions of each attribute follow.
You can specify that certain objects are globally excluded from Identity Provisioning by the Identity Manager Fan-Out Driver. You can list a fully distinguished LDAP object name or a simple common name. If you add an object that has already been provisioned to target platforms, the object is deleted from the target platforms.
The time-out interval, in seconds, for LDAP operations initiated by the Web interface. If an LDAP request does not return within the time-out value, the operation fails.
The time-out interval, in seconds, for Core Driver LDAP operations. If an LDAP request by a Core Driver does not return within the time out-value, the operation fails.
In the Web interface, click
> . The page is displayed.Modify provisioning attributes as desired.
Search objects determine the users and groups that are included in the Census and Platform Set populations.
Start a Trawl after you make Search object changes. For details about starting a Trawl, see Starting a Census Trawl.
Search objects can be any of the following:
User Objects: Users who are Search objects are added to the Census.
Group Objects: Groups that are Search objects are added to the Census. Members of groups that are Search objects are added to the Census.
Organizational Role Objects: Occupants of Organizational Role objects that are Search objects are added to the Census.
Organization Objects and Organizational Unit Objects: Container objects are scanned for users and groups to add to the Census.
Dynamic Group Objects: Members of Dynamic Group objects that are Search objects are added to the Census.
The settings of the
and attributes described in the following section take precedence in determining which objects are added to the Census.Include Users: Determines if users covered by the Search object are added to the Census.
Include Groups: Determines if groups covered by the Search object are added to the Census.
Expand: Determines if users who are members of Group objects or occupants of Organizational Role objects found inside a container Search object are added to the Census.
Include Aliases: Determines if Alias objects covered by the Search object are added to the Census. The User or Group object that is represented by an Alias object is provisioned to platforms.
Depth: Determines how many steps down the eDirectory tree hierarchy the Core Driver looks beyond the container object for users and groups to add to the Census. A Depth of zero causes the search to stop at the Search object container.
In Census: Determines if users and groups covered by this Search object are included in the Census.
Platform Set Associations: Specifies which Platform Sets this Search object is used to populate.
Click
> . The page is displayed.Click
. The page is displayed.Specify the Search object distinguished name and attributes as desired, then click
.For details about Search object attributes, see Search Object Attributes.
Click
> . The page is displayed.In the list of Search objects, click the name of the Search object to modify. The
page is displayed.Update the attributes of the Search object as desired, then click
.For details about Search object attributes, see Search Object Attributes.
Click
> . The page is displayed.In the list of Search objects, click the name of the Search object to be deleted. The
page is displayed.In the list of Platform Sets under
, click each button. The confirmation page is displayed each time you click a button. Click for each.Under the In
heading, click the button. The confirmation page is displayed. Click .A UID/GID Set contains entries for users and groups, together with their corresponding Linux/UNIX UID and GID numbers.
A UID/GID Set is associated with each Platform Set so that the UID and GID numbers of users and groups managed by driver are the same on all Linux/UNIX platforms within the Platform Set.
When a new user or group is added to a Platform Set, it receives the next available UID/GID number.
You can reserve a range of numbers for local use by the platform administrators. The driver does not assign UID or GID numbers within the reserved range.
Leave this option empty to use the posixAccount and posixGroup uidNumber and gidNumber attributes.
Descriptions of each attribute follow.
The highest UID/GID number that has been assigned to a user or group.
Specifies a range of UID/GID numbers that the driver does not assign to users or groups.
The Platform Sets that use this UID/GID Set.
In the Web interface, click
> . The page is displayed.Click
. The page is displayed.Type a name for the UID/GID Set configuration object in the ASAM System container.
Specify the lowest and highest numbers to be reserved for local system administrator use, then click
.The value for these numbers cannot be changed after you create the UID/GID Set.
In the Web interface, click
> . The page is displayed.In the list, click the name of the UID/GID Set you want to view. The
page is displayed.Remove all Platform Sets associated with the UID/GID Set.
For information about removing a Platform Set, see Removing a Platform Set.
In the Web interface, click Fan
> . The page is displayed.Click the
button of the UID/GID Set you want to remove. The confirmation page is displayed. Click .To display a status overview of your Identity Manager Fan-Out Driver system, click
> in the Web interface.To display status details for a component, click the component name on the
page.You can use the Web interface to view documentation for the Identity Manager Fan-Out Driver. To view the documentation, click
> .You can use the Web interface to view log files. You can also use Audit to view log information.
To start the Log Viewer, click
> . The page is displayed.You can control the display of log files by setting the values of the following fields. Click
after you have specified new values.Component: The component whose log you want to view.
Log Type: The type of log for the selected component that you want to view. This can be the Operational Log or the Audit Log.
Lines to Return: The number of lines to be returned at one time. This value determines the size of a set of lines used in scrolling operations, such as Next and Find Next.
Date: The date of the log information that you want to display. Type this date in yyyy-mm-dd format. For example, specify June 26, 2004 as 2004-06-26.
Time: The time of the first log record to display. Type the time in hh:mm:ss (24-hour clock) format. Seconds are optional. For example, specify 1:30 p.m. as 13:30.
Find: A search string. The first set of lines containing the Find String, written after the time specified, is displayed. All lines containing the find string are marked with an icon so that they can be easily identified as you scroll through the log.
To view the documentation for a given message, click its Message ID in the log display. An explanation for the message is displayed.
Navigation links are provided for the following functions:
Beginning of Day: Scrolls the log display to the beginning of the day specified by Date.
End of Day: Scrolls the log display to the end of the day specified by Date.
Most Current: Scrolls the log display to most current set of lines.
Previous: Scrolls the display to the previous set of lines. Scrolling stops at the beginning of the day specified by Date.
Next: Scrolls the display to the next set of lines. Scrolling stops at the end of the day specified by Date.
Find Previous: Scrolls the display to the previous set of lines that include the find string. Scrolling stops at the beginning of the day specified by Date.
Find Next: Scrolls the display to the next set of lines that include the find string. Scrolling stops at the end of the day specified by Date.
You can use the Web interface to search for and display objects in the Census and in the user and group population of a Platform Set.
Click
> . The page is displayed.Select the Search Type you want.
Type the Search String.
Objects whose name begins with the string you type are matched. If you leave this field blank, all objects are matched.
Select the maximum number of results to be returned.
Click
.Objects matching the search string are returned, up to the maximum count that you specified.
Click the name of an object in the results list to view its attributes. The
page is displayed for that object.Naming exceptions are produced when a new User or Group object covered by a Census Search object is found with the same name as an Enterprise User or Enterprise Group object that is already present in the Census.
To review naming exceptions in the Web interface, click
> .In the Web interface, click
> .Use iManager or a similar utility to change the name of the User or Group object that is causing the conflict.
To remove the record of the naming exception, click the Remove button for the exception in the list on the
page of the Web interface.Trawl processing automatically removes naming exceptions from the list after you have resolved them.
If you have recurring exceptions that are normal for you, you can permanently exclude them from the Census and the exception list.
In the Web interface, click
> .In the desired row, click the button for the action you want to take.
To exclude all users and groups with this common name, click
.If the user or group already exists in the Census and on platforms, the platforms receive a Delete Pending event and, after the Delete Pending Duration, a Delete event. The object is not provisioned to the platform again.
To exclude this specific user or group, click
.The Platform Receiver can return an error indication for its processing of a provisioning event. Such events remain pending for the platform, but are marked in an error state. You can use the Web interface to clear these events or to mark them to be sent to the Platform Receiver again.
In the Web interface, click
> . The page is displayed.Click the name of the platform whose errors you want to handle. The
page is displayed.Select the desired action for the events that are in error.
If additional events for a user or group associated with a platform are created (by a Trawl or by the Event Subsystem), pending events that are in error are cleared for that user or group.
Object Services examines portions of eDirectory specified by Census Search objects to build and maintain the Census. This process is known as a Trawl. Only the primary Core Driver performs Trawls. For information about setting the primary Core Driver, see Designating the Primary Core Driver.
You can use the Web interface to display information about the last Trawl, to start a Trawl, and to stop a Trawl that is in progress.
NOTE:Core Driver installation adds additional indexes for attributes of the objects added to the Identity Vault. Depending on the size of the existing directory tree, these indexes can take some time to bring online. Before you begin your first Trawl, verify that the indexes are in the online state as detailed in Section A.2, Core Driver Indexes.
To display Trawl information, click
> .Click
> . The page is displayed.Click
.For information about scheduling Trawls to run automatically, see Specifying Trawl Times.
You can use the Web interface to stop a Trawl.
Click
> . The page is displayed.Click
. It can take a few moments for the Trawl to stop.The driver shim configuration file /usr/local/ASAM/data/fanout.conf controls operation of the driver shim. You can specify the configuration options listed in Table 6-2, one per line. You can also specify these options on the command line. For details about driver shim command line values, see Section A.3, Driver Shim Command Line Options.
Table 6-2 Driver Shim Configuration File Statements
Option (Short and Long Forms) |
Description |
---|---|
-conn <connString> -connection <connString> |
A string with connection options. Enclose the string in double quotes ("). If you specify more than one option, separate the options with spaces.
|
-path <driverPath> |
Specifies the path for driver files. The default path is /opt/novell/racfdrv. |
-netinterface <ipaddress> |
Specifies the ip address through which the driver listens for client requests. |
-sp <RLpassword>,<DOpassword>, -setpassword <RLpassword>,<DOpassword>, |
Sets the Remote Loader and Driver object passwords. |
-t <traceLevel> -trace <traceLevel> |
Sets the level of debug tracing. 0 is no tracing, and 10 is all tracing. For details, see Section A.4, The Trace File. The output file location is specified by the tracefile option. |
-tf <fileName> -trace <traceLevel> |
Sets the tracefile location. The default is /user/local/nxdrv/logs/trace.log. |
-ndl -nodirxmllog |
Disables writing to the driver status log file. Disables writing to dirxml.log. |
-tracefile /usr/local/ASAM/debug.log -trace 0 -connection "ca=/usr/local/ASAM/keys/ca.pem port=8090" -path /usr/local/ASAM/
The Fan-Out driver uses SSL X.509 certificates to maintain secure connectivity between platforms and core drivers. These certificates are located in the file system, under the following paths for the Core Driver and Platform Services, respectively:
/usr/local/ASAM/data/CoreDriver/certs/ /usr/local/ASAM/data/PlatformServices/certs/
For Core Drivers, there are five files:
ca_cert.pem—This is the public certificate file for the Fan-Out "Root CA"
ca_key.pem—This is the private key file for the Fan-Out “Root CA”
ca.pem—This is the public certificate for the local Fan-Out Core Driver
key.pem—This is the private key file for the local Fan-Out Core Driver
ca.pem—This is also the public certificate file for the Fan-Out "Root CA"
For Platform Services, there are three files:
cert.pem—This is the public certificate file for this platform.
key.pem—This is the private key file for this platform.
ca.pem—This is the public certificate file for the Fan-Out "Root CA"
Each certificate can be viewed in plaintext, using the OpenSSL command:
openssl x509 -in <path to certificate.pem> -text Certificate: Data: Version: 3 (0x2) Serial Number: 1002 (0x3ea) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Novell Account Management 3.1 Certificate Authority Validity Not Before: Sep 30 15:30:42 2014 GMT Not After : Oct 1 15:30:42 2015 GMT Subject: CN=localhost, OU=localhost, OU=platform sets, OU=event driven objects, OU=asam system, O=system . . .
The contents contain important fields, such as the Subject Name, DNS Alternate Subject Names, Serial Number, Before and After Dates, and Issuer. A combination of these fields are used to verify access during communication.
Alternatively, you can find the Certificate Expirations for everything in the Fan-Out Driver iManager Plug-In:
Click on Fan-
Click on
From here, you will find the certificate expiration date for the Root CA.
Click on
to list the certificate expiration dates for all core drivers; or click on to view the certificate expiration dates for all platforms.Certificates are created for Core Drivers during Core Driver startup, and for Platforms during the Platform Services installation and secure task. During this process, the Core Driver uses two attributes on the cn=Certificate Services,ou=Manager Services,ou=ASAM System object:
<definition display-name="Verify serial number of incoming platform connection: " id="111" name="verifySerialNumber" type="boolean"> <description>During the SSL handshake between the driver and the connecting platform, the serial number can be verified against the last serial number generated by the core driver. Enter a value of "true" if you wish to verify this serial number upon connecting.</description> <value>false</value> </definition>
The definition above configures whether this Core Driver should validate Platform serial numbers when attempting to establish a connection.
When a Platform Services is installed, a platform certificate is issued and an expiration date is stamped on the certificate “Not Before” field. The duration of this certificate depends upon the Certificate Services attribute “ASAM-certDelayExpireTime” value. This is global for all platforms and core drivers. When a certificate is approaching expiration, a message may be displayed and logged to the system syslog to indicate:
CRT012A Platform Certificate will expire on 20151001153042Z
You can renew the platform certificate by running the following command:
/usr/local/ASAM/bin/PlatformServices/PlatformReceiver/asamrcvr -t
After obtaining the new certificates, simply re-start any services that are using it, such as asampsp or asamrcvr.
When a Core Driver is installed, a certificate is issued and an expiration date is stamped on the certificate ASAM-certExpirationDelay value. This is global for all platforms and core drivers. When a certificate is approaching expiration, a message may be displayed and logged to the system syslog to indicate:
field during shim startup. The duration of this certificate depends upon the Certificate Services attributeCRT013A Core Driver Certificate will expire on 20151001153042Z
You can recreate the Core Driver certificates with a couple methods. Changing any of the Core Driver object properties, such as Network Address and restarting the Core Driver will automatically regenerate a new certificate. Alternatively, you may simply delete the ca.pem file and restart the Core Driver to allow it to regenerate a new certificate.
The Root CA for the Fan-Out driver is the most important certificate, as it is used to issue and sign all certificate files for Platforms and Core Drivers. This certificate has a duration of 10 years. However, when it is renewed, a few steps must be followed. This procedure preserves the Root CA’s key, which is necessary to keep platform and core driver certificates valid, so do not delete the ca_key.pem:
Remove the following files from all Core Driver servers:
ca_cert.pem ca.pem
Restart any of the Core Driver server shims to allow it to regenerate a new set of ca_cert.pem and ca.pem files.
Copy the ca_cert.pem and ca.pem to the remaining Core Driver servers and restart those driver shims to load the new Root CA.
Because the ca.pem must be distributed to all platform objects, you must also force Platform Services to renew their certificates via section 6.7.3, or manually copy ca.pem to each platform and restart the Platform Services processes.
NetIQ® Identity Manager Fan-Out Driver components record messages to their Audit Log, Operational Log, and their host system log. Examining these should be foremost in your troubleshooting efforts.
The Audit and Operational logs of Core Driver components are maintained in their logs directory.
By its very nature, the Fan-Out Driver is highly dependent upon the proper operation of your network and NetIQ eDirectory™. If you are having problems with the driver, ensure that the various driver components are able to communicate with one another, and that eDirectory is functioning properly.
For information pertaining to performance issues, see Section 4.2, Configuration and Performance Guidelines.
IMPORTANT:Make sure that you upgrade the Identity Manager Fan-Out Driver, including all of your platforms, when new versions or support packs become available.
Identity Manager Fan-Out Driver components support the option to produce extensive debugging output. Although this output is intended primarily for use by NetIQ Technical Support, you might find it useful for your own troubleshooting efforts.
Because debugging mode adversely affects performance, it should not be used for routine operations.
To obtain debugging output for the Core Driver:
Specify the destination for debugging information by setting the Debug Log File and Debug to DSTrace configuration parameters as desired.
For more information, see Driver Object Configuration Parameters.
Specify the debugging information to be produced.
In iManager, click
> . The page is displayed.Select the Core Driver components you want debugging information for.
Click
.Problems with Core Driver configuration can result in improper driver operation. The messages logged by Identity Manager Fan-Out Driver components can lead you to the source of such problems.
Ensure that rights are properly set to enable the driver to perform its functions.
For the rights required by the ASAM Master User object, see Section 6.2.2, ASAM Master User Security.
For the rights required by administrative users, see Rights Required for Web Application Use.
Ensure that your platform has a valid certificate. For more information, see Section IV, Platform Services Administration.
For platforms that use the DES interface, ensure that the DES encryption key specified for the platform in the Platform Configuration object and the DES encryption key specified in the platform configuration file are identical.
Ensure that the Core Drivers referred to by your platform configuration file are running and that they are using the network address and TCP port number specified in the platform configuration file.
Examine the Core Driver and Platform Services Process log files.
Ensure that your platforms have been upgraded to the current version when you upgrade the Core Driver.
Verify that LDAP is running on the servers that hold replicas of User and Group objects covered by Census Search objects.
Verify that the platform certificate has been created on the host running the Platform Receiver.
Ensure that the Core Drivers referred to by your platform configuration file are running and that they are using the network address and TCP port number specified in the platform configuration file.
Examine the logs generated by the Platform Receiver and the Core Driver for error messages.
Ensure that Census Trawls are being run at appropriate intervals and that they complete without errors.
You can check to see when daily Census Trawls are scheduled through the Web interface. For details, see Specifying Trawl Times.
You can view the Exceptions to see if any naming exceptions have occurred. For details, see Section 6.5.14, Reviewing Naming Exceptions.
You can check the Core Driver Operational Log to see when the last Census Trawl was completed. Examine the Core Driver Operational Log for any potential errors that could have prevented the successful creation of Census information.
Ensure that your Census Search object parameters are set so that all intended users are included in the Census. For details, see Section 6.5.8, Configuring Search Objects. You can review the contents of the Census by using the Web interface. For further details, see Section 6.5.13, Displaying Provisioning Details.
Census entries relate to objects in eDirectory using their globally unique identifier (GUID). This prevents accidental reuse of a name from resulting in unintended access to resources. If a user that is represented in the Census is removed from eDirectory, the Census entry is marked inactive. If a new User object with the same name and context is created in eDirectory, the old Census entry remains inactive and a naming exception occurs.
Detailed network troubleshooting, which can depend on a number of factors particular to your environment, are beyond the scope of this document. However, communication problems among the various Identity Manager Fan-Out components are often caused by basic issues.
To verify IP Connections between platforms and the Core Driver, use the ping command. From a command prompt on the Linux, UNIX or Windows system, use a command prompt to enter ping ipaddr, where ipaddr is the IP address of the remote computer.
Firewalls can disrupt connectivity between the Core Driver and its connected systems. To verify that the TCP port is reachable, use a command prompt to enter telnet ipaddr 3451, where ipaddr is the IP address of the remote computer. The TCP port 3451 is used by the Core Driver for communication with the connected platforms.
Check DNS if you are using named hosts in your platform or Core Driver address configurations. DNS resolution is necessary to verify certificates for SSL communication.
eDirectory is complex, and the details of troubleshooting are beyond the scope of this document. Refer to your eDirectory documentation for further details. Additional information can be found on the NetIQ Support Web site.
Part III provides you with information you need to plan deployment of Platform Services for the NetIQ® Identity Manager Fan-Out Driver. It includes the following chapters:
This section presents an overview of the Platform Services part of the NetIQ® Identity Manager Fan-Out Driver. Platform Services makes requests to Core Drivers for Authentication Services and provisioning events.
If the Fan-Out Driver is new to you, read the information presented in Section I, Concepts and Facilities.
Topics in this section are
The Platform Services Process makes requests to Core Drivers for Authentication Services functions such as authentication, user name resolution, and password changes.
NOTE:For an overview of how Platform Services works with the components of the Core Driver—the other major part of Identity Manager Fan-Out Driver architecture—see Section I, Concepts and Facilities.
Figure 8-1 Platform Services
The Platform Services System Intercept is hooked into the login process of a system using standard, vendor-provided mechanisms. It provides password verification and password change functions.
The Platform Receiver obtains provisioning events from Event Journal Services and acts on them by running Receiver scripts to create and maintain users and groups as appropriate.
Platform Services also provides an application programming interface (API) that you can use for your own applications. For more information, see Section V, API Development.
Some types of platforms communicate with the Core Driver for Authentication Services using Secure Sockets Layer (SSL). Others use DES encryption. All platform communication with Event Journal Services uses SSL.
The Platform Services Cache Daemon obtains provisioning events from Event Journal Services and stores them in a local memory cache for efficient retrieval by the Name Service Switch. This information contains a complete record for a Linux or UNIX account or group, which may be accessed by services that use the Name Service Switch system calls.
The Name Service Switch is a system library providing complete account redirection as an alternative to storing user and group accounts and passwords locally. By providing such services through a memory cache, this data is protected from interactive accounts on the local system. In addition, the data remains centrally managed by eDirectory™ and a large number of accounts may be accessed by a single Linux or UNIX system, improving on traditional /etc/passwd methods for accomplishing this, which can be inefficient to update or access.
Authentication Services uses eDirectory for functions such as user authentication. The Platform Services Process, together with the System Intercept, provides Authentication Services on a platform.
z/OS*, Linux and UNIX systems can redirect password verification and password changes through Authentication Services to eDirectory. An IBM* i (i5/OS and OS/400) system can authenticate users locally, but uses Authentication Services to replicate passwords in its password store from the passwords of objects in eDirectory that correspond to its users. z/OS, Linux and UNIX systems can supplement password redirection with password replication for fail-safe operation.
The Identity Manager Fan-Out Driver uses the system intercept on Windows* systems to capture password change information and store it in eDirectory. Password change information from eDirectory is delivered to authorized systems as provisioning events, replicating password information from eDirectory.
You can use the platform configuration file to specify which users use Authentication Services and which ones authenticate locally. The driver has a built-in list of special users that, by default, are excluded from Authentication Services. For more information about the platform configuration file, see Section 10.0, The Platform Configuration File. For more information about the standard exclude list, see Section 8.10, Standard Exclude List.
Identity Provisioning uses events from eDirectory to provision user and group account information to the platform. The Platform Receiver, together with the Receiver scripts, provides Identity Provisioning on a platform.
You can use the platform configuration file to specify which users and groups are managed using Identity Provisioning and which ones are managed locally. The driver has a built-in list of special users and groups that, by default, are excluded from Identity Provisioning. For more information about the platform configuration file, see Section 10.0, The Platform Configuration File. For more information about the standard exclude list, see Section 8.10, Standard Exclude List.
Each managed user and group is assigned the same UID and GID number across all Linux/UNIX platforms in a Platform Set.
Account Redirection uses eDirectory for user and group account information. By extending your users and groups with the posixAccount and posixGroup auxiliary classes, you can assign the following Posix attributes for your users and groups:
loginName
uidNumber
gidNumber
gecos
homeDirectory
loginShell
groupName
memberUid
These attributes correspond to the following lines in /etc/passwd:
loginName:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell
For groups, they correspond to the following lines in /etc/group:
groupName:x:gidNumber:memberUid
This Posix information will be synchronized to a local memory cache on your Linux or UNIX system and accessed by the Name Service Switch. The Name Service Switch runs when a user logs on and also when a command that requires information from this or another user or group account is invoked.
The Platform Services Process provides the Authentication Services interface to eDirectory by communicating with the Core Driver. This interface is called by the System Intercept for such functions as checking a user's password at log in. It is also used by the Authentication Services (AS) Client API to provide eDirectory access to your own applications. For details about using the AS Client API, see Section V, API Development.
The Platform Services Process maintains persistent connections with Core Drivers for Authentication Services and performs load balancing and failover.
The Platform Services Process obtains configuration information, such as the location of Core Drivers, from the platform configuration file. For additional information about the platform configuration file, see Section 10.0, The Platform Configuration File.
On platforms where the volume of traffic with Core Drivers is so low that running the Platform Services Process is not justified by the performance benefits, you can connect the System Intercept and AS Client API directly to core services. For details, see Section 10.3.11, DIRECTTOAUTHENTICATION Statement.
The Platform Services Cache Daemon obtains provisioning events from the Event Journal Services component of the Core Driver. The Platform Services Cache Daemon examines each event and updates the local cache for the appropriate account record. When the daemon is run for the first time, a full sync is performed to synchronize all users and groups with the local cache. This may take some time, depending on how many users and groups you have to synchronize with the platform. However, once this full sync occurs, the data is written to a protected and encrypted local file cache for temporary storage when the cache daemon is shut down. Upon startup, this cache is loaded into memory again and updated by Event Journal Services when changes are made in eDirectory.
System integration of Platform Services makes use of standard, vendor-provided system control points.
Details about configuring and administering Platform Services are provided in later sections of this guide. Also be aware that this guide is one of three available administration guides for the Fan-Out Driver, each tailored to the range of platforms with which it can work:
Identity Manager Fan-Out Driver for Linux and UNIX Administration Guide
Identity Manager Fan-Out Driver for Mainframes Administration Guide (z/OS)
Identity Manager Fan-Out Driver for Midrange Administration Guide (IBM i, OS/400, i5/OS)
System integration of Platform Services for z/OS makes use of standard exits provided by the security system in use (RACF*, CA* ACF2*, or CA Top Secret*). For more information, see the Identity Manager Fan-Out Driver for Mainframes Administration Guide.
System integration of Platform Services for most Linux/UNIX systems makes use of the Pluggable Authentication Module (PAM) framework that is defined by OSF RFC 86.0. Applications must make the appropriate PAM API calls in order to be PAM-aware. You can also modify your applications to use the AS Client API directly. For more information, see the Identity Manager Fan-Out Driver for Linux and UNIX Administration Guide.
System integration of Platform Services for AIX* supports both the Loadable Authentication Module (LAM) system provided by AIX and the PAM framework; you choose which you wish to use. The PAM framework is only recommended for AIX versions 5.3 and later.
Password changes on an IBM i system are provided to the Core Driver through the Password Change Validation Program Exit, which is controlled by system value QPWDVLDPGM. Password changes in eDirectory are received by the platform as provisioning events. For additional information, see the Identity Manager Fan-Out Driver for Midrange Administration Guide.
The Platform Receiver obtains provisioning events from the Event Journal Services component of the Core Driver. The Platform Receiver examines each event and the current status of users and groups on the platform. Then the Platform Receiver calls Receiver scripts as necessary to perform needed changes. On password replication platforms, the Platform Receiver also updates the local password store.
The Platform Receiver provides failover support for connections to Event Journal Services.
The Platform Receiver obtains configuration information, such as its mode of operation and the location of the Core Driver, from the platform configuration file. For additional information about the platform configuration file, see Section 10.0, The Platform Configuration File.
The Platform Receiver can be configured to obtain and process provisioning events in five different modes.
In Full Sync Mode, the Platform Receiver connects to Event Journal Services and requests a Full Sync. Event Journal Services provides, and the Platform Receiver processes, a complete set of provisioning events to populate the users and groups for the platform. Then the Platform Receiver ends.
The first time a Platform Receiver is run for a new platform, it automatically receives provisioning events for all users and groups for the platform. If this process is interrupted, processing resumes the next time the Platform Receiver is run. There is no need to run the Platform Receiver in Full Sync Mode during routine installation.
You can run the Platform Receiver in Full Sync Mode to recover from a disaster on the platform that affects the user or group population.
You can run the Platform Receiver in Full Sync Mode any other time as appropriate to ensure that the user and group population on the platform is consistent with eDirectory.
If a Full Sync operation is interrupted, the provisioning process resumes the next time the Platform Receiver is run in Persistent Mode, Polling Mode, or Scheduled Mode. Do not start the Platform Receiver in Full Sync Mode to recover from an interrupted Full Sync operation, because Full Sync processing starts from the beginning each time.
Check Mode functions similarly to Full Sync Mode, except that Receiver scripts are invoked in Check Mode. In Check Mode, the base scripts take no actions to alter the user or group population on the platform.
If you extend the base scripts, take no actions that alter the user or group population while Check Mode is in effect.
Operation in Check Mode does not affect the queue of pending events maintained by Event Journal Services for the platform.
Check Mode is useful for testing your extensions to Receiver scripts.
You can use Check Mode at any time to verify that the user and group population on the platform is consistent with eDirectory.
In Persistent Mode, the Platform Receiver connects to Event Journal Services, obtains queued provisioning events, and processes them. It then remains connected, processing additional events as they become available.
In Polling Mode, the Platform Receiver connects to Event Journal Services, obtains queued provisioning events, and processes them. The Platform Receiver then closes the connection, waits for five minutes, and repeats the process until you stop it. For details about specifying the interval between polling cycles, see Section 10.3.21, POLLINT Statement and Section 10.3.22, POLLRAND Statement.
In Scheduled Mode, the Platform Receiver connects to Event Journal Services, obtains queued provisioning events, and processes them. It then closes the connection and ends. Scheduled Mode is designed for use with external job schedulers, such as the UNIX cron utility.
You specify the mode of operation for the Platform Receiver through the RUNMODE statement in the platform configuration file or through a command line parameter. For details about specifying the RUNMODE statement, see Section 10.3.24, RUNMODE Statement.
You can periodically run the Platform Receiver in Full Sync Mode to ensure that accounts on the platform are consistent with eDirectory.
For routine operations, we recommend that, unless you need the real-time processing of events provided by Persistent Mode, you run the Platform Receiver in Polling Mode or Scheduled Mode. This reduces the number of concurrent connections that must be serviced by the Core Driver host. The frequency of change activity in the population, the operating schedule of the platform, and the nature of the connection between the platform and the Core Driver should help you determine which of these modes to use.
You can use Check Mode for testing extensions to Receiver scripts.
The Platform Receiver examines the provisioning events it obtains from Event Journal Services and inspects the state of users and groups on the platform. Then the Platform Receiver calls Receiver scripts as needed to make the state of users and groups on the platform consistent with eDirectory.
The Identity Manager Fan-Out Driver provides a set of fully functional base scripts. You can extend these base scripts as appropriate for your needs. For example, if you have a third party system that uses its own user ID database, you can extend the base scripts to add new users to it based on membership in a special group, and to remove users from it when they are removed from the group.
The Receiver script functions are
Add User
Modify User
Delete User
Delete User Pending
Enable User
Disable User
Rename User
Add User to Group
Remove User from Group
Add Group
Modify Group
Delete Group
Delete Group Pending
Rename Group
NOTE:These are the functions performed by Receiver scripts. The actual implementation is platform-OS dependent. Multiple functions might be combined into a single script, or the steps of a single function might be distributed across several scripts. Not all functions are meaningful for all platform-OS types.
In addition to the scripts that perform actions on users and groups, there are utility scripts that are used for such functions as testing for the existence of a user and checking group membership.
The base scripts are extensively commented. For details on the operation of the base scripts, examine the scripts themselves. Become thoroughly familiar with the operation of a base script before you attempt to extend it.
Platform Services normally excludes certain special users from Authentication Services processing and Identity Provisioning. You can use the platform configuration file to override this or to specify additional users and groups to be excluded.
Users excluded from Authentication Services are authenticated using the local security system. Provisioning events are not processed for users and groups excluded from Identity Provisioning.
For details about Include/Exclude processing, see
Following is the standard list of users and groups that are excluded from Authentication Services and Identity Provisioning processing.
Account Operators |
adm |
admin |
administrator |
administrators |
audit |
Backup Operators |
bin |
Cert Publishers |
cron |
daemon |
DB2XML |
DHCP Administrators |
dip |
disk |
DnsAdmins |
DnsUpdateProxy |
Domain Admins |
Domain Computers |
Domain Controllers |
ecs |
Enterprise Admins |
floppy |
ftp |
games |
gdm |
gopher |
Group Policy Creator Owners |
guest |
halt |
hpdb |
ibmuser |
ident |
imnadm |
IUSR_WIN2KEDIR |
IWAM_WIN2KEDIR |
kmem |
krbtgt |
ldap |
listen |
lock |
lp |
lpd |
|
mailnull |
man |
mem |
MTS Impersonators |
news |
nfsnobody |
noaccess |
nobody |
nobody4 |
nogroup |
nscd |
ntp |
nusers |
nuucp |
nwgroup |
nwldap |
nwprint |
nwroot |
nwuser |
operator |
other |
perf |
Print Operators |
printq |
QAUTPROF |
QBRMS |
QCLUMGT |
QCLUSTER |
QCOLSRV |
QDBSHR |
QDBSHRDO |
QDESADM |
QDESUSR |
QDFTOWN |
QDIRSRV |
QDLFM |
QDOC |
QDSNX |
QEJB |
QFNC |
QGATE |
QIJS |
QIPP |
QLPAUTO |
QLPINSTALL |
QMSF |
QNETSPLF |
QNETWARE |
QNFSANON |
QNTP |
QPEX |
QPGMR |
QPM400 |
QRJE |
QSECOFR |
QSNADS |
QSPL |
QSPLJOB |
QSRV |
QSRVBAS |
QSVCDRCTR |
QSYS |
QSYSOPR |
QTCM |
QTCP |
QTFTP |
QTMHHTP1 |
QTMHHTTP |
QTMPLPD |
QTSTRQS |
QUMB |
QUSER |
QYPSJSVR |
radvd |
RAS and IAS Servers |
Replicator |
root |
rpc |
rpcuser |
rpm |
Schema Admins |
security |
Server Operators |
shutdown |
slocate |
staff |
sync |
sys |
sys1 |
sysadmin |
system |
TsInternetUser |
tty |
users |
usr |
utmp |
uucp |
wheel |
wine |
www |
xfs |
|
|
This section helps you plan for deployment of Platform Services for the NetIQ® Identity Manager Fan-Out Driver. If the Fan-Out Driver is new to you, read the information presented in Section I, Concepts and Facilities before proceeding.
Before you can install and use Platform Services, you must complete the installation of at least one Core Driver and have it running.
The installation planning process for the Core Driver addresses a number of installation-wide issues. Review Section II, Core Driver Administration, especially the planning section, before you proceed.
For information about required software and systems, as well as supported platforms and operating environments, see the Identity Manager 4.5 Drivers Documentation Web site. From this index page, you can select a readme file associated with the platform(s) for which you need support.
Topics in this section include
In order for users to be able to log in to the operating system using Authentication Services, they must be defined to the operating system on the platform. You can automate account maintenance through the use of provisioning events. For details about managing accounts, see Section 8.3, Identity Provisioning.
Users, passwords, and groups in eDirectory™ that do not conform to the character set and length restrictions imposed by your operating system cannot participate in Authentication Services or Identity Provisioning on your platform.
The Identity Manager Fan-Out Driver does not support authentication or password change for users having a null password.
In some cases, a system other than eDirectory might contain the users that you want to participate with the Identity Manager Fan-Out Driver. There are tools, such as LDIF, that you can use to import these users into eDirectory. If you cannot extract the passwords for the affected user accounts, you can use the Password Migration component of the Fan-Out Driver. This component can help you accomplish a smooth transition to basing your user accounts in eDirectory.
The connection between the Platform Receiver and Event Journal Services uses Secure Sockets Layer (SSL). SSL connections are authenticated through the use of certificates. Some types of the Platform Services Process use SSL for their connections to the Core Drivers for Authentication Services, and others use DES encryption.
Obtaining a security certificate for your platform from the Core Driver requires that you supply the fully distinguished name and password of an eDirectory user with Read and Create object rights to the ASAM System container.
Identity Manager Fan-Out Driver platform certificates are stored in the data\ platformservices\certs subdirectory of the ASAM directory of their host server file system. Ensure that access to the certs directory is limited to the appropriate users.
Administrative password resets must be done through an eDirectory utility, such as iManager, or through a program that uses the AS Client API.
Use of the AS Client API is secured on IBM i and UNIX platforms through SSL and a token that is stored in the asam\data\platformservices\certs directory by the Platform Services Process. Ensure that access to the certs directory is limited to the appropriate users.
Use of the AS Client API is secured on z/OS Platforms through the Authorized Program Facility (APF). Ensure that access to the z/OS Platform Services Load Library is limited to the appropriate users.
When planning for Authentication Services, include the following considerations:
If you don’t plan to use Authentication Services to authenticate system users or provide password change information to Core Drivers, you don’t need to install the System Intercept.
If you don't plan to use the AS Client API or Authentication Services, you don't need to run the Platform Services Process.
If your use of Authentication Services and the AS Client API is infrequent and does not require high performance, consider using the DIRECTTOAUTHENTICATION statement in the platform configuration file. This configuration does not use the Platform Services Process. For details about the DIRECTTOAUTHENTICATION statement, see Section 10.3.11, DIRECTTOAUTHENTICATION Statement.
You might need to permanently exclude some users from Authentication Services processing. You might want to phase in your implementation by using a subset of your users to start with. For details about excluding users from Authentication Services processing, see Section 10.3.5, AS.USER.INCLUDE Statement / AS.USER.EXCLUDE Statement.
You must specify which Core Drivers are used for Authentication Services. You might want to establish different preference groups for sets of these Core Drivers based on their network connectivity or other issues. For details, see Section 10.3.7, AUTHENTICATION Statement.
When planning for Identity Provisioning, include the following considerations:
If you don't plan to use Identity Provisioning, you don't need to run the Platform Receiver.
You might need to permanently exclude some users and groups from Identity Provisioning. You might want to phase in your implementation by using a subset of your users and groups to start with. For details about excluding users and groups from Identity Provisioning, see Section 10.3.4, AM.USER.INCLUDE Statement / AM.USER.EXCLUDE Statement and Section 10.3.3, AM.GROUP.INCLUDE Statement / AM.GROUP.EXCLUDE Statement.
If the base Receiver scripts do not meet your needs, you can write your own extensions. Decide what additional processing you will perform and how you will test your extensions.
All platforms in a Platform Set have the same population of users and groups associated with them for Identity Provisioning. Users and groups on Linux/UNIX platforms in Platform Sets that share a common UID/GID Set have the same UID or GID on each participating platform. Decide how you will organize your Platform Sets and UID/GID Sets.
You must specify which Core Drivers are used for Identity Provisioning. For details, see Section 10.3.23, PROVISIONING Statement.
You must choose the mode of operation used by the Platform Receiver to obtain events. For details, see Section 8.8.1, Modes of Operation and Section 8.8.2, Selecting a Mode of Operation.
When planning for Replication Platforms, include the following considerations:
By default, the Core Driver converts passwords to lowercase before sending them to the Platform Receiver. For more information, see Lower Password Case.
The Permit Password Replication attribute of a Platform object determines whether provisioning events for user accounts are sent to the platform before the passwords for these accounts are known to the Identity Manager Fan-Out Driver.
Platforms configured with Permit Password Replication set to
do not receive Provisioning events for user accounts until the account passwords are known to the driver.Platforms configured with Permit Password Replication set to
do receive Provisioning events when they occur for an account, even if the password is not known to the driver.The driver uses system intercepts to collect password information. To be provisioned onto a platform configured with Permit Password Replication set to
, users must either change their passwords on a platform where the system intercepts are installed and configured, or authenticate on a participating redirection platform.By planning a staged deployment of the driver so that most users have authenticated using other platforms first, you can ensure the availability of these users to password replication platforms when you are ready to deploy the driver on them.
For more information, see Section 6.5.6, Configuring Platforms.
When planning for Account Redirection Platforms, include the following considerations:
Use the Account Redirection option if you wish to redirect all account information, including loginName, uidNumber, gidNumber, gecos, homeDirectory, loginShell, memberUid fields and passwords.
If you plan to use Account Redirection, you do not need to run the Platform Receiver or the Platform Services Process. Instead, you need to configure your system for the Name Service Switch and configure the Platform Services Cache Daemon for system startup.
If you plan to use Account Redirection, you must populate your user and group accounts with the posixAccount and posixGroup auxiliary classes. This can be done manually on a per-object basis or through a bulk LDIF import process. Alternatively, you may run the Linux and UNIX User Settings Driver to automatically populate this information when users and groups are created or modified. For details on this driver, see the Identity Manager Driver documentation for the Linux and UNIX user settings.
If you plan to use Identity Manager with a connected system running AIX or HP-UX, you may need to replace the standard comm utility (invoked by the comm command) included with the operating system. Versions of comm that are included with either of these operating systems have been known to fail when used with files that contain long text lines. In general, the problem occurs with text lines longer than 2000 characters.
The Identity Manager driver uses comm to get information from /etc/group. Therefore, if any of your AIX or HP-UX connected systems has an /etc/group file with a line longer than 2000 characters, you should use one of the following vendor-approved GNU packages to replace the comm utility:
This section describes the platform configuration file and its use. NetIQ® Identity Manager Fan-Out Driver Platform Services components use the platform configuration file to locate Core Driver components, to locate their run-time files, and to control their operation.
IMPORTANT:Because the platform configuration file contains sensitive information, you should use the appropriate access controls to restrict its use to the driver system itself, and to its administrators.
Topics in this section include
The location of the platform configuration file depends on which operating system the platform is using.
For Linux and UNIX, the default configuration file is /usr/local/ASAM/data/asamplat.conf. You can use a command line parameter to specify a different platform configuration file. More information can be found in Section IV, Platform Services Administration.
Use the following syntax guidelines for the platform configuration file:
Any line beginning with an asterisk (*), a semicolon (;), or an octothorpe (#) is a comment. All text that follows a semicolon or an octothorpe is a comment.
Configuration file statements are case-insensitive.
Except as noted, the order in which statements appear in the file does not matter.
Any parameter value that contains spaces must be enclosed in quotes. Do not use quotes with other values. For example:
PASSWORDPROMPT "Password: " PROVISIONING cdriver1.digitalairlines.com
This section describes the following platform configuration file statements:
The ADMINPASSWORD statement specifies the password of the administrative user specified by the ADMINUSER statement. If there is no ADMINPASSWORD statement, you are prompted to enter the password when obtaining a platform security certificate.
Syntax:
ADMINPASSWORD Pswd
Pswd specifies the password of the administrative user.
Example:
ADMINPASSWORD 18emf25dhf
The ADMINUSER statement specifies the fully distinguished name of an eDirectory user with Read and Create object rights to the ASAM System container. If there is no ADMINUSER statement, you are prompted to enter a user object name when obtaining a platform security certificate.
Syntax:
ADMINUSER Fdn
Fdn specifies the fully distinguished name of an eDirectory user with Read and Create object rights to the ASAM System container.
Example:
ADMINUSER .Admin.DigitalAirlines
AM.GROUP.INCLUDE and AM.GROUP.EXCLUDE provide a list of specific groups or group masks to be included or excluded from Identity Provisioning. This can be useful for installation verification and early implementation and for special groups that should be managed locally. Multiple AM.GROUP.INCLUDE and AM.GROUP.EXCLUDE statements can be coded, and they can be mixed together. There is no limit to the number of groups that can be included or excluded.
Syntax:
AM.GROUP.INCLUDE GroupMask[ GroupMask, GroupMask ...]
AM.GROUP.EXCLUDE GroupMask[ GroupMask, GroupMask ...]
GroupMask can be a single complete group name, or it can include masking characters to represent more than one group. If more than one GroupMask matches a given group, the most specific GroupMask is used. GroupMask is case-insensitive. For more information, see Section 10.4.1, Mask Characters and Examples.
Unless AM.GROUP.EXCLUDE * is coded, AM.GROUP.INCLUDE * is always assumed. Certain special groups are always excluded unless the IGNORESTANDARDEXCLUDES statement is specified. For details, see Section 10.3.13, IGNORESTANDARDEXCLUDES Statement.
Do not code both an AM.GROUP.INCLUDE statement and an AM.GROUP.EXCLUDE statement.
For more information, see Section 10.4, Using Include and Exclude Configuration Statements.
Example:
AM.GROUP.EXCLUDE sales, mkt*
AM.USER.INCLUDE and AM.USER.EXCLUDE provide a list of specific user IDs or user ID masks to be included or excluded from Identity Provisioning. This can be useful for installation verification and early implementation and for special user IDs that should be managed locally. Multiple AM.USER.INCLUDE and AM.USER.EXCLUDE statements can be coded, and they can be mixed together. There is no limit to the number of users that can be included or excluded.
Syntax:
AM.USER.INCLUDE UserMask[ UserMask, UserMask ...]
AM.USER.EXCLUDE UserMask[ UserMask, UserMask ...]
UserMask can be a single complete user ID, or it can include masking characters to represent more than one user ID. If more than one UserMask matches a given user ID, the most specific UserMask is used. UserMask is case-insensitive. For more information, see Section 10.4.1, Mask Characters and Examples.
Unless AM.USER.EXCLUDE * is coded, AM.USER.INCLUDE * is always assumed. Certain special users are always excluded unless the INGORESTANDARDEXCLUDES statement is specified. For details, see Section 10.3.13, IGNORESTANDARDEXCLUDES Statement.
Do not code both an AM.USER.INCLUDE * statement and an AM.USER.EXCLUDE * statement.
Identity Manager Fan-Out Driver Linux/UNIX platforms always manage root locally.
For more information, see Section 10.4, Using Include and Exclude Configuration Statements.
Example:
AM.USER.EXCLUDE act*, billing%, sys*, sales48
AS.USER.INCLUDE and AS.USER.EXCLUDE provide a list of specific user IDs or user ID masks to be included or excluded from Authentication Services. This can be useful for installation verification and early implementation and for special user IDs that should be authenticated locally. Multiple AS.USER.INCLUDE and AS.USER.EXCLUDE statements can be coded, and they can be mixed together. There is no limit to the number of users that can be included or excluded, although a large list can cause a performance impact because it must be searched for every user login. These statements apply to system authentications only and are not used by the AS Client API routines (although there is an API call to test whether a user ID is excluded).
Syntax:
AS.USER.INCLUDE UserMask[ UserMask, UserMask ...]
AS.USER.EXCLUDE UserMask[ UserMask, UserMask ...]
UserMask can be a single complete user ID, or it can include masking characters to represent more than one user ID. If more than one UserMask matches a given user ID, the most specific UserMask is used. UserMask is case-insensitive. For more information, see Section 10.4.1, Mask Characters and Examples.
Unless AS.USER.EXCLUDE * is coded, AS.USER.INCLUDE * is always assumed. Certain special users are always excluded unless the INGORESTANDARDEXCLUDES statement is specified. For details, see Section 10.3.13, IGNORESTANDARDEXCLUDES Statement.
Do not code both an AS.USER.INCLUDE * statement and an AS.USER.EXCLUDE * statement.
For more information, see Section 10.4, Using Include and Exclude Configuration Statements.
Example:
AS.USER.EXCLUDE act*, billing%, sys*, sales48
The ASAMDIR statement specifies the file path where the Identity Manager Fan-Out Driver is installed. Fan-Out Driver components use ASAMDIR to find files needed for execution.
Syntax:
ASAMDIR FilePath
FilePath specifies the location in file system where the component is installed. If there is no ASAMDIR statement, FilePath defaults as follows:
z/OS: /usr/local/ASAM in HFS
IBM i: /usr/local/ASAM
Linux and UNIX: /usr/local/ASAM
Windows: c:\novell\asam
Example:
ASAMDIR c:\novell\asam
The AUTHENTICATION statement specifies the network address and port of one Core Driver used for Authentication Services. In order to use Authentication Services, you must have at least one AUTHENTICATION statement in your configuration file.
A maximum of 100 AUTHENTICATION statements can be coded.
Syntax:
AUTHENTICATION Address [PORT PortNumber] [PREF PrefGroup]
Address specifies the DNS name or IP address of a Core Driver used for Authentication Services.
PortNumber specifies the TCP port number that is to be used to communicate with this Core Driver. PORT is optional. PortNumber defaults to 3451.
IMPORTANT:If you specify a port number other than the default, you must also use the Web interface to specify the same port number for the Core Driver configuration object.
PrefGroup specifies the Preference Group Number that determines the way a Core Driver is selected. It is optional, and the default is for all Core Drivers listed to be in Preference Group 1. Core Drivers within a Preference Group are selected equally for load balancing. Core Drivers with the lowest Preference Group Number are always tried first, followed by the Core Drivers with the next Preference Group Number, and so on, until a Core Driver can be contacted. Preference Group Number must be coded as a positive integer.
Examples:
AUTHENTICATION cdriver1.digitalairlines.com AUTHENTICATION cdriver2.digitalairlines.com AUTHENTICATION cdriver5.digitalairlines.com PORT 5009 PREF 2
The CODEPAGE statement specifies a code page to be used by the Platform Receiver. Data received and sent by the Platform Receiver is encoded in UTF-8.
Syntax:
CODEPAGE CodepageID
CodepageID specifies the code page to be used by the Platform Receiver for converting values from and to UTF-8. For information about the available choices for CodepageID, see the man page for iconv on your system.
If no CODEPAGE statement is present, UTF-8 values are used without conversion.
Example:
CODEPAGE iso88591
The DEBUGLOGFILE statement specifies a destination file for debugging data written when the -d command line parameter is present for a component.
Syntax:
DEBUGLOGFILE FilePath
FilePath specifies the location in file system where the debugging output is to be written.
Example:
DEBUGLOGFILE /usr/local/ASAM/debug.txt
The DEBUGTOSTDOUT statement specifies that debugging data is to be written to the standard output channel stdout when the -d command line parameter is present for a component.
Syntax:
DEBUGTOSTDOUT
Example:
DEBUGTOSTDOUT
The DIRECTTOAUTHENTICATION statement causes Authentication Services to connect directly to a Core Driver for Authentication Services without using the Platform Services Process. Use the DIRECTTOAUTHENTICATION statement on platforms where the volume of traffic with Core Drivers is so low that running the Platform Services Process is not justified.
Platforms using the DIRECTTOAUTHENTICATION statement do not perform Core Driver load balancing, although failover support is available if you specify multiple AUTHENTICATION statements.
Syntax:
DIRECTTOAUTHENTICATION
Example:
DIRECTTOAUTHENTICATION
The ENTROPY statement specifies the file where components obtain entropy for SSL.
Syntax:
ENTROPY FilePath
FilePath specifies the file that contains entropy.
If no ENTROPY statement is coded, the default is to use the /dev/random device for entropy. If there is no /dev/random device, the default entropy file is /etc/entropy.
If your platform has a /dev/random device, you do not need to code an ENTROPY statement.
Example:
ENTROPY /etc/entropy
The IGNORESTANDARDEXCLUDES statement specifies that the standard list of users and groups excluded from Identity Provisioning and Authentication Services processing is not used. If this statement is not present, the standard list of excludes is used. For the standard list of excluded users and groups, see Section 8.10, Standard Exclude List.
Syntax:
IGNORESTANDARDEXCLUDES
Example:
IGNORESTANDARDEXCLUDES
The LOCALE statement identifies the language to be used by the component.
Syntax:
LOCALE Id
Id specifies the two-character ISO 639 language identifier.
Example:
LOCAL en
The PASSWORDPROMPT statement specifies the prompt issued by the PAM module to request the user's password for authentication.
Syntax:
PASSWORDPROMPT Text
If there is no PASSWORDPROMPT statement, Text defaults to
"NDS Password: "
Example:
PASSWORDPROMPT "Password: "
The PASSWORDPROMPTCURRENT statement specifies the prompt issued by the PAM module to request the user's current password for password changes.
Syntax:
PASSWORDPROMPTCURRENT Text
If there is no PASSWORDPROMPTCURRENT statement, Text defaults to
"Current NDS Password: "
Example:
PASSWORDPROMPTCURRENT "Enter Current Password: "
The PASSWORDPROMPTCHANGE statement specifies the prompt issued by the PAM module to request the user's new password for password changes.
Syntax:
PASSWORDPROMPTCHANGE Text
If there is no PASSWORDPROMPTCHANGE statement, Text defaults to
"New NDS Password: "
Example:
PASSWORDPROMPTCHANGE "New Password: "
The PASSWORDPROMPTCHANGEAGAIN statement specifies the prompt issued by the PAM module to verify the user's new password for password changes.
Syntax:
PASSWORDPROMPTCHANGEAGAIN Text
If there is no PASSWORDPROMPTCHANGEAGAIN statement, Text defaults to
"Re-enter New NDS Password: "
Example:
PASSWORDPROMPTCHANGEAGAIN "Verify New Password: "
The PLATFORMNAME statement specifies the common name of the Platform object. If there is no PLATFORMNAME statement, you are prompted to enter the name when obtaining a platform security certificate.
Syntax:
PLATFORMNAME Cn
Cn specifies the common name of the Platform configuration object that was specified in the Web interface when platform was defined.
Example:
PLATFORMNAME WestCentral
The PASSWORDSOURCE statement allows you to specify where encrypted passwords should be stored. For example, on older UNIX systems, encrypted password information is stored in /etc/passwd. On most modern UNIX systems, this information is stored in /etc/shadow. On non-trusted HP-UX, the PASSWORDSOURCE statement should be used to specify whether the HP-UX system is using /etc/passwd or /etc/shadow for encrypted password information. By default, the installer package will determine which source to use; however, if you are running HP-UX in Trusted Computing Base (TCB) mode, where there is no /etc/shadow file, then you should omit the PASSWORDSOURCE statement and let Platform Services use standard HP API hooks to manage the encrypted password storage.
Syntax:
PASSWORDSOURCE fully-qualified-path-to-file
An important example of the PASSWORDSOURCE statement’s use is on HP-UX, when shadow passwords are enabled. The default location to look for encrypted passwords on non-trusted-mode HP-UX is /etc/passwd. When shadow passwords are enabled on HP-UX, PASSWORDSOURCE should be set as follows:
PASSWORDSOURCE /etc/shadow
The POLLINT statement specifies the interval in number of seconds between polling cycles. It can be used to spread the amount of traffic and load placed on the Core Driver during event processing. The default for the polling interval is 300 seconds (5 minutes), which, in some circumstances, may be too frequent.
Syntax:
POLLINT seconds
Example:
POLLINT 600
In the above example, POLLINT will set the polling interval to 600 seconds (10 minutes).
The POLLRAND statement specifies the minimum and maximum polling interval in seconds from which to choose a random interval between polling cycles. It can be used to spread the amount of traffic and load placed on the Core Driver during event processing. The default for the polling interval is 300 seconds (5 minutes), which, in some circumstances, may be too frequent.
Syntax:
POLLRAND minsec maxsec
Example:
POLLRAND 300 1200
In the above example, POLLRAND will set the platform receiver (asamrcvr) to select a random integer between 300 and 1200 to represent the interval in number of seconds before the next polling cycle begins.
The PROVISIONING statement specifies the network address and port of one Provisioning Manager Core Driver. A PROVISIONING statement must appear in the configuration file for the Platform Receiver and when obtaining a security certificate.
You can code more than one PROVISIONING statement. The first PROVISIONING statement in the file identifies the Provisioning Manager that is tried first. If a connection with the Provisioning Manager identified by the first PROVISIONING statement fails, the Provisioning Managers identified by any other PROVISIONING statements are tried, in the order the PROVISIONING statements appear in the configuration file, until a connection is successful or there are no more PROVISIONING statements.
Syntax:
PROVISIONING Address [PORT PortNumber]
Address specifies the DNS name or IP address of a Provisioning Manager.
PortNumber specifies the TCP port number that is to be used to communicate with the Provisioning Manager. PORT is optional. The default port number for the Provisioning Manager is 3451.
IMPORTANT:If you specify a port number other than the default, you must also use the Web interface to specify the same port number for the Core Driver configuration object.
Example:
PROVISIONING cdriver1.digitalairlines.com PROVISIONING cdriver4.digitalairlines.com
The RUNMODE statement specifies the mode of operation the Platform Receiver uses. Command line parameters that specify a mode of operation override the mode specified on the RUNMODE statement.
Syntax:
RUNMODE Mode
Mode specifies the mode of operation for the Platform Receiver. Possible values follow.
Table 10-1 Values For Specified Mode
Value |
Description |
---|---|
PERSISTENT |
The Platform Receiver uses Persistent Mode. |
POLLING |
The Platform Receiver uses Polling Mode. |
SCHEDULED |
The Platform Receiver uses Scheduled Mode. |
If no RUNMODE statement or mode-related command line parameter is present, the Platform Receiver uses persistent Mode.
For more information about Platform Receiver modes of operation, see Section 8.8.1, Modes of Operation.
Example:
RUNMODE polling
The SYSLOGFACILITY statement specifies the SYSLOG facility name to use for message logging on Linux/UNIX systems.
Syntax:
SYSLOGFACILITY FacilityName
FacilityName specifies the SYSLOG facility to use for logging messages. The possible values for a specific Linux/UNIX system are mapped by the syslog.h file of that particular system.
If no SYSLOGFACILITY statement is coded, the default value is LOG_DAEMON.
Example:
SYSLOGFACILITY LOG_DAEMON
The TRACEFILE statement specifies that debugging output is generated and the file path where it is written. If the TRACEFILE statement is present in the platform configuration file, full debugging output is generated even if the -d command line parameter is not present.
To obtain debugging output from the system intercepts when you use the DIRECTTOAUTHENTICATION statement, you must use either the TRACEFILE or the TRACETOSTDOUT statement.
Syntax:
TRACEFILE FilePath
FilePath specifies the location in the file system where debugging output is written.
Example:
TRACEFILE c:\novell\asam\debug.txt
The TRACETOSTDOUT statement specifies that debugging output is generated and that it is written to the standard output channel stdout. If the TRACETOSTDOUT statement is present in the platform configuration file, full debugging output is generated even if the -d command line parameter is not present.
To obtain debugging output from the system intercepts when you use the DIRECTTOAUTHENTICATION statement, you must use either the TRACEFILE or the TRACETOSTDOUT statement.
Syntax:
TRACETOSTDOUT
Example:
TRACETOSTDOUT
The UPDATEPASSWORD statement specifies that the driver updates the local security system upon a successful check password or change password operation, or when password replication information is received from the Core Driver. This allows a user to log in using the last password that worked on the system if the driver, eDirectory, or the network is not available, and the local security system is appropriately configured.
If there is no UPDATEPASSWORD statement present in the platform configuration file, the driver does not store passwords in the local security system.
Syntax:
UPDATEPASSWORD
Example:
UPDATEPASSWORD
The CRYPTTYPE statement specifies the format to use for storing passwords if the Fan-Out driver is configured to update local passwords. Therefore, the CRYPTTYPE statement works only if the platform configuration file (asamplat.conf) also contatins the UPDATEPASSWORD statement.
When the Fan-Out driver is configured to update local Linux or UNIX passwords, the driver can automatically choose from the available password storage formats of the target operating system. The CRYPTTYPE statement allows you to override this choice with a specific format you prefer.
The Fan-Out driver supports many different operating systems which, in turn, support many different formats for locally stored passwords.
Syntax:
CRYPTTYPE format rounds
Possible values for format are DES, MD5, BLOWFISH, SHA256, SHA512 and SUN_MD5.
Since its version 9 (12/02) release, Solaris has supported DES, MD5, BLOWFISH and SUN_MD5. Linux support is based on the version of glibc. Most recent Linux distributions support DES, MD5, SHA256 and SHA512. Blowfish is not in the mainline of glibc, but has been added in some Linux distributions, including SUSE® Linux.
NOTE:Some formats supported by the Fan-Out driver may not be appropriate for your operating system. For example, inappropriate CRYPTTYPE formats in asamplat.conf cause the driver to failover to DES on Solaris and MD5 on Linux.
The value for rounds only applies to BLOWFISH, SHA256 or SHA512. This second argument can be used to indicate the number of rounds, or repetitions, of transformation to be used. For BLOWFISH, possible values for rounds are 04, 05, 06, 07, 08, 09, 10, 11 or 12. For SHA256 and SHA512 any number within the range of 1000-999999999 is a possible value for rounds.
Example (MD5 format):
CRYPTTYPE MD5
Example (BLOWFISH format):
CRYPTTYPE BLOWFISH 09
Example (SHA512 format):
CRYPTTYPE SHA512 7000
The Fan-Out driver is designed to use default format types when the following conditions exist:
If an unacceptable rounds argument is specified for BLOWFISH on Linux, glibc uses MD5 instead.
If an unacceptable rounds argument is specified for SHA256 or SHA512 on Linux, glibc substitutes 1000 for the unacceptable value.
If an unacceptable rounds argument is specified for BLOWFISH on Solaris, Solaris substitutes 11 for the unacceptable value.
If no CRYPTTYPE statement is used in asamplat.conf on Solaris or Linux, the driver will attempt to use the native operating system configuration files to decide upon an encryption mechanism:
On Solaris /etc/security/policy.conf is consulted.
On Linux /etc/login.defs and /etc/default/passwd are consulted. If both exist, configuration information in /etc/login.defs is given preference over configuration information in /etc/default/passwd.
If no encryption configuration information can be found in the native configuration files, DES is used on Solaris and MD5 is used on Linux.
The UPDATESAMBA statement specifies that the driver updates the Samba password file upon a successful check password or change password operation, or when password replication information is received from the Core Driver.
If there is no UPDATESAMBA statement present in the platform configuration file, the driver does not store passwords in the Samba password file.
Syntax:
UPDATESAMBA FilePath
FilePath specifies the location of the smbpasswd program in file system.
Example:
UPDATESAMBA /usr/local/samba/bin/smbpasswd
The USEFILEIPC statement specifies that data from the Platform Receiver should be made accessible by the Platform Receiver scripts by using file Input/Output rather than environment variables.
While environment variables are a convenient method for communicating data between the Platform Receiver and the scripts, they have size limitations, based on the operationg system parameter ARG_MAX, that make it impossible to process events when they become too large. For example, a group that contains many users could exceed this size limit. The value of ARG_MAX varies on different operating systems.
Syntax:
USEFILEIPC
Example:
USEFILEIPC
The EXCLUDEUNMANAGED statement specifies that the Platform Receiver should query the Fan-Out Driver Census (in the Identity Vault) if it cannot reconcile a user’s membership in a group account on a local system with a corresponding group account managed in Identity Manager.
Not all group accounts on a local system need to be replicated and tracked centrally from the Identity Vault. For example, Linux and UNIX often place users in certain default groups that are of no consequence to security and therefore not added to the Identity Vault.
The Fan-Out driver does not make this distinction between groups managed by Identity Manager and groups relevant only to the local system. If the Platform Receiver detects that a user is member to a local group that does not also exist in the Identity Vault, it reverses the membership in its charge to maintain parity with Identity Manager.
The EXCLUDEUNMANAGED statement bypasses this default behavior. When it is specified, the Platform Receiver will first query the Census to see if the group account in question also exists in the Identity Vault. If the group is not found in the Census, it is excluded automatically and the local unmanaged group membership can be preserved.
Syntax:
EXCLUDEUNMANAGED
Example:
EXCLUDEUNMANAGED
The various Include and Exclude statements can be used in the platform configuration file to determine which users are authenticated through Platform Services and which users are authenticated locally, and which users and groups are managed based on provisioning events and which users and groups are managed locally.
These statements allow the use of masking characters to specify a mask that can match more than one user ID or group.
For details about each Include and Exclude statement, see the corresponding statement description.
Certain special users and groups are always processed locally unless you specify the IGNORESTANDARDEXCLUDES statement. For more information about this statement, see Section 10.3.13, IGNORESTANDARDEXCLUDES Statement. For a list of the users and groups in the standard exclude list, see Section 8.10, Standard Exclude List.
You can use masks to match more than one user ID or group in Include and Exclude statements. The following tables list mask characters and provide examples of masks.
Table 10-2 Mask Characters
Mask Character |
Matches |
---|---|
* |
Any string of zero or more characters. The asterisk (*) mask character can only be used at the end of a mask. |
% |
Any single character |
? |
Any single character |
\? |
Any single character |
\a |
A single alphabetic character |
\n |
A single numeric character |
\x |
A single alphanumeric character |
\s |
A single @, #, $, or other OS-dependent non-alphanumeric special character |
Table 10-3 Example Masks
Mask |
Matches |
---|---|
Z* |
ZEBRA ZULU ZED ZABRZE Z9 |
Z\n* |
Z9 Z9WWW |
\s\a\a\n\? |
#BB29 #BB2A #AB9_ |
\aFF |
AFF BFF CFF DFF EFF |
* |
All strings |
%%%%% |
All five-character strings |
????? |
All five-character strings |
\?\?\?\?\? |
All five-character strings |
The order in which INCLUDE and EXCLUDE statements are specified does not matter.
If more than one mask matches a given user ID or group, the most specific mask is used.
The mask is case-insensitive.
Specifying the same mask on both an INCLUDE and an EXCLUDE statement is a syntax error.
Unless EXCLUDE * is coded, INCLUDE * is assumed for each statement type. Certain special users and groups are excluded unless the IGNORESTANDARDEXCLUDES statement is specified. For details, see Section 10.3.13, IGNORESTANDARDEXCLUDES Statement.
Do not code both an INCLUDE * statement and an EXCLUDE * statement of the same type.
Part IV provides you with information you need to plan for deploying the Linux and UNIX Platform Services of the NetIQ® Identity Manager Fan-Out Driver. It includes the following chapters:
The installation and setup of NetIQ® Identity Manager Fan-Out Driver Platform Services includes tasks performed on the platform and the Core Driver. This section describes the installation tasks that are performed on the platform system. For details about platform configuration and administration tasks, see Section 12.0, Configuring and Administering Platform Services.
The Core Driver tasks include defining UID/GID Sets, defining Platform Sets, and defining Platform objects. These tasks must be completed before you can use Platform Services. For more information about these tasks, see Section II, Core Driver Administration.
After the planning process has been completed, installation of Platform Services for Linux and UNIX by experienced system programmers familiar with the local environment and the Identity Manager Fan-Out Driver should take about half an hour.
Topics in this section include
Platform Services for Linux/UNIX consists of four major components:
Platform Services Process: The Platform Services Process receives requests from other processes and manages communications with one or more Core Drivers for Authentication Services.
System Intercept: The System Intercept is implemented in most Linux/UNIX systems using a Pluggable Authentication Module (PAM). The Platform Services PAM module communicates with the Platform Services Process for password verification and password changes. In AIX the System Intercept may be implemented either by PAM or LAM (Loadable Authentication Modules), which is IBM’s proprietary predecessor to the PAM standard.
Platform Receiver: The Platform Receiver requests provisioning events from Event Journal Services and runs a Receiver script to carry out the appropriate action for each event as it is received.
Platform Services Cache Daemon: The Platform Services Cache Daemon requests provisioning events from Event Journal Services and stores the information locally in a memory cache pool. Requests by the local system for account information, such as the Fan-Out Name Services Switch, can access this information efficiently.
Secure Sockets Layer (SSL), used by Platform Services for communication with Core Drivers, requires a source of entropy. Some Linux/UNIX implementations provide a /dev/random device for entropy. If your Linux/UNIX implementation does not include a /dev/random device, you must install an entropy daemon. You must also include an ENTROPY statement in your platform configuration file to specify the source of entropy. For information about the platform configuration file, see Section 10.0, The Platform Configuration File.
The PRNGD entropy daemon can be installed from the /prngd directory of the distribution media.
Solaris versions before Solaris 9 do not include a /dev/random device. Sun has released this functionality for versions 2.6 onward in Patch ID 112438-01.
The Platform Services Process provides an interface for the System Intercept and the AS Client API to one or more Core Drivers for Authentication Services.
The Platform Services Process is called whenever a user attempts to enter the system using a user ID and password or when a user attempts to change the password. Such a request is passed from the system intercept to the Platform Services Process, which then communicates with a Core Driver and returns a response.
The Platform Services Process performs the following tasks:
Handles password check and password change requests from users
Communicates with Core Drivers for Authentication Services
Redirects Authentication Services requests to another Core Driver if a Core Driver is unreachable or returns an unexpected error
Gathers and logs performance statistics
The Platform Services Process communicates with Core Drivers using Secure Sockets Layer (SSL).
Start the Platform Services Process during system startup and stop it during system shutdown.
The Platform Services Process reads its configuration information from ASAM/data/asamplat.conf, the platform configuration file. The Platform Services Process logs messages to the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. For details about the platform configuration file, see. Section 10.0, The Platform Configuration File.
The Platform Services System Intercept communicates with the Platform Services Process for password verification and password changes.
The System Intercept is implemented in most Linux/UNIX systems using a Pluggable Authentication Module (PAM). Platform Services for AIX uses the Loadable Authentication Module (LAM) system provided by AIX. AIX 5.3 and later also supports PAM.
The Platform Receiver processes provisioning events received from the Event Journal Services component of the Core Driver.
The Platform Receiver communicates with Event Journal Services using Secure Sockets Layer (SSL). Data is encoded using UTF-8. You can use the CODEPAGE statement in the platform configuration file to configure the Platform Receiver to convert data using a specified code page. For details about the platform configuration file, see Section 10.0, The Platform Configuration File.
Run the Platform Receiver on a schedule that is appropriate for your requirements. For details about Platform Receiver operation, see Section 8.8, The Platform Receiver.
The Platform Receiver reads its configuration information from ASAM/data/asamplat.conf, the platform configuration file. It logs messages to the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file.
When the Platform Receiver successfully updates a password in the local security system or Samba password file, it logs a message to SYSLOG.
Receiver scripts for Linux/UNIX platforms are implemented as shell scripts. The Platform Receiver (asamrcvr) runs the scripts from ASAM/bin/PlatformServices/PlatformReceiver/scripts.
Provisioning events are received as groupings of name-value pairs as shown in the following example:
enterpriseUserName bob
The Platform Receiver calls a Receiver script whenever it is necessary to obtain information about users or groups on the platform and whenever it is appropriate to take an action for a user or group on the platform.
When the Platform Receiver calls a Receiver script, it maps the name-value pairs in environment variables as shown in the following example:
ENTERPRISEUSERNAME=bob
User names and group names are checked for validity before they are mapped to environment variables. A utility Receiver script is called to perform the validity checking.
Receiver scripts are called as appropriate to determine group affiliations for user events and group membership for group events.
Receiver scripts are called to take the necessary actions.
When the Platform Receiver responds to events by calling the appropriate scripts, the sequence in which those scripts are called is not always consistent. This is because the Platform Receiver’s responses can be influenced by many variables, including:
Other events received prior to the current event
The latest synchronization between eDirectory and the connected system
Table 11-1 provides examples of typical script execution order and demonstrates how that order can vary.
Table 11-1 Script Execution Order Examples
Event |
Script Execution Order |
---|---|
Add a user to eDirectory |
platformverifyandmapname.sh does_user_exist.sh adduser.sh addusertogroup.sh enableuser.sh disableuser.sh |
Add a group to eDirectory |
platformverifyandmapname.sh doesgroupexist.sh adduser.sh addgroup.sh populategroup.sh |
Add a user to an eDirectory group (causing the Platform Receiver |
(Group event response:) platformgetgrnam.sh platformgetpwnam.sh doesgroupexist.sh platformverifyandmapname.sh doesgroupexist.sh platformgroupmem.sh NOTE:The above scripts provide reason-checking before continuing with the remaining scripts. modgroup.sh populategroup.sh (User event response:) platformgetgrnam.sh platformgetpwnam.sh does_user_exist.sh platformverifyandmapname.sh does_user_exist.sh platformgroupaff.sh enableuser.sh disableuser.sh moduser.sh addusertogroup.sh removeuserfromgroup.sh |
The Name Service Switch communicates with the Platform Services Cache Daemon for account information defined by the RFC 2307 Posix Profile attributes. This library module may be installed on any Linux or UNIX system for complete account redirection, providing an alternative to storing user and group accounts and passwords locally. This information is delivered from eDirectory™ and updated live through Identity Management event mechanisms.
The Platform Services Cache Daemon processes provisioning events received from the Event Journal Services component of the Core Driver. These events are stored in local memory for quick access and the cache is updated live when new events are processed. The daemon communicates with Event Journal Services using Secure Sockets Layer (SSL). Data is encoded using UTF-8. You can use the CODEPAGE statement in the platform configuration file to configure the Platform Services Cache Daemon to convert data using a specified code page. For details about the platform configuration file, see Section 10.0, The Platform Configuration File. Run the daemon on system startup. For details about the daemon's operation, see Section 8.6, The Platform Services Cache Daemon.
The daemon reads its configuration information from ASAM/data/asamplat.conf, the platform configuration file. The daemon logs messages to the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file.
Authentication Services for Linux/UNIX redirects authentication requests to eDirectory and can replicate passwords from eDirectory.
When a password for a user associated with a Linux/UNIX system that uses password replication is changed in eDirectory, a provisioning event is generated by the Core Driver and given to the Platform Receiver for processing. By default, the Core Driver converts passwords to lowercase before sending them to the Platform Receiver. For more information about password case, see Lower Password Case.
Because password replication information travels in both directions, it is affected by the Include/Exclude lists of both Authentication Services and Identity Provisioning. It is important therefore, to configure the Include/Exclude lists for both the Platform Services Process and the Platform Receiver symmetrically if the platform uses password replication.
This section presents step-by-step tasks that can be used in various Platform Services installation scenarios.
Before beginning installation, be sure to complete the following:
Verify that your platform meets minimum system requirements. For information about required systems and software, as well as supported platforms and operating environments, see the Identity Manager 4.5 Drivers Documentation Web site. From this index page, you can select a Readme file associated with the platform(s) for which you need Fan-Out Driver support.
To improve your readiness, complete the planning suggestions detailed in Section 9.0, Planning for Platform Services before you begin.
Install, setup and configure the Fan-Out Core Driver (see Section 5.0, Installing the Core Driver)
Follow the steps in Section 6.5.6, Configuring Platforms.
Obtain the Platform Services distribution package for your target operating system from the NetIQ downloads site.
Always check the NetIQ Support Web Site for the latest support pack and product update information. Check the Release Notes and Readme files for the version you are installing for any special actions that might be required.
When you are ready to begin installation, refer to the following tasks, depending on your scenario:
To install Platform Services:
From your installation media, locate and execute the appropriate self-extracting installer:
sh aix_platformservices.bin sh freebsd_x86_platformservices.bin sh hpux_platformservices.bin sh hpux_ia64_platformservices.bin sh linux_x86_platformservices.bin sh linux_x86_64_platformservices.bin sh debian_x86_platformservices.bin sh linux_s390x_platformservices.bin sh solaris_sparc_platformservices.bin sh solaris_x86_platformservices.bin sh tru64_platformservices.bin
Select a language, read and accept the License Agreement.
Enter a path for installation or press the /usr/local.
key for the default,Enter the address of the primary Core Driver.
This represents the hostname or IP address of the system running the Core Driver Shim.
Enter the TCP port of the primary Core Driver or enter the default, 3451.
If you wish to enter secondary drivers, select
and repeat steps 4-5 of this task for each. Otherwise, select .Enter the name of the platform.
NOTE:The name you enter needs to have already been setup and specified when the Core Driver was configured for a new connected system, prior to Platform Services installation.
Enter an eDirectory administrative user.
This identity will authenticate to eDirectory and must have read and write privileges to the ASAM System container subtree.
Enter the password for the eDirectory administrative user.
Choose a provisioning option to configure this platform:
Select /etc/passwd and /etc/group.
to provision users and groups toSelect
to setup the system’s Name Service Switch (NSS) for virtual provisioning.Select
to configure this platform for API use only (no provisioning).NOTE:For more information about these options, see Section 12.2, Provisioning.
Choose an option for user password authentication:
Select
to redirect authentication requests to the Metadirectory.Select /etc/shadow.
to authenticate users locally fromSelect
to redirect authentication requests to the Metadirectory but synchronize passwords to provide local failover.NOTE:For more information about these options, see Section 12.3, Authentication.
If you selected
or in the previous step, now select whether users can change their eDirectory passwords from this Linux/UNIX platform.To upgrade an existing installation of Platform Services:
If any Platform Services daemons are running, be sure to stop them before proceeding. For more information, see Section 11.3.5, Stopping Platform Services.
From your installation media, locate and execute the appropriate self-extracting installer:
sh aix_platformservices.bin sh freebsd_x86_platformservices.bin sh hpux_platformservices.bin sh hpux_ia64_platformservices.bin sh linux_x86_platformservices.bin sh linux_x86_64_platformservices.bin sh debian_x86_platformservices.bin sh linux_s390x_platformservices.bin sh solaris_sparc_platformservices.bin sh solaris_x86_platformservices.bin sh tru64_platformservices.bin
Select a language, read and accept the License Agreement.
When prompted to
, select .Restart your Platform Services daemon. For more information, see Section 11.3.4, Starting Platform Services
Since the release of Identity Manager 3.6, the Fan-Out Platform Services installer supports command-line non-interactive installations and configurations. Using this feature you can install Platform Services with a single command line, allowing the entire process to be scripted for a mass deployment. To use the unattended installation feature, you must specify the -non-interactive parameter with one or more of the following parameter options.
To specify the DNS or IP hostname(s) and TCP port(s) of the Fan-Out Core Driver Shim:
-corehost hostname:port[,hostname:port]
For example, if you had three hosts, the command line would be similar to the following:
-corehost host10:3451,host20:3451,host30:3451
To specify the eDirectory administrative user:
-admin admin-dn
To specify the password for the eDirectory administrative user:
-password password
To specify the name of the platform object to configure this host with:
-platname name
To specify the name of the platform set under which to auto-create the platform object, use all of the following options:
-platformset name
-permit-pass-sync <yes | no | ifAvailable>
When you specify a platform set and a permit password sync option, the platform will be automatically created within the specified platform set with the corresponding password sync options. The IP or DNS information will also be automatically populated by the Core Driver. If a platform with this name already exists, the installation will fail.
To specify the platform’s provisioning configuration, use one of these options:
-local-prov | -nss-prov | -no-prov
Respectively these options represent: local provisioning, NSS (virtual) provisioning, and API only (no provisioning).
To specify the platform’s authentication configuration, use one of the following options:
-auth-redir | -auth-local | -auth-local-failover
Respectively these options represent: redirect authentication, authenticate locally, and authentication redirection with local failover.
To specify whether PAM should be auto-configured for password publishing, use one of the following options:
-pam-pass | -no-pam-pass
To specify the installation path:
-path path
To specify the default run mode (operation mode) of the Platform Receiver:
-runmode <persistent | polling>
The following command will automatically install Platform Services on Linux for local authentication and provisioning:
sh linux_x86_platformservices.bin -non-interactive -corehost 10.0.0.1:3451 -admin admin.acme -password novell -platname linux123 -local-prov -auth-local -pam-pass -path /usr/local -runmode persistent
If you have a custom process for deploying installations, upgrades or updates, you may prefer to extract the installation content manually for integration into your process. The self-extracting .bin installers use platform-specific packages to deploy the distribution files. These packages can be recovered by executing the appropriate installer with the -extract parameter.
For example, if linux_x86 were the operating system architecture of your target platform, you would execute the following command:
sh linux_x86_platformservices.bin -extract
This resulting extraction would produce the following temporary directory structure:
linux_86 linux_86/setup linux_86/setup/admin.fanplat linux_86/setup/install linux_86/license-C.txt linux_86/license-zh_cn.txt linux_86/license-de.txt linux_86/license-cs.txt linux_86/package linux_86/package/novell-DXMLfanplat-3.6.rpm linux_86/license-es.txt linux_86/license-fr.txt linux_86/license-it.txt linux_86/license.txt linux_86/license-jp.txt linux_86/license-zh_tw.txt linux_86/license-nl.txt linux_86/license-pl.txt linux_86/license-pt.txt linux_86/license-ru.txt linux_86/license-sv.txt
The installation script is located under the setup directory. The native package file, which is located inside the package directory, will vary in name depending on the operating system used by your target platform. To determine the name of your native package file, see Table 11-2.
Table 11-2 Native Package Names by Platform.
Platform |
Native Package Name |
---|---|
Linux |
novell-DXMLfanplat-3.6.rpm |
Solaris |
DXMLfanplat-3.6.pkg |
AIX |
novell-DXMLfanplat-3.6.rpm |
HP-UX |
novell-DXMLfanplat-3.6.depot |
FreeBSD |
novell-DXMLfanplat-3.6.tgz |
Debian |
novell-DXMLfanplat-3.6.deb |
Tru64 |
DXMLFANPLAT-6.6.tar.gz |
Once you have extracted the contents from the .bin archive, you may choose to modify the configuration script, <os>/setup/install, and wish to rebundle the contents into a new .bin installer. To do so, first extract the header file:
head -n 76 <os>_platformservices.bin > header
Then, edit the files as necessary inside the <os> directory. Finally, recreate the .bin:
tar cf <os>_platformservices.tar <os> cat header <os>_platformservices.tar > <os>_platformservices.bin
After the initial installation or upgrade of Platform Services, other tasks that you may need to perform from time to time include the following:
If you have chosen to configure for authentication redirection on a platform that is running Linux or UNIX, you will need to manually configure PAM on that system. For technical instructions on how to configure PAM for authentication, see Section B.1, PAM Configuration Notes.
The Platform Services installer automatically copies sample configurations you can use as templates to the following location:
If you are running Linux: /usr/local/ASAM/PlatformServices/pam.d/
If you are running UNIX: /usr/local/ASAM/PlatformServices/pam.conf.sample/
If you have chosen to configure for authentication redirection on a platform that is running AIX, and you want to use IBM’s proprietary Loadable Authentication Module (LAM), you will need to manually configure the Fan-Out Driver’s LAM module on that AIX system. For technical instructions on how to configure LAM for authentication, see Section B.3, LAM Configuration Notes.
The Platform Services installer automatically copies sample LAM-related configuration files you can use as templates to the following location:
/usr/local/ASAM/bin/PlatformServices/methods.cfg.sample /usr/local/ASAM/bin/PlatformServices/user.sample /usr/local/ASAM/bin/PlatformServices/user.sample2
Upon initial deployment of the Fan-Out Driver Platform Services, you may find it useful and necessary to perform an initial migration or synchronization of users and groups within the Identity Vault. You can perform a full synchronization by executing asamrcvrd fullsync. Location of this executable will vary depending on your target platform. See Table 11-3 for the appropriate full command line that includes your directory location.
Table 11-3 Command for Full Synchronization by Platform
Platform |
Synchronization Command |
---|---|
Linux |
/etc/init.d/asamrcvrd fullsync |
Solaris |
/etc/init.d/asamrcvrd fullsync |
AIX |
/etc/rc.d/init.d/asamrcvrd fullsync |
HP-UX |
/sbin/init.d/asamrcvrd fullsync |
FreeBSD |
/usr/local/rc.d/init.d/asamrcvrd fullsync |
Tru64 |
/sbin/init.d/asamrcvrd fullsync |
Starting Platform Services requires you to start one or more of the following components, depending on your configuration:
Platform Receiver
Platform Services Process
Platform Services Cache Daemon
For more information about these components, see Section 11.1, About Platform Services for Linux and UNIX and Section 12.0, Configuring and Administering Platform Services.
You can start the Platform Receiver by executing asamrcvrd start. Location of this executable will vary depending on your target platform. See Table 11-4 for the appropriate full command line that includes your directory location.
Table 11-4 Command for Starting the Platform Receiver
Platform |
Platform Receiver Start Command |
---|---|
Linux |
/etc/init.d/asamrcvrd start |
Solaris |
/etc/init.d/asamrcvrd start |
AIX |
/etc/rc.d/init.d/asamrcvrd start |
HP-UX |
/sbin/init.d/asamrcvrd start |
FreeBSD |
/usr/local/rc.d/init.d/asamrcvrd start |
Tru64 |
/sbin/init.d/asamrcvrd start |
You can start the Platform Services Process by executing asampspd start. Location of this executable will vary depending on your target platform. See Table 11-5 for the appropriate full command line that includes your directory location.
Table 11-5 Command for Starting the Platform Services Process
Platform |
Platform Services Process Start Command |
---|---|
Linux |
/etc/init.d/asampspd start |
Solaris |
/etc/init.d/asampspd start |
AIX |
/etc/rc.d/init.d/asampspd start |
HP-UX |
/sbin/init.d/asampspd start |
FreeBSD |
/usr/local/rc.d/init.d/asampspd start |
Tru64 |
/sbin/init.d/asampspd start |
You can start the Platform Services Cache Daemon by executing asampsd start. Location of this executable will vary depending on your target platform. See Table 11-6 for the appropriate full command line that includes your directory location.
Table 11-6 Command for Starting the Platform Services Cache Daemon
Platform |
Platform Services Cache Daemon Start Command |
---|---|
Linux |
/etc/init.d/asampsd start |
Solaris |
/etc/init.d/asampsd start |
AIX |
/etc/rc.d/init.d/asampsd start |
HP-UX |
/sbin/init.d/asampsd start |
Stopping Platform Services requires you to stop one or more of the following components, depending on your configuration:
Platform Receiver
Platform Services Process
Platform Services Cache Daemon
For more information about these components, see Section 11.1, About Platform Services for Linux and UNIX and Section 12.0, Configuring and Administering Platform Services.
You can stop the Platform Receiver by executing asamrcvrd stop. Location of this executable will vary depending on your target platform. See Table 11-7 for the appropriate full command line that includes your directory location.
Table 11-7 Command for Stopping the Platform Receiver
Platform |
Platform Receiver Stop Command |
---|---|
Linux |
/etc/init.d/asamrcvrd stop |
Solaris |
/etc/init.d/asamrcvrd stop |
AIX |
/etc/rc.d/init.d/asamrcvrd stop |
HP-UX |
/sbin/init.d/asamrcvrd stop |
FreeBSD |
/usr/local/rc.d/init.d/asamrcvrd stop |
Tru64 |
/sbin/init.d/asamrcvrd stop |
You can stop the Platform Services Process by executing asampspd stop. Location of this executable will vary depending on your target platform. See Table 11-8 for the appropriate full command line that includes your directory location.
Table 11-8 Command for Stopping the Platform Services Process
Platform |
Platform Services Process Stop Command |
---|---|
Linux |
/etc/init.d/asampspd stop |
Solaris |
/etc/init.d/asampspd stop |
AIX |
/etc/rc.d/init.d/asampspd stop |
HP-UX |
/sbin/init.d/asampspd stop |
FreeBSD |
/usr/local/rc.d/init.d/asampspd stop |
Tru64 |
/sbin/init.d/asampspd start |
You can stop the Platform Services Cache Daemon by executing asampsd stop. Location of this executable will vary depending on your target platform. See Table 11-9 for the appropriate full command line that includes your directory location.
Table 11-9 Command for Stopping the Platform Services Cache Daemon
Platform |
Platform Services Cache Daemon Stop Command |
---|---|
Linux |
/etc/init.d/asampsd stop |
Solaris |
/etc/init.d/asampsd stop |
AIX |
/etc/rc.d/init.d/asampsd stop |
HP-UX |
/sbin/init.d/asampsd stop |
If you are using PAM (or LAM on AIX) for password authentication, it may be helpful to verify that the Platform Services Process (asampsp) and the API Library (libascauth) are functioning properly, before you finalize PAM configuration. You can do this with a program called asctest, which is included with your Platform Services installation. Here’s where to find it:
/usr/local/ASAM/bin/PlatformServices/PlatformClient/asctest
This program allows you to test the various calls (listed in Table 11-10) that can be made to the API library in support of PAM. To use asctest, simply enter it from a command line with no parameters. When prompted select the desired method by entering its corresponding letter ( ) and respond to any further prompts. The following table provides descriptions of the API methods.
Table 11-10 API methods used for PAM.
API Method |
Description |
---|---|
ASC_ADMINRSTPASSWD |
Reset a user password using an administrative reset. |
ASC_CHGPASSWD |
Change a user’s password. |
ASC_CHKPASSWD |
Check a user’s password. |
ASC_DAYS |
Convert seconds to days. |
ASC_GETCONTEXT |
Look up a user’s context from a contextless name. |
ASC_GETGROUPBYGID |
Look up a group by its gidNumber. |
ASC_GETUSERBYUID |
Look up a user by its uidNumber. |
ASC_GRPMEM |
List a group’s members. |
ASC_LISTSEQV |
List a user’s security equivalences. |
ASC_READATTR |
Read a single-valued attribute on a user. |
ASC_READGROUPATTR |
Read an attribute on a group. |
ASC_RIGHTS |
Test attribute rights for one object over another. |
ASC_SECEQUAL |
Check user security equivalence to another object. |
ASC_STRERROR |
Convert ASCLIENT error code into a human-readable text string. |
ASC_USER_INCLUDE_EXCLUDE |
Check whether a user matches the include/exclude list. |
Your installation of Platform Services includes an uninstall script for easy removal of the product from a target platform. If your intallation included the use of PAM (or LAM for AIX), you must manually remove those components before before running the uninstall script.
If you have configured your system to use the Fan-Out Driver PAM module for authentication, make sure you first remove the Fan-Out Driver Platform Services module, ascauth, from your PAM configuration before uninstalling the product. Leaving PAM with invalid library references can leave your system in an unpredictable state for new logon requests.
If you have configured your system to use the Fan-Out Driver LAM module (/usr/lib/security/DCE) for authentication, make sure you first remove any LAM-related modifications you made to the following files:
/etc/security/user usr/lib/security/methods.cfg
To uninstall Platform Services, run the following script:
/usr/local/ASAM/bin/PlatformServices/plat-uninstall
After you have installed and configured Platform Services for the NetIQ® Identity Manager Fan-Out Driver, you can run the configuration script at any time to change any aspect of your initial configuration by entering the following command:
/usr/local/ASAM/bin/PlatformServices/plat-config
The options for configuration will depend on your situation, as discussed in the following topics for this section:
NOTE:For additional details about the topics in this section, see Section B.0, Platform Services Technical Notes.
Connections between Platform Services and Core Drivers use Secure Sockets Layer (SSL). SSL connections are authenticated through the use of certificates.
The certificates used by the Identity Manager Fan-Out Driver are minted by the Certificate Services component of the Core Driver. When you install and configure Platform Services, you obtain a certificate.
To obtain a new certificate for your platform, run the plat-config script and select option 1.
Platform certificates are stored in the ASAM/data/platformservices/certs directory. Ensure that access to the certs directory is limited to the appropriate users.
There are two primary methods for provisioning: local and virtual.
Local provisioning uses the Platform Receiver (asamrcvr file) and supplied scripts to locally create or modify user and group account information using native commands, such as useradd and user mod. Attributes such as uid, home directory, and login shell can be populated from the Identity Vault or managed by the local Linux or UNIX system.
After installation, the connected Linux or UNIX system can be fully synchronized with the Identity Vault to make associations and synchronize data fields. For more information on this task, see Section 11.3.3, Running a Full Synchronization.
The Platform Receiver needs to be running to keep the system synchronized with the Identity Vault. For more information, see Starting the Platform Receiver.
Users associated with a connected Linux or UNIX platform managed by the Fan-Out Driver can authenticate in any of the following ways, depending on how you have installed Platform Services.
With local authentication, passwords are stored locally (in /etc/shadow for example) and users that log onto the Linux or UNIX system will authenticate with this password. To synchronize passwords with the Identity Vault, ensure the following keyword statement is located inside your asamplat.conf file:
UPDATEPASSWORD
NOTE:If you use the UPDATEPASSWORD statement, you also may include a CRYPTTYPE statement in the asamplat.conf file.
The CRYPTTYPE statement allows you to override the password storage format (DES, MD5, BLOWFISH, SHA256, SHA512 or SUN_MD5) that is automatically configured by the driver. For more information, see Section 10.3.29, CRYPTTYPE Statement.
The Platform Receiver (asamrcvr file) needs to be running to keep passwords synchronized with the Identity Vault. For more information, see Starting the Platform Receiver.
With redirected authentication, passwords are not stored locally. Instead, when a user logs on to the Linux or UNIX system, the Fan-Out Driver’s PAM (or LAM) module will redirect the request to the Identity Vault, where the password is checked along with eDirectory Password and Login rules. Optionally, password policies can be enforced.
To configure your system to use the PAM module for authentication redirection, you will need to manually configure PAM for each application that is to be PAM-enabled. For details on manually configuring PAM, see Section B.1, PAM Configuration Notes.
If you are running AIX and chose to use LAM for authentication redirection, you will need to manually configure LAM as detailed in Section B.3, LAM Configuration Notes.
The Platform Services Process (asampsp file) also needs to be running to provide a connection pool and driver load balancing. For more information, see Starting the Platform Services Process.
Authentication redirection with local failover is a hybrid of local authentication and authentication redirection. In such a scenario, authentication is redirected unless the connection between Platform Services and the Identity Vault is unavailable, in which case local authentication takes place. In this configuration, you will need the Platform Receiver running to synchronize passwords and the Platform Services Process running to provide authentication. For information about starting these two services, see Section 11.3.4, Starting Platform Services.
If you have chosen the virtual provisioning option (see Section 12.2, Provisioning), users will authenticate to the Linux or UNIX system using the Name Service Switch, which is supplied by Platform Services. Virtual users and their password information are kept in a local protected cache on the connected system. This provides the system with a local copy and therefore all the advantages of using local provisioning. If you wish to enforce eDirectory password and login rules, you will also need to manually configure PAM for authentication redirection.
You will need to decide whether users should be allowed to change their passwords from the Linux or UNIX system, using PAM-enabled tools such as passwd, or require users to change their passwords from another system, such as a Web portal or eDirectory client.
When you allow password changes from the Linux or UNIX system, configured with Platform Services, the PAM passwd module is automatically configured to redirect password changes back to the Identity Vault. No manual configuration is required.
NetIQ® Identity Manager Fan-Out Driver components record messages to their Audit Log, Operational Log, and their host system log. Examining these should be foremost in your troubleshooting efforts.
The Audit and Operational logs of Core Driver components are maintained in their logs directory.
The Linux/UNIX Platform Services Process and Platform Receiver write log messages to the Linux/UNIX SYSLOG facility.
By its very nature, the Identity Manager Fan-Out Driver is highly dependent upon the proper operation of your network and eDirectory™. If you are having problems with the driver, ensure that the various driver components are able to communicate with one another and that eDirectory is functioning properly.
For information pertaining to Identity Manager Fan-Out Driver performance issues, see Section 4.0, Core Driver Planning.
IMPORTANT:Make sure you upgrade the driver, including all of your platforms, when new versions or support packs become available.
Identity Manager Fan-Out Driver components support the option to produce extensive debugging output. Although this output is intended primarily for use by NetIQ Technical Support, you might find it useful for your own troubleshooting efforts.
Because debugging mode adversely affects performance, it should not be used for routine operations.
To obtain debugging output for the Platform Services Process or Platform Receiver on Linux/UNIX:
Add a DEBUGLOGFILE statement or DEBUGTOSTDOUT statement to the platform configuration file.
For details about the platform configuration file, see Section 10.0, The Platform Configuration File.
Specify the debugging command line parameter when you start the Platform Services Process or Platform Receiver.
To obtain full debugging output, specify -d \* on the command line.
To obtain debugging output limited to messages exchanged with Core Drivers, specify the -d dom parameter.
If a user cannot authenticate through the driver but can log in through eDirectory, ensure that the user is present in the Census and is not marked as being inactive. If the user is not present and active in the Census, review your Census Search object specifications.
Ensure that the user name and password conform to the character set and length restrictions imposed by the platform operating system.
Ensure that user and group names conform to the character set and length restrictions imposed by the platform operating system.
Identity Provisioning information for platforms that use password replication is not normally available unless password information is available. For example, if you have just installed and configured the Fan-Out Driver for the first time, and you run the Platform Receiver in Full Sync Mode on a system whose Platform object specifies Permit Password Replication, no accounts are created there. You must install the password intercepts, and users must authenticate through the driver or change their passwords so that password replication information is available. Then that account information becomes available to the platform.
Detailed network troubleshooting, which can depend on a number of factors particular to your environment, are beyond the scope of this document. However, communication problems among the various Identity Manager Fan-Out components are often caused by basic issues.
To verify IP Connections between platforms and the Core Driver, use the ping command. From a command prompt on the Linux, UNIX or Windows system, use a command prompt to enter ping ipaddr, where ipaddr is the IP address of the remote computer.
Firewalls can disrupt connectivity between the Core Driver and its connected systems. To verify that the TCP port is reachable, use a command prompt to enter telnet ipaddr 3451, where ipaddr is the IP address of the remote computer. The TCP port 3451 is used by the Core Driver for communication with the connected platforms.
Check DNS if you are using named hosts in your platform or Core Driver address configurations. DNS resolution is necessary to verify certificates for SSL communication.
If you receive the message, OAP001E Error in SSL configuration. Check system for entropy, your SSL entropy configuration might be in error, or your entropy daemon might not be properly installed. For additional information about entropy, see Section 11.1.1, Secure Sockets Layer Entropy Requirements.
If a user cannot access the local Linux or UNIX system through the Name Service Switch and Platform Services Cache Daemon, but can log in through eDirectory, check the following:
The user is present in the Census and platform search object.
The user has been extended with the posixAccount auxiliary class.
A Universal Password policy exists and is configured to allow agents to retrieve the Universal Password.
The driver filter is configured with the posixAccount class and attributes.
Part V describes the Authentication Services (AS) Client application programming interface (API) of the NetIQ® Identity Manager Fan-Out Driver. It includes the following chapters:
NetIQ® Identity Manager Fan-Out Driver platforms provide an Authentication Services (AS) application programming interface (API) that can be used by applications to access eDirectory™. This API is compatible with the AS Client API that was provided in the NDS® Authentication Services and the Account Management 3.0 products. To use this API, you must obtain and install the Identity Manager Fan-Out Driver.
The platform configuration file provides the information necessary for establishing communications with a Core Driver. For details about the platform configuration file, see Section 10.0, The Platform Configuration File.
In the C language environment, a call must be made to ASC_INIT() or ASC_INIT_EXT() to process the platform configuration file and initialize the environment before API calls can be made to the Core Driver. The header file ascauth.h provides the function prototypes for the API calls and their return value definitions.
In the Java environment, a call must be made to the INIT() method to process the platform configuration file and initialize the environment before API calls can be made to the Core Driver. Class com.novell.asam.JAscAuth.JAscAuth provides the methods used to call the API.
Details about platforms/environments with which you use the API are provided in earlier sections of this guide. Also be aware that this guide is one of three available administration guides for the Fan-Out Driver, each tailored to the range of platforms with which it can work:
Identity Manager Fan-Out Driver for Linux and UNIX Administration Guide
Identity Manager Fan-Out Driver for Mainframes Administration Guide (z/OS)
Identity Manager Fan-Out Driver for Midrange Administration Guide (IBM i, OS/400, i5/OS)
Topics in this section are
Access to the API using C in the Linux/UNIX environment is through calls to the shared library. The shared library and the C header file ascauth.h are copied to system-specific directories during the Linux/UNIX Platform Services installation process.
Access to the API using Java is through calls to the methods of class com.novell.asam.JAscAuth.JAscAuth. The jascauth.jar file is copied to the ASAM/bin/PlatformServices/PlatformClient/Java directory during Platform Services installation.
The caller must have read access to the /usr/local/ASAM/data/PlatformServices/certs directory.
For additional information about the Linux/UNIX platform, see the Identity Manager Fan-Out Driver for Linux and UNIX Administration Guide.
API routines are provided to perform the following functions:
Initialize the environment.
C: ASC_INIT, ASC_INIT_EXT
Java: init
Terminate the environment.
Validate a user ID and password combination.
Java: checkPassword
Change a user's password, given the current password.
Java: changePassword
Reset a user's password as an administrative user.
Java: adminResetPassword
Obtain the fully distinguished name for a user ID.
Java: getContext
Determine if a user has security equal to a given object.
C: ASC_SECEQUAL
Java: securityEquals
Determine if an object has the specified effective rights to the specified attribute of another object.
C: ASC_RIGHTS
Java: effectiveRights
Obtain a list of members of a group.
C: ASC_GRPMEM
Java: groupMembers
Obtain a list of security equivalences for a user.
C: ASC_LISTSEQV
Java: listSecurityEquivalences
Obtain attribute values for an object.
C: ASC_READATTR
Java: readAttribute
Determine if a given user is in the Include/Exclude list.
Decode API return values.
C: ASC_STRERROR
Java: strError
Convert number of seconds to number of days.
C: ASC_DAYS
Java: secondsToDays
This section presents all AS Client API functions available in the C programming language for the NetIQ® Identity Manager Fan-Out Driver. Information for each function includes syntax, parameters, return values and an example of the function as applied in code.
The C functions for the Fan-Out Driver API include the following:
Performs an administrative reset of a user's password. The new password is marked as being expired unless it is non-expiring.
#include <ascauth.h>
int ASC_ADMINRSTPASSWD(ASCENV *asce, char *adminUser, char *adminPassword, char *user, char *newpass);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
adminUser |
The Enterprise User ID of an administrative user with rights to change the target user's password. |
adminPassword |
The password of the administrative user ID. |
user |
The Enterprise User ID whose password is to be changed. |
newpass |
The new password for the user. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Password changed |
AS_NOUSER |
User inactive or not found in the Census |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
AS_INSUFFICIENTRIGHTS |
Administrative user does not exist, administrative user does not have rights to change the password, or administrative user password not valid |
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; ASCUSER ascu; char *adminUser, *adminPass, *user, *newpass; int rc; if (argc != 5) { fprintf(stderr, "usage: %s <adminUser> <adminPass> <user> <newpass>\n", argv[0]); exit(EXIT_FAILURE); } adminUser = argv[1]; adminPass = argv[2]; user = argv[3]; newpass = argv[4]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* change the user's password */ rc = ASC_ADMINRSTPASSWD(asce, adminUser, adminPass, user, newpass); if (rc == AS_OK) printf("password has been changed\n"); else if (rc == AS_NO) printf("password has not been changed\n"); else printf("RC=%d, %s", rc, ASC_STRERROR(rc));
/* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Changes the password of a user.
#include <ascauth.h>
int ASC_CHGPASSWD(ASCENV *asce, char *user, char *oldpass, char *newpass);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
user |
The Enterprise User ID whose password is to be changed. |
oldpass |
The old password for the user. |
newpass |
The new password for the user. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Password changed |
AS_NO |
Old password is invalid |
AS_NOUSER |
User inactive or not found in the Census |
AS_REVOKED |
User's password is okay, but the user is disabled |
AS_INTRUDER |
Intruder lockout is enabled for this user |
AS_PASSDUPLICATE |
New password has been used previously |
AS_PASSTOOSHORT |
New password is too short |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; ASCUSER ascu; char *user, *oldpass, *newpass; int rc; if (argc != 4) { fprintf(stderr, "usage: %s <user> <oldpass> <newpass>\n", argv[0]); exit(EXIT_FAILURE); } user = argv[1]; oldpass = argv[2]; newpass = argv[3]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* change the user's password */ rc = ASC_CHGPASSWD(asce, user, oldpass, newpass); if (rc == AS_OK) printf("password has been changed\n"); else if (rc == AS_NO) printf("password has not been changed\n"); else printf("RC=%d, %s", rc, ASC_STRERROR(rc));
/* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Verifies the password of a user.
#include <ascauth.h>
int ASC_CHKPASSWD(ASCENV *asce, char *user, char *pass, ASCUSER *ascu);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
user |
The Enterprise User ID to be checked. |
pass |
The password to be checked for the user. |
ascu |
The ASCUSER structure (defined in ascauth.h) to be filled in by ASC_CHKPASSWD() if the password is valid. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Password is okay |
AS_NO |
User ID/Password combination is invalid |
AS_NOUSER |
User inactive or not found in the Census |
AS_REVOKED |
User's password is okay, but the user is disabled |
AS_INTRUDER |
Intruder lockout enabled for this user |
AS_BADCLIENT |
Local host is not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
If an AS_OK return code is returned, the following fields in the ASCUSER structure contain additional information about the authenticated user:
<ascu>.pass.expire |
Number of seconds until the password expires (or -1 if the password does not expire) |
<ascu>.pass.interval |
Password change interval in seconds (or -1 if the password does not expire) |
If an AS_REVOKED code is returned, the following field in the ASCUSER structure contains additional information about the user:
<ascu>.login.disabled |
User disabled flag |
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; ASCUSER ascu; char *user, *pass; int rc; if (argc != 3) { fprintf(stderr, "usage: %s <user> <password>\n", argv[0]); exit(EXIT_FAILURE); } user = argv[1]; pass = argv[2]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* check the user's password */ rc = ASC_CHKPASSWD(asce, user, pass, &ascu); if (rc == AS_OK) printf("password ok\n"); else if (rc == AS_NO) printf("password invalid\n"); else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Converts an integer number of seconds into an integer number of days.
#include <ascauth.h>
long ASC_DAYS(long secs);
secs |
A number of seconds. |
Returns the integer number of days corresponding to the given number of seconds.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> printf("*** CHKPASWD expire days=%ld, expire interval days=%ld\n", ASC_DAYS(ascu.pass.expire), ASC_DAYS(ascu.pass.interval));
Obtains a user's fully distinguished object name from the Census and copies it into the buffer supplied by the caller.
#include <ascauth.h>
int ASC_GETCONTEXT(ASCENV *asce, char *user, char *buffer, u_int size);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
user |
The Enterprise User ID. |
buffer |
The buffer that is to receive the context. The result is truncated and the call returns AS_TOOSMALL if the buffer size cannot hold the entire result. |
size |
The length in bytes of the buffer. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Context was found |
AS_NOUSER |
User inactive or not found in the Census |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_TOOSMALL |
Size of the pre-allocated buffer is too small-result truncated |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
The buffer is padded with nulls if needed.
The format of the returned login context is the simple dot form. For example: .jondoe.j.myorg
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> #define MAX_CONTEXT 512 main(int argc, char *argv[]) { ASCENV *asce; char *user, *context; int rc; if (argc != 2) { fprintf(stderr, "usage: %s <user>\n", argv[0]); exit(EXIT_FAILURE); } user = argv[1]; /* allocate buffer */ context = (char *) malloc(MAX_CONTEXT); /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* get the user's context */ rc = ASC_GETCONTEXT(asce, user, context, MAX_CONTEXT); if (rc == AS_OK) printf("context is %s\n", context); else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); free(context); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Obtains a list of all members of the given group and places it in the buffer supplied by the caller.
#include <ascauth.h>
int ASC_GRPMEM(ASCENV *asce, char *object, char *buf, u_int size);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
object |
The fully distinguished group name whose membership list is to be returned. |
buf |
The buffer in which the membership list is to be returned. Member names are separated by a new line ‘\n' character. The list is truncated and the call returns AS_TOOSMALL if the buffer size cannot hold the entire list. |
size |
The size of the buffer you provided. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Member list successfully returned |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_TOOSMALL |
Size of the pre-allocated buffer is too small-list truncated |
AS_INVALIDOBJ |
Specified object does not exist |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
The list is truncated, and the call returns AS_TOOSMALL if the buffer size cannot hold the entire list. You can retry with a larger buffer.
You can use ASC_SECEQUAL to see if an individual user is a member of a given group.
The groups a given user is a member of are included in the list returned by ASC_LISTSEQV.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; char *group, buffer[2000]; int rc; if (argc != 2) { fprintf(stderr, "usage: %s <group>\n", argv[0]); exit(EXIT_FAILURE); } group = argv[1]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* Get group membership info */ rc = ASC_GRPMEM(asce, group, buffer, sizeof(buffer)); if (rc == AS_OK) printf("Members of group %s:\n%s\n", group, buffer); else if (rc == AS_TOOSMALL) { printf("Members of group %s:\n%s\n", group, buffer); printf("** list was truncated because of lack of buffer space **\n"); } else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Reads the platform configuration file and initializes the environment so that calls can be made to a Core Driver. This function or ASC_INIT_EXT() must be called before any other API function.
#include <ascauth.h>
ASCENV *ASC_INIT(char *filename);
filename |
The name of the platform configuration file. If you call ASC_INIT() with a NULL in place of the filename parameter as in ASC_INIT(NULL), the default is as follows: z/OS: Always uses the ASCLIENT started task active configuration. IBM i: /usr/local/ASAM/data/asamplat.conf Linux/UNIX: /usr/local/ASAM/data/asamplat.conf |
Returns a pointer to the API environment item created upon success. If an error has occurred, NULL is returned.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main() { ASCENV *asce; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* now you can make additional authentication calls here */ /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Reads the platform configuration file and initializes the environment so that calls can be made to a Core Driver. This function or ASC_INIT() must be called before any other API function. ASC_INIT_EXT() differs from ASC_INIT() in that you can provide a buffer into which the API places error messages if the API environment cannot be initialized.
#include <ascauth.h>
ASCENV *ASC_INIT_EXT(char *filename, char *error_msg, size_t size);
filename |
The name of the platform configuration file. If you call ASC_INIT_EXT() with a NULL in place of the filename parameter as in ASC_INIT_EXT(NULL, buffer, BUFSIZE), the default is as follows: z/OS: Always uses the ASCLIENT started task active configuration. IBM i: /usr/local/ASAM/data/asamplat.conf Linux/UNIX: /usr/local/ASAM/data/asamplat.conf |
error_msg |
A buffer you provide into which an error message can be placed if the environment cannot be initialized. |
size |
The size of the error_msg buffer you have provided. |
Returns a pointer to the environment item created upon success. If an error has occurred, NULL is returned, and a descriptive error message is placed into the error_msg buffer.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> #define BUFSIZE 256 main() { ASCENV *asce; /* initialize the authentication environment */ /* allocate buffer */ buffer = (char *) malloc(BUFSIZE); asce = ASC_INIT_EXT(NULL, buffer, BUFSIZE); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); fprintf(stderr, " %s \n", buffer); exit(EXIT_FAILURE); } /* now you can make additional authentication calls here */ /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Obtains a user's Security Equals attribute list and places it in the buffer supplied by the caller.
#include <ascauth.h>
int ASC_LISTSEQV(ASCENV *asce, char *user, char *buf, u_int size);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
user |
The Enterprise User ID whose Security Equals list is to be returned. |
buf |
The buffer in which the security equivalence list is to be returned. Object names are separated by a new line ‘\n' character. The list is truncated and the call returns AS_TOOSMALL if the buffer size cannot hold the entire list. |
size |
The size of the buffer you provided. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Security equivalence list successfully returned |
AS_NOUSER |
User inactive or not found in the Census |
AS_BADCLIENT |
Local host is not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_TOOSMALL |
Size of pre-allocated buffer is too small-the list is truncated |
AS_INVALIDOBJ |
Specified object does not exist |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
The list is truncated, and the call returns AS_TOOSMALL if the buffer size cannot hold the entire list. You can retry with a larger buffer.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; char *object, buffer[2000]; int rc; if (argc != 2) { fprintf(stderr, "usage: %s <object>\n", argv[0]); exit(EXIT_FAILURE); } object = argv[1]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* Get security equivalence info */ rc = ASC_LISTSEQV(asce, object, buffer, sizeof(buffer)); if (rc == AS_OK) printf("Security equivalences of object %s:\n%s\n", object, buffer); else if (rc == AS_TOOSMALL) { printf("Security equivalences of object %s:\n%s\n", object, buffer); printf("** list was truncated because of lack of buffer space **\n"); } else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Returns the value of the specified single-valued attribute for the specified object.
#include <ascauth.h>
int ASC_READATTR(ASCENV *asce, char *object, char *attribute, char *buffer, u_int bufsize);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
object |
The Enterprise User ID or fully distinguished object name of the object whose attribute value is to be returned. |
attribute |
The single-valued attribute whose value is to be returned for the object. Only the Home Directory attribute of a User object is supported at this time. |
buffer |
The buffer in which the object's attribute value is to be returned. The results are truncated and the call returns AS_TOOSMALL if the buffer size cannot hold the entire attribute value. |
bufsize |
The size of the buffer you provided. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
Attribute value has been placed in the buffer successfully |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_ATTRNOTFOUND |
Attribute does not exist for the specified object |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_TOOSMALL |
Size of the pre-allocated buffer is too small-results are truncated |
AS_INVALIDOBJ |
Specified object does not exist |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
The results are truncated, and the call returns AS_TOOSMALL if the buffer size cannot hold the entire attribute value. You can retry with a larger buffer.
Only the Home Directory attribute of a User object is supported at this time.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; char *user, buffer[2000]; int rc; if (argc != 2) { fprintf(stderr, "usage: %s <UserObjectFDN>\n", argv[0]); exit(EXIT_FAILURE); } user = argv[1]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* Get User object's home directory info */ rc = ASC_READATTR(asce, user, "HOME DIRECTORY", buffer, sizeof(buffer)); if (rc == AS_OK) printf("Home Directory for User object %s:\n%s\n", user, buffer); else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Checks the specified effective rights of one object over another for a specific attribute.
#include <ascauth.h>
int ASC_RIGHTS(ASCENV *asce, char *obj1, char *obj2, char *attribute, char *rights);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
obj1 |
The Enterprise User ID or fully distinguished object name whose effective rights are to be tested. |
obj2 |
The Enterprise User ID or fully distinguished object name for which access by obj1 is to be tested. |
attribute |
The name of an attribute of obj2 for which the effective rights of obj1 are requested. The special attribute names All Attributes Rights, Entry Rights, and SMS Rights can also be specified. |
rights |
The rights to test. The characters specified must be in the following set: [S,C,R,W,A]. These correspond to Supervisor, Compare, Read, Write, and Add Self. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
User or object has the specified rights to the specified object attribute |
AS_NO |
User or object does not have the specified rights to the specified object attribute |
AS_ATTRNOTFOUND |
Specified attribute could not be found |
AS_INVALIDOBJ |
Specified user not found in the Census or the specified object does not exist |
AS_INVALIDOBJLEN |
Specified object exceeds maximum length |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; char *obj1, *obj2, *attr, *rights; int rc; if (argc != 5) { fprintf(stderr, "usage: %s <obj1> <obj2> \ <attribute> <rights>\n", argv[0]); exit(EXIT_FAILURE); } obj1 = argv[1]; obj2 = argv[2]; attr = argv[3]; rights = argv[4]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* check for rights */ rc = ASC_RIGHTS(asce, obj1, obj2, attr, rights); if (rc == AS_OK) printf("User has rights\n"); else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Checks to see if a user has security equivalence to the specified object.
#include <ascauth.h>
int ASC_SECEQUAL(ASCENV *asce, char *user, char *object);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
user |
The Enterprise User ID to be tested. |
Object |
The fully distinguished object name to test the user for security equivalence. |
Returns one of the following integer values defined in ascauth.h:
AS_OK |
User has security equivalence to the specified object |
AS_NO |
User does not have security equivalence to the object |
AS_NOUSER |
User inactive or not found in the Census |
AS_BADCLIENT |
Local host not authorized to query the Core Driver |
AS_NOAGENT |
No Core Driver could be contacted |
AS_NOAUTHENV |
No environment has been established |
AS_INVALIDREQ |
Call rejected by the Core Driver as not valid or not supported |
AS_INVALIDARGS |
Invalid arguments supplied to the function |
AS_INVALIDOBJ |
Specified object does not exist |
AS_KEYEXPIRED |
Old key rejected by the Core Driver because the expiration date has passed |
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main(int argc, char *argv[]) { ASCENV *asce; char *user, *object; int rc; if (argc != 3) { fprintf(stderr, "usage: %s <user> <object>\n", argv[0]); exit(EXIT_FAILURE); } user = argv[1]; object = argv[2]; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* check for security equivalence */ rc = ASC_SECEQUAL(asce, user, object); if (rc == AS_OK) printf("User has security equivalence\n"); else printf("RC=%d, %s", rc, ASC_STRERROR(rc)); /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Returns the error string for the specified ASC function error code.
#include <ascauth.h>
const char *ASC_STRERROR(int errnum);
errnum |
The error return value from a call to an ASC_ function. |
Returns a static character string corresponding to the integer errnum value as defined in ascauth.h for ASC function error codes.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> rc = ASC_CHKPASSWD(asce, userid, password, &ascu); strcpy(status, ASC_STRERROR(rc)); printf("\n*** CHKPASSWD return code = %d (%s)\n", rc,status);
Terminates and frees the environment that was created by a call to ASC_INIT() or ASC_INIT_EXT(). After the environment is terminated, no more calls to the Core Driver can be made without first issuing another ASC_INIT() or ASC_INIT_EXT() call.
#include <ascauth.h>
void ASC_TERM(ASCENV *asce);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
No value is returned from this function.
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> main() { ASCENV *asce; /* initialize the authentication environment */ asce = ASC_INIT(NULL); if (asce == NULL) { fprintf(stderr, "Error: cannot initialize authentication environment\n"); exit(EXIT_FAILURE); } /* now you can make additional authentication calls here */ /* now terminate the authentication environment */ ASC_TERM(asce); return 0; }
Determines if a given user matches an AS.USER.INCLUDE or AS.USER.EXCLUDE statement in the platform configuration file.
#include <ascauth.h>
int ASC_USER_INCLUDE_EXCLUDE(ASCENV *asce, char *user);
asce |
The environment item returned from the call to ASC_INIT() or ASC_INIT_EXT(). |
user |
The Enterprise User ID of the user to be checked. |
Returns one of the following integer values defined in ascauth.h:
AS_NOMATCH |
The user does not match any INCLUDE/EXCLUDE statement. Because“AS.USER.INCLUDE * is implicit in the absence of AS.USER.EXCLUDE *, the user is included. |
AS_INCLUDED |
User matches an AS.USER.INCLUDE statement. |
AS_EXCLUDED |
User matches an AS.USER.EXCLUDE statement or an entry in the built-in standard exclude list. |
AS_NOAUTHENV |
No environment has been established. |
#include <stdio.h> #include <stdlib.h> #include <ascauth.h> rc = ASC_USER_INCLUDE_EXCLUDE(asce, userid); if (rc == AS_NOMATCH) printf("%s does not match an Include or Exclude statement\n", userid); else if (rc == AS_INCLUDED) printf("%s matches an Include statement\n", userid); else if (rc == AS_EXCLUDED) printf("%s matches an Exclude statement\n", userid); else printf("RC=%d, %s", rc, ASC_STRERROR(rc));
This section presents the AS Client API Java implementation for the NetIQ® Identity Manager Fan-Out Driver.
Descriptions of Java classes and methods include the following:
To view the reference documentation in JavaDoc format, see the asam\bin\platformservices\platformclient\java\javadoc directory on the platform system.
For code examples, see the asam\bin\platformservices\platformclient\java directory on the platform system.
Provides the methods you use to access the AS Client API.
public JAscAuth()
The following fields map the AS Client API return codes. For more information about return codes from the AS Client API, see Section C.0, Troubleshooting the API.
public static int AS_OK = 0
public static int AS_NO = 1
public static int AS_NOUSER = 2
public static int AS_NOAGENT = 3
public static int AS_NOSERVER = 3
public static int AS_BADCLIENT = 4
public static int AS_REVOKED = 5
public static int AS_INTRUDER = 6
public static int AS_INVALIDARGS = 7
public static int AS_INVALIDOBJ = 8
public static int AS_INVALIDOBJLEN = 9
public static int AS_PASSDUPLICATE = 10
public static int AS_PASSTOOSHORT = 11
public static int AS_TOOSMALL = 12
public static int AS_ATTRNOTFOUND = 13
public static int AS_WSOCKUP = 14
public static int AS_WSOCKDOWN = 15
public static int AS_NOAUTHENV = 16
public static int AS_PRODUCTEXPIRED = 17
public static int AS_INCLUDED = 18
public static int AS_EXCLUDED = 19
public static int AS_NOMATCH = 20
public static int AS_NOLICENSE = 21
public static int AS_INVALIDREQ = 22
public static int AS_KEYEXPIRED = 23
The following methods invoke the API functions:
Performs an administrative reset of a user's password. The new password is marked as being expired unless it is non-expiring.
You must call the init method to initialize the JAscAuth environment before calling adminResetPassword. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public void adminResetPassword( java.lang.String adminUser, java.lang.String adminPass, java.lang.String user, java.lang.String pass)
adminUser |
The Enterprise User ID of an administrative user with rights to change the target user's password |
adminPass |
The password of the administrative user |
user |
The Enterprise User ID whose password is to be changed |
pass |
The new password for the user |
Changes the password of a user.
You must call the init method to initialize the JAscAuth environment before calling changePassword. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public void changePassword( String user, String oldPass, String newPass)
user |
The Enterprise User ID whose password is to be changed |
oldPass |
The old password for the user |
newPass |
The new password for the user |
Verifies the password of a user.
You must call the init method to initialize the JAscAuth environment before calling checkPassword. For more information about init, see init.
The checkPassword method can optionally return information about the user and password in a JAscUser object. For details about the contents of JAscUser, see Classes Used by checkPassword.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public void checkPassword( String user, String pass)
public void checkPassword( String user, String pass, JAscUser ascuser)
user |
The Enterprise User ID whose password is to be verified |
pass |
The password to be verified for the user |
ascuser |
A JAscUser object to be filled with information about the user and password |
Destroys the JAscAuth environment and frees its underlying resources.
public void destroy()
Checks the effective rights of one object over another for a specific attribute.
You must call the init method to initialize the JAscAuth environment before calling effectiveRights. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public void effectiveRights( String user, String object, String attribute, String rights)
user |
The Enterprise User ID or fully distinguished object name whose effective rights are to be tested |
object |
The Enterprise User ID or fully distinguished object name for which access by user is to be tested |
attribute |
The name of an attribute of object for which the effective rights of user are tested. The special attribute names All Attributes Rights, Entry Rights, and SMS Rights can also be specified. |
rights |
The rights to test. The characters specified must be in the following set: [S,C,R,W,A]. These correspond to Supervisor, Compare, Read, Write, and Add Self. |
Returns the fully distinguished object name from the Census for a given user.
You must call the init method to initialize the JAscAuth environment before calling getContext. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public String getContext(String user)
user |
The Enterprise User ID whose context is to be returned |
Returns the return code from the last call to the AS Client API.
For details about return codes from the AS Client API, see Section C.0, Troubleshooting the API.
public int getLastReturnCode()
Returns an enumeration of all members of a given Group.
You must call the init method to initialize the JAscAuth environment before calling groupMembers. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public Enumeration groupMembers(String group)
group |
The Enterprise Group or fully distinguished Group object name whose members are to be returned |
Initializes the JAscAuth environment using the platform configuration file.
You can optionally specify the location of the platform configuration file to be used. If you do not specify the location of the platform configuration file, the default platform configuration file is used.
Call the destroy method to free the JAscAuth environment and its underlying resources when you are finished. For more information about destroy, see destroy.
public void init()
public void init(java.lang.String filename)
filename |
The path name of the platform configuration file to use |
Returns an enumeration of a given user's security equivalences.
You must call the init method to initialize the JAscAuth environment before calling listSecurityEquivalences. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public Enumeration listSecurityEquivalences(String user)
user |
The Enterprise User ID whose Security Equals attribute values are to be returned |
Returns an enumeration of the values of a specified attribute for a given object.
You must call the init method to initialize the JAscAuth environment before calling readAttribute. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public Enumeration readAttribute( String object, String attribute)
object |
The Enterprise User ID or fully distinguished object name of the object whose attribute values are to be returned |
attribute |
The single-valued attribute whose value is to be returned for the object. Only the Home Directory attribute of a User object is supported at this time. |
Returns the integer number of days for the given number of seconds.
public long secondsToDays(long secs)
Checks to see if a user has security equivalence to the specified object.
You must call the init method to initialize the JAscAuth environment before calling securityEquals. For more information about init, see init.
For details about the exceptions that can be thrown, see Exception Classes in com.novell.asam.JAscAuth.
public void securityEquals( String user, String object)
user |
The Enterprise User ID to be tested |
object |
The fully distinguished object name for which the security equivalence of user is to be tested |
Returns the string representation of the given AS Client API return code.
public String strError(int rc)
rc |
The AS Client API return code value whose string representation is to be returned |
Determines if a given user matches an AS.USER.INCLUDE or AS.USER.EXCLUDE statement in the platform configuration file.
public int userIncludeExclude(String user)
user |
The Enterprise User ID of the user to be checked |
AS_NOMATCH |
The user does not match any INCLUDE/EXCLUDE statement. Because AS.USER.INCLUDE * is implicit in the absence of AS.USER.EXCLUDE *, the user is included. |
AS_INCLUDED |
User matches an AS.USER.INCLUDE statement. |
AS_EXCLUDED |
User matches an AS.USER.EXCLUDE statement or an entry in the built-in standard exclude list. |
The following topics describe classes used by the checkPassword method of JAscAuth to return information.
The checkPassword method of JAscAuth optionally returns a JAscUser object with information about the user being authenticated.
public JAscUser()
public JAscLoginRestrict login |
Contains the user's login disabled flag |
public JAscPassRestrict pass |
Contains the user's password expiration information |
The checkPassword method of JAscAuth optionally returns a JAscUser object with information about the user being authenticated. One of the fields in JAscUser is a JAscLoginRestrict object, which contains the user's login disabled flag.
public JAscLoginRestrict()
public int disabled |
The user's login disabled flag |
public int getDisabled() |
Returns the user's login disabled flag |
The checkPassword method of JAscAuth optionally returns a JAscUser object with information about the user being authenticated. One of the fields in JAscUser is a JAscPassRestrict object, which contains password expiration information.
public JAscPassRestrict()
public long interval |
The password change interval in seconds (or -1 if the password does not expire) |
public long expire |
The number of seconds until the password expires (or -1 if the password does not expire) |
public long getInterval() |
Returns the password change interval in seconds (or -1 if the password does not expire) |
public long getExpire() |
Returns the number of seconds until the password expires (or -1 if the password does not expire) |
The following exceptions, along with java/lang/NullPointerException, are the exceptions that are thrown by the methods of JAscAuth.
Thrown when a method requires an authentication environment, but a valid authentication environment does not exist.
Most methods of com.novell.asam.JAscAuth.JAscAuth require that you call the init method before you call them. InvalidJAscException is thrown if you do not do so.
Corresponds to a return code of 16, AS_NOAUTHENV, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when the attribute specified to the readAttr method was not found for the specified object.
Corresponds to a return code of 13, AS_ATTRNOTFOUND, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when the password specified to the checkPassword method is not valid.
Corresponds to a return code of 1, AS_NO, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when the network address used by the platform to contact a Core Driver for a method call does not match the network address listed in the Platform Configuration object in the ASAM System container.
Corresponds to a return code of 4, AS_BADCLIENT, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown by changePassword when the password cannot be changed.
Also thrown by changePassword if the old password given is not valid.
Corresponds to a return code of 1, AS_NO, and a return code of 4, AS_BADCLIENT, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown by most method calls when an unexpected or indeterminate error condition occurs.
Thrown by adminResetPassword if the administrative user does not exist, if the administrative user password specified is not valid, or if the administrative user does not have rights to change the password.
Also thrown by adminResetPassword if the network address used by the platform to contact a Core Driver does not match the network address listed in the Platform Configuration object in the ASAM System container.
Corresponds to a return code of 24, AS_INSUFFICIENTRIGHTS from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown by checkPassword and changePassword when the specified user is locked because of intruder detection.
Corresponds to a return code of 6, AS_INTRUDER, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when a parameter passed to a method is null or not valid.
Corresponds to a return code of 7, AS_INVALIDARGS, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when an object passed to a method is not found or is not of the correct type.
Corresponds to a return code of 8, AS_INVALIDOBJ, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when an object name passed to a method is longer than the maximum allowable name.
Corresponds to a return code of 9, AS_INVALIDOBJLEN, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when a method call is not known by the Core Driver.
Corresponds to a return code of 22, AS_INVALIDREQ, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when the DES encryption key used by a non-SSL platform has expired.
Corresponds to a return code of 23, AS_KEYEXPIRED, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when no Core Driver could be contacted to process a method call.
Corresponds to a return code of 3, AS_NOAGENT, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when the user specified to a method call is inactive or not in the Census.
Corresponds to a return code of 2, AS_NOUSER, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown by changePassword when the new password has been previously used for the user object, and the user is required to use unique passwords.
Corresponds to a return code of 10, AS_PASSDUPLICATE, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown by changePassword when the new password is shorter than the minimum password length set for the user.
Corresponds to a return code of 11, AS_PASSTOOSHORT, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown when the expiration date for the platform has passed.
Corresponds to a return code of 17, AS_PRODUCTEXPIRED, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
Thrown by checkPassword and changePassword when the specified user is disabled.
Corresponds to a return code of 5, AS_REVOKED, from the AS Client API. For more information, see Section C.0, Troubleshooting the API.
The following topics describe simple modifications to several popular products to enable them for use with the NetIQ® Identity Manager Fan-Out Driver.
The Apache* HTTP Web Server software is one of the most popular Web servers in use today. It is developed by the Apache Group and can be downloaded free from the Apache Software Foundation Web site. Apache provides the facility to configure additional modules to handle specific functions, such as user authentication and locating a user's home directory.
You can install Platform Services on your Apache server and configure Apache to authenticate users using the AS Client API. You can also configure Apache to use the AS Client API to find a user's home directory on a NetWare® file system that is mounted on a Linux Apache server. Example modules are provided in the ASAM/bin/PlatformServices/PlatformClient/Apache directory created by the Platform Services installation process.
QUALCOMM* Incorporated distributes freeware Linux/UNIX POP3 software known as Qpopper* in C source form. With no modifications, Qpopper can use Authentication Services for authentication through PAM. Qpopper can also be modified to use Authentication Services for authentication through the AS Client API.
You can obtain Qpopper from the QUALCOMM Web site.
You can install Platform Services on your POP server and use Qpopper to authenticate users using Authentication Services through PAM or through the API.
Directions for modifying Qpopper to use the AS Client API can be found in the ASAM/bin/PlatformServices/PlatformClient/POP directory created by the Platform Services installation process.
SASL, the Simple Authentication and Security Layer, is a generic authentication protocol. Many connection-based protocols, such as SMTP, LDAP, IMAP, and POP3, support SASL. New authentication mechanisms that support SASL are automatically supported by those protocols. Furthermore, protocols that use SASL for authentication support Kerberos* authentication through the Generic Security Services Application Programming Interface (GSSAPI).
A common open-source SASL library is Cyrus SASL, which is available at ftp://ftp.andrew.cmu.edu/pub/cyrus-mail.
Directions for modifying Cyrus SASL to use the AS Client API for authentication can be found in the ASAM/bin/PlatformServices/PlatformClient/sasl directory created by the Platform Services installation process.
SSH* Communications Security produces a secure login application known as SSH Secure Shell. Source is available at ftp://ftp.ssh.com/pub/ssh. SSH Secure Shell is a commercial product. The rules governing the commercial and non-commercial use of SSH Secure Shell can be found at the SSH Communications Security Web Site.
You can install Platform Services on your server and modify the Secure Shell daemon, sshd, to use the AS Client API to authenticate users.
The sshd using the Identity Manager Fan-Out Driver allows users to skip setting up passphrases, because the authentication stage of setting up the Secure Shell connection is achieved with the driver instead of public-private key cryptography. After you have authenticated, your Secure Shell session is securely encrypted, as normal.
The Identity Manager Fan-Out Driver provides sample instructions for modifying the Secure Shell sshunixuser.c module. These instructions are distributed in the ASAM/bin/PlatformServices/PlatformClient/SSH directory created by the Platform Services installation process.
TACACS+ is a security protocol designed by Cisco Systems*, Inc. that is used to control dial-up access into networks. An unsupported but freely available implementation of TACACS+ is available in ftpeng.cisco.com in pub/tacacs.
You can install Platform Services on your server and modify TACACS+ to use the AS Client API to authenticate users.
Directions for modifying TACACS+ to use the AS Client API for authentication can be found in the ASAM/bin/PlatformServices/PlatformClient/TACACS directory created by the Platform Services installation process.
Part VI includes the following appendixes:
This appendix provides technical details to supplement information in earlier sections of this Guide about configuration and administration of the Core Driver.
This section includes the following topics:
The Core Driver of the NetIQ® Identity Manager Fan-Out can call a user-provided routine to enforce local password rules. This routine is called when a password change request is received from a password redirection platform.
The Password Change Validation Exit is passed the fully distinguished name of the user, the old password, the new password, and a message buffer. The exit can accept or reject the password change request and, if the request is rejected, provide an explanation in the message buffer. The explanation is written to the Core Driver Audit log and is displayed to the user.
A sample Password Change Validation Exit is provided in the ASAM directory created by the installation process in asam\bin\coredriver\chgpasswdexit\verpass.c.
To implement the Password Change Validation Exit:
Design, write, and build your Password Change Validation Exit. You can use the sample Password Change Validation Exit verpass.c as a guide.
Place a copy of the library containing your Password Change Validation Exit on each server that runs a Core Driver.
Specify the appropriate Change Password Exit Function and Change Password Exit Library configuration parameters for each Core Driver. For details, see Driver Object Configuration Parameters.
eDirectory uses indexes to optimize attribute location. Installation of the Fan-Out Driver includes creation of additional indexes for specific attributes of the objects added to the Identity Vault. Table A-1 provides a list of these custom indexes.
Table A-1 List of Indexes added to eDirectory for Fan-Out Driver
Index Name |
Attribute Name |
Type |
---|---|---|
ASAM_aliases |
ASAM-aliases |
Value |
ASAM_deletePendingsUpTo |
ASAM-deletePendingsUpTo |
Value |
ASAM_deletesUpTo |
ASAM-deletesUpTo |
Value |
ASAM_eGroupMembers |
ASAM-eGroupMembers |
Value |
ASAM_eGroupMembership |
ASAM-eGroupMembership |
Value |
ASAM_eventsUpTo |
ASAM-eventsUpTo |
Value |
ASAM_inputGUID |
ASAM-inputGUID |
Value |
ASAM_inputReference |
ASAM-inputReference |
Value |
ASAM-NetAddressList |
ASAM-NetAddressList |
Value |
ASAM_passwordsUpTo |
ASAM-passwordsUpTo |
Value |
ASAM_platformAssociation |
ASAM-platformAssociation |
Value |
Country |
c |
Value |
GUID |
GUID |
Value |
Locality |
l |
Value |
Object_Class |
objectClass |
Value |
Organization |
Organization |
Value |
ou |
ou |
Value |
State |
s |
Value |
Tree_Root |
t |
Value |
Depending on the size of the existing tree in your Identity Vault, these indexes can take some time to install and bring online. Before you begin your first Trawl, verify that the indexes are in the online state.
To view the Server object indexes and their state:
In iManager, select
> .Select the Server object for the Core Driver.
The following options can be specified on the driver shim command line. You can also specify driver shim configuration file statements as command line options. For details about the driver shim configuration file, see Section 6.6, The Driver Shim Configuration File.
The following command line options are used to set up the driver shim SSL certificates:
Table A-2 Driver Shim Command Line Options for Setting Up SSL Certificates
Option (Short and Long Forms) |
Description |
---|---|
-s -secure |
Secures the driver by creating SSL certificates, then exits. |
-p -password |
Specifies the Remote Loader password. |
Table A-3 Other Driver Shim Command Line Options
Option (Short and Long Forms) |
Description |
---|---|
-c <congFile> -config <configFile> |
Instructs the driver shim to read options from the specified configuration file. Options are read from ddname DRVCONF by default. |
-? -help |
Displays the command line options, then exits. |
-v -version |
Displays the driver shim version and build date, then exits. |
The default trace file exists on the connected Linux and UNIX system at /usr/local/ASAM/debug.log. A large amount of debug information can be written to this file. Use the trace level setting in /etc/nxdrv.conf to control what is written to the file. For details about /usr/local/ASAM/data/fanout.conf, see Section 6.6, The Driver Shim Configuration File.
Table A-4 Driver Shim Trace Levels
Trace Level |
Description |
---|---|
0 |
No debugging. |
1–3 |
Identity Manager messages. Higher trace levels provide more detail. |
4 |
Previous level plus Remote Loader, driver, driver shim, and driver connection messages. |
5–7 |
Previous level plus change log and loopback messages. Higher trace levels provide more detail. |
8 |
Previous level plus driver status log, driver parameters, driver command line, driver security, driver Web server, driver schema, driver encryption, driver PAM, driver SOAP API, and driver include/exclude file messages. |
9 |
Previous level plus low-level networking and operating system messages. |
10 |
Previous level plus maximum low-level program details (all options). |
The following is an example /etc/nxdrv.conf line to set the trace level:
-trace 9
To view the trace file:
Use a Web browser to access the driver shim at https://driver-address:8091. Substitute the DNS name or IP address of your driver for driver-address.
Authenticate by using any user name and the password that you specified as the Remote Loader password.
Click
.This appendix provides technical details to supplement information in earlier sections of this Guide about configuration and administration of Platform Services.
This section includes the following topics:
Identity Manager Fan-Out Driver platforms for most Linux/UNIX implementations make use of the Pluggable Authentication Modules (PAM) framework for system-entry services, such as login. PAM is defined by OSF RFC 86.0.
When a service (login, ftp, user written application, etc.) makes a call to the PAM API, the request is forwarded to the appropriate authentication module based on the specifications you have made in the PAM configuration file, normally /etc/pam.conf. (Most Linux implementations separate the PAM parameters for various services into files in the /etc/pam.d/ directory.) A sample pam.conf file for Platform Services is included in each Linux/UNIX platform distribution.
Topics in this section include:
The simple presence of Platform Services on a Linux or UNIX system is not enough to make PAM work with Identity Manager. This functionality must be activated by adding the appropriate line-entries to your PAM configuration file(s).In most cases, you can determine the necessary line entries by using a set of sample PAM configuration file templates that are part of the Platform Services installation. Using these templates will enable the default PAM support for Platform Services, which is to redirect three of the most common sign-on applications to Identity Manager: ssh, passwd, and su. These templates are located as follows:
Operating System |
PAM Configuration File Templates Location |
---|---|
AIX |
/usr/local/ASAM/bin/PlatformServices/pam.conf.sample |
FreeBSD |
/usr/local/ASAM/bin/PlatformServices/pam.d |
HP-UX |
/usr/local/ASAM/bin/PlatformServices/pam.conf.sample |
Linux |
/usr/local/ASAM/bin/PlatformServices/pam.d |
Solaris |
/usr/local/ASAM/bin/PlatformServices/pam.conf.sample |
There are two basic methods for using the templates to update PAM on each of your systems based on your current setup, as summarized in the following table.
Table B-1 Two methods for using the sample PAM configuration files.
Method |
Description |
When to use this method |
Applications redirected to Identity Manager |
---|---|---|---|
Replace current configuration file(s) with provided sample(s). |
Select from the pre-configured sample files supplied with Platform Services for your version of Linux or UNIX. Use it/them in place of your current PAM configuration file(s). |
If you have never modified the default PAM configuration file(s) that came with your implementation of Linux or UNIX, then this easiest method should work for you. |
ssh, passwd, su (default configuration) |
Use sample(s) as a guide. |
Manually modify your current PAM configuration files, using the supplied sample(s) as a guide. |
When it is not appropriate to replace your current PAM configuration file(s) with one or more of the supplied samples. Examples: You have already modified your PAM configuration from the vendor default, or you have an OS version that does not match the samples. |
Any you choose. |
If you want Identity Manager to work with more system-entry applications than those included in the sample file templates included with Platform Services, then you will need to be more familiar with how PAM works. The remainder of this section offers information and examples to use when your needs for PAM surpass the Platform Services default configuration.
The PAM architecture enables authentication by multiple authentication services through stacking. Stacking service modules can force users to authenticate to several authentication services, possibly using different passwords, or it can allow users the opportunity to authenticate using any one of several methods or some combination of methods.
It is very important to understand certain return codes returned by services in the stack, because these return codes are used in conjunction with the control flag to determine the behavior of the authentication flow within the stack.
Always test the logical flow of your configuration. Some configurations could allow users to log in without passwords, while others could prevent login by anyone, including root. Many service modules, including the Platform Services service module, treat root differently from other users.
For detailed information about PAM, see RFC 86.0, included in each Linux/UNIX Platform Services distribution package.
For PAM configuration file information specific to your Linux/UNIX implementation, see the man pages, typically man pam.conf.
For Linux-PAM documentation on the Web, see the Linux Kernel site.
An entry in pam.conf has the form:
service module-type control-flag module-path option
service The name of a service, such as login and ftp. The specification other indicates the module to be used by all other applications not specified in the file.
module-type The type of PAM function.
auth User authentication
account Account access, such as expiration and time of day restrictions
session Session management accounting
password Password change
control-flag Determines continuation or failure behavior of the module. This is especially important if stacking is used.
required This module must return success in order to have the overall result be successful. If this module fails, stack processing continues.
requisite Like required, except stack processing fails immediately if this module fails. Requisite is not used in all versions of PAM.
sufficient If this module is successful, skip the remaining modules in the stack, even if their control flags indicate they are required. If this module fails, the overall result might be determined by other modules in this stack.
optional If this module fails, the overall result can be successful if another module in this stack returns success. If this module succeeds, the overall result might be determined by other modules in this stack. If no other modules are required, then a success by an optional module causes success for the stack.
module-path The pathname of the module to be invoked for the function. The PAM service module for Platform Services, pam_ascauth, checks the user ID to see if it is in the Exclude list or is the user ID root (unless the root_nds PAM parameter is specified). If either condition is met, then pam_ascauth returns PAM_IGNORE, which has the same effect as the Platform Services authentication service not being included in the stack.
option Command line parameters to be passed to the module. The developer of a module can use these any way desired, but the PAM framework recommends that several parameters always be supported. Among these are use_first_pass (use the same password as that used by the first module that asked for one) and try_first_pass (like use_first_pass, but prompt if it is not valid).
The Platform Services PAM module supports several other parameters. For details about these parameters, see Using Options with the Platform Services PAM Module.
The following is a fragment from the sample pam.conf file that is provided with Platform Services for Solaris 8.
login auth sufficient /usr/lib/security/pam_ascauth.so.1 stats login auth required /usr/lib/security/pam_unix.so.1 try_first_pass
This fragment deals with authenticating users of the login service.
The first line specifies the Platform Services PAM module, pam_ascauth.so.1, passing it a parameter of stats, which causes it to write additional statistics records about its processing to syslog. If pam_ascauth.so.1 returns success, the user is granted access to the system. If pam_ascauth.so.1 returns failure, the next module is called.
The second line calls the native Solaris PAM module. It is invoked only if the Platform Services PAM module returns failure. This module first tries the password that was entered by the user and rejected by the driver. If the password is not valid, the user is prompted for the local Linux or UNIX system password. If that password is rejected, the user is not granted access to the system. Even if this module returns success, the next module in the stack, if any, is called.
WARNING:You must be familiar with PAM configuration for your particular Linux/UNIX implementation before attempting to create your own PAM configuration files. Take extreme care in configuring PAM on your systems. Mistakes here can result in major security exposures.
The examples in the following sections demonstrate possible PAM configurations.
The first section in the Solaris 2.9 Example PAM Configuration File Fragment represents the auth configuration for service-name OTHER in a generic Solaris 2.10 /etc/pam.conf file. The first module (pam_authtok_get) prompts for a user ID and password. The second module (pam_dhkeys) does a keylogin (if needed). The third module (pam_unix_cred) establishes credentials for Solaris projects (see the project man page). Finally, pam_unix_auth is called to do an authentication based on the default repository as listed in nsswitch.conf.
The second section in this example, which would replace the first section, authenticates using the Identity Manager Fan-Out Driver. If the driver authentication fails, an attempt is made to authenticate the user against the local repository, using the password from the driver prompt. Note that pam_unix_cred is placed before pam_ascauth, in case project credentials are needed. There are no known negative side effects to placing the pam_unix_cred before pam_ascauth, even in environments where Solaris projects are not used.
#vendor supplied OTHER auth requisite pam_authtok_get.so.1 OTHER auth required pam_dhkeys.so.1 OTHER auth required pam_unix_cred.so.1 OTHER auth required pam_unix_auth.so.1 #Identity Manager Fan-Out Driver variation OTHER auth required pam_unix_cred.so.1 OTHER auth sufficient pam_ascauth.so.1 stats OTHER auth requisite pam_unix_authtok_get.so.1 OTHER auth required pam_dhkeys.so.1 OTHER auth required pam_unix_auth.so.1
The following example represents a possible auth configuration for service-name sshd on a FreeBSD* 5.5 platform. FreeBSD 5.5 uses /etc/pam.d, so this example’s auth fragment comes from /etc/pam.d/sshd and the service-name is reflected in the file name, not the first column in the file.
# vendor supplied auth required pam_nologin.so no_warn auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass # Identity Manager Fan-Out Driver variation auth required pam_nologin.so no_warn auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth sufficient pam_ascauth.so stats auth required pam_unix.so no_warn try_first_pass
In the above example, pam_nologin and pam_opie* are placed above pam_ascauth in the stack so that the features they support remain enabled for all users. Then authentication is attempted via the Fan-Out driver. If the user can not be authenticated with the Fan-Out driver, the local authentication methods are attempted.
The following example represents a possible auth configuration for service-name sshd on a SUSE 10 and 11 platforms. SUSE, versions 10 and 11 (as with most distributions of Linux), uses /etc/pam.d, so this example’s auth fragment comes from /etc/pam.d/sshd and the service-name is reflected in the file name, not the first column in the file. The various configuration files for many distributions of Linux include a common file for each module type. The following example shows how to add the Fan-Out driver PAM module to a particular service without modifying the common file.
# vendor supplied auth include common-auth auth required pam_nologin.so # Identity Manager Fan-Out Driver variation auth sufficient pam_ascauth.so auth include common-auth auth required pam_nologin.so
You can specify the following parameters to the Platform Services PAM module to control its operation:
Table B-2 Options available for the Platform Services PAM Module
option |
Description |
---|---|
always_fail |
Instructs PAM module to always return PAM_AUTH_ERR (used for testing). |
always_ignore |
Instructs PAM module to always return PAM_IGNORE (used for testing). |
conf |
Specifies where the platform configuration file is located. The default location is /usr/local/ASAM/data/asamplat.conf. Example: conf=/usr/local/ASAM/data/myplat.conf |
debug |
Instructs the PAM module to write debugging records to syslog. |
ignore_no_user |
Instructs PAM module to return PAM_IGNORE when an authentication request returns “No user.” |
must_prompt |
Instructs PAM module to prompts all users for current password during a password change, even excluded users. |
no_warn |
Instructs PAM module not to pass any warnings to a system-entry application that is requesting authentication. |
root_nds |
Forces the root user to be authenticated and managed by the Identity Manager Fan-Out Driver. This is not normally desirable. If this option is not specified, the root user is managed by the local security mechanism. |
stats |
Instructs the PAM module to write syslog records containing authentication statistics. The records contain information on what type of request was made, the result, and the elapsed time to complete the request. |
succeed_no_user |
Instructs the PAM module to return PAM_SUCCESS when an authentication request returns “No user.” |
try_first_pass |
Instructs the PAM module to try the password that was provided by the previous PAM module in the stack. If this does not work, the user is prompted to enter a password. |
use_first_pass |
Instructs the PAM module to use the password that was provided by the previous PAM module in the stack. If this does not work, the module fails. |
For more information about PAM module configuration, see Overview of pam.conf.
To use SSHD (secure shell daemon) to authenticate users through the PAM interface, your version of SSHD must be PAM-compliant. It is also recommended that you include the following directives in sshd_config, the configuration file for SSHD:
PasswordAuthentication yes ChallengeResponseAuthentication no UsePAM yes
For more information on SSHD configuration directives, consult the sshd_config man pages.
IBM’s proprietary Loadable Authentication Module (LAM) interface is an alternative to PAM on AIX systems. In fact, the Identity Manager Fan-Out Driver fully supports PAM only on AIX 5.3 and later.
If you use LAM with the Fan-Out Driver, be sure to include the following considerations in your configuration.
The Fan-Out Driver’s LAM module is named DCE and located here on your AIX system:
/usr/lib/security/DCE
NOTE:IBM also has a deprecated LAM module named DCE, which is their implementation of the Distributed Computing Environment. IBM’s DCE LAM module is unrelated to the Fan-Out Driver’s DCE LAM module.
To enable the DCE LAM module as an available authentication mechanism, you must add it to the methods.cfg configuration file located here on your AIX system:
/usr/lib/security/methods.cfg
A sample methods.cfg file is included in /usr/local/ASAM/bin/PlatformServices.
The DCE LAM module can be made the default authentication method for all users, or it can be associated with particular users, via the user file located here on your AIX system:
/etc/security/user
Two sample user files are included in /usr/local/ASAM/bin/PlatformServices:
user.sample shows how to make DCE the default authentication mechanism.
user.sample2 shows how to make DCE the default authentication mechanism with fail-over to local authentication if DCE authentication is unavailable.
Alternatively, the DCE LAM module can be explicitly associated with Fan-Out Driver managed users by adding the SYSTEM and registry attributes to the mkuser command in the Fan-Out Driver’s adduser.sh script as follows:
COMMAND="/usr/bin/mkuser -R files SYSTEM=\"DCE\" registry=DCE "
To enable LAM on AIX 5.3 and later, you also need to modify the login.cfg file located here on your AIX system:
/etc/security/login.cfg
In this file, make sure that auth_type is set to STD_AUTH.
Finally, to use ssh with the DCE LAM module, you will need to check your sshd_config file located here on your AIX system:
/etc/ssh/sshd_config
In this file, it is important for PasswordAuthentication to have the default setting of yes .
Identity Manager Fan-Out Driver platforms may also be configured for account redirection using the Name Service Switch and the Platform Services Cache Daemon.When a service requests account information such as uidNumber, gidNumber or homeDirectory, the Name Service Switch redirects these calls to the appropriate library configured by the Name Service Switch configuration file, /etc/nsswitch.conf. If configured to use the Fan-Out Platform Services Cache Daemon, information is retrieved from Event Journal Services memory cache which resides on the local Linux or UNIX system.
The Platform Services Process provides Authentication Services and the interface for the AS Client API. It establishes and maintains connections to Core Drivers and provides load balancing and failover among them.
The Platform Services Process must be running if you plan to use Authentication Services on the platform.
Table B-3 Platform Services Process Command Line Parameters
Option |
Argument |
Explanation |
---|---|---|
-a |
Configuration File Path |
Specifies the platform configuration file to use. If you do not specify this option, the default is /usr/local/ASAM/data/asamplat.conf. |
-s |
None |
Obtain a security certificate for the Platform and end. This is needed only during the initial configuration process. |
This involves two types of files.
The Platform Services Process reads the platform configuration file to locate Core Drivers, to determine which users are authenticated using Authentication Services, and to find other configuration information. For details about the platform configuration file, see Section 10.0, The Platform Configuration File.
The Linux/UNIX Platform Services Process writes messages to log files in the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. Log messages are documented in the Messages Reference.
The Platform Receiver obtains provisioning events from Event Journal Services and calls the appropriate Receiver script to process the given type of event. For more information about Receiver scripts, see Receiver Scripts.
The Platform Receiver must be running if you plan to use Identity Provisioning on the platform.
Table B-4 Platform Receiver Command Line Parameters
Option |
Argument |
Explanation |
---|---|---|
-a |
Configuration File Path |
Specifies the platform configuration file to use. If you do not specify this option, the default is /usr/local/ASAM/data/asamplat.conf. |
-i |
None |
The Platform Receiver uses Polling Mode. |
-c |
None |
The Platform Receiver uses Check Mode. |
-p |
None |
The Platform Receiver uses Persistent Mode. |
-f |
None |
The Platform Receiver uses Full Sync Mode. |
-r |
None |
The Platform Receiver uses Scheduled Mode. |
-s |
None |
Obtain a security certificate for the Platform and end. This is needed only during the initial configuration process. |
The following options determine the mode of operation for the Platform Receiver.: -i, -c, -p, -f, and -r. They are mutually exclusive. If none of them is present, the mode of operation specified by the RUNMODE statement in the platform configuration file is used. If there is no RUNMODE statement, the Platform Receiver uses Persistent Mode.
For more information, see Section 8.8.1, Modes of Operation.
This involves three types of files.
The Platform Receiver reads the platform configuration file to locate the Core Driver, to determine which users and groups are managed using provisioning events, and to find other configuration information. For details about the platform configuration file, see Section 10.0, The Platform Configuration File.
Receiver scripts for Linux/UNIX platforms are implemented as shell scripts. The Platform Receiver runs the Receiver scripts from ASAM/bin/PlatformServices/PlatformReceiver/scripts. The installation process stores the base scripts in subdirectories of the scripts directory. For information about Receiver scripts, see Receiver Scripts.
The Linux/UNIX Platform Receiver writes messages to log files in the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. Log messages are documented in the Messages Reference.
The Platform Services Cache Daemon provides Account information for account redirection. It establishes and maintains a connection to the Core Driver and synchronizes Posix profile and password information from eDirectory® to a local memory cache.The Platform Services Cache Daemon must be running if you plan to use Account Redirection through the Name Service Switch on the platform.
Table B-5 Platform Services Process Command Line Parameters
Option |
Argument |
Explanation |
---|---|---|
-a |
Configuration File Path |
Specifies the platform configuration file to use. |
This involves three types of files.
The Platform Services Cache Daemon reads the platform configuration file to locate Core Drivers and to find other configuration information. For details about the platform configuration file, see Section 10.0, The Platform Configuration File.
The Linux/UNIX Platform Services Cache Daemon writes messages to log files in the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. Log messages are documented in the Messages Reference.
The Linux/UNIX Platform Services Cache Daemon writes the memory cache to a protected, encrypted file on the local file system in the /usr/local/ASAM/data/PlatformServices/certs directory. This file is written upon shutdown and read upon startup in order to provide quick retrieval of account information without having to synchronize with eDirectory upon every startup.
Most calls to the NetIQ® Identity Manager Fan-Out Driver AS Client API return a value that describes the outcome of the call. These return code values are defined in the C language ascauth.h header file and are provided as fields in the JAscAuth class in the Java interface. The C language API function ASC_STRERROR() and the Java interface method strError() can be used to return a text string that corresponds to the return code. This text string is included in many of the messages that are written to the platform log file for errors involving API calls.
The Java interface uses exceptions for most non-affirmative API call outcomes.
The following table lists the return codes and their corresponding text string, and suggests actions to take for them.
Table C-1 Return Codes for Troubleshooting
Return Code |
Symbol Text String |
Explanation and Suggested Action |
---|---|---|
0 |
AS_OK Action successful |
The operation returned a positive response. For calls such as check password, this corresponds to an answer of “Yes.” |
1 |
AS_NO Action not successful |
The operation returned a negative response. For calls such as check password, this corresponds to an answer of “No.” |
2 |
AS_NOUSER Unknown user |
The Enterprise User ID specified on the call is inactive or is not in the Census. Action: If you expect this user to be active in the Census, see Section II, Core Driver Administration for additional information. |
3 |
AS_NOAGENT No Core Drivers are available for authentication |
No Core Drivers could be contacted to process the request. Action: This is generally caused by a configuration problem.
For more information, see parts 2 and 3 in this guide. |
4 |
AS_BADCLIENT Local host is not authorized to query the Core Driver |
The network address used by the platform to contact a Core Driver did not match the network address listed in the Platform Configuration object in the ASAM System container. Action: For information about managing Platform objects with the Web interface, see. For an administrative password reset, this can indicate that the administrator user ID/password is not valid or that the administrator does not have rights to change the password. |
5 |
AS_REVOKED User is disabled/revoked |
The specified Enterprise User ID corresponds to a User object that has been disabled. |
6 |
AS_INTRUDER Intruder detection is active |
The specified Enterprise User ID corresponds to a User object that has been locked because of intruder detection. |
7 |
AS_INVALIDARGS Invalid arguments |
The arguments specified on the call are not valid. Action: Make certain that the arguments passed to the call are of the correct type and value. For example, an argument that specifies the name of an object cannot be blank or null, and an argument that specifies a buffer size to hold a result cannot be zero. |
8 |
AS_INVALIDOBJ Invalid object |
An object specified as an argument was not of the correct type or was not found. Action: Verify that the objects specified on arguments to the call are of the proper type. Handle the not-found condition as appropriate for your application. |
9 |
AS_INVALIDOBJLEN Invalid object length |
An object name specified as an argument was longer than the maximum allowable eDirectory™ object name. Action: Check object names that are specified as arguments to be sure that they do not exceed the maximum length for an eDirectory object name. |
10 |
AS_PASSDUPLICATE Password has been previously used |
The new password that was specified to the change password API function has been previously used for this User object and the User object is required to specify unique passwords. Action: Specify a password that has not been previously used. |
11 |
AS_PASSTOOSHORT Password does not meet password rules |
The new password that was specified to the change password API function is shorter than the minimum password length set for the User object. Action: Specify a password that meets the password rules for the User object. |
12 |
AS_TOOSMALL Buffer is too small |
The size specified for a buffer argument is too small to hold the result. The result is truncated. Action: Allocate a larger buffer, and issue the request again. |
13 |
AS_ATTRNOTFOUND Attribute not found |
The attribute specified was not found for the specified object. Action: Process this response accordingly, or specify the name of an attribute that exists for the specified object. |
14 |
AS_WSOCKUP WINSOCK not initialized |
Not used in the Identity Manager Fan-Out Driver. |
15 |
AS_WSOCKDOWN WINSOCK not terminated |
Not used in the Identity Manager Fan-Out Driver. |
16 |
AS_NOAUTHENV No authentication environment established |
The asce argument did not specify a valid environment item. C Action: Verify that a successful call to ASC_INIT() or ASC_INIT_EXT() has been made. Successful calls return a pointer to a valid environment item. Unsuccessful calls return NULL. Verify that the pointer to the environment item is correctly specified as an argument to this call. Java Action: Verify that a successful call to init() has been made. |
17 |
AS_PRODUCTEXPIRED Ascauth client has expired |
The expiration date for the platform has passed. Action: Install a current version of Platform Services. |
18 |
AS_INCLUDED User matched an INCLUDE statement |
The Enterprise User ID specified on a call to ASC_USER_INCLUDE_EXCLUDE() matched an AS.USER.INCLUDE statement in the platform configuration file. |
19 |
AS_EXCLUDED User matched an EXCLUDE statement |
The Enterprise User ID specified on a call to ASC_USER_INCLUDE_EXCLUDE() matched an AS.USER.EXCLUDE statement in the platform configuration file. |
20 |
AS_NOMATCH User did not match any INCLUDE/EXCLUDE statement |
The Enterprise User ID specified on a call to ASC_USER_INCLUDE_EXCLUDE() did not match any AS.USER.INCLUDE or AS.USER.EXCLUDE statement in the platform configuration file. The user is included because AS.USER.INCLUDE * is implicit if AS.USER.EXCLUDE * is not specified. |
21 |
AS_NOLICENSE Client is not licensed to use the driver |
Not used in the Identity Manager Fan-Out Driver. |
22 |
AS_INVALIDREQ API request is not valid or unsupported |
The AS Client API call was not recognized by the Core Driver. Action: Ensure that the version of Platform Services and the version of the Core Driver are compatible. |
23 |
AS_KEYEXPIRED Client is using an expired DES key |
The DES encryption key used by a non-SSL version of Platform Services has expired. Action: Update the KEY statement in the platform configuration file with the same encryption key that is specified for the Platform in the Platform object in the ASAM System container. For information about managing Platform objects with the Web interface, see Section II, Core Driver Administration. |
24 |
AS_INSUFFICIENTRIGHTS Client is using an expired DES key |
An administrative password reset was rejected. The administrative user does not exist, the password given for the administrative user is not valid, or the administrative user does not have rights to change the target user's password. |
NetIQ® Identity Manager Fan-Out Driver components write messages to their Operational Logs, the System Log, and the Audit Log. These messages record key processing occurrences, diagnostic information, and general statistical information. The messages can be useful to you in monitoring the operation of the driver and in troubleshooting problems.
This section presents all existing messages for the NetIQ Identity Manager Fan-Out Driver. Each message is followed by one or more explanation(s), possible cause(s), and suggested action(s) as needed.
Each message begins with a code of 3-5 characters associated with the driver component that generated the message. Use this code to find message information quickly as follows:
Each message written by the driver begins with a message identifier. The text of the message follows the message identifier. A diagnostic code, meaningful to the NetIQ product support team, follows the message text.
Example message:
OBJ010I Trawl complete. aas1625
In this example, the message identifier is OBJ010I. The message text is Trawl complete. The diagnostic code is aas1625.
The last character of the message identifier represents one of the following possible severity codes:
Table D-1 Message Severity Codes
D |
Debugging |
I |
Informational |
W |
Warning |
E |
Error |
Each message identifier begins with a code of 3-5 characters associated with the driver component that generated the message. Message explanations in this reference are grouped according to these codes so you can find them quickly.
Messages beginning with AGT are issued by the Core Driver for Authentication Services.
Messages beginning with AUDA are issued by Audit Services for Authentication Services.
Messages beginning with AUDG are issued by Audit Services for general components.
Messages beginning with AUDR are issued by Audit Services to report actions taken during Receiver script processing.
Messages beginning with AXML are issued by the Core Driver during interactions with the Identity Manager engine.
Messages beginning with CFG are issued by Platform Configuration file processing.
Messages beginning with CFGA are issued during installation when migrating values from the asamcore.conf file to Driver object configuration parameters.
Messages beginning with CFGP are issued by platform configuration file processing.
Messages beginning with CRT are issued by Certificate Services.
Messages beginning with DIR are issued by the Core Driver during LDAP directory access.
Messages beginning with DOM are issued by driver components as they communicate among themselves.
Messages beginning with DRVCOM are issued by the include/exclude system.
Messages beginning with EJS are issued by Event Journal Services.
Messages beginning with HES are issued by driver components as they use HTTP to communicate.
Messages beginning with LWS are issued by the Core Driver as it functions as an HTTP server.
Messages beginning with NET are issued by driver components during verification of SSL certificates.
Messages beginning with OAP are issued by driver components when communicating among themselves.
Messages beginning with OBJ are issued by Object Services.
Messages beginning with PLS are issued by Platform Services.
Messages beginning with PRCV are issued by Platform Receivers.
Messages beginning with RDXML are issued by the embedded Remote Loader.
Messages beginning with W3LM are issued by Web Services.
Audit Services maintains the Operational Logs and Audit Logs for the Core Driver in the logs directory. You can use the Web interface to view these logs.
Other log messages are handled depending on the system as follows.
System messages written by the Core Driver, and all messages written by the Linux/UNIX Platform Services Process and Platform Receiver, are written using the SYSLOG facility specified by the SYSLOGFACILITY statement of their respective configuration files.
The severity code of each message is used to determine the priority as follows.
Table D-2 Linux/UNIX Message Destination by Severity Code
Severity |
Priority |
---|---|
Debugging |
LOG_DEBUG |
Informational |
LOG_INFO |
Warning |
LOG_WARNING |
Error |
LOG_ERR |
System messages written by the Core Driver are written to the Windows Application Log.
Messages beginning with AGT are issued by the Core Driver for Authentication Services.
AGT001I Password Migration Mode is enabled.
AGT002I < thread_id> Processing compatibility mode request from ipAddress on port portNumber.
AGT003E < thread_id> Error reading from socket connected to ip_address.
AGT004I < thread_id> Compatibility mode request has ended.
AGT005E < thread_id> Invalid request was received from the platform.
The platform host is running a down-level version of the platform software.
AGT006W < thread_id> Request received from an unauthorized platform ip_address.
Someone might be attempting to breach security.
AGT007E < thread_id> DES key has expired for Platform ip_address.
AGT008W < thread_id> Response to request_type request from ip_address for objectDN is: answer.
AGT009W < thread_id> Response to request_type request from ip_address is: answer.
AGT010E < thread_id> Error writing to socket connected to ip_address.
AGT018E Password replication for user user failed with error code code.
AGT023E Write of ePassword for user user failed with error code code. (LDAP server: server: port).
Verify that the LDAP server specified in the driver parameters is running and configured properly. For information about the LDAP server, refer to your eDirectory documentation.
Verify that the computer running the Core Driver can communicate with the LDAP server using TCP/IP.
Check the eDirectory replication status.
AGT025I Password Change Validation Exit Registered using function from library library.
AGT026E Could not open library library for Password Change Validation Exit.
AGT027E Could not import function function from library library for Password Change Validation Exit.
AGT028E The Password Change Validation Exit has rejected the password change for user user. Reason: reason.
Messages beginning with AUDA are issued by Audit Services for Authentication Services.
AUDA001I Administrative Password Reset by driver_name for Platform platform_name IP address platform_ip_address: eUser eUser, Return Value rc, Elapsed Time seconds.
AUDA002W Connection Rejected by driver_name for Platform platform_name IP address platform_IP_address: Reason reason.
AUDA003I Check Password by driver_name for Platform platform_name IP address platform_ip_address: eUser eUser, Return Value rc, Elapsed Time seconds.
AUDA004I Change Password by driver_name for Platform platform_name IP address platform_ip_address: eUser eUser, Return Value rc, Elapsed Time seconds.
AUDA005I Get Context by driver_name for Platform platform_name IP address platform_ip_address: eUser eUser, Return Value rc, Elapsed Time seconds.
AUDA006I Get Security Equivalents by driver_name for Platform platform_name IP address platform_ip_address: eUser eUser, Return Value rc, Elapsed Time seconds.
AUDA007I Get Group Members by driver_name for Platform platform_name IP address platform_ip_address: Group group, Return Value rc, Elapsed Time seconds.
AUDA008I Check Security Equivalence by driver_name for Platform platform_name IP address platform_ip_address: eUser eUser to object object, Return Value rc, Elapsed Time seconds.
AUDA009I Check Rights to Attribute by driver_name for Platform platform_name IP address platform_ip_address: Object1 object1, Rights [rights], Attribute attribute_name, Object2 object2, Return Value rc, Elapsed Time seconds.
AUDA010I Get Attribute by driver_name for Platform platform_name IP address platform_ip_address: Object object, Attribute attribute_name, Return Value rc, Elapsed Time seconds.
Messages beginning with AUDG are issued by Audit Services for general components.
AUDG001I component_object started: Version version ID= code_id_string, Tree tree_name, ASAM System Container system_container, ASAM Master User master_user, Command Line command_line.
AUDG002I component_object ended. Start time was time_stamp.
AUDG003I component_object Interval Start Time: interval_start_time: name = value.
AUDG004I component_object Interval Start Time: interval_start_time: Platform: platform_object name = value.
AUDG007E Unable to write to log file because of insufficient memory.
AUDG008E Unable to open log file filename.
The Core Driver does not have the necessary file system rights.
AUDG009E Unable to write to logtype log file. Failed with errno errno.
AUDG010E Unable to write to logtype log file index. Failed with errno errno.
AUDG011E Error logging message to log file. Internal error interr symbolicname.
Messages beginning with AUDR are issued by Audit Services to report actions taken during Receiver script processing.
AUDR001I Add User on Platform platform_object: eUser eUser, UID uid, Platform Association platform_association.
AUDR002I Modify User on Platform platform_object: eUser eUser, UID uid, Platform Association platform_association.
AUDR003I Delete User on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR004I Enable User on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR005I Disable User on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR006I Rename User on Platform platform_object: eUser eUser, Old Platform Association old_platform_association, New Platform Association new_platform_association.
AUDR007I Move User on Platform platform_object: eUser eUser, Old Platform Association old_platform_association, New Platform Association new_platform_association.
AUDR008I Add User to Group on Platform platform_object: eUser eUser, eUser Platform Association eUser_platform_association, eGroup eGroup, eGroup Platform Association eGroup_platform_association.
AUDR009I Remove User from Group on Platform platform_object: eUser eUser, eUser Platform Association eUser_platform_association, eGroup eGroup, eGroup Platform Association eGroup_platform_association.
AUDR010I Add Group on Platform platform_object: eGroup eGroup, GID gid, Platform Association platform_association.
AUDR011I Modify Group on Platform platform_object: eGroup eGroup, GID gid, Platform Association platform_association.
AUDR012I Delete Group on Platform platform_object: eGroup eGroup, Platform Association platform_association.
AUDR013I Rename Group on Platform platform_object: eGroup eGroup, Old Platform Association old_platform_association, New Platform Association new_platform_association.
AUDR014I Move Group on Platform platform_object: eGroup eGroup, Old Platform Association old_platform_association, New Platform Association new_platform_association.
AUDR015I Replicate Password on Platform platform_object: eUser eUser.
AUDR016E Add User failed on Platform platform_object: eUser eUser, UID uid.
AUDR017E Modify User failed on Platform platform_object: eUser eUser, UID uid, Platform Association platform_association.
AUDR018E Delete User failed on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR019E Enable User failed on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR020E Disable User failed on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR021E Rename User failed on Platform platform_object: eUser eUser, Old Platform Association platform_association.
AUDR022E Move User failed on Platform platform_object: eUser eUser, Old Platform Association platform_association.
AUDR023E Add User to Group failed on Platform platform_object: eUser eUser, eUser Platform Association eUser_platform_association, eGroup eGroup, eGroup Platform Association eGroup_platform_association.
AUDR024E Remove User from Group failed on Platform platform_object: eUser eUser, eUser Platform Association eUser_platform_association, eGroup eGroup, eGroup Platform Association eGroup_platform_association.
AUDR025E Add Group failed on Platform platform_object: eGroup eGroup, GID gid.
AUDR026E Modify Group failed on Platform platform_object: eGroup eGroup, GID gid, Platform Association platform_association.
AUDR027E Delete Group failed on Platform platform_object: eGroup eGroup, Platform Association platform_association.
AUDR028E Rename Group failed on Platform platform_object: eGroup eGroup, Old Platform Association platform_association.
AUDR029E Move Group failed on Platform platform_object: eGroup eGroup, Old Platform Association platform_association.
AUDR030E Replicate Password failed on Platform platform_object: eUser eUser.
AUDR031I Pending Delete User on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR032I Pending Delete Group on Platform platform_object: eGroup eGroup, Platform Association platform_association.
AUDR033E Pending Delete User failed on Platform platform_object: eUser eUser, Platform Association platform_association.
AUDR034E Pending Delete Group failed on Platform platform_object: eGroup eGroup, Platform Association platform_association.
AUDR035I User user authentication result is returnCode (reasonString) [elapsedTime elapsed seconds].
Messages beginning with AXML are issued by the Core Driver during interactions with the Identity Manager engine.
AXML0000I Success.
AXML0006E The event could not be processed. The driver will retry the event.
AXML0008W The driver is in discard-events mode and will not process events.
AXML0012W Some initialization parameters could not located; default values are being used.
AXML0013E The event for object dn failed with error code code. The event has been discarded.
3, 85 - Time-out. Increase the LDAP time-out value in the Web interface.
16 - No such attribute. The system attempted to access an attribute that was not present on an eDirectory object.
17 - Type not found. The schema might not have been correctly updated.
32 - Object not found. The system attempted to access an eDirectory object that was not present.
49 - Invalid credentials. Check the username and password in the Driver object parameters.
51, 52 - Busy/unavailable. Check the health of your LDAP server using DSTrace.
81 - Server down. Restart your LDAP server, or check network connectivity between the Core Driver server and the LDAP server.
For a full list of eDirectory errors, see your eDirectory documentation.
An error of -1 is an internal error. In this case, and for all errors, examine your log files for more information about the error.
AXML0014E No GUID could be found for the event.
AXML0015E Could not retrieve the LDAP attribute map. The ASAM Master User and Password driver parameters might be invalid, or the specified user does not have sufficient rights.
The ASAM Master User and Password driver parameters might be invalid. By default, a user named ASAMMaster is used to log in to eDirectory with an installation-generated password.
eDirectory or LDAP on the specified server might be down or in an error state.
Check the ASAM Master User and Password parameters to make sure a valid user and password are specified. Also, make sure the user has sufficient rights.
Verify that eDirectory and LDAP are healthy on the specified server.
Messages beginning with CFG are issued by Platform Configuration file processing.
CFG001E Could not open configuration file filename.
The file does not exist. The default location for the file is in the ASAM\data directory. The file path can be specified by using the -a command line option.
You don't have permission to read the file.
CFG002E Error parsing configuration file line: <configline>.
CFG003W Configuration file line was ignored. No matching statement name found: < configline>.
CFG004E Error parsing configuration file line. No statement name was found: <configLine>.
CFG005E A required statement statement_id is missing from the configuration file.
Messages beginning with CFGA are issued during installation when migrating values from the asamcore.conf file to Driver object configuration parameters.
CFGA001E Invalid ASAM System Container configuration.
CFGA002E Invalid Entropy configuration.
CFGA003E Invalid ASAM Master User configuration.
CFGA004E Invalid ASAM Master User Password configuration.
CFGA005E Invalid LDAP Host and Port configuration.
CFGA006E Invalid Locale configuration.
CFGA007E Invalid ASAM Directory configuration.
CFGA008E Invalid Debug Log File configuration.
CFGA009E Invalid Syslog Facility configuration.
CFGA010E Invalid Storage Key configuration.
Messages beginning with CFGP are issued by platform configuration file processing.
CFGP001E Invalid statement_name statement.
CFGP002I There are no Core Drivers configured for provisioning. If you want to provision to this platform, specify a PROVISIONING statement.
CFGP003I There are no Core Drivers configured for authentication. If you want to use authentication redirection or APIs on this platform, specify an AUTHENTICATION statement.
Messages beginning with CRT are issued by Certificate Services.
CRT001E Error: Certificate Authority not found.
CRT002E Error: Could not contact directory. Check username and password.
The ASAM Master User and ASAM Master User Password are not correct.
Ensure that the ASAM Master User and ASAM Master User Password are specified correctly.
CRT003E Error: Certificate Services not properly configured.
The Core Driver configuration specifies the wrong ASAM System OU.
Verify that the ASAM System Container Core Driver parameter is correct.
CRT004E Error: component_name not properly configured.
CRT005E Error: Internal Server Error.
CRT006E Error: Insufficient rights to create component_name configuration object.
CRT007E Error: Insufficient rights to modify component_name configuration object.
CRT008I All certificate and host information has been checked and verified successfully.
CRT009I Certificates have been updated with new host information.
CRT010I New driver certificates were created.
CRT011I The certificate authority was retrieved successfully from the primary Core Driver.
Messages beginning with DIR are issued by the Core Driver during LDAP directory access.
DIR001E Attribute Not Supported.
DIR002E Request Build Error.
DIR003D Error.
DIR004D Success.
DIR005D Operations Error.
DIR006D Protocol Error.
DIR007D Time Limit Exceeded.
DIR008D Size Limit Exceeded.
DIR009D Compare False.
DIR010D Compare True.
DIR011D Authentication Method Not Supported.
DIR012D Strong Authentication Required.
In bind requests, the LDAP server accepts only strong authentication.
In a client request, the client requested an operation, such as delete, that requires strong authentication.
In an unsolicited notice of disconnection, the LDAP server discovers the security protecting the communication between the client and server has unexpectedly failed or been compromised.
DIR013D Partial Results.
DIR014D Referral.
DIR015D Admin Limit Exceeded.
DIR016D Unavailable Critical Extension.
DIR017D Confidentiality Required.
DIR018D SASL Bind in Progress.
DIR019D No Such Attribute.
DIR020D Undefined Type.
DIR021D Inappropriate Matching.
DIR022D Constraint Violation.
DIR023D Type or Value Exists.
DIR024D Invalid Syntax.
DIR025D No Such Object.
Search operations that find the search base but cannot find any entries that match the search filter.
Bind operations.
DIR026D Alias Problem.
DIR027D Invalid DN Syntax.
DIR028D Is Leaf.
DIR029D Alias Dereference Problem.
DIR030D Inappropriate Authentication.
The client returns simple credentials when strong credentials are required.
The client returns a DN and a password for a simple bind when the entry does not have a password defined.
DIR031D Invalid Credentials.
The client passed either an incorrect DN or password.
The password is incorrect because it has expired, intruder detection has locked the account, or some other similar reason.
DIR032D Insufficient Access.
DIR033D Busy.
DIR034D Unavailable.
DIR035D Unwilling to Perform.
The add entry request violates the server's structure rules.
The modify attribute request specifies attributes that users cannot modify.
Password restrictions prevent the action.
Connection restrictions prevent the action.
DIR036D Loop Detected.
DIR037D Naming Violation.
The request places the entry subordinate to an alias.
The request places the entry subordinate to a container that is forbidden by the containment rules.
The RDN for the entry uses a forbidden attribute type.
DIR038D Object Class Violation.
The add or modify operation tries to add an entry without a value for a required attribute.
The add or modify operation tries to add an entry with a value for an attribute that the class definition does not contain.
The modify operation tries to remove a required attribute without removing the auxiliary class that defines the attribute as required.
DIR039D Not Allowed on Non Leaf Object.
The client requests a delete operation on a parent entry.
The client requests a modify DN operation on a parent entry.
DIR040D Not Allowed on RDN (Relative Distinguished Name).
DIR041D Already Exists.
DIR042D No Object Class Modifications.
DIR043D Results Too Large.
DIR044D Affects Multiple DSAS.
DIR045D Other.
Use DSTRACE to gather more specific error information.
DIR046D Server Down.
DIR047D Local Error.
DIR048D Encoding Error.
DIR049D Decoding Error.
DIR050D Time Out.
DIR051D Authentication Unknown.
DIR052D Filter Error.
DIR053D User Cancelled.
DIR054D Parameter Error.
DIR055D No Memory.
DIR056D Connect Error.
DIR057D Not Supported.
DIR058D Control Not Found.
DIR059D No Results Returned.
DIR060D More Results to Return.
DIR061D Client Loop.
DIR062D Referral Limit Exceeded.
The hop limit is two.
The referral is to server D, which can be contacted only through server B (1 hop) which contacts server C (2 hops) which contacts server D (3 hops)
With these conditions, the hop limit is exceeded and the LDAP libraries return this code.
DIR063D No Such Object.
DIR064D Invalid Argument.
DIR065D Revoked.
DIR066W Unable to connect to LDAP. Component will retry connection periodically.
DIR067W Directory Services returned rc.
DIR068E LDAP Server server is not responding correctly. RC = rc.
DIR069I LDAP Server is now responding to requests.
Messages beginning with DOM are issued by driver components as they communicate among themselves.
DOM0001W XML parser error encountered: errorString.
Messages beginning with DRVCOM are issued by the include/exclude system.
DRVCOM000I nameversion Copyright 2005 Omnibond Systems, LLC. ID=code_id_string.
DRVCOM001W Invalid include/exclude CLASS statement.
DRVCOM002D An include/exclude Rule was added for class: class.
DRVCOM003D An include/exclude Association Rule was added for association association.
Messages beginning with EJS are issued by Event Journal Services.
EJS0001E No Platform object FDN was provided with the Platform Receiver request.
EJS0002E Unable to create an instance of the string handler.
EJS0003E Unable to create an instance of the memory manager.
EJS0004E Unable to create an instance of the ASAM directory interface, direrr= DirectoryError (DirectoryErrorText).
An invalid ASAM Master User or ASAM Master User Password is specified in the Driver object parameters.
An invalid DNS name or IP address, or port number is specified for the LDAP Host and Port in the Driver object parameters.
The LDAP host is down or not responding to requests.
Ensure that the correct network address and port is specified for the LDAP Host and Port in the Driver object parameters.
Ensure that the host running the LDAP server is functioning correctly.
EJS0005E Directory Search object DirectorySearchObjectFDN not found with scope= DirectorySearchScopeLevel.
This message is accompanied by messages EJS0007W and EJS0008W.
EJS0006E Directory search error for object DirectorySearchObjectFDN, direrr= DirectoryError (DirectoryErrorText), numRows= DirectoryEntriesReturned, scope= DirectorySearchScopeLevel.
EJS0007W Directory search requested attributes=DirectoryAttributes.
EJS0008W Directory search for values= DirectorySearchValues.
EJS0009E Directory modification error for object DirectoryObjectFDN, direrr= DirectoryError ( DirectoryErrorText), actions= ActionsToPerform.
EJS0010E Directory modification error for object DirectoryObjectFDN, direrr= DirectoryError ( DirectoryErrorText).
EJS0011E Unable to create or obtain the Event Journal Services Platform item.
There might not be enough free memory available on the system.
A string handler interface could not be created (look for message EJS0002E).
A memory manager interface could not be created (look for message EJS0003E).
An ASAM directory interface object could not be created (look for message EJS004E).
The Platform FDN provided by the Platform Receiver is invalid (look for message EJS0031E).
EJS0012W Event EventType for object DirectoryObjectFDN could not be processed.
EJS0013W Unable to obtain UID/GID information for object DirectoryObjectFDN.
EJS0014E Unable to create a directory search request.
EJS0015E Unable to delete attribute DirectoryAttribute for object DirectoryObjectFDN.
EJS0016E Unable to add attribute DirectoryAttribute with value AttributeValue for object DirectoryObjectFDN.
EJS0017E Unable to create a directory modify attributes request.
EJS0018E Unable to delete value AttributeValue for attribute DirectoryAttribute for object DirectoryObjectFDN.
EJS0019E Unable to replace attribute DirectoryAttribute value OldAttributeValue with new value NewAttributeValue for object DirectoryObjectFDN.
EJS0020E Unable to obtain the CN of the Platform object DirectoryObjectFDN.
EJS0021E No Census object was found for the Platform object DirectoryObjectFDN.
EJS0022E Unable to parse the journal value for object DirectoryObjectFDN.
EJS0023I No UID/GID number was found for object DirectoryObjectFDN.
EJS0024W No Platform Receiver attribute list was loaded for object class DirectoryObjectClass.
The LDAP server is down or not responding properly.
EJS0026W The password could not be retrieved for object DirectoryObjectFDN.
EJS0029E ElementTagName SOAP element could not be created in the Platform response document.
EJS0031E Invalid Platform FDN platformFDN was specified by the Platform Receiver.
EJS0032E Unable to search for pending events for Platform platformFDN.
EJS0033I Platform PlatformName returned ReturnCode for event EventType for object DirectoryObjectFDN.
prrcSuccess - The event was successfully processed by the Platform Receiver.
prrcIgnored - The event was ignored by the Platform Receiver.
prrcExcluded - The event was excluded by the Platform Receiver.
prrcWarning - The event was processed by the Platform Receiver, but all necessary actions were not completed.
prrcError - The event was not processed successfully by the Platform Receiver.
EJS0034I Processed event EventType for Platform PlatformName was removed for object DirectoryObjectFDN.
EJS0035I Platform PlatformName added association PlatformAssociation for object DirectoryObjectFDN.
EJS0037I Platform PlatformName has NumberOfEvents events pending.
EJS0038W A Platform Receiver is already active for Platform platformName.
It is also possible that a Platform Receiver has abended and left its connection token active with Event Journal Services.
If a Platform Receiver abended, and you are trying to start a new one, allow several minutes for Event Journal Services to release control to a new instance of the Platform Receiver.
EJS0041I Searching for objects with pending events for Platform platformName.
EJS0042I Pending event search for Platform platformName returned numObjects objects.
EJS0043I Ready to send events to Platform platformName.
EJS0044I Removing all error events for Platform platformName.
An administrator is clearing the events using the Web interface.
EJS0045I Re-sending all error events for Platform platformName.
EJS0046I Removing event eventType for object objectCN.
EJS0047I Re-sending error event eventType for object objectCN.
EJS0048I Platform Receiver platformName version is version build level build.
EJS0049E Event event for object objectCN was changed to an error state.
The Core Driver was trying to process the event, but it could not obtain the object's password from ePassword.
EJS0050E Unable to open temporary file fileName for event processing (error= errno, reason= reason).
The Core Driver might not have the proper permissions to the file system.
The file system might be full.
Make sure the Core Driver has read/write permission to the path.
Make sure enough space exists on the volume.
EJS0051E Unable to obtain a directory connection.
EJS0052E Unable to create temporary work files.
The Core Driver might not have the proper permissions to the file system.
The file system might be full.
Make sure the Core Driver has read/write permission to the path.
Make sure enough space exists on the volume.
EJS0053I Now attempting to process event eventType for object objectDN.
EJS0054E Unable to add attribute attributeName value attributeValue for object objectCN.
EJS0055E Populate event was generated for object objectCN on platform platformName.
EJS0056I Updated event timestamps for platform PlatformName.
EJS0057I Removing error event eventType for object objectCN.
EJS0058E Unable to create ASAM Directory Interface item.
The server is low on memory.
EJS0059E Ignoring event for objectDN because of error status.
The platform returned an error while attempting to process the event.
If the event was for a User object, the eUser password was not available, and the platform's permit password replication setting is YES, an error state is returned for that User object.
Invalid event data.
Check for platform errors using the Web interface, and re-send the error events to the platform.
Use the Web interface to clear error events for the platform if needed.
EJS0060W Unable to obtain the alternate name of the Platform object DirectoryObjectFDN.
An Alternate Naming Attribute was specified for the Platform Set, but that attribute has not been included in the Subscriber filter.
Messages beginning with HES are issued by driver components as they use HTTP to communicate.
HES001E Unable to initialize the HTTP client.
HES002I Connecting to host host_name on port port_number.
HES003W Core Driver has an incorrect certificate. rc = rc.
Messages beginning with LWS are issued by the Core Driver as it functions as an HTTP server.
LWS0001I Server has been initialized.
LWS0002I All services are now active.
LWS0003I Server shut down successfully.
LWS0004W Server shut down with warnings.
LWS0005E Server shut down with errors.
LWS0006I Starting service.
LWS0007E Failed to start service.
LWS0008I Stopping all services.
LWS0009I Local host is host_name ( IP_address).
LWS0010I Local host is IP_address.
LWS0011I Server is now processing client requests.
LWS0012I service is now active on port number.
LWS0013I service is now inactive on port number.
LWS0014E An error was encountered while parsing execution parameters.
LWS0015E service failed to start with error number.
LWS0020I Server version level: level.
LWS0023I Listen port number is already in use.
LWS0024W Too many retries to obtain port number.
LWS0025I Local TCP/IP stack is down.
LWS0026E Unrecoverable TCP/IP error number returned from internal_function_name.
LWS0027W Listen socket was dropped for port number.
LWS0028E Unable to reestablish listen socket on port number.
LWS0029I < id> Client request started from ip_address on port number.
LWS0030I < id> Client request started from host ( ip_address) on port number.
LWS0031W Unable to stop task id: reason.
LWS0032I < id> Client request has ended.
LWS0033I < id> Client request: resource.
LWS0034W < id> Write operation for client data has failed.
LWS0035W < id> Read operation for client data has timed out.
LWS0036W < id> Client request error: error_code - error_text.
LWS0037W < id> Client request error: code.
LWS0038I Received command: command_text.
LWS0043E Task id ended abnormally with RC= retcode.
LWS0045I Idle session time-out is number seconds.
LWS0046I Maximum concurrent sessions limited to number.
LWS0047W Unable to delete log file filename.
Examine the current logs for related messages.
LWS0048I Log file filename successfully deleted.
LWS0049E Error error authenticating to the directory as fdn.
Verify that the ASAM Master User has the appropriate rights.
Verify that the password given for the ASAM Master User object in the configuration parameters is correct.
LWS0050E Server application initialization failure was detected.
LWS0051E Server initialization failure was detected.
Messages beginning with NET are issued by driver components during verification of SSL certificates.
NET001W Certificate verification failed. Result is result.
The security certificate has expired.
The component's CERTS directory has been corrupted.
Messages beginning with OAP are issued by driver components when communicating among themselves.
OAP001E Error in SSL configuration. Check system for entropy.
OAP002E Error in SSL connect. Network address does not match certificate.
OAP003E Error in SSL connect. Check address and port.
The configuration information does not specify the correct network address or port number.
Correct the configuration.
OAP004E HTTP Error: cause.
OAP005E HTTP Error: Internal Server Error.
Ensure that the LDAP Host and Port Driver object configuration parameter is specified correctly.
Messages beginning with OBJ are issued by Object Services.
OBJ001I Processing Users In search_object.
OBJ002I Checking for deleted users.
OBJ004I Processing groups in search_object.
OBJ005I Checking for deleted groups.
OBJ007I Starting Trawl.
OBJ008I Phase phase_number: Processing Users.
OBJ009I Phase phase_number: Processing Groups.
OBJ010I Trawl complete.
OBJ013W No valid Search objects found for Census_or_Platform_set.
OBJ014W No Platforms found in Platform_set.
OBJ015I No UID/GID Sets found.
OBJ016W Search object search_object_name does not have a value for attribute_name. It is ignored.
OBJ017E UID/GID Set UID_GID_set_name, specified for Platform Set Platform_set_name, was not found.
OBJ018W No Platform Sets found.
OBJ019I UID/GID number assigned to user in UID/GID Set uidgid_set_name.
OBJ020I Exception resolved for exception_object.
OBJ021I Added user_or_group_name to Platform Set Platform_set_name.
OBJ022I Enterprise object object_name removed from Census.
OBJ023I Enterprise object object_name renamed to new_object_name.
OBJ024I Created Exception object for object_dn.
Two or more objects in the directory have the same GUID.
If the Exception object is because of a create problem, a naming conflict has occurred. Rename the user or group so its name is unique.
If the Exception object is because of a duplicate GUID, look in the operational log for a listing of the objects that use the same GUID, and see TID 10064771 for information on resolving GUID conflicts.
OBJ025I User user_name, attribute(s) attribute_list modified in Census.
OBJ026I Group group_name, attribute(s) attribute_list modified in Census.
OBJ027I User user_name added to Census.
OBJ028I Group group_name added to Census.
OBJ030E Error error_id authenticating to eDirectory as username.
OBJ031E Error error_id renaming object dn to cn.
OBJ032E Out of memory.
OBJ033E Error error_id retrieving from dn.
OBJ034E Error error_id retrieving attributes for object.
OBJ035E Error error_id modifying attributes for object.
OBJ036E Error error_id searching for object object.
OBJ037E Error error_id creating object object.
OBJ038E Error error_id removing object object.
OBJ039E Unexpected error processing information retrieved from the directory in function function_name.
OBJ040E Unable to load request document.
OBJ041E Unable to determine DN for the ASAM System Container.
OBJ042E Unable to process some users in search_object.
OBJ043E Unable to process some groups in search_object.
OBJ044E Unable to process some aliases in search_object.
OBJ046I Updated attribute attribute_name in object object.
A new user was added to the Census, and a group to which it belongs was updated accordingly.
A new group was added to the Census, and a user in that group was updated accordingly.
OBJ047I Removed object_cn from Platform Set Platform_set.
OBJ051E Duplicate GUID found among the listed objects: dn_list.
A list of the objects having duplicate GUIDs is produced in the log.
OBJ052E Duplicate ASAM-inputGUID found among the listed objects: dn_list.
A list of the objects having duplicate GUIDs is produced in the log.
OBJ053I Created events of type event_type for object.
OBJ055E UID/GID Set set_name was not found.
OBJ056E Unable to retrieve object object_dn referenced by alias alias_dn.
OBJ057E Unable to retrieve attribute attribute_name from object_dn.
OBJ058E Duplicate UID/GID number uidgid_number found in both object1 and object2.
OBJ059E Cannot remove Platform Set Platform_set_name. It has associated Platform objects.
OBJ060I Removed Platform Set Platform_set.
OBJ061E Cannot remove UID/GID Set uidgid_set_name. It is used by a Platform Set.
OBJ062I Removed UID/GID Set uidgid_set.
OBJ064W Error error_id setting LDAP time-out.
OBJ065E Platform Set set_name not found in directory.
OBJ066E Unable to recognize object type of Search object search_object_name.
OBJ069E Skipping checks for deleted users because of errors during processing of users.
OBJ070E Skipping checks for deleted groups because of errors during processing of groups.
OBJ072E Unrecognized object class for object dn in function_name.
OBJ073E Cannot handle object class internal_objectclass_identifier for object dn in function_name.
OBJ074E Cannot determine Platform Set for dn.
OBJ075I Trawl aborted because of user request.
The Core Driver was shut down.
OBJ076I Deleting Platform Set set_name.
OBJ077I Deleting UID/GID Set set_name.
OBJ079E Unable to convert dn dn to required format.
OBJ080E Unable to create file file_name. Error = errno.
OBJ081E Unable to write to file file_name. Error = errno.
OBJ082E Unable to delete file file_name. Error = errno.
OBJ084I Checking UID/GID Set UIDGID_set.
OBJ086W Unable to start Trawl because a Trawl is already running.
A manual Trawl was started and it had not completed before the scheduled Trawl time arrived.
OBJ087E Cleanup of resources from the previous Trawl failed.
OBJ088E Unable to allocate resources for starting a Trawl.
OBJ089E Unable to start the Trawl task.
OBJ090E Unable to read from file file_name. Error = errno.
OBJ091W Object type of object_dn is not recognized.
OBJ092E Unable to determine value of attribute attribute_name for object object_name.
OBJ093E Unable to create directory search request.
OBJ094E Unable to create request to modify attributes in the directory.
OBJ095E Unable to initialize mutex.
OBJ096E Unable to find object dn during repair of links in Census because of error error_id.
OBJ097I ASAM-inputGUID updated in object dn.
OBJ098I Processed processed_count of users_in_search_object users.
OBJ099I Processed processed_count of groups_in_search_object groups.
OBJ100I Processed processed_count of aliases_in_search_object aliases.
OBJ102I Processed processed_count UIDGID objects.
OBJ105I Dispatching new event notification to Platform platformName.
Only Platform Receivers that are running in Persistent mode are notified of new events that are pending. Platform Receivers running in other modes discover the new events the next time they poll or connect to Event Journal Services.
OBJ106I Phase phase_number: Processing Password Updates.
OBJ107E Attempt to process an event with no DN was aborted.
OBJ108I Updated password for user object_dn.
OBJ109E Error error_id updating password for user object_dn.
OBJ111I Removed password from temporary storage for user user_dn.
OBJ112I Error error_id removing password for user user_dn from temporary storage.
OBJ113I user_or_group_name updated for driver storage format.
OBJ114I Removed object_cn from UID/GID Set UIDGID_set.
OBJ115I Migrating user_or_group_name to driver storage format.
OBJ116I Updating inclusion in Platform Set platform_set for user_or_group.
OBJ117I Updating association to platform platform for user_or_group.
OBJ118I Updating UID/GID in set uidgid_set for user_or_group.
OBJ119I Removed object object_dn.
OBJ120I Object Services received an event for object_dn.
OBJ121I Object Services received an event for object with unidentified dn.
OBJ122I Processing a pseudo-event for object_dn.
OBJ123E Delete action for object_cn aborted because of invalid Search object.
OBJ124I Obsolete object dn successfully removed.
After removal of a large number of objects, it can be desirable to use directory maintenance techniques to reduce the size of the directory on disk.
OBJ125I Migration status changed to migration_status.
Each user or group is migrated to the new data format the first time it is processed by the Core Driver.
After all users and groups have migrated to the new data format, cleanup of obsolete objects begins.
The status is reported as Complete after all users or groups have been migrated, and all obsolete objects have been cleaned up. The size of the eDirectory database can be reduced by using standard eDirectory maintenance practices when this stage has been reached.
OBJ126I Phase phase_number: Migration Cleanup.
OBJ127E Alternate name attribute alternate_name must have single value or form <platform set name>:<alt name>.
OBJ128I Created Census entry for alternate name alternate_name.
OBJ129E Could not add alternate name alternate_name to the Census. Name already exists.
OBJ130I Removed alternate name alternate_name from Census.
OBJ131I Name is on the census exclude list.
OBJ132I Removed obsolete Platform Association association from object_cn.
Messages beginning with PLS are issued by Platform Services.
PLS001I core_driver is not responding correctly. rc = rc.
PLS002I core_driver is now responding to requests.
Messages beginning with PRCV are issued by Platform Receivers.
PRCV001E Unable to create the platform parameter item.
PRCV002E Unable to create a string handler item.
PRCV003E Unknown command line option or error: option= ShortOptionValue, long option= LongOptionValue.
PRCV004E Mutually exclusive command line parameters were specified.
PRCV005I You can specify only one of the following options: -i, -c, -p, -f, or -r.
PRCV006E Platform Configuration file parsing has failed because of a syntax error.
PRCV007E Unable to create a configuration parameter item.
PRCV008E Unable to load the string resource file StringResourceFileName.
Ensure that the ASAMDIR statement is correct.
PRCV009E Unable to establish a connection with host ipAddress port portNumber.
The host that runs the Core Driver is down.
Event Journal Services has failed.
The Core Driver is running on a different port than is expected by the Platform Receiver.
Ensure that the Core Driver host is up.
Ensure that the Core Driver is running.
Ensure that the Core Driver is listening on the port number expected by the Platform Receiver.
PRCV010I Connection established with host ipAddress port portNumber.
PRCV011E Unable to begin a session with host ipAddress port portNumber, reason= reasonString.
The Core Driver has terminated the connection.
The request was rejected by the Core Driver because of an invalid certificate or internal server error.
An instance of the DOM interface could not be created.
An instance of the SOAP request document could not be created.
Ensure that the Core Driver is running.
Ensure that the platform host has network connectivity to the host running the Core Driver.
Ensure that the correct security certificate is installed on the system.
PRCV012W MessageFromManager.
PRCV013E Unable to complete the get next platform event request.
PRCV014I The driver running on host ipaddress on port port is shutting down.
PRCV015E The security certificate could not be loaded.
No security certificate has been created for this platform.
The security certificate is invalid.
The security certificate could not be found, possibly because of an incorrect ASAMDIR statement in the Platform Configuration file.
Ensure that the ASAMDIR statement is correct.
PRCV016I The Platform Receiver is shutting down because of a stop request.
PRCV017I SSL Certificate Local FDN is SSLLocalFDN.
If this message is issued, the FDN should be verified to be the correct object in eDirectory.
PRCV018I The Platform Receiver for platformName is running in runMode mode.
PRCV019I An event was received for object objectCN.
PRCV020I The event for object objectCN was excluded.
PRCV021I Connection established with host ipAddress port portNumber version version build level build.
PRCV022I Platform Receiver version is version build level build.
PRCV023I Event summary for Platform platformName: received= numReceived, processed= numProcessed, excluded= numExcluded, ignored= numIgnored, errors= numErrors.
This message is displayed when the Platform Receiver terminates.
PRCV024I objectType event totals for Platform platformName: received= numReceived, processed= numProcessed, excluded= numExcluded, ignored= numIgnored, errors= numErrors.
This message is displayed when the Platform Receiver terminates.
PRCV025I Platform Receiver executed for days days, hours hours, minutes minutes, and seconds seconds.
This message is displayed when the Platform Receiver terminates.
Messages beginning with RDXML are issued by the embedded Remote Loader.
RDXML000I nameversion Copyright 2005 Omnibond Systems, LLC. ID=code_id_string.
RDXML001I Client connection established.
RDXML002I Request issued to start Driver Shim.
RDXML003E An unrecognized command was issued. The driver shim is shutting down.
RDXML004I Client Disconnected.
RDXML005W Unable to establish client connection.
RDXML006E Error in Remote Loader Handshake.
RDXML007I Driver Shim has successfully started and is ready to process events.
RDXML008W Unable to establish client connection from remoteName.
RDXML009I Client connection established from remoteName.
Messages beginning with W3LM are issued by Web Services.
W3LM001I Object driverDN created by webUserDN.
W3LM002I Object driverDN deleted by webUserDN.
W3LM003I Event Listener eventListenerDN deleted by webUserDN.
W3LM004I Trawl Initiated by webUserDN.
W3LM007I Platform platformDN deleted by webUserDN.
W3LM008I Platform platformDN created by webUserDN.
W3LM009I Platform Set platformSetDN marked for deletion by webUserDN.
W3LM010I Platform Set platformSetDN created by webUserDN.
W3LM011I UID/GID Set UIDGIDSetDN marked for deletion by webUserDN.
W3LM012I UID/GID Set UIDGIDSetDN created by webUserDN.
W3LM013I SearchObject searchObjectDN created by webUserDN.
W3LM014I SearchObject searchObjectDN deleted by webUserDN.
W3LM015I Object objectDN modified by webUserDN.
W3LM016I Connection (default) netAddress attribute on object objectDN modified by webUserDN.
W3LM017I netAddress attribute on object objectDN modified by webUserDN.
W3LM018W Web Interface login Failure loginDN.
W3LM019I Successful Web Interface login by loginID.
W3LM020W Web Interface login attempt with invalid credentials.
W3LM021W Web Interface login attempt with invalid DN Syntax.
W3LM022W Web Interface login attempt for an unknown user.
W3LM023W Web Interface login attempt failure with an unknown error.
W3LM024E Check the Trawl Time-Out value and re-enter.
This section describes updates to this document since its original release date of June 22, 2012.
Location |
Update Description |
---|---|
Listed Changes and Enhancements to 4.0.2b release |
|
Section 5.2.1, Installing the Driver Shim on Linux or Solaris |
Added note to step 7 about existing Fan-Out installation location |
NetIQ Identity Manager 4.5 Integration Module for Linux* and UNIX* Readme at the Identity Manager 4.5 Drivers Documentation Site |
Updated Supported Versions list |
Location |
Update Description |
---|---|
Added procedure for Core Driver Shim Auto-Start. |
Account Redirection
The process of ensuring that users and groups are the same across all platforms by redirecting account information requests to a User or Group object in eDirectory™.
AS Client API
The Authentication Services application programming interface (API). The AS Client API can be used by applications to perform functions, such as user ID/password verification, password changes, and obtaining information from eDirectory.
ASAM Directory
The file system directory that contains the binaries, configuration information, and other related files used by Identity Manager Fan-Out Driver components.
ASAM Master User Object
The User object that Core Driver components use for LDAP Bind operations.
ASAM System Container Object
The container object in eDirectory that holds component configuration and user and group management objects.
Audit Log
The log of occurrences of interest for auditing purposes. The Audit Log is maintained by the Audit Services component of each Core Driver.
Audit Services
The Core Driver component that performs logging.
Authentication Services
The set of services that provides access to information from eDirectory for authentication purposes. The principal components of Authentication Services are the Core Driver Authentication Services component, the Platform Services Process, the AS Client API, and the System Intercept.
Census
The collection of Enterprise User and Enterprise Group objects that represent users and groups from eDirectory that can be associated with a Platform Set. Object Services maintains the Census using provisioning events. Object Services on the primary Core Driver initially builds and periodically verifies the Census through the use of Trawls.
Census Search Object
An eDirectory object used to specify users and groups to be included in the Census.
Certificate
A digital object used to authenticate and secure SSL communications.
Certificate Services
The Core Driver component that issues certificates for other components.
Context
The location of an object within the eDirectory tree.
Core Driver
The components that provide Identity Provisioning and Authentication Services to platforms, and provide for the management of the Identity Manager Fan-Out Driver.
DES
Data Encryption Standard, approved by the U.S. government.
Enterprise Group (eGroup)
An object that represents a group of users that can be defined on a platform. Enterprise Group objects reside in the Census container.
Enterprise User (eUser)
An object that represents a user that can be defined on a platform. It is used by Authentication Services to locate the corresponding User object in eDirectory. Enterprise User objects reside in the Census container.
Entropy Daemon
A process that collects and provides cryptographically strong random data.
Event Driven Objects
A container in the ASAM System container that holds objects affected by provisioning events.
Event Journal Services
The Core Driver component that manages event information and provides provisioning events to Platform Receivers.
Event Subsystem
The Core Driver component that receives provisioning events from eDirectory and provides them to Object Services.
Identity Provisioning
The automatic provisioning of account related information from eDirectory to a target platform. The principal components of Identity Provisioning are the Event Subsystem, Object Services, Event Journal Services, Platform Receivers, and Receiver scripts.
Name Service Switch
A library for Linux and UNIX operating systems that implements a set of system functions used by programs to retrieve user and group account information. The Fan-Out Driver provides a Name Service Switch that allows a Linux or UNIX system to redirect account information from eDirectory.
Naming Exception
A conflict detected by Object Services between multiple User or Group objects having the same common name.
Object Services
The Core Driver component that maintains the Census.
Operational Log
A log of occurrences pertaining to the processing of a component. Audit Services maintains the Operational Log for the Core Driver.
PAM
Pluggable Authentication Module. PAM is a standard framework for UNIX defined by OSF RFC 86.0 that provides for authentication of users by facilities external to the original UNIX operating system.
Password Redirection
The process of ensuring that users' passwords are the same across all platforms by redirecting authentication requests to a User object in eDirectory.
Password Replication
The process of ensuring that users' passwords are the same across all platforms by replicating password information between the platforms and eDirectory.
Platform
A system that uses the Core Driver for Identity Provisioning, Authentication Services, or both.
Platform Configuration File
The file that contains configuration information for Platform Services. It identifies users to include or exclude from processing, and contains information used to locate the Core Driver servers.
Platform Object
The object in the ASAM System container that contains information about a platform.
Platform Receiver
The Platform Services component that obtains provisioning events from Event Journal Services and runs Receiver scripts to process them as appropriate for the platform.
Platform Services
The Identity Manager Fan-Out Driver components that run on a platform. These include the System Intercept, the Platform Services Process, the AS Client API, the Platform Receiver, and Receiver scripts.
Platform Services Cache Daemon
The process that runs on a platform and communicates with the Core Driver for Posix account information. Along with the Name Service Switch, the Platform Service Cache Daemon provides complete account redirection.
Platform Services Process
The process that runs on a platform and communicates with the Core Driver for Authentication Services. The Platform Services Process provides Core Driver server connection management, load balancing, and failover capability.
Platform Set
A group of platforms that share a common set of users and groups.
Platform Set Search Object
An eDirectory object used to specify users and groups to be included in a Platform Set.
Primary Core Driver
The Core Driver that serves the Web interface, provides environmental information during the installation of other Core Drivers, performs Census Trawls, and listens for events from eDirectory.
Provisioning Event
An event, such as an add, modify, or delete, originating from eDirectory, that pertains to a user account or group. The Event Subsystem subscribes to events from eDirectory and passes them to Object Services. Object Services records provisioning events in eUser and eGroup objects. Event Journal Services passes the events to Platform Receivers. Platform Receivers run Receiver scripts to process provisioning events as appropriate for the platform.
Provisioning Manager
The Core Driver component that comprises Object Services, Audit Services, Certificate Services, Event Journal Services, and Web Services. Platforms access the Provisioning Manager to obtain a security certificate and to obtain provisioning events.
Receiver Script
A script invoked by the Platform Receiver to process provisioning events. A fully functional set of base scripts, written in the customary scripting language for the platform, is provided. You can extend these scripts as appropriate for your needs.
Secondary Core Driver
Any Core Driver other than the primary Core Driver.
Secure Sockets Layer (SSL)
The communications protocol used for communication between components. SSL is a standard security protocol that provides communications privacy. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.
System Intercept
A vendor-provided control point into the system that is used to interface with Authentication Services for a platform.
System Log
The operating system log of information that is of system-wide interest.
Trawl
The process used by Object Services to collect information from eDirectory to initially build and periodically ensure the validity of the Census.
Universal Time
By international agreement, the world-wide standard for systematic time keeping. Universal Time is based on the mean solar time at zero degrees longitude. Formerly known as GMT, Universal Time is abbreviated as Z or as UT.
User and Group Subtree
The high level container object that you specify during installation of the Core Driver that holds users and groups that can be included in the Census. The ASAM Master User is granted Supervisor rights to this container.
Web Application
The Web-based application that is used to administer and monitor the Identity Manager Fan-Out Driver. The application is accessed as a plug-in to the iManager interface.
Web Services
The Core Driver component that provides the Web interface.
This section describes updates to this document since its original release date of October 28, 2014.
Location |
Update |
---|---|
Added Section 6.7. |
THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, NETIQ CORPORATION PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU.
For purposes of clarity, any module, adapter or other similar material ("Module") is licensed under the terms and conditions of the End User License Agreement for the applicable version of the NetIQ product or software to which it relates or interoperates with, and by accessing, copying or using a Module you agree to be bound by such terms. If you do not agree to the terms of the End User License Agreement you are not authorized to use, access or copy a Module and you must destroy all copies of the Module and contact NetIQ for further instructions.
This document and the software described in this document may not be lent, sold, or given away without the prior written permission of NetIQ Corporation and Omnibond Systems, LLC., except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of NetIQ Corporation and Omnibond Systems, LLC.. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data.
This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. NetIQ Corporation and Omnibond Systems, LLC. may make improvements in or changes to the software described in this document at any time.
U.S. Government Restricted Rights: If the software and documentation are being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), in accordance with 48 C.F.R. 227.7202-4 (for Department of Defense (DOD) acquisitions) and 48 C.F.R. 2.101 and 12.212 (for non-DOD acquisitions), the government’s rights in the software and documentation, including its rights to use, modify, reproduce, release, perform, display or disclose the software or documentation, will be subject in all respects to the commercial license rights and restrictions provided in the license agreement.
© 2015 Omnibond Systems, LLC. All Rights Reserved. Licensed to NetIQ Corporation. Portions copyright © 2015 NetIQ Corporation. All Rights Reserved.
For information about NetIQ trademarks, see https://www.netiq.com/company/legal/.
For NetIQ trademarks, see the NetIQ Trademark and Service Mark list.