CA SiteMinder’s “DisallowForceLogin” registry key demystified

Warning: This page deals with one of the vague Policy Server flags and assumes certain level of familiarity with the dark soul of CA SiteMinder.

Is is pretty hard to understand the meaning of the DisallowForceLogin registry key for SiteMinder Policy Server from the official documentation, even when you have plenty of time and manuals. This page pretends to summarize all that you may need to know about it, should you have to deal with this functionality some day.

History and Functionality

In a pre-R6 environment, when a user submits a password change request that contains an invalid current password, the Password Change Information screen appears with a message stating that the old password is incorrect. The user can provide the correct credential and change the password.

In R6 and R12, the Policy Server redirects the user to the login screen without the message (that is, ”forces login screen”). Enabling the DisallowForceLogin registry key allows the old behavior in a new environment. When enabled, the Policy Server properly redirects users who have submitted a password change request that contains an invalid current password to the Password Change Information screen. This screen displays the invalid current password message. When disabled, the Policy Server redirects users to:

  • The login page that does not display the invalid current password message. This redirect occurs if an On-Auth-Reject-Redirect response is not bound to the policy configured with the user directory.
  • The URL associated with the On-Auth-Reject-Redirect response bound to the policy configured with the user directory

According to R6SP5 README, there are three cases affected by the DisallowForceLogin value:

  • Force password change or password expired.
  • Self Password change.
  • Optional password change.

Continue reading “CA SiteMinder’s “DisallowForceLogin” registry key demystified”

How to upgrade Microsoft UAG 2010 SP1 to SP2

How do you upgrade from UAG 2010 SP1 to UAG 2010 SP2? Well, it appears that such upgrade is not as trivial as expected.

First, Microsoft UAG is based on another Microsoft product – Microsoft TMG, – which has to be upgraded separately. Besides that, there is no direct upgrade package for the UAG itself. Thus, the correct upgrade path would be as follows: UAG SP1 => UAG SP1 Update 1 => TMG SP2 => UAG SP2. Of course, the whole process is documented in TechNet – but you have to be aware about this upgrade path first…

There is another caveat in this upgrade. In case you have some UAG trunks configured (and I assume you have some, since what do you need UAG for otherwise?), you have to active UAG configuration after each step in the upgrade process, otherwise you’ll end up without configured trunks – they will disappear silently during the process. Thanks to TechNet forums for solving this one for me!