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
|
Copyright © 2014 CA.
All rights reserved.
|
|