Author: Anton Khitrenovich

CA SiteMinder’s “DisallowForceLogin” registry key demystified

~ Anton Khitrenovich ~ Leave a comment

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

~ Anton Khitrenovich ~ Leave a comment

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!

Recipe: email delivery system for automatic tests

~ Anton Khitrenovich ~ Leave a comment

Some time ago I was asked to help in implementing an automatic test for one of the application flows. In this flow the system under test was sending emails with dynamic content to the end user, and the test had to verify the content of those emails.

The testing system had two basic requirements:

  1. The email address to send those emails should be unique, since several tests of this kind will run simultaneously.
  2. The retrieval of those emails should be as simple as possible, without any dependency on specific programming languages or libraries.

To make the long story short – the solution that we implemented consists of the ‘sendmail’ daemon with specially crafted aliases file, shell script to parse incoming email and store it in the own file by username, ‘httpd’ daemon to expose the files with emails over HTTP and a cron script to clean those files; all those based on standard RHEL 5.5 distribution.  Continue reading “Recipe: email delivery system for automatic tests” →

How to configure multiple EAIs with different authentication levels in WebSEAL

~ Anton Khitrenovich ~ Leave a comment

A week ago I had to investigate whether it is possible to configure multiple EAIs in WebSEAL, when each one provides different authentication level. While configuration of several EAIs is pretty simple – all that you need is one trigger URL per EAI, and this is perfectly supported – placing each one of the on the own authentication level does not look trivial. The definition of authentication level per authentication method in WebSEAL is implicit, by the order of the authentication methods in the list.

For example, the list below defines password authentication to be level 1 and EAI to be level 2:

[authentication-levels]
level = unauthenticated
level = password
level = ext-auth-interface

But how do you define EAI to act as both first and second method? Well, simple – but not so intuitive:

[authentication-levels]
level = unauthenticated
level = ext-auth-interface
level = ext-auth-interface

Note that here EAI is mentioned twice – both as a first and as a second authentication level!

Additional missing piece of the puzzle is to tell WebSEAL which one of your EAIs represents each authentication level. This is solved via special “am-eai-auth-level” HTTP header from your EAI back to WebSEAL upon successful authentication, in the same way you send the username:

HTTP/1.1 200 OK
Date: Thu, 28 Jun 2012 12:00:00 GMT
am-eai-user-id: john
am-eai-auth-level: 2
Content-Type: text/plain
Content-Length: ........

Now you have to check with EAI should be invoked when the user comes to the login page. This information is available to your login page via %AUTHNLEVEL% macro. The processing can be easily done via JavaScript on the static logic or using server-side processing when LRR is enabled.

How to install RDP 6.1 on Windows Server 2003

~ Anton Khitrenovich ~ 11 Comments

Microsoft RDP client (aka “Remote Desktop Connection” or “Terminal Services Client”)  allows you to connect from your Windows station to other Windows servers. Version 6.1 was released in 2008 and nowadays many popular tools (such as mRemoteNG) state it as a requirement. Unfortunately, this version is available for Windows XP/Vista and Windows Server 2008, but not for Windows Server 2003.

So, how can you install RDP client 6.1 on Windows Server 2003?

It appears that in March 2011 Microsoft released security update for RDP client 6.0 and 6.1 – which can be installed on Windows Server, since the original RDP client 6.0 is supported there. Now, pay attention to this note in the “more information” section:

Bottom line? Take the official RDP client 6.0, download KB 2481109 for Windows Server 2003 (the security update mentioned above) – and you are ready to run with RDP client 6.1 on your Windows Server 2003!