The APSExpire section of the APS configuration file controls the operation of APSExpire.
A site defines jobs by name. Each setting is the name of a job and the values define the criteria for the job. When APSExpire executes, a job name must be specified. The program will look for the definition of this job in this section of the file.
Each job defines a user directory or subset of a user directory. The syntax for ODBC and LDAP directories are different.
For LDAP directories, jobs are defined using this syntax:
<job name>= <LDAP directory> READ(<ip>) BASE(<base DN>) SCOPE(<scope>) FILTER(<filter>)
<job name> is an arbitrary name for the job.
<ip of LDAP directory> is the ip address, the network name, or the SiteMinder User Directory name of an LDAP directory defined to SiteMinder through the Policy Interface (it cannot contain spaces if used here). If it is an ip address, it may contain the port address as well. This must match up with the definition of a User Directory in the SiteMinder Policy Store (APSExpire will attempt to look up the directory using this value).
READ(<ip>) is an optional clause that tells APSExpire to read from a different directory than the base directory. In some cases, much higher performance can be achieved by reading from a dedicated replicant directory that either SiteMinder does not use at all or is the last directory in a failover chain. If specified, however, the alternate directory must be a replicant of the "real" directory.
BASE(<search Base>) is optional and defines the scope of the search. If it is not specified, APSExpire searchs the entire directory using the search base defined in the SiteMinder User directory entry. This is useful when an entire LDAP directory is not to be processed as a single job. Sites do this when the LDAP directory is very large and APSExpire processing is to be spread over multiple servers or jobs.
SCOPE(<scope>) is optional and is generally used with the BASE option above. <scope> can either be base or sub. It specifies how the LDAP search should be processed.
FILTER(<extra filter>) is another optional setting that allows a site to further refine a job. This filter is ANDed with any filters that APSExpire uses for its own operations. Once again, this is intended to segregate an LDAP directory into smaller jobs for performance reasons.
When using BASE, SCOPE and FILTER, it is the responsibility of the site to make sure that every user will be processed. APSExpire does not examine the sum of all defined jobs to ensure that all users get processed.
For ODBC directories, jobs are defined using this syntax:
<job name>= <ODBC directory> WHERE(<extra WHERE clause>)
<job name> is an arbitrary name for the job.
<ODBC directory> is the DSN name or the SiteMinder User Directory name of an ODBC user directory (neither can have embedded spaces in this context) defined to SiteMinder through the Policy Interface. This must match up with the definition of a User Directory in the SiteMinder Policy Store (APSExpire will attempt to look up the directory using this value).
WHERE(<extra WHERE clause>) is another optional setting that allows a site to further refine a job. This clause is ANDed with any WHERE clause that APSExpire uses for its own operations. This is intended to segregate an ODBC directory into smaller jobs for performance purposes.
When using WHERE, it is the responsibility of the site to make sure that every user will be processed. APSExpire does not examine the sum of all defined jobs to ensure that all users get processed.
Each User Directory should be processed by APSExpire on a periodic basis, preferably daily, even if the special processing for the events is not desired. This ensures that new user records will be initialized properly.
APSExpire must run on the Policy Server machine.
The time that it takes to process a single user is relatively fixed (though based on the platform). However, the time required to find users to process is a function of the size of the directory. It may be obvious, but it must be said: Larger directories will take more time to process than smaller directories.
At APS Version 4.0, APSExpire was completely redesigned to handle larger User Directories. The amount of time required to process each user could not be reduced significantly (in fact, other required enhancement increased the per-user time slightly). However, the change to use smapsNextAction has significantly improved performance for locating users to be processed (which, prior to Version 4.0, was where APSExpire spent most of its time).
The use of smapsNextAction, however, introduced the restrictions presented earlier in this chapter. The performance improvement was so dramatic that the restrictions were deemed acceptable.
In an additional performance-enhancing effort, APSExpire jobs need not define an entire User Directory; they can define a subset of a directory. In this way, a site can load-balance multiple APSExpire executions across multiple Policy Servers and/or spread the processing over a period of time.
When dividing a User Directory into subsets, it is the responsibility of the site to ensure that all users are covered. For example, it would be an error (undetected by APS) to create two jobs, one to handle users whose last names start with the letters "A" through "M" and another job for user names starting with "O" through "Z", since users whose names start with "N" would never be processed.
|
Copyright © 2014 CA.
All rights reserved.
|
|