Hide AnyConnect 3.1 Last User Name at Start Before Login

[webabc123]

For added security, we have set our laptops to not display the last user who logged into Windows.  The user must type both their user ID and their password each time they log into Windows.  This is so if a laptop is lost or stolen, the thief would have to hack both the user ID and password to break in before the system locks them out to Bitlocker recovery mode,  If the thief has the user name, they now only need to break a password that could have been guessable within a few tries if the user sets it to something weak and commonly used (Password2, Monkey123 etc.) that barely meets the minimum complexity requirements.

However, I found that SBL shows the last login ID used to connect to VPN and this would give away the user's Windows ID.  How do we change that to not display last used user ID in AnyConnect SMC 3.1 for all users?  Is it in a preferences file we can push out via Group Policy?

It would be nice if the user iD could be hidden only at SBL use of AnyConnect, but still fills it out for the user if they launch AnyConnect after logging into Windows.

[Marvin Rhoads]

Int the profile, you would "<RestrictPreferenceCaching>" That will keep the credentials including username from being cached locally between sessions. Reference.

I don't believe you can enable it only for SBL but disable it for desktop-launched VPN. You can disable the later altogether and force SBL.

If you want the highest security, issue your users smartcards with digital certificates embedded and require the use of those certificates via insertion of the smartcard and unlocking the certificate for reading by AnyConnect via token code. :)

[webabc123]

We can't do the smartcards.  Users would just leave them plugged in or else store them in the bag with the laptop and that careless practice would reduce the usefulness of smartcards if the laptop was stolen.

We don't want it to remove the host server name or remove preferences that may have selected in the GUI (such as whether or not to start the connection when the client is launched).

Also, is this something stored in the local XML file that we can edit and send to workstations without it being later overwritten by the ASA?

[webabc123]

I don't understand exactly what to do based on what you wrote above or what was at the link you posted. I think there are some words missing. I see nothing on the Cisco page that says which file to edit or how, so I just made a guess and found an xml file on the laptop in the Programdata/Cisco folder that had the text "" in it. It was named anyconnectlocalpolicy.xml and I changed false to true and saved it. It didn't work. It actually did the opposite of what I wanted. It seems to have blanked out the user name in the Windows desktop, but still left it exposed when no user is logged in when launched from SBL.

[webabc123]

I don't understand exactly what to do based on what you wrote above or what was at the link you posted. I think there are some words missing. I see nothing on the Cisco page that says which file to edit or how, so I just made a guess and found an xml file on the laptop in the Programdata/Cisco folder that had the text "RestrictPreferenceCaching" in it. It was named anyconnectlocalpolicy.xml and I changed false to true and saved it. It didn't work. It actually did the opposite of what I wanted. It seems to have blanked out the user name in the Windows desktop, but still left it exposed when no user is logged in when launched from SBL.

[Marvin Rhoads]

Sorry but I assumed some prerequisite knowledge of how AnyConnect profiles work.

In general, AnyConnect profiles are deployed and updated from the ASA that controls the VPN. We generally create and update them there and any changes are pushed out when a user next connects.

We also have the options of pre-deploying by manually or using a modified installer or software deployment tool to get the files to the users as a starting point. In that case, we can modify the profiles (xml files) using the AnyConnect VPN profile editor.

I'd suggest going back earlier in the document I linked to and reading the introductory chapters for a more complete picture. Most specifically, the chapter on deploying the client.