So you don’t have to go through the pain again, once the download is complete you can find the SafeWord download files here:

C:\Program Files\Secure Computing\Installs

SafeWord RemoteAccess Keeps You Waiting is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

In my instance, I found that a user would be able to authenticate once, but then the second authentication instance would fail. Checking the agent logs was not much help as no logs were being recorded. After checking that the latest version of the SafeWord Agent was installed, I remembered that I has run the SCW on the system to help secure it. By default, the agent logs are located in:

C:\Program Files\Secure Computing\SafeWord\AgentLogs.

By giving the NETWORK SERVICE account write rights to this folder the agent was able to create a log file. The second part of the issue, I was able to identify in the agent log. The file:

C:\Program Files\Secure Computing\SafeWord\ServerVerification\SWEC.MD5

was unable to be written to the file system. By allowing the NETWORK SERVICE account write rights to the:

C:\Program Files\Secure Computing\SafeWord\ServerVerification

folder, the agent could write this file and authentication worked successfully.

SafeWord RemoteAccess vs. Security Configuration Wizard is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

To fix this, I’ve had to add the URL to our SharePoint installation to the Local Intranet zone and pass-through authentication works fine. I can’t seem to find any technical information on this issue, but I’m assuming that Internet Explorer does not default pass authentication through to just any web site. This issue does not appear to affect Internet Explorer 7 on Windows Vista.

Windows XP, Internet Explorer 7 and SharePoint is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

1. AAC sends a RADIUS Access-Request with the users credentials
2. PINsafe sends back a RADIUS Access-Accept
3. AAC sends a RADIUS Access-Request
4. PINsafe sends back a RADIUS Access-Reject (the credentials are now invalid as the password can only be used once)
5. AAC sends a RADIUS Access -Request
6. PINsafe sends back a RADIUS Access -Reject
7. AAC sends a RADIUS Access -Request
8. PINsafe sends back a RADIUS Access -Reject

This is because Advanced Access Control is not handling the RADIUS Message-Authenticator attribute correctly. Well good news, Citrix have created a private hotfix which I was able to test out earlier this afternoon and authentication is now working successfully. This hotfix replaces Citrix.AuthenticationService.RADIUSClient.dll and you will have to call Citrix to get a copy of the file. Quote case number 31367637 as a reference if required.

Now the next thing for me to do is test this fix out with integrating Vasco DIGIPASS authentication with Advanced Access Control, which I’ve seen having the same issues.

UPDATE: Unfortunately this fix hasn’t make it in time for the 4.5 release of Advanced Access Control. Once you upgrade to 4.5 you may have to request an updated fix. Apparently this fix or an equivalent has made it into Advanced Access Control 4.5. Graham from Swivel has tested with PINsafe sucessfully with AAC 4.5.

AAC 4.2 and Swivel PINsafe is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.