This chapter details how APS interfaces with each type of User Directory. This includes information about how APS stores its information within the directory, what "native" capabilities of the directory are supported (if any) and what APS features are not supported by specific User Directories.
General schema information is presented first, followed by details for each User Directory type.
This section contains the following topics:
Forgotten Password Services (FPS) Data
Password Replication/Synchronization
This section lists every attribute maintained and used directly by APS. APS assumes that all attributes exist and processing will fail if an attribute does not exist. Except for encrypted fields and those otherwise noted, your site can change the values of these attributes. However, you must take care to format the information in the attribute correctly so that APS can read it. For performance reasons, APS has little format verification.
Note that the fields used to handle FPS verification (such as secret questions) are not maintained by APS at all; they are compared by FPS and, in some cases updated (as in the control data). However, the field names and contents are entirely defined by the site and actually maintained by the site's user management tools, not APS.
The attributes listed in this section are in alphabetical order.
All dates and times are in Greenwich (ZULU) time zone. This eliminates all complications of multiple policy/web servers in different time zones and daylight savings time. These values are stored in the format:
yyyymmddhhmmssZ
For example,
20010307164130Z
is Wednesday, March 7, 2001 at 11:41:30am Eastern time.
The Attribute/Column names used in this chapter can be changed on a per-site (or even per-directory server) basis. The names used here are the names that APS will use internally. If not remapped, APS will also use these names externally. To rename an attribute/column, use the [MAPPING] section of the APS.cfg file.
Some fields are suppressible, meaning that an entry can exist in the [MAPPING] section to map the field to a null name. In this case, APS will not store or use a value for that field. If an attribute is not suppressible, but a mapping to a null value exists in APS.cfg, the internal name of the attribute will be used. This will probably result in an error.
Note: Between APS Version 3 and Version 4, one attribute (smapsInactivityWarning) was dropped from use and a new attribute (smapsNextAction) was added. smapsOldBlob is also no longer used, except for sites upgrading from versions of APS prior to version 3.0.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.2
RDBMS Type: character
Max Length: 24 (see note)
suppressible: Yes
Format: <integer> <reason>
Examples: 0 Admin account
7 Wire Room Op
365
This attribute is used to override, on a per-user basis, the amount of time that can elapse between this user's logins before the user is disabled due to inactivity. As a general rule, this value should not be used; it is intended for a small number of users.
The first part of the value must be the number of days to use. The rest of the field is ignored and can be used to store any information (for example, why the override is there, who put it there, etc.).
Setting this value to zero tells APS that this user is never disabled due to inactivity, even if this conflicts with settings in the APS.cfg file.
If this field is null or contains no value, then the settings in the APS.cfg file will be used.
APS never writes to this field, except as part of APSAdmin.
Note on length: This field contains a number, followed by a comment, thus the length is truly variable. APSAdmin allows 3 characters for the integer value, a space, and up to 20 characters of user-entered comment. If your site has a custom interface to this field, you may want to make this field longer. APS itself, outside of APSAdmin, never updates this field.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.3
RDBMS Type: character
Max Length: 36 (see note)
suppressible: No
Format: <date/time> <reason>
Examples: 20010307164130Z Conversion
This is, essentially, the creation date of the user. It is used as the base date for all calculations if smapsLastPasswordChange or smapsLastLogin are not set or if this date is later. If not set, the current date/time is used. APSExpire will initialize this field, if necessary.
User creation utilities should set this value, but it is not required, since APSExpire will set it the next time that utility is run and APS will initialize a null value when the user authenticates.
If this field is later than smapsLastPasswordChange or smapsLastLogin, this field's value will be used instead. The reason for this is best demonstrated by an example: smapsLastLogin is used to calculate when an account expires. If a user's account has expired and the user is disabled, the user will immediately be expired again at next login, since smapsLastLogin is still too old. The old solution was to reset smapsLastLogin, but that caused the "real" date of last login to be lost. Instead, sites may reset this date instead in these cases (and in the similar case of password expiration).
Note on length: This field contains a date, followed by a comment, thus the length is truly variable. APSAdmin allows 15 characters for the date value, a space, and up to 20 characters of user-entered comment. If your site has a custom interface to this field, you may want to make this field longer. APS only writes the date/time (without a comment) to this field when it is initialized.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.4
RDBMS Type: character
Max Length: 36 (see note)
suppressible: Yes
Format: <date/time> <reason>
Examples: 20010601000000Z End of semester
20010601000000Z End of subscription
APS will not allow users to login after this date/time, regardless of activity. APS will not cancel an existing session when this time arrives, it will only prevent authentication after the specified date/time.
Sites may use this field freely. APS will never set or modify this value, but it will honor it if the date is readable. The <reason> is not used by APS, but may be passed to event redirection pages as the value of the DISABLEDREASON macro.
This field may need to be cleared to enable a user to authenticate.
Note on length: This field contains a date, followed by a comment, thus the length is truly variable. APSAdmin allows 15 characters for the date value, a space, and up to 20 characters of user-entered comment. If your site has a custom interface to this field, you may want to make this field longer.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.5
RDBMS Type: character
Max Length: 36 (see note)
suppressible: Yes
Format: <date/time> <reason>
FOREVER <reason>
Examples: 20010207164130Z Failure Count
FOREVER Failure Count
APS will not allow users to login until this date/time, regardless of whether the user successfully authenticates. APS uses this field to implement the Auto Reset Failure Count functionality.
If the Use Internal Disables is in effect for LDAP directories, APS will use this field to disable users and will use the word FOREVER instead of a date. For ODBC (RDBMS) directories, APS will always use this field for this purpose (regardless of the Use Internal Disables setting).
Sites may use this field freely. The reason is not used by APS, but may be passed to event redirection pages as the value of the DISABLEDREASON macro.
This field may need to be cleared to enable a user to authenticate.
Note on length: This field contains a date, followed by a comment, thus the length is truly variable. APSAdmin allows 15 characters for the date value, a space, and up to 20 characters of user-entered comment. If your site has a custom interface to this field, you may want to make this field longer. APS can write to this field, but never more than 36 characters.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.6
RDBMS Type: character
Max Length: 24 (see note)
suppressible: Yes
Format: <integer> <reason>
Examples: 0 Administrator
7 Wire Room Op
365
This attribute is used to override, on a per-user basis, the expiration period of a user's password. The performance impact of this value is nominal. As a general rule, it should not be used, since it creates maintenance overhead and thus can be an administrative nightmare.
The first part of the value must be the number of days to use. The rest of the field is ignored and can be used to store any information (for example, why the override is there, who put it there, etc.).
If the integer value is set to zero, then the user's password will never expire.
If this field is null or contains no value, then the settings in the APS.cfg file will be used.
APS never writes to this field, except as part of APSAdmin.
Note on length: This field contains a number, followed by a comment, thus the length is truly variable. APSAdmin allows 3 characters for the integer value, a space, and up to 20 characters of user-entered comment. If your site has a custom interface to this field, you may want to make this field longer. APS never writes to this field.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.7
RDBMS Type: character
Max Length: 24
suppressible: No
Format: <integer> <date/time>
Examples: 0 20010307170000Z
2 20010307173022Z
This attribute is used by APS to track the current authentication failure count. When reset, this field should not cleared; it must be set to zero with a date and time. This is required because APS also keeps this value in memory so that a server outage will not open a security hole. APS will read the value from disk and compare the date/time against its in-memory value. The later value will be used.
The first part of the value is the counter, which is followed by the effective date of the most recent failure (or reset).
Note that just setting a value into this field is insufficient to disable a user (at the next login), since if the date/time is over Failure Count Timeout minutes old, the user will not be disabled.
This field may need to be updated to enable a user account.
LDAP Type: cis/Single Values
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.8
RDBMS Type: character
Max Length: 56 (see note)
suppressible: Yes
Format: <integer> <date/time> <IP address> <reason>
Examples: 2 20010307170000Z 192.158.7.10 SiteMinder
This attribute is maintained by APS and is informational only. The <integer> component is the number of failed logins since smapsLastLogin (or smapsBaseDate, if the user has never logged in).
The <date/time> is when the most recent failure actually occurred.
The <IP address> is the reported tcp/IP address of the client. Note that this value is not trustworthy due to network address translation and spoofing.
The <reason> is why the login was rejected (if known).
APS copies the current value of this attribute to smapsFailuresSincePreviousLogin when the user successfully authenticates and then clears this attribute.
This value may be significantly different than smapsFailureCount, since the failure count times out and only includes password rejections. This is the actual total and includes all types of failures.
Note that if your site wishes to display failure count information on a user's screen, you should use smapsFailuresSincePreviousLogin, since the user just logged in and this value has been cleared.
Note on length: This field contains a number, followed by a comment, thus the length is truly variable. APSAdmin allows 3 characters for the integer value, a space, 15 characters for the date, another space, 15 characters for the IP address, yet another space and up to 20 characters of comment. If your site has a custom interface to this field, you may want to make this field longer.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.9
RDBMS Type: character
Max Length: 56 (see note)
suppressible: Yes
Format: <integer> <date/time> <IP address> <reason>
Examples: 2 20010307170000Z 192.158.7.10 SiteMinder
This attribute is maintained by APS and is informational only. This information is copied from smapsFailuresSinceLastLogin when the user successfully authenticates.
Note that if your site wishes to display failure count information on a user's screen, you should use smapsFailuresSincePreviousLogin, since the user just logged in and the other value has been cleared.
Note on length: This field contains a number, followed by a comment, thus the length is truly variable. APSAdmin allows 3 characters for the integer value, a space, 15 characters for the date, another space, 15 characters for the IP address, yet another space and up to 20 characters of comment. If your site has a custom interface to this field, you may want to make this field longer.
LDAP Type: cis/Multi-Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.10
RDBMS Type: character
Max Length: As long as possible (see note)
suppressible: Yes
Format: <key>=<integer> <date> <IP address>
Examples: LICENSE =1 20010307144130Z 10.2.2.1
PROFILE=2 20010307144633Z 10.2.2.1
This attribute is used to store information about Generational Redirect. If generational redirects are not used, this attribute can be omitted from the schema.
Each element (this is a multi-valued attribute under LDAP) tracks the last version of a page that the user was redirected to, when and what the IP address of the browser was (the IP address is not reliable).
Note on length: Under ODBC (RDBMS) directories, this is stored as a single-value, each "element" separated from others using a semicolon (";"). The length of each element can vary, since the length of the <key> name is essentially unlimited and the length of the <integer> value can vary greatly. The total length of this field can be calculated by a site, but if new generational redirects are added, additional space will have to be provided. Thus, a site should plan this length carefully.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.11
RDBMS Type: character
Max Length: 35
suppressible: Yes
Format: <integer> <date/time> <IP address>
Examples: 2 20010307170000Z 192.158.7.10
APS uses this attribute to track the number of grace logins that the user has consumed since his/her password expired. The <date/time> and <IP address> are informational only. If the user changes their password, this value is reset to blank/null.
If grace logins are not used, then this attribute can be safely omitted from the schema.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.12
RDBMS Type: character
Max Length: 25KB
suppressible: Yes
Format: <encrypted>
The user's password history is stored in this attribute. APS will maintain this value. This value should never be modified, except by APS.
APS will only keep about 12KB worth of history, but limit is imposed before encryption. Encryption effectively doubles the length, so a site should provide storage for up to 25KB characters of data.
Since the information is encrypted, it is impossible to just truncate it; it must be stored in its entirety. Truncating the data may cause server failures.
To reserve the full amount of storage in an ODBC directory for every user row may be unreasonable. What many sites do is set the length of this column to some smaller value (for example 2k), then run triggers within the database to alert administrators when a certain percentage of this space starts to get used (say 90% - the field grows very slowly, usually less than 100 bytes per password change). If a single test user starts to consume too much, approaching the maximum length defined, the site clears the value for that one account. If multiple users start to approach the value, either determined by triggers or by periodic examination of the data, the column is enlarged.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.13
RDBMS Type: character
Max Length: 30 (see note)
suppressible: Yes
Format: <any non-blank value>
Examples: Initial Load
If this attribute is non-blank, APS will force the user to change their password the next time that the user logs in (if redirection, etc., is also configured).
APS clears/nulls this attribute when the user actually changes their password.
If sites do not wish to use the immediate change functionality, this attribute may be safely omitted from the schema.
Note on length: When set, this field contains any text comment, thus the length is truly variable. APSAdmin allows up to 30 characters of comment. If your site has a custom interface to this field, you may want to make this field longer.
This field is no longer used by APS and it may safely be removed from existing schemas.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.15
RDBMS Type: character
Max Length: 32
suppressible: No
Format: <date/time> <IP address>
Examples: 20010307175245Z 192.168.42.10
This attribute holds the most recent login date and time (and IP address, if available, though it is not reliable).
Sites should not modify this value. It is used for inactivity calculations.
This field is required for proper APS operation.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.16
RDBMS Type: character
Max Length: 128 (see note)
suppressible: No
Format: <date/time> <comment>
Examples: 20010307175245Z APS Interface
This attribute holds the date and time that the user's password last changed, if known. APS will update this field when the password is changed using any APS interface. It is up to the site to update this field if the password is changed in any other way.
This value is used for password expiration calculations and is required for APS operation.
Note on length: This field contains a date, followed by a comment, thus the length is truly variable. APSAdmin can set this to 15 characters for the date, a space, and the full length of the administrator's DN plus 12 characters. Thus, this field needs to accommodate the largest DN of your site. If your site has a custom interface to this field, you may want to make this field even longer.
LDAP Type: cis/Multi-valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.17
RDBMS Type: special, see description
suppressible: Yes
Format: <date/time> <result> <IP address> <comment>
Examples: 20010307175245Z SUCCESS 10.2.3.2
20010307175245Z FAILED 10.2.3.2 SiteMinder
APS uses this attribute to track all authentication activity for this user since the smapsPreviousLogin date. This includes both successes and failures.
This data is informational only. APS does not use it for anything.
In ODBC (RDBMS) directories, this information is kept in a separate table. This table should contain 2 columns: one to store the user's id and another to store the log entry. The names of the fields are discussed in the section on ODBC queries later in this chapter. The maximum length of the Log Entry column is about 60 characters (15 for date, a space, 7 for status, a space, 15 for the IP address, another space, and a comment).
If this field is suppressed, no authentication history will be kept. To suppress its use, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.18
RDBMS Type: character
Max Length: 60 (see note)
suppressible: Yes
Format: <integer> <date/time> <IP address> <reason>
Examples: 12 20010307170000Z 192.158.7.10 SiteMinder
This attribute is maintained by APS and is informational only. This information is identical to the information maintained in smapsFailuresSinceLastLogin except that it contains the highest value that the account ever reached.
If this field is suppressed, no such information will be kept. To suppress its use, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
Note on length: This field contains a number, followed by a comment, thus the length is truly variable. APSAdmin allows 3 characters for the integer value, a space, 15 characters for the date, another space, 15 characters for the IP address, yet another space and up to 20 characters of comment. If your site has a custom interface to this field, you may want to make this field longer.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.19
RDBMS Type: character
Max Length: 36 (see note)
suppressible: Yes
Format: <date/time> <reason>
Examples: 20010307171211Z Forgotten Password
20010307171211Z Admin Reset
If set, if the user fails to login by the specified date and time, the authentication attempt will be rejected. If the user successfully authenticates before this date/time, APS will clear the value.
If the writable directory server is down when the user authenticates, APS will be unable to clear this attribute and the user may not be able to login at a later date.
APS will never set this field, but it will clear it upon a successful authentication prior to the specified date/time.
This field may need to be cleared to enable a user account.
Note on length: This field contains a date, followed by a comment, thus the length is truly variable. APSAdmin allows 15 characters for the date value, a space, and up to 20 characters of user-entered comment. If your site has a custom interface to this field, you may want to make this field longer.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.20
RDBMS Type: character
Max Length: 45
suppressible: No
Format: <date/time> <reason>
Examples: 20010307171211Z ACCOUNT INACTIVITY EXPIRE
20010307171211Z ACCOUNT PURGE
This field is used by APSExpire to trigger activity for the account. It is only concerned with the date/time value; the reason is ignored.
APS will update (or at least check for updates to) this field every time that it modifies any value in the user's entry.
APSExpire will process any entries that have a null value for this field, so if a site performs maintenance on a record that may change this value, it should null out the field so that APSExpire will process this account.
This field is required for APS operation and may not be omitted.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.21
RDBMS Type: not used
suppressible: Yes
Format: <32-bit checksum>
Examples: 2165
This attribute is only used by sites that have converted from a pre-version 3.0 release of APS and, even then, only for a short period of time, in order to detect old copies of APS utilities at their site.
This attribute is not used or needed in any other case.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.22
RDBMS Type: not used
suppressible: Yes
Format: <encrypted>
Note: This description applies to LDAP directories only. ODBC (RDBMS) directories uses a stored procedure to obtain the functionality described (the stored procedure will probably need a column to store its data). See the ODBC Queries section later in this chapter).
When a user changes their own password, APS will attempt to read back the password (after it has been changed) to obtain the hashed value that the Directory has stored and store it back into this attribute.
If the Auto Force Change setting is in effect, APS will compare this value with the value stored in the user's password attribute. If they differ, APS assumes that the user's password changed using an interface other than one provided by APS and the user will be forced to change their password.
Note that this functionality requires that users have the right to read their own password back and that the administrator credentials specified in the SiteMinder User Directory also have this ability. If not, then APS cannot read the current value of the user's password. Some LDAP implementations (such as Microsoft Active Directory) will not allow the hashed value to be read back in any case.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.23
RDBMS Type: character
Max Length: 32
suppressible: Yes
Format: <date/time> <IP address>
Examples: 20010307175245Z 192.168.42.10
This attribute holds the login date and time prior to the current login date and time (and IP address, if available, though it is not reliable).
If the last login date is to be displayed on user screens, this value should be used rather than smapsLastLogin, since that value will reflect the current login date and time.
Sites should not modify this value. It is informational only. APS does not use this value for any reason.
If this field is suppressed, no such information will be kept. To suppress its use, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.24
RDBMS Type: character
Max Length: 9
suppressible: Yes
Format: <number>
Examples: 12
This attribute is informational only. APS will maintain it, but does not use it for any calculations.
This attribute contains the total number of failed logins (for any reason) for this user. It is often displayed on Help Desk panels to give the administrator an idea of the level and pattern of usage for the particular user record.
Sites should not modify this value.
If this field is suppressed, no such information will be kept. To suppress its use, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.25
RDBMS Type: character
Max Length: 9
suppressible: Yes
Format: <number>
Examples: 25
This attribute is informational only. APS will maintain it, but does not use it for any calculations.
This attribute contains the total number of successful logins for this user. It is often displayed on Help Desk panels to give the administrator an idea of the level and pattern of usage for the particular user record. In other words, a support desk operator can differentiate, using the value in this field, between a new user, an occaisional user, or a user that authenticates to the site on a regular basis.
Sites should not modify this value.
If this field is suppressed, no such information will be kept. To suppress its use, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.26
RDBMS Type: character
Max Length: 5
suppressible: Yes
Format: <number>
Examples: 2
This attribute is used by the Forgotten Password Services component of APS to track the number of failed attempts (for lockout purposes).
Sites should not modify this value.
This field can be completely omitted if FPS is not used by a site.
If this field is to be suppressed at a site using FPS, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
LDAP Type: cis/Multi-valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.27
RDBMS Type: special, see description
suppressible: Yes
Format: <date/time> <comment>
Examples: 20010401173244Z Requesting verification
This attribute is used by the Forgotten Password Services component of APS to record the use of FPS. It is used by FPS to track successful and failed uses of FPS in order to enforce the Max Success Frequency and Max Attempts Frequency settings.
In ODBC (RDBMS) directories, this information is kept in a separate table. This table should contain 2 columns: one to store the user's id and another to store the log entry. The names of the fields are discussed in the section on ODBC queries later in this chapter. The maximum length of the Log Entry column is about 60 characters (15 for date, a space, and a comment).
Sites should not modify this value.
This field can be completely omitted if FPS is not used by a site.
If this field is to be suppressed at a site using FPS, be sure to specify this attribute in the [MAPPINGS] section of the APS.cfg file.
LDAP Type: cis/Single Valued
LDAP OID: 1.3.6.1.4.1.2552.1.1.9.28
RDBMS Type: character
Max Length: 72
suppressible: Yes
Format: <encrypted>
If the OneShotPassword capability ( Unsupported "Page" Cross-Reference) of FPS is to be used, APS uses this attribute to store encrypted information about this use. This value will be cleared when used, but there is no security problem if it is retained.
The maximum length refers to the amount of space required to store a 32 character encrypted password.
Sites should not modify this value.
This field can be completely omitted if FPS is not used by a site or the OneShotPassword capability is not in use.
The section above describes the attributes that "belong" to APS; that is, the fields that APS needs and maintains for its own purposes or for auditing purposes.
The Forgotten Password Services (FPS) component of APS allows users to change (or recover) their password without knowing their old password. This is done by requiring the user to enter information, usually the answers to a series of questions, and matching that information with data stored in the user record.
Unlike the above attributes, the information used in the FPS process does not "belong" to APS and is not maintained by it. The FPS process merely uses this information in the way that it is configured to do so. APS/FPS does not care what this information is, it merely needs to know the attribute names and the format (in some cases) in which it is stored.
There are three FPS-related attributes described in the previous section. Those attributes are used for control purposes and are not end-user visible, nor are they typically modified by a site outside of the FPS process. This section talks about the fields/attributes that are used by the FPS process to interact with the user.
This information is defined and maintained by whatever user management tools used by the site. APS/FPS generally does not do anything with this data except to match it up against user input (with the possible exception of certain control information used internally by APS, described later).
Most of the FPS configuration process involves the mapping of input fields (from the input forms) to the user attributes and describes how the comparison is performed. For example, the configuration might indicate that an input field called "FirstName" is compared, case-insentively, to a attribute called "givenname". This comparison is generally performed during the "Identify" phase of the FPS process in order to figure out who the user is.
The second (optional, but commonly used) phase of the FPS process involves verification; the attempt by the user to prove that they are who they say they are. This is typically done by presenting the user with one or more questions, gathering the user's answers, then comparing those answers with the ones stored in the user record.
APS does not provide any mechanism for storing these questions in the user record, for updating it, or even for displaying it. This should all be part of the User Management Application. While APS does not require specific names for such attributes, it does need to understand how that information is stored so that it can perform its operations correctly.
The most trivial example involves a single question and answer. In these cases, two attributes can be used: a Question and an Answer. These attributes can be called anything the site wants to call them and are expected to contain character data. FPS is configured to pass whatever is in the Question attribute (the name of the attribute is identified in the APS.cfg file) to the Verify form and the posted data is compared to the data stored in the Answer attribute (also named in the APS.cfg file).
There is actually an even simpler case, where the question is fixed for the entire site, so only an answer is needed. This configuration is generally not recommended, since it is trivial to socially engineer an answer to break into the user account.
Most sites prefer to use the more complex case where a number of questions and their answers are stored in the user record, allowing FPS to select a subset of those questions for display. This is a much more complicated case.
The issue is not one of where the information is stored in the user record, it is an issue of how the information is formatted within the user record.
With multiple questions and answers, the answers must be tightly coupled with the question that they belong to; the two must be stored together, rather than in separate attributes (especially on LDAP directories, where the order in which multi-valued attributes are returned is not guaranteed).
Thus, FPS expects such data to contain a question and answer, stored together, separated by a "pipe" or "vertical bar" character ("|").
FPS will also select a subset of multiple questions. Because of this, FPS needs to "remember" which questions have already been asked and when they were asked. This information is updated by FPS and is associated with each question/answer pair by placing it in front of the question/answer pair and separating it with another pipe character.
Thus, a single question/answer should be stored in the form:
<control data>|<question>|<answer>
FPS does not care about the format of the question. Whatever is stored between tne two pipes will be passed to the verify page. That page can do whatever translations that it must in order to display the correct user question (challenge). Typically, this is not the actual text of the question (this is discussed in great detail elsewhere in this document). Usually, it is a code (in FPS parlance, a Question ID, or QID) that the Verify page uses to lookup the actual text of the question. This method accomplishes several things:
The control data portion of the data should be left blank at initialization (in other words, the entire field should just start with the pipe). FPS will write a date/time or the word DELETED into this area, depending on how it is configured.The answer is the text that FPS will match against the user input. This information is generally not encrypted, but can be, either using SmAPSEx or, in the case of ODBC directories, using stored procedures. The issue here is that the User Management Tool must be able to encrypt the information when it is stored in the user record, so both the User Management Tool and FPS must agree on the encryption scheme.
If the word DELETED appears, then this question has been asked and FPS is configured to consume questions. In these cases, FPS will never ask the question again. User Management Tools should keep such information in the user record and not allow the user to re-select the same question, because it has already been used. The question should remain in the user record to prevent the question from ever being selected again by the user.
If a date appears in the control field, it is important that the User Management Tool maintain this value, otherwise questions may not be selected correctly in the future.
The above discusses how each question/answer pair is stored in the user record. There is also an issue of how all of the question/answer pairs are stored together. FPS recognizes two different methods.
The name of the attribute used and the storage format is defined in the APS.cfg.
Note: APS does support Microsoft Active Directory and this support is provided using its LDAP interface. However, because Active Directory deviates so extensively from the LDAP specification, APS contains a significant amount of special processing and thus Active Directory is discussed in its own section.
Starting with Version 3.0, APS no longer stored its per-user information in a single LDAP attribute (the "Blob"); all information is stored in individual attributes. This section describes these attributes, the data that they are expected to contain (and the format) and how to set up your schema.
Sites converting from APS versions prior to version 3 should contact CA for a utility to convert their old style APS Blob to the new attributes.
There is no "standard" way to update an LDAP schema. Each vendor implements their own way to do it. In addition, most sites have policies or requirements for how schemas are updated, naming conventions and data layout issues.
APS tries to place as few restrictions as possible for the schema that it needs. The attributes must exist for every user entry in the User Directory that will be maintained by APS, with the exception of the attributes marked as optional and suppressed in the [MAPPINGS] section of the APS Configuration File.
How sites accomplish this is entirely up to the administrators at the site. There are a number of choices available; no tools are provided to do this for you (there are some sample files provided for iPlanet LDAP directories, however). CA Professional Services has considerable experience in this area and can help or advise you, if you so desire.
There are three steps required to ensure that the attributes exist for every user:
Attributes need not have the names defined above. If the attributes are to be renamed, the names must be remapped as described in the [MAPPINGS] section.
The LDAP RFI requires that each attribute have an OID (a globally unique identifier). Some implementations do not require this or build them automatically. Other implementations not only require an OID, but that it also conform to OID formatting standards. CA has obtained and assigned the following OIDs for this use (these are also listed in the Schema section above):
|
Schema Object |
OID |
|
smapsInfo (objectClass) |
1.3.6.1.4.1.2552.1.1.9.1 |
|
smapsAccountInactivityDays |
1.3.6.1.4.1.2552.1.1.9.2 |
|
smapsBaseDate |
1.3.6.1.4.1.2552.1.1.9.3 |
|
smapsDisableAfter |
1.3.6.1.4.1.2552.1.1.9.4 |
|
smapsDisableUntil |
1.3.6.1.4.1.2552.1.1.9.5 |
|
smapsExpirePasswordDays |
1.3.6.1.4.1.2552.1.1.9.6 |
|
smapsFailureCount |
1.3.6.1.4.1.2552.1.1.9.7 |
|
smapsFailuresSinceLastLogin |
1.3.6.1.4.1.2552.1.1.9.8 |
|
smapsFailuresSincePreviousLogin |
1.3.6.1.4.1.2552.1.1.9.9 |
|
smapsGenerationalRedirects |
1.3.6.1.4.1.2552.1.1.9.10 |
|
smapsGraceLoginsUsed |
1.3.6.1.4.1.2552.1.1.9.11 |
|
smapsHistory |
1.3.6.1.4.1.2552.1.1.9.12 |
|
smapsImmediateChange |
1.3.6.1.4.1.2552.1.1.9.13 |
|
smapsInactivityWarning |
1.3.6.1.4.1.2552.1.1.9.14 |
|
smapsLastLogin |
1.3.6.1.4.1.2552.1.1.9.15 |
|
smapsLastPasswordChange |
1.3.6.1.4.1.2552.1.1.9.16 |
|
smapsLoginHistory |
1.3.6.1.4.1.2552.1.1.9.17 |
|
smapsMaxFailures |
1.3.6.1.4.1.2552.1.1.9.18 |
|
smapsMustLoginBy |
1.3.6.1.4.1.2552.1.1.9.19 |
|
smapsNextAction |
1.3.6.1.4.1.2552.1.1.9.20 |
|
smapsOldBlob |
1.3.6.1.4.1.2552.1.1.9.21 |
|
smapsPassword |
1.3.6.1.4.1.2552.1.1.9.22 |
|
smapsPreviousLogin |
1.3.6.1.4.1.2552.1.1.9.23 |
|
smapsTotalFailures |
1.3.6.1.4.1.2552.1.1.9.24 |
|
smapsTotalLogins |
1.3.6.1.4.1.2552.1.1.9.25 |
|
smfpsLockoutCounter |
1.3.6.1.4.1.2552.1.1.9.26 |
|
smfpsLog |
1.3.6.1.4.1.2552.1.1.9.27 |
|
smfpsOneShot |
1.3.6.1.4.1.2552.1.1.9.28 |
The LDAP RFI requires that custom objectClasses have an OID (a globally unique identifier). Some implementations do not require this or build them automatically. Other implementations not only require an OID, but that it also conform to OID formatting standards. CA has obtained and assigned "1.3.6.1.4.1.2552.1.1.9.1" as the OID for the smapsInfo objectClass.
An attribute can appear in multiple objectClasses.
Note that the selection of where to put the attributes (described in the previous step) can have a considerable impact on this step. For example, if the attributes were added to a standard objectClass, this step is already done. If an existing custom objectClass was used, then this step may already be done. Using a new objectClass will require that this step be performed.
Also, consider new users. As new users get added to the User Directory, they will need to have access to the attributes as well, so the objectClass will need to be added to their list as well. This will probably impact any user management system implemented at the site.
Note: These steps only need to be performed on a single Master Directory. The changes will be propagated to other masters and consumers (though the changes will be recorded in subsidiary servers in the 99user.ldif file).
There is no special setup for standard LDAP User Directories.
There is no standard for LDAP native password policies. However, many vendors have implemented them using extended services (how extended services are accessed is defined in the LDAP standard, but the particular details of such extensions is vendor-specific).
Expiration policies are enforced by LDAP directories when the user attempts to authenticate to the directory. This authentication is actually performed by SiteMinder, before APS is invoked. Any failure, even if accompanied by extended information such as Password Expired, is seen by SiteMinder as an authentication failure and so reported to APS. Thus, APS is unable to support such policies.
Password content policies are enforced during the password change process. Most LDAP implementations will refuse a password change if it does not conform to a native password policy. However, this refusal is returned as a generic error code and (vendor-specific) extensions need to be used to determine the specific reason for the refusal. APS does not support native password content policies on standard LDAP user directories.
This second restriction is relatively easy to avoid. APS will apply its own password content policies before attempting to update the password in the underlying directory. If the APS content policy is at least as restrictive as the Directory's policy, then the password will already conform the the directory's rules. Bear in mind that this method cannot accommodate the password history restrictions.
Expiration policies are considerably more difficult to accommodate. Most sites simply turn off any native expiration policies and use SiteMinder (with APS) to perform all authentications. If LDAP is to be used directly by some applications, those applications should be modified to update APS' control information on every authentication.
If the user satisfies the conditions for any Ignore keyword in the APS.cfg file, APS will not perform any authentication time processing for this user, including detecting if the user is disabled or detecting disabling conditions (such as password expired).
APS will recognize that a user is disabled if any of the following are true (this is not necessarily the order in which APS actually does detection). Note that the Use Internal Disables setting does not affect detection, only how APS actually disables users.
The Disabled Reason is derived from the text following "DISABLED" in the group's name (any additional hyphen is removed).
This search cannot be suppressed.
The Disabled Reason is derived from the text following "DISABLED" in the group's name (any additional hyphen is removed).
This search can be suppressed by remapping "memberof" to a null value.
The account may become disabled (as described in the next section) during authentication, but this will set one of the above conditions.
APS itself can disable a user for only four reasons:
smapsDisabledUntil is set to the current date and time, plus the number of minutes indicated by the Max Failures On Change followed by the text "Failure Count".
APS never really enables an account itself. Some of the mechanisms used by APS to maintain the user status have built-in reset capabilities (dates). APS does not actually update a user record to re-enable it.
To re-enable an account, a site must ensure that all of the above criteria that APS uses to detect that a user account is already disabled are not true. In other words, the user account cannot be a member of a disabled group, smapsDisableUntil must be set correctly, etc.
Even then, it may appear that a user remains disabled. The usual cause is that while the user account does get enabled, the conditions that caused the account to become disabled remain, thus causing APS to just disable the account again. These reasons are:
For the most part, all APS features are supports by standard LDAP directories (of course, "standard" is the operative word).
The IsLDAP() function (used in settings overrides) returns TRUE if the current user is stored in an LDAP directory (of any type).
The LDAP Disabled Groups setting controls where APS will create any disabled groups within the directory, if the Use Internal Disables setting is not in effect.
The Check LDAP Password Existence and Auto Force Change settings may or may not be supported, depending on whether the implementation allows an LDAP client to read the (hashed) user password.
When APS was originally designed, LDAP supported groups in one way: what are now call forward groups.
A forward group is a group object, physically stored, that contains the DN of all of its members in a multi-valued attribute (usually uniqueMember).
Forward groups do not scale well. In order to provide more scalability, the LDAP standards committee defined reverse groups.
A reverse group is a group object, physically stored, whose DN is contained in its member's records (usually memberof or groups). In other words, each user contains a list of the groups of which it is a member in a multi-valued attribute. Reverse groups scale much better than forward groups.
APS supports forward groups by default, but can support reverse groups, if they are used at the site. It can also support a mix of forward and reverse groups.
You must tell APS which groups will be reverse groups (since there is no standard, quick, way to tell the difference). You configure this in the [Mappings] section of the APS Configuration File.
To have APS treat all LDAP groups as reverse groups, use:
LDAP.ReverseGroups=*
An asterisk should not be considered a wildcard. It can only be used in the above manner to indicate that all groups are reverse groups.
To specify a single group as a reverse group:
LDAP.ReverseGroups=cn=Disabled-NoCredit, o=nds.com
Multiple such lines can exist, one for each reverse group.
Note: Some LDAP vendors has also implement something that they call virtual groups. APS does not support virtual groups as of this writing, but, for most purposes, they can be easily simulated using override expressions or using the Disable setting.
All FPS functionality is supported for standard LDAP implementations, with the exception of question/answer encryption. This can still be accomplished, however, using the SmAPSEx library.
APSExpire has special settings for LDAP directories so that the user directory can be partitioned into smaller "chunks" for processing. See the chapter on Daily Processing (APSExpire), for details.
APSAdmin fully supports LDAP User Directories. However, APSAdmin only supports the entry of the full user DN on the user selection panel.
A considerable amount of work has gone into APS to optimize performance when dealing with LDAP directories.
APS reads the entire user entry into memory before handling any request. This means that all settings overrides and attribute references required by email templates canbe handled without another request to the directory server. The additional overhead of this single read is nominal, the performance of the read is the lookup and network latency, not the actual data transfer.
When writing to the directory, APS "gangs" all of the updates into a single request to the directory server. This is a huge performance gain. While suppressing individual attributes can improve storage resource utilization (disk space), it has little impact on the update performance; the performance overhead for the entire update far outweighs the incremental performance cost of additional fields (as long as the updates are submitted together).
A side-effect of the ganged updates is improved fault tolerance. LDAP guarantees that all writes submitted as a single request either succeed or fail together. No single field will be updated without the others.
What this means, for example, is that the password cannot be updated without the password change date attribute. They either both update or neither updates.
In a multi-mastering situation, this is even more critical. Parts of the update cannot go to each of two servers. All of the updates will be posted to the same place at the same time.
APS does not use SiteMinder's Enhanced Referrals. It does not keep pools of LDAP handles, pinging them periodically to determine connection health and to keep the connections from timing out. It does use SiteMinder handles for reading (and, in some cases, writing) to the directory server, but requests normal handles from SiteMinder.
This means that APS fully supports multi-mastering. With no writeback settings (discussed below), APS follows write referrals to any or all masters that it needs to accomplish its task. This is entirely handled within the LDAP SDK and is subject to its own performance issues.
LDAP supports master/consumer servers, where one or more directory servers are masters and others are consumers. Consumer servers are, by definition, read only and are tuned for high performance reads. Typically, SiteMinder is configured to deal with consumers and all writes should go to the master(s). When a change goes to the master, it replicates that change to other masters and any consumers.
However, LDAP implements such relationships using referrals. When the write is made to a consumer server, the server responds to the LDAP client with a special message that says "I am a consumer, please resubmit your request to <list of master servers>". The LDAP client is expected to (possibly open a new connection and) resubmit the request to each of the master servers in the list until the request is satisfied.
The LDAP SDK can be told to accomplish this automatically and, in fact, when SiteMinder Enhanced Referrals are turned off, it does so. APS uses such handles when it uses SiteMinder handles.
However, even this mechanism has a fairly significant performance penalty when doing a large number of writes: every write is at least two round trips to directory servers; the first to the consumer which then returns the referral.
Sites can bypass this referral process within APS by specifying LDAP Write Back Information. This tells APS that one or more master servers exist and to do all writes to that list instead of submitting the update request to the SiteMinder-supplied handle.
A few implementation-dependent "features" have created some idiosyncrasies for APS support:
This problem can be solved by defining multiple names for the same LDAP directory within the Policy Server's host file, all with the same IP address (alternatively, multiple DNS aliases could also be used). Then the multiple User Directories can be specified within the SiteMinder Policy Store, each with a unique name. APS can then determine the correct entry to use.
APS is very careful of its resource utilization, so its use of the Directory Manager can be considered "safe"; it will not consume unreasonable amounts of server resources. However, the use of this account must be determined by the site.
Backup LDAP servers, as of this writing, are, by the LDAP specification, read-only servers. If SiteMinder is configured to use a backup LDAP server, APS will be unable to write to the directory. Errors will be logged to the console indicating this state.
This problem can sometimes be avoided using the writeback settings in the APS Configuration File, but only if the Primary LDAP Directory Server is operational at all times.
APS supports LDAP multi-mastering in two ways:
Some implementations of LDAP are actually LDAP interfaces to other data stores. Many of these implementations provide multi-mastering on their own. Examples are X.500, ISOCOR and Oracle's LDAP implementation. CA does not recommend any particular implementation.
While APS does generally support the same consumer failover as SiteMinder and fully supports LDAP multi-mastering, the FPS subsystem does not currently support consumer failover.
Note: APS does support Microsoft Active Directory and this support is provided using its LDAP interface. However, because Active Directory deviates so extensively from the LDAP specification, APS contains a significant amount of special processing and thus Active Directory is discussed in its own section.
APS supports Microsoft Active Directories running in LDAP mode only.
APS tries to place as few restrictions as possible for the schema that it needs, in part because many sites have policies or requirements for how schemas are updated, naming conventions and data layout issues. The attributes must exist for every user entry in the User Directory that will be maintained by APS, with the exception of the attributes marked as optional and suppressed in the [MAPPINGS] section of the APS Configuration File.
How sites accomplish this is entirely up to the administrators at the site. There are a number of choices available; no tools are provided to do this for you. CA Professional Services has considerable experience in this area and can help or advise you, if you so desire.
There are three steps required to ensure that the attributes exist for every user:
Attributes need not have the names defined above. If the attributes are to be renamed, the names must be remapped.
Microsoft Active Directory requires that each attribute have an OID (a globally unique identifier). CA has obtained and assigned the following OIDs for this use (these are also listed in the Schema section above):
|
Schema Object |
OID |
|
smapsInfo (objectClass) |
1.3.6.1.4.1.2552.1.1.9.1 |
|
smapsAccountInactivityDays |
1.3.6.1.4.1.2552.1.1.9.2 |
|
smapsBaseDate |
1.3.6.1.4.1.2552.1.1.9.3 |
|
smapsDisableAfter |
1.3.6.1.4.1.2552.1.1.9.4 |
|
smapsDisableUntil |
1.3.6.1.4.1.2552.1.1.9.5 |
|
smapsExpirePasswordDays |
1.3.6.1.4.1.2552.1.1.9.6 |
|
smapsFailureCount |
1.3.6.1.4.1.2552.1.1.9.7 |
|
smapsFailuresSinceLastLogin |
1.3.6.1.4.1.2552.1.1.9.8 |
|
smapsFailuresSincePreviousLogin |
1.3.6.1.4.1.2552.1.1.9.9 |
|
smapsGenerationalRedirects |
1.3.6.1.4.1.2552.1.1.9.10 |
|
smapsGraceLoginsUsed |
1.3.6.1.4.1.2552.1.1.9.11 |
|
smapsHistory |
1.3.6.1.4.1.2552.1.1.9.12 |
|
smapsImmediateChange |
1.3.6.1.4.1.2552.1.1.9.13 |
|
smapsInactivityWarning |
1.3.6.1.4.1.2552.1.1.9.14 |
|
smapsLastLogin |
1.3.6.1.4.1.2552.1.1.9.15 |
|
smapsLastPasswordChange |
1.3.6.1.4.1.2552.1.1.9.16 |
|
smapsLoginHistory |
1.3.6.1.4.1.2552.1.1.9.17 |
|
smapsMaxFailures |
1.3.6.1.4.1.2552.1.1.9.18 |
|
smapsMustLoginBy |
1.3.6.1.4.1.2552.1.1.9.19 |
|
smapsNextAction |
1.3.6.1.4.1.2552.1.1.9.20 |
|
smapsOldBlob |
1.3.6.1.4.1.2552.1.1.9.21 |
|
smapsPassword |
1.3.6.1.4.1.2552.1.1.9.22 |
|
smapsPreviousLogin |
1.3.6.1.4.1.2552.1.1.9.23 |
|
smapsTotalFailures |
1.3.6.1.4.1.2552.1.1.9.24 |
|
smapsTotalLogins |
1.3.6.1.4.1.2552.1.1.9.25 |
|
smfpsLockoutCounter |
1.3.6.1.4.1.2552.1.1.9.26 |
|
smfpsLog |
1.3.6.1.4.1.2552.1.1.9.27 |
|
smfpsOneShot |
1.3.6.1.4.1.2552.1.1.9.28 |
An attribute can appear in multiple objectClasses.
Note that the selection of where to put the attributes (described in the previous step) can have a considerable impact on this step. For example, if the attributes were added to a standard objectClass, this step is already done. If an existing custom objectClass was used, then this step may already be done. Using a new objectClass will require that this step be performed.
Also, consider new users. As new users get added to the User Directory, they will need to have access to the attributes as well, so the objectClass will need to be added to their list as well. This will probably impact any user management system implemented at the site.
Certain remappings are required in the APS.cfg file to identify and process Active Directories. The following three lines are the minimum required to support an Active Directory as a user store (in the [Mapping] section of the APS.cfg file):
userPassword={IsInDirectory("<dirname>")} unicodePwd
inetOrgPerson={IsInDirectory("<dirname>")} user
smapsPassword ={ IsInDirectory("<dirname>") }
Note that <dirname> is the name of the User Directory entry in your Policy Store.
If the only User Directory is an Active Directory, then the following three lines can be used:
userPassword=unicodePwd inetOrgPerson=user smapsPassword=
APS does not support Active Directory password content policies (the policies that define the required format for a password). Active Directory will refuse a password change if it does not conform to its defined native password policy. However, this refusal is returned as a generic error code.
This restriction is relatively easy to avoid. APS will apply its own password content policies before attempting to update the password in the directory. If the APS content policy is at least as restrictive as the Active Directory's policy, then the password will already conform the the directory's rules. Bear in mind that this method cannot accommodate password history restrictions.
APS does support some of Active Directory's native expiration policies.
If the user satisfies the conditions for any Ignore keyword in the APS.cfg file (page 55), APS will not perform any authentication time processing for this user, including detecting if the user is disabled or detecting disabling conditions (such as password expired).
APS will recognize that a user is disabled if any of the following are true (this is not necessarily the order in which APS actually does detection). Note that the Use Internal Disables setting does not affect detection, only how APS actually disables users.
The Disabled Reason is derived from the text following "Disabled" in the group's name (any additional hyphen is removed).
This search cannot be suppressed.
The Disabled Reason is derived from the text following "Disabled" in the group's name (any additional hyphen is removed).
This search can be suppressed by remapping memberof to a null value.
APS itself can disable a user for only four reasons (APS will never set the native account status bits):
smapsDisabledUntil is set to the current date and time, plus the number of minutes indicated by the Max Failures On Change setting followed by the text "Failure Count".
APS never really enables an account itself. Some of the mechanisms used by APS to maintain the user status have built-in reset capabilities (dates). APS does not actually update a user record to re-enable it.
To re-enable an account, a site must ensure that all of the above criteria that APS uses to detect that it is already disabled are not true. In other words, the account cannot be a member of a disabled group, smapsDisableUntil must be set correctly, etc.
Even then, it may appear that an account remains disabled. The usual cause is that while the account does get enabled, the conditions that caused it to become disabled remain, thus causing APS to just disable it again. These reasons are:
Most APS features are supports by Active Directory, but there is some special processing in addition to the native support above.
Active Directory requires that passwords be updated using LDAPS (LDAP over SSL) connections. If writebacks are used, this means that the LDAP Writeback Use SSL setting may be required.
If not using writebacks, the "Use Secure Connections" checkbox must be selected in the SiteMinder User Directory entry.
The IsLDAP() function (used in settings overrides) returns TRUE if the current user is stored in an LDAP directory (of any type).
The LDAP Disabled Groups setting controls where APS will create any disabled groups within the directory, if the Use Internal Disables setting is not in effect.
The Check LDAP Password Existence and Auto Force Change setting will not function under Active Directory.
When APS was originally designed, LDAP supported groups in one way: what are now call forward groups.
A forward group is a group object, physically stored, that contains the DN of all of its members in a multi-valued attribute (usually uniqueMember).
Forward groups do not scale well. In order to provide more scalability, the LDAP standards committee defined reverse groups.
A reverse group is a group object, physically stored, whose DN is contained in its member's records (usually memberof or groups). In other words, each user contains a list of the groups of which it is a member in a multi-valued attribute. Reverse groups scale much better than forward groups.
APS supports forward groups by default, but can support reverse groups, if they are used at the site. It can also support a mix of forward and reverse groups.
You must tell APS which groups will be reverse groups (since there is no standard, quick, way to tell the difference). You configure this in the [Mappings] section of the APS Configuration File.
To have APS treat all LDAP groups as reverse groups, use:
LDAP.ReverseGroups=*
An asterisk should not be considered a wildcard. It can only be used in the above manner to indicate that all groups are reverse groups.
To specify a single group as a reverse group:
LDAP.ReverseGroups=cn=Disabled-NoCredit, o=nds.com
Multiple such lines can exist, one for each reverse group.
Note: Some LDAP vendors also implement something that they call virtual groups. APS does not support virtual groups as of this writing, but, for most purposes, they can be easily simulated using override expressions or using the Disable setting.
All FPS functionality is supported for Active Directories, with the exception of question/answer encryption. This can still be accomplished, however, using the SmAPSEx library.
APSExpire has special settings for LDAP directories so that the user directory can be partitioned into smaller "chunks" for processing. See the chapter entitled Daily Processing (APSExpire) for details.
APSAdmin fully supports LDAP User Directories. However, APSAdmin only supports the entry of the full user DN on the user selection panel.
A considerable amount of work has gone into APS to optimize performance when dealing with LDAP directories and this optimization applies directly to Active Directory implementations.
APS reads the entire user entry into memory before handling any request. This means that all settings overrides and attribute references required by email templates can be handled without another request to the directory server. The additional overhead of this single read is nominal, the performance of the read is the lookup and network latency, not the actual data transfer.
When writing to the directory, APS "gangs" all of the updates into a single request to the directory server. This is a huge performance gain. While suppressing individual attributes can improve storage resource utilization (disk space), it has little impact on the update performance; the performance overhead for the entire update far outweighs the incremental performance cost of additional fields (as long as the updates are submitted together).
A side-effect of the ganged updates is improved fault tolerance. LDAP guarantees that all writes submitted as a single request either succeed or fail together. No single field will be updated without the others.
What this means, for example, is that the password cannot be updated without the password change date attribute. They either both update or neither updates.
In a multi-mastering situation, this is even more critical. Parts of the update cannot go to each of two servers. All of the updates will be posted to the same place at the same time.
APS does not use SiteMinder's Enhanced Referrals. It does not keep pools of LDAP handles, pinging them periodically to determine connection health and to keep the connections from timing out. It does use SiteMinder handles for reading (and, in some cases, writing) to the directory server, but requests normal handles from SiteMinder.
This means that APS fully supports multi-mastering. With no writeback settings (discussed below), APS follows write referrals to any or all masters that it needs to accomplish its task. This is entirely handled within the LDAP SDK and is subject to its own performance issues.
LDAP supports master/consumer servers, where one or more directory servers are masters and others are consumers. Consumer servers are, by definition, read only and are tuned for high performance reads. Typically, SiteMinder is configured to deal with consumers and all writes should go to the master(s). When a change goes to the master, it replicates that change to other masters and any consumers.
However, LDAP implements such relationships using referrals. When the write is made to a consumer server, the server responds to the LDAP client with a special message that says "I am a consumer, please resubmit your request to <list of master servers>". The LDAP client is expected to (possibly open a new connection and) resubmit the request to each of the master servers in the list until the request is satisfied.
The LDAP SDK can be told to accomplish this automatically and, in fact, when SiteMinder Enhanced Referrals are turned off, it does so. APS uses such handles when it uses SiteMinder handles.
However, even this mechanism has a fairly significant performance penalty when doing a large number of writes: every write is at least two round trips to directory servers; the first to the consumer which then returns the referral.
Sites can bypass this referral process within APS by specifying LDAP Write Back Information. This tells APS that one or more master servers exist and to do all writes to that list instead of submitting the update request to the SiteMinder-supplied handle.
A few Active Directory "features" have created some idiosyncrasies for APS support:
This is easily solved in one of two ways: Either use the LDAP Disabled Groups setting to explicitly specify where groups should be created or pre-create all of the groups so that APS does not need to create them.
This problem can be solved by defining multiple names for the same LDAP directory within the Policy Server's host file, all with the same IP address (alternatively, multiple DNS aliases could also be used). Then the multiple User Directories can be specified within the SiteMinder Policy Store, each with a unique name. APS can then determine the correct entry to use.
APS does provide support for Windows NT domain directories. However, this support is severely limited because the schema in such directories cannot be extended. On the other hand, APS does support several native capabilities of such directories.
Windows NT domain directories do not support schema changes, so none of the schema attributes described in the first section of this chapter are possible.
There is a small amount of additional setup required for APS to support Windows NT domain directories.
When APS sends email to a user, it needs access to the user's email address. However, there is no place to store this information in the schema. APS can, however, still do this.
For Windows NT users, APS looks at the Description field in the user's entry. Within that field, APS looks for the string Email:. The text immediately following, up to the end of the description field or the next space, will be used as the user's email address.
APS does not support Windows Domain Directory password content policies (the policies that define the required format for a password). The Domain Controller will refuse a password change if it does not conform to its defined native password policy. However, this refusal is returned as a generic error code.
This restriction is relatively easy to avoid. APS will apply its own password content policies before attempting to update the password in the directory. If the APS content policy is at least as restrictive as the Domain Controller's policy, then the password will already conform the the directory's rules. Bear in mind that this method cannot accommodate password history restrictions, since the directory's password history is not accessible.
APS has limited support for native expiration policies. In fact, APS has little of its own such policies with this type of directory because it cannot maintain its own information within the user record.
APS cannot keep track of the last password change date. Normally, it would use this date to calculate the password expiration date. Instead, APS will use the actual password expiration date stored natively in the user record. However, APS will perform no password expiration unless it has a password expiration delay defined. This is important to note. The password expiration delay so configured is completely ignored by APS, but is needed to trigger APS to check the user record for password expiration.
APS honors the account expiration date stored natively on the user record. It does not calculate its own date at any time. As is the case with password expiration, this date is only checked if there is an account inactivity delay configured in APS.cfg. The actual setting is ignored, but instead triggers the APS activity.
APS will check and honor the immediate password change flag stored in the user record.
APS honors the native account disabled flags. It will also set the flag, if it needs to disable the user.
If the account satisfies the conditions for any Ignore keyword in the APS.cfg file, APS will not perform any authentication time processing for this user, including detecting if the account is disabled or detecting disabling conditions (such as password expired).
APS recognizes that an account is disabled if the native account disabled flag is set in the user record. In this case, the reason code will be Windows.
If the account satisfies any of the conditions defined in APS.cfg using the Disable setting, it will also be considered disabled. The keyword defines the Disabled Reason code.
If APS needs to disable an account for any reason, it will set the native account disabled flag. Note that the reason that the account was disabled is lost in this case, since there is no place to store such information.
To enable an account, merely reset the native account disabled flag and ensure that any conditions defined using the Disable setting are not satisfied.
However, this can still prevent the user from authenticating.
APS tracks failure counts for Windows Domain users in memory (there is no place in the user record to store it). If the user is locked out because of a maximum failure count, then the account may be disabled immediately when they make their next authentication attempt, subject to the following rules:
There are two caveats here:
APS is extremely limited in what it can do with users in a Windows Domain Directory because of the lack of any place to store control information in the user record.
FPS does not support users stored in Windows Domain Directories.
APSExpire does not support users stored in Windows Domain Directories. This is generally not needed, Windows provides its own tools.
APSAdmin does not support the maintenance of users stored in Windows Domain Directories. However, administrators (the online users) can use APSAdmin to administer other users.
Fault tolerance is entirely implemented by the Windows Domain. APS has no special processing for these directories.
APS supports Windows Domain Directories for backwards compatibility. However, due to the very nature of the directory mechanism, it is extremely limited with what it can do
There is no "standard" way to update an ODBC schema. Each vendor implements their own way to do it. In addition, most sites have policies or requirements for how schemas are updated, naming conventions and data layout issues.
APS tries to place as few restrictions as possible for the schema that it needs. The attributes described in the first section of this chapter must exist for every user entry in the User Directory that will be maintained by APS, with the exception of the attributes marked as optional and suppressed in the [MAPPINGS] section of the APS Configuration File.
How sites accomplish this is entirely up to the administrators at the site. There are a number of choices available; no tools are provided to do this for you. CA Professional Services has considerable experience in this area and can help or advise you, if you so desire.
The simplest way to organize the schema for an ODBC directory is to just add all of the non-multiple-valued attributes to the existing user table as columns, then add two new tables for the two multi-valued attributes.
However, this is not always possible due to naming policies and possible table size constraints.
Columns (attributes) need not have the names defined below. If the columns are to be renamed, the names must be remapped as described in the section starting on Unsupported "Page" Cross-Reference.
Unlike SiteMinder (which reads each column as a separate query), APS "wants" to read an entire row to retrieve the user. The contents of the row is cached so that it is available for settings overrides and mail replacement values. This means that the entire user row is retrieved. This may have both capacity and security implications.
This can be easily tuned by defining a stored view of the user that restricts APS to "seeing" only those columns that the site wishes APS to have access to. A site can use the query overrides in the [ODBC] section of the APS.cfg file to define APS-specific versions of these queries that use these stored views. The APS view of a user can be different from SiteMinder's view of the data.
Some sites have quite successfully stored the APS-specific information in a separate table from the rest of the user information. Those sites merely used a stored query to join the APS table with the user table to get the views that they want.
Many of the attributes described below are listed as "variable length". In each case, the length listed is the maximum length used by APS itself. However, these columns typically contain a "comment" that can be placed on the information by a site. The comment can be of any length allowed by that site.
Some attributes, specifically smapsGenerationalRedirects and smapsHistory, can become extremely large, depending on site usage.
smapsGenerationalRedirects contains a list of generational redirect information. Normally, this is actually a relatively small (or non-existent) amount of information. However, if sites use a large number of generational redirects, the data storage requirements of this column can increase. A site should review its expected use of this feature to determine the amount of storage required.
The smapsPassword column contains encrypted data containing information about previously used passwords. APS places a hard restriction on the maximum length of this data. That hard limit is listed with the attribute description. However, the reality is that it would take an automated password changer a considerable amount of time to enlarge the data to that size.
Since the information is encrypted, it is impossible to just truncate it; it must be stored in its entirety.
To reserve the full amount of storage for every user row may be unreasonable. What many sites do is set the length of this column to some smaller value (for example 2k), then run triggers within the database to alert administrators when a certain percentage of this space starts to get used (say 90% - the field grows very slowly, usually less than 100 bytes per password change). If a single test user starts to consume too much, approaching the maximum length defined, the site clears the value for that one account. If multiple users start to approach the value, either determined by triggers or by periodic examination of the data, the column is enlarged.
APS does not support native ODBC data formats at this time. This is currently under review by the product team for a future enhancement.
Two attributes are implemented as separate tables that will grow. The Login History table is maintained by APS and will be pruned as each user authenticates to prevent infinite growth. The FPS History table will grow indefinitely, records written each time a user runs FPS.
Wherever possible, APS will use the queries defined in the SiteMinder ODBC Query Scheme associated with the User Directory. However, there are some additional queries that APS needs and there will be times that it is not appropriate for APS to use queries defined to SiteMinder.
In addition to the APS-specific queries, every query defined in the SiteMinder Query Scheme can be overridden for use by APS.
Each query has replacement parameters, or placeholders, embedded within them that indicate where APS (or SiteMinder) is to place values before executing the query. Each query will replace these parameters with specific values in the order defined by the query. Thus, the first parameter for a given query might be replaced by the User's ID. It is not possible to change the order of the parameters (the choice of placeholders and their order is defined by SiteMinder's Query Schemes). Placeholders are indicated in a query by "%s".
All of these queries are defined or overridden in the APS.cfg file in the [ODBC] section.
The Enumerate query overrides the query by the same name defined to SiteMinder. APS does not use this query at this time.
The Get Object Info query overrides the query by the same name defined to SiteMinder. APS does not use this query at this time.
The Lookup query overrides the query by the same name defined to SiteMinder. APS does not use this query at this time.
The Init User query overrides the query by the same name // defined to SiteMinder. APS does not use this query at this time.
The Authenticate User query overrides the query by the same name defined to SiteMinder. APS uses this query to determine if the old password entered during a password change is valid. The default query is:
SELECT Name FROM SmUser WHERE Name='%s' AND Password='%s'
The first parameter is the user's name (entered to SiteMinder) and the second value is the (clear-text) old password as entered during the change password process.
This query can be a stored procedure, but the replacement parameters must retain their order and meaning. If the password is encrypted, then this query almost must be a stored procedure.
The Get User Property query overrides the query by the same name defined to SiteMinder. APS uses this query to retrieve the attribute values defined for the user.
The default query is:
SELECT %s FROM SmUser WHERE Name='%s'
The first parameter is always replaced by an asterisk (retrieve all defined columns); the second parameter is the user's ID. If all columns should not be returned, this query should be overriden to reference a stored view in the database that returns fewer columns. Note that only columns returned on this query can be used in overrides or as macros in mail or redirections.
The first parameter is always replaced as a constant asterisk. A query could be defined with this, but then APS could not use the query defined to SiteMinder (which contains a replacement parameter in this position).
This query can be a stored procedure (if the underlying RDBMS supports rows returned from stored procedures), but the replacement parameters must retain their order and meaning.
The Set User Property query overrides the query by the same name defined to SiteMinder. APS uses this query to set attribute values for the user. The default query is:
UPDATE SmUser SET %s='%s' WHERE Name='%s'
The first parameter is the (mapped) name of the attribute (column) to modify, the second is the value to set it to. The third parameter is the user's name.
APS does special processing when using this query. If the query defined to APS (or SiteMinder) uses UPDATE, then APS will build a query to update all columns at once, using standard SQL syntax.
If, however, a stored procedure is used for this query, APS will call the stored procedure for each change. Parameters must appear in the same order for stored procedures.
The use of the UPDATE query is for higher performance.
If column access is to be restricted, create a stored VIEW in the database and use an UPDATE query to the stored view.
The Get User Properties query overrides the query by the same name defined to SiteMinder. APS does not use this query at this time.
The User Properties setting overrides the setting by the same name defined to SiteMinder. APS does not use this query at this time.
The Lookup User query overrides the query by the same name defined to SiteMinder. FPS and APSExpire use this query to locate users in the directory. The default query is:
SELECT Name, 'User' AS Class FROM SmUser WHERE %s
The parameter is the WHERE clause built up by FPS or APSExpire.
The Get User Groups query overrides the query by the same name defined to SiteMinder. APS uses it to return the list of group in which the current user is a member. The default query is
SELECT SmGroup.Name FROM SmGroup, SmUser, SmUserGroup WHERE SmUser.Name='%s' AND SmUser.UserID=SmUserGroup.UserID AND SmGroup.GroupID=SmUserGroup.GroupID
The parameter is the user's name.
Each row returned represents a group name that the user is a member of.
The Is Group Member query overrides the query by the same name defined to SiteMinder. APS uses it to determine if the user is in a specific group, both for internal purposes and to determine the result of IsInGroup() calls in an override expression. The default query is:
SELECT ID FROM SmUserGroup WHERE UserID= (SELECT UserID FROM SmUser WHERE Name='%s') AND GroupID= (SELECT GroupID FROM SmGroup WHERE Name='%s')
The first parameter is the user's name, the second is the name of the group of interest.
If the result of the query contains any rows or data, the user is considered a member of the group.
The Set Password query overrides the query by the same name defined to SiteMinder. APS uses it to actually change the user's password. Typically, it is a stored procedure, but it need not be. The default query is:
UPDATE SmUser SET Password='%s' WHERE Name='%s'
The first parameter is the new password, the second is the name of the user.
Note that the password may be encrypted, if SmAPSEx encrypted it.
This query can be a stored procedure (and should be), but the replacement parameters must retain their order and meaning.
Passwords will always be set using this query, never the Set User Properties query above.
Note: The Get Login History query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if Login History is to be maintained.
Login History contains an entry for each login attempt by a user. Typically, it will be a separate table containing two fields, the history entry and the user's name.
The next three queries are also used to manipulate login history.
The query has one parameter that is the user's name.
The Get Login History query must return a single column with the login history entry. Its name is irrelevant. The entries should be returned in date order.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
SELECT smapsLoginHistory FROM LoginHistory WHERE Name='%s' ORDER BY smapsLoginHistory
Note: The Set Login History query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if Login History is to be maintained.
Login History contains an entry for each login attempt by a user. Typically, it will be a separate table containing two fields, the history entry and the user's name.
The query has two parameters. The first is the Login History value and the second is the user's name.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
INSERT INTO LoginHistory (smapsLoginHistory, Name)
VALUES ('%s','%s')
Note: The Delete Login History query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if Login History is to be maintained.
Login History contains an entry for each login attempt by a user. Typically, it will be a separate table containing two fields, the history entry and the user's name.
The query has two parameters. The first is the date and time to delete before and the second is the user's name.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
DELETE FROM LoginHistory WHERE LEFT(smapsLoginHistory, 15)<'%s' AND Name='%s'
Note: The Clear Login History query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if Login History is to be maintained.
Login History contains an entry for each login attempt by a user. Typically, it will be a separate table containing two fields, the history entry and the user's name.
The Clear Login History query is used by APSAdmin to clean out all of the login history for a specific user.
The query has a single parameter used to identify the user.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
DELETE FROM LoginHistory WHERE Name='%s'
Note: The Get FPS Log query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if FPS Logging is to be maintained.
The FPS Log contains an entry for each FPS usage attempt by a user. Typically, it will be a separate table containing two fields, the log entry and the user's name.
The next two queries defined are also used to manipulate the FPS Log.
The query has one parameter that is the user's name.
The Get FPS Log query must return a single column with the log entry. Its name is irrelevant. The entries should be returned in date order.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
SELECT smfpsLog FROM FPSHistory WHERE Name='%s' ORDER BY smfpsLog
Note: The Add FPS Log query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if FPS Logging is to be maintained.
The FPS Log contains an entry for each FPS usage attempt by a user. Typically, it will be a separate table containing two fields, the log entry and the user's name.
The query has two parameters. The first is the FPS Log value and the second is the user's name.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
INSERT INTO FPSHistory (smfpsLog, Name) VALUES ('%s','%s')
Note: The Clear FPS Log query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if FPS Logging is to be maintained.
The FPS Log contains an entry for each FPS usage attempt by a user. Typically, it will be a separate table containing two fields, the log entry and the user's name.
The Clear FPS Log query is used by APSAdmin to clean out all of the FPS Log entries for a specific user.
The query has a single parameter used to identify the user.
The actual names of the table and columns are defined by the query and do not matter to APS.
An example query might be:
DELETE FROM FPSHistory WHERE Name='%s'
Note: The Set Password Checksum query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if Auto Force Change functionality is required.
The Auto Force Change keyword in this file tells APS to check for password changes outside of APS and, if detected, force the user to change their password at next login. It is used to automatically treat external (administrative) password changes as Force Immediate Change situations without requiring changes to the administration utility.
Under LDAP, APS uses the smapsPassword attribute to handle this functionality. Under ODBC, this is not necessarily possible. Databases are typically protected so that passwords cannot be read back.
If Auto Force Change is to be used, this and the following query must be defined. They are almost always stored procedures.
The query has a single parameter used to identify the user (the user's password has already been changed).
Typically, the implementation of this functionality uses some special attribute to store the checksum (or the entire password value, for that matter).
An example query might be:
CALL SetPasswordChecksum('%s')
Note: The Test Password Checksum query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if Auto Force Change functionality is required.
The Auto Force Change keyword in this file tells APS to check for password changes outside of APS and, if detected, force the user to change their password at next login. It is used to automatically treat external (administrative) password changes as Force Immediate Change situations without requiring changes to the administration utility.
Under LDAP, APS uses the smapsPassword attribute to handle this functionality. Under ODBC, this is not necessarily possible. Databases are typically protected so that passwords cannot be read back.
If Auto Force Change is to be used, this and the previous query must be defined. They are almost always stored procedures.
The query has a single parameter used to identify the user. The function should return a numeric or boolean value, where non-zero indicates that the checksum is invalid.
Typically, the implementation of this functionality uses some special attribute to store the checksum (or the entire password value, for that matter).
An example query might be:
?=CALL TestPasswordChecksum('%s')
Note: The Compare FPS Answer query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if FPSí ODBC Encrypt functionality is required.
The answers to FPS questions can be encrypted in an ODBC database. This is indicated to APS using the ODBC Encrypt keyword in the [FPS-Verify] section of the APS.cfg file. This query is one way that sites can implement this encryption.
There is no default for this query. If not defined and ODBC Encrypt was specified in APS.cfg, FPS will generate an error, since it won't know how to compare an encrypted answer (this is assuming that the encryption is not being performed by SmAPSEx).
The query must be a stored procedure that takes three arguments (or, at least, three substitution parameters) and return a numeric or boolean value (non-zero indicates that the compare is true).
The first parameter is the user name. The second parameter is the name of the attribute, as configured to APS. The third parameter is the user-entered answer (in clear text).
The implementation of this function usually encrypts (or hashes) the user supplied value (the third parameter) and compares it to the value stored in the user entry.
An example query might be:
?=CALL CompareFPSAnswer('%s', '%s', '%s')
Note: The Add To Group query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if the APSAdmin API is to be used to maintain group memberships.
The APSAdmin API functions use this query to add users to an existing group (creation of groups is not supported).
There is no default query for this purpose. If not specified and a user must be added to a group, an error will be logged and the update will fail.
An example query might be:
INSERT INTO SmUserGroup (UserID, GroupID) VALUES ('%s', '%s')
Note: The Remove From Group query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if the APSAdmin API is to be used to maintain group memberships.
The APSAdmin API functions use this query to remove users from an existing group.
There is no default query for this purpose. If not specified and a user must be removed from a group, an error will be logged and the update will fail.
An example query might be:
DELETE FROM SmUserGroup WHERE UserID='%s' AND GroupID='%s'
Note: The Admin Translation query does not exist in the SiteMinder Query Scheme and has no default. Therefore, a query must be defined if the APSAdmin API is to be used in certain scenarios.
The APSAdmin APS functions use this query to translate input user identity (on the APSAdmin user selection form) to a user name that can be used on future queries.
The query is expected to return a single record with at least one column that is the user's name (the one used in all of the other queries).
If not specified, then the query is not used and the data entered is expected to be the user's name. If multiple records or no records are returned, a "User record could not be found" error is displayed to the administrator. If multiple records are returned, an error is issued to the console log as well.
This query is typically used if the administrator is expected to identify users to APSAdmin using something other than userid, such as membership number.
An example query might be:
SELECT Name FROM Users WHERE MemberNumber='%s'
If the account satisfies the conditions for any Ignore keyword in the APS.cfg file, APS will not perform any authentication time processing for this user, including detecting if the account is disabled or detecting disabling conditions (such as password expired).
APS will recognize that an account is disabled if any of the following are true (this is not necessarily the order in which APS actually does detection):
APS itself can disable an account for only four reasons (APS will never set the native account status bits):
If Auto Reset Failure Count setting is in effect:
smapsDisabledUntil is set to the current date and time, plus the number of minutes indicated by the Max Failures On Change setting followed by the text "Failure Count".
smapsDisabledUntil is set to "FOREVER Failure Count".
APS never enables an account. Some of the mechanisms used by APS to maintain the user status have built-in reset capabilities (dates). APS does not actually update a user record to re-enable it.
To re-enable an account, a site must ensure that all of the above criteria that APS uses to detect that it is already disabled are not true. In other words, the account cannot be a member of a disabled group, smapsDisableUntil must be set correctly, etc.
Even then, it may appear that an account remains disabled. The usual cause is that while the account does get enabled, the conditions that caused it to become disabled remain, thus causing APS to just disable it again. These reasons are:
APS does not support native ODBC (RDBMS) data formats, such as dates and binary formats. However, some sites have quite successfully used temporary tables and triggers to convert the APS maintained data into and out of native formats. CA Professional Services has some experience in this area and may be able to help, if this is required.
The Auto Force Change setting makes no sense for ODBC directories and is not support.
Disabled groups are not supported.
FPS fully supports ODBC (RDBMS) directories. There is special processing for handling encrypted FPS answers (See ODBC Encrypt.).
APSExpire has special settings for ODBC directories so that the user directory can be partitioned into smaller "chunks" for processing. See the chapter entitled Daily Processing (APSExpire) for details.
APSAdmin fully supports ODBC User Directories. Using the Admin Translation query, users can be selected using arbitrary identification.
APS does a few things that significantly improve performance and fault tolerance when dealing with ODBC User Directories. Note that if improperly configured, performance can actually be worse; some fine-tuning is always desirable.
However, this may come at a cost. If there are a large number of columns in the user table that APS should not access, they will be returned anyway. In this case, it may be desirable to use a stored view instead of accessing the raw table (this is generally considered good practice for SQL databases anyway).
Stored procedures are extremely difficult to implement and debug, since they are so implementation-dependent. APS uses the "standard" ODBC mechanism for invoking stored procedures. Please see the documentation for the directory vendor for any special formatting or escapes required to implement stored procedures or embedded function calls within queries. CA cannot provide support for writing these queries, as ever vendor differs in their implementation.
However, CA Professional Services may be contracted to help a site develop and troubleshoot such queries.Some ODBC implementations limit the number of characters allowed for a column name (or the number of significant characters). These implementations may require that the default attribute names be remapped to shorter names.
APS, out of the box, does not support password replication or synchronization between multiple user directories.
This is not a simple subject, but deserves some attention in this document.
There are many technical problems with password replication. Here are a few of the bigger examples:
There are a number of reasons that sites consider password replication/synchronization. Some are better implemented in other ways, thus avoiding many of the problems listed above.
Shared Directories Some people are under under the impression that "Password Synchronization" must occur between "applications", even if the "applications" share a common user directory. This is actually a trivial case, since the credentials are only stored once and can (usually, but not always) be shared between the two applications (presumably, one of the applications is SiteMinder). With SiteMinder's broad User Directory support, this case of "synchronization" is non-existent (or trivial, depending on how you look at it). This, of course, depends on whether the applications require their own operational user attributes or can share the "native" ones.
If the underlying system cannot be accessed through any other mechanism than SiteMinder, this synch is not needed, in fact. An alternate solution for this case is presented in the chapter on Best Practices for Storing Legacy/Back-End Credentials.
Since SiteMinder supports both Windows Domain Directories and Active Directory, this is better accomplished using a shared directory than by replication. iPlanet (and possibly others) also has a replicator available to perform password synchronization at the directory level.
This case is trivially solved using SiteMinder's Auth/AZ mapping. In fact, without such mapping, no single sign-on is possible, since when the user will authenticates against different directories, SiteMinder will consider them different users.
This case only occurs when two (or more) data stores are accessed independently, directly by the user and both are used for authentication.
In these cases, sites cannot get Single Sign-On (because of the different access controls), but they want each user to have a single set of credentials that they can use to log into each application. When the credentials change in one application, they should change in all others. Things like forced password change, password expiration, etc, should be enforced according to common (or at least negotiated) rules.
This is the only true Password Synchronization case and is actually quite rare. All of the other cases are better handled using other mechanisms.
Note: The two directories involved are often otherwise unrelated and no other provisioning is required.
Such replication is, however, still possible, even though it is not supported out of the box by APS. APS calls a specific function every time a user's password changes, passing the user identity and the new password. This function can be hooked to capture the change, and then the function can write the changes to any or all of the other places that it is needed.
This function is part of the SmAPSEx library (described on Unsupported "Page" Cross-Reference), but is not publicly available in the SDK (imagine the possibility of Trojan horses capturing password changes). However, it is available to CA Professional Services to provide custom solutions.
|
Copyright © 2013 CA.
All rights reserved.
|
|