Different login scripts for different anyconnect profile/policy?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-17-2019 08:28 AM - edited 06-17-2019 08:44 AM
Hi,
Wonder if the ASA/FTD with Anyconnect can apply different login scripts to different anyconnect profiles/policies?
Say I have a windows login script added on the firewall. I want to associate this script with corp users only when they login to anyconnect VPN using "vpn.company.com" and not pushing the script to contractors when they login to VPN using "vpn.company.com/contractors".
I actually disabled the Scripting in the contractor Anyconnect profile but the same script is still pushed down to the contractor's laptop...
Thanks,
/S
- Labels:
-
AnyConnect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-17-2019 08:02 PM
FTD doesn't support login script. You can't push them through FTD.
With ASA, execution of scripts is based on the anyconnect profile which is linked to a a group policy.
How do you authenticate your users?
Let's assume you use a radius server. When a corporate user connects you can assign them to the group policy that has an anyconnect profile running scripts whereas if a non corporate user connects, you assign them an another group policy with an anyconnect profile that doesn't have scripting configured.
Does that make sense?
Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-17-2019 08:26 PM
I was not aware that scrip is not supported on FTD, even 6.4.0.1 code?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-17-2019 09:12 PM
If you push scripts through another way, you can import the anyconnect xml profile into ftd to be delivered to clients and this script has to be done out of ftd using profile editor. Then the script could run.
Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-18-2019 04:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-20-2019 01:57 PM
Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2021 03:53 AM
Francesco,
I know this is an old post, but do you mean you can activate the "onconnect" script on a per Group-Policy basis?
If yes, is this how it's done?
group-policy GP-ANY-MYGROUPPOL2 attributes [...] webvpn anyconnect profiles value profile-xml-with-script type user exit
Further up in the config, profile-xml-with-script is linked to a file on the flash:
webvpn anyconnect profiles profile-xml-with-script disk0:/profile-xml-with-script.xml
This xml would contain:
<EnableScripting UserControllable="false">true</EnableScripting>
Also, presumably to use an XML file from the ASA as opposed to an offline deployment, does an end user need write-access to: %ALLUSERSPROFILE%\Cisco\Cisco AnyConnect Secure Mobility Client\Script ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-14-2021 05:48 AM
Just in case it helps others, the above configuration worked, but with some limitations:
- It seems only a single script can be run "OnConnect"
- It's effectively an on-off switch for this script per ASA group-policy
- You cannot direct a certain group-policy to execute a certain script, which is a shame
- The group-policy dictates an XML file to download, but be careful that the <Hostname> tags are unambiguous when enumerating all the XML files within the "PROGRAMDATA\...\Policies" folder. Overlaps will lead to unpredictable behaviour
Finally, I had a steer via another post that permissions issues within ProgramData are not common. There is some suggestion that the files will get written in by a SYSTEM user, but I wasn't able to confirm it.
