Anyconnect Client profile files deleted after client upgrade

[Marcel Verbruggen - Pennings]

L.S.

I am running anyconnect version 3.1.02040 on a Windows 7 64-bit machine with UAC turned on.

The ASA I am connecting to is a 5510 running ASA OS 8.4.5

The problem I have is the following:

We are using machine certificate authentication combined with RADIUS user authentication.

The machine certificates are stored in the Machine/Personal container in the local machine.

By default, the anyconnect client does not have the rights to access this certificate store when run by the user in non-elevated mode.

We do not want to have the user run the client as administrator (in elevated mode) all the time.

Therefor we have made an Anyconnect Client profile that sets the Certificate Store Override parameter to true and attached it to the group policy.

With this XML in place (in the C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile folder)

the users can connect to the ASA and authenticate using the certificate without the need for elevated rights. This is all working perfectly.

The anyconnect client and XML file are distributed to the clients using a software distribution system (Microsoft SCCM).

The problem happens when I update the Anyconnect package on the ASA. I recently updated the package to release 3.1.03103. This is what happens:

• The user can connect using the 3.1.02040 client (certicate authentication works without elevation, since the XML Anyconnect Client Profile is present)
• The Anyconnect software updates itself to the new version during the connection, pushed from the ASA.
• The VPN is established.

However, the XML file that is associated with the group policy is deleted during the upgrade process and not placed back in the Profile folder on the client after the upgrade.

This means the user cannot connect without using elevated rights the next time he wants to connect.

If he uses elevated rights after the upgrade, the XML is pushed back from the ASA normally, allowing the user to connect without elevation again any subsequent times.

Is there any way to push the XML profile to the client from the ASA after the upgrade of the Anyconnect software?

[Rostislav Opocensky]

Hi,

have you or anyone else found a way around this?

It is clear that there are legitimate situations when the client profile must be present on the client machine prior to establishing VPN, otherwise it is impossible to connect. Selecting a proper certificate store and using a correct group-url are a few examples of this.

We have solved the initial installation by using MST transform files. We created an installation package containing the original Cisco MSI file, our own MST file created by MS Orca as well as a client XML profile and a company logo. We have one such installation package for internal users and another one for external users. They differ mainly in the client XML profiles.

The installation is being performed by calling msiexec.exe with lots of cmd-line arguments. A customized setup.hta file together with Cisco's setup.exe can be used for this, but — as in our case — a simple .BAT file suffices. So the initial installation of AnyConnect for different kinds of users is a piece of cake.

The trouble begin when you need to perform an upgrade of AnyConnect. Prior to installing a new version, the previous one is deleted including the client XML profiles. And this easily leaves users unable to connect. They still see the connection entry in the AnyConnect UI (because the preferences.xml file is not deleted). But the corresponding XML profile is gone.

My attempt to solve the issue by uploading MST transform files directly to ASA (in ASDM: Configuration → Remote Access VPN → Network (Client) Access → AnyConnect Customization/Localization → Customized Installer Transforms) failed. The transform was correctly taken into account during the upgrade. However, because the transform referenced an XML profile that did not exist at the time of installation, the upgrade failed, leaving the user without any version of AnyConnect. The following can be found in the Windows event log (ext.xml is the profile referenced by the transform MST file):

Product: Cisco AnyConnect Secure Mobility Client -- Error 1308. Source file not found: C:\WINDOWS\TEMP\install\BB2E8D8\CommonAppDataFolder\Cisco\Cisco AnyConnect Secure Mobility Client\Profile\ext.xml.  Verify that the file exists and that you can access it.

The documentation on creating customized AnyConnect installs is terse, but it can be done. However, there is a major issue awaiting everyone who depends on the XML client profiles, because after upgrading the AnyConnect from ASA the profiles are gone. I believe that leaving the XML Client Profiles intact when removing the old version of AnyConnect so that the new version could use them would solve the issue altogether. Could possibly anyone from Cisco comment on this? I look forward to any responses.

Regards,

Rostislav

[Marcel Verbruggen - Pennings]

The client upgrade process basically just calls the uninstaller process within Windows. This means anything that was installed together with the client (such as xml files in a mst process) will also be uninstalled during the upgrade.

We have found the only proper solution/workaround for this problem is therefor to basically install the xml files as a seperate MSI process. It is a bit of work to write a separate installer for them, but it is manageable. Accidentally this also makes the xml files easier to upgrade from management tools such as SCCM without the need to update the whole client (for instance when a site is added or parameters change). 

Within SCCM you can make the xml files dependant on the Anyconnect client. This means they can never be installed without the main client by a user. We also do this for seperate Anyconnect modules such as the Start Before Logon module.

I hope this helps

[Rostislav Opocensky]

Thank you for your prompt response. The key is that the uninstaller removes everything that was installed by the installer. In our case that includes the client profiles. So we are about to create multiple installation packages as you suggested. Thanks again for the hint!