Tutorial: Manage User and Group Properties from the Command Line⁠

Overview⁠

When configuring Access Server for your needs, you can customize global properties for the entire server for all users and groups and set properties for specific users and groups. This tutorial describes these properties.

In the example commands given in the documentation, <USER_OR_GROUP> indicates where you can specify one of these:

A user name
A group name
__DEFAULT__

An installed Access Server.
Console access with root privilege.
Configured users (and groups).

Important notes about the commands below

Ensure you use single quotes (') around the <PASSWORD> instead of double quotes (") if you specify passwords on the command line that have unique characters in them with special meaning on the command line—such as the $ character (variable).
If you set a property for a user that doesn’t exist, the result of the command is to create the user and set the property. Thus, if, for example, you set the auto-login property (prop_autologin) either false or true on a user that doesn’t exist, then the user will automatically exist from that point on. To authenticate, the user must also exist in the authentication system, and it depends on your chosen authentication system to set up a password and possibly an account for that user.
Properties work with inheritance. For example, if you enable the auto-login property on a group, users in that group inherit the privilege to download an auto-login type configuration file. Suppose you specifically deny the auto-login property on a user in that group. In that case, users in that group can get an auto-login type configuration file, except for that user. If neither the user nor the group has anything specified in the auto-login property, then it will be inherited from __DEFAULT__, which by default has the value "false".
Groups need a subnet to work with. It can either be a global subnet you configure in the VPN Settings page or the server's global configuration database, or a subnet you define specifically for the group. Without a valid subnet from which to draw IP addresses, users assigned to a group tend to end up with one of the standard addresses from the globally configured dynamic IP address pool.
Many commands with the sacli tool write changes to the configuration databases that store all the settings but may not take effect immediately. You must refresh the running servers with the sacli start command, and changes will be effective. This command only refreshes or restarts components that need it. Additionally, suppose you make changes that may require a connected user to be disconnected and reconnected. In that case, the Access Server may issue a 'kick' command to such a connected client, forcing it to disconnect and reconnect and obtain the correct settings from the server.

The following commands are common tasks for managing user and group properties from the command-line interface.

Connect to the console and get root privileges.
Run commands below for your needs:
- Show the current properties for all users:
```
sacli UserPropGet
```
- Show the current properties for a specific user or group:
```
sacli --pfilt <USER_OR_GROUP> UserPropGet
```
- Remove all properties (this deletes the user or group):
```
sacli --user <USER_OR_GROUP> UserPropDelAll
```
- Refresh the Access Server configuration:
```
sacli start
```

Connect to the console and get root privileges.
Run commands below for managing auto-login privileges:
- Enable the auto-login privilege for a user or group:
```
sacli --user <USER_OR_GROUP> --key "prop_autologin" --value "true" UserPropPut
```
- Disable or revoke the auto-login privilege for a user or group:
```
sacli --user <USER_OR_GROUP> --key "prop_autologin" --value "false" UserPropPut
```
- Remove the auto-login property from a user or group:
```
sacli --user <USER_OR_GROUP> --key "prop_autologin" UserPropDel
```
- Refresh the Access Server configuration:
```
sacli start
```
Run these commands for defining auto-login connection profiles:
- Allow all users in a group to use auto-login connection profiles:
```
sacli --user <GROUP_NAME> --key "prop_autologin" --value "true" UserPropPut
```
- Allow all users to use auto-login connection profiles by default:
```
sacli --user "__DEFAULT__" --key "prop_autologin" --value "true" UserPropPut
```
- Deny all users' auto-login connection profiles:
```
sacli --user "__DEFAULT__" --key "prop_autologin" UserPropDel
```
- Restore to default and have it adhere to any inheritance:
```
sacli --user <USER_OR_GROUP> --key "prop_autologin" UserPropDel
```
- Refresh the Access Server configuration:
```
sacli start
```

Connect to the console and get root privileges.

Use the commands below to create new users and groups:

Add a new user from scratch:

sacli --user <USER_NAME> --key "type" --value "user_connect" UserPropPut

Create a new group from scratch:

sacli --user <GROUP_NAME> --key "type" --value "group" UserPropPut
sacli --user <GROUP_NAME> --key "group_declare" --value "true" UserPropPut

Add a user to a group:

sacli --user <USER_NAME> --key "conn_group" --value <GROUP_NAME> UserPropPut

Remove a user from a group:

sacli --user <USER_NAME> --key "conn_group" UserPropDel

Refresh the Access Server configuration:
```
sacli start
```

Connect to the console and get root privileges.
Use the commands below for setting passwords:
- Set the password for a user in local authentication mode:
```
sacli --user '<USER_NAME>' --new_pass '<PASSWORD>' SetLocalPassword
sacli start
```
- Remove password for a user in local authentication mode:
```
sacli --user '<USER_NAME>' RemoveLocalPassword
sacli start
```
- Change the minimum password length when password strength checking is enabled (the default is 8):
```
sacli --key "auth.local.0.min_len" --value "<NEW_VALUE>" ConfigPut
sacli start
```

Connect to the console and get root privileges.
Use the commands below for managing users' and groups' authentication methods:
Important
Ensure you configure RADIUS, LDAP, or SAML authentication if assigned to a user or group.
- Assign an authentication method to a user:
```
sacli --user <USER> --key "user_auth_type" --value "<MODE>" UserPropPut
```
  1. Where <MODE> can have these values:
    local
    pam
    radius
    ldap
    saml
- Assign an authentication method to a group:
```
sacli --user <GROUP_NAME> --key "user_auth_type" --value "<MODE>" UserPropPut
```
  1. Where <MODE> can have these values:
    local
    pam
    radius
    ldap
    saml
- Refresh the Access Server configuration:
```
sacli start
```

Define a subnet⁠

To assign a user a static IP address, you must first configure a static IP address network. By default, Access Server uses dynamic IP addresses. Depending on your configuration, you must configure a subnet at either the global or group level.

It helps to understand the following for configuring subnets:

All subnets you use must be unique, so when you configure a subnet, ensure it’s different from anything else you have.
For IP addresses on the subnet, it’s important to know that Access Server uses the start IP address and the end IP address for itself. For example, with the subnet 198.51.100.0/24, Access Server uses 198.51.100.1 and 198.51.100.254. You can’t use these for your user’s static IP address assignment. Valid addresses are 198.51.100.2 through 198.51.100.253.
Note⁠
In our documentation, we use example IPv4 addresses and subnets reserved for documentation, such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
Ensure you replace them with valid IPv4 addresses and subnets for your network(s).
Access Server uses IP addresses more efficiently when you configure groups with subnets rather than a global static IP addressing space. This is because IP addressing and access control work internally, creating a certain 'waste' of IP addressing space. It’s possible that Access Server can run out of assignable addresses even though your clients haven’t used the entire subnet. However, since millions of IP addresses are in private IP address space, this should not pose any problems.
In the commands below, if we assume we want to configure 198.51.100.0/24 as the subnet to use, then SUBNET is 198.51.100.0, and CIDR is 24. In the case of SUBNET/CIDR, you write it as 198.51.100.0/24.

Define a global subnet⁠

You can define a default VPN client address pool for users that aren't assigned to groups. You can set it from the VPN Server page on the Subets tab in the Admin Web UI or with the following commands.

Connect to the console and get root privileges.

Assign a global, default static IP addressing network:

sacli --key "vpn.server.static.0.network" --value <SUBNET> ConfigPut
sacli --key "vpn.server.static.o.netmask_bits" --value <CIDR> ConfigPut

You can now jump down to the instructions for assigning a user a static IP address.

Define a subnet for users not part of a group⁠

If you have some users in groups, but the user you want to assign a static IP address to isn't part of one, the default Default VPN client address pool configured in the Admin Web UI on the Subnets tab in VPN Server.

Connect to the console and get root privileges.
Assign a default static IP addressing network for users not part of a group:
```
sacli --key "vpn.server.static.0.network" --value <SUBNET> ConfigPut
sacli --key "vpn.server.static.o.netmask_bits" --value <CIDR> ConfigPut
```
- You can now jump down to the instructions for assigning a user a static IP address.

Define a group subnet⁠

If the user you want to assign a static IP address to is part of a group, the static IP address you assign to the user must fall within the subnet of the assigned group. If the group doesn't have a subnet yet, you must assign it first to use static IP addressing for a user in a group. For groups without defined subnets, Access Server dynamically allocates IP addresses to your users from the Default group address pool configured in the Admin Web UI on the Subnets tab in VPN Server. To switch a user over to a static IP address, you must assign a subnet to the user’s group. Such a subnet is only for static assignment and forces all users in the group to use IP addresses from the group subnet. There are two subnet fields under a group’s Networking section from the individual group page in the Admin Web UI:

Subnets assigned to this group.
Dynamic subnet ranges for this group.

You define the subnet for the static IP address assignment in the first field. The second field specifies a dynamic allocation range for users in a group that doesn't get a static IP address assigned.

Connect to the console and get root privileges.
Assign a primary subnet for static IP addressing space to a group:
```
sacli --user <GROUP_NAME> --key "group_subnets.0" --value <SUBNET/CIDR> UserPropPut
```
- You can now jump down to the instructions for assigning a user a static IP address.

Assign a user a static IP address⁠

Now that you have a subnet defined—either globally or at the group level—you can assign your user a static IP address.

Assign a user a static IP address:

sacli --user <USER_NAME> --key "conn_ip" --value <IP_ADDRESS> UserPropPut

Access control rules, or access control lists (ACLs), allow you to specify which IP addresses or subnets users and groups can access through the VPN. Access Server enforces these rules through firewall rules, automatically pushing relevant routes to VPN clients based on configured access control rules, ensuring that no unauthorized traffic passes through.

NAT Method: When using NAT (Network Address Translation), traffic appears to come from the Access Server. This method doesn’t require any special routing configurations on the target network.
Routing Method: When using routing, the VPN client's IP address is exposed to the network. You must configure the target network to route traffic back to the VPN client through Access Server as the gateway. This is typically done using (static) routes in your network.

Applying access control⁠

You can apply ACLs at different levels:

Global Settings: Applied to all users.
Group Level: Applied to specific user groups.
User Level: Applied to individual users.

Rules applied at different levels are additive, meaning users will inherit access control rules from global, group, and user-specific settings.

Command-line management of ACLs⁠

You can manage ACLs via the command line using the sacli command-line tool.

For steps on managing ACLs from the Admin Web UI, refer to these tutorials:

Connect to the console and get root privileges.

Use these commands for common configurations:

Grant access to a single IP using NAT:

sacli --user <USER_OR_GROUP> --key "access_to.0" --value "+NAT:192.0.2.100/32" UserPropPut

Grant access to a single IP using routing:

sacli --user <USER_OR_GROUP> --key "access_to.0" --value "+ROUTE:192.0.2.100/32" UserPropPut

Grant access to a range of IP addresses (subnet) using NAT:

sacli --user <USER_OR_GROUP> --key "access_to.0" --value "+NAT:192.0.2.0/24" UserPropPut

Grant access to a range of IP addresses (subnet) using routing:

sacli --user <USER_OR_GROUP> --key "access_to.0" --value "+ROUTE:192.0.2.0/24" UserPropPut

Grant access to TCP port 443 on a specific IP using NAT:

sacli --user <USER_OR_GROUP> --key "access_to.0" --value "+NAT:192.0.2.100:tcp/443" UserPropPut

Example: specifying multiple access control rules:

sacli --user <USER_OR_GROUP> --key "access_to.0" --value "+NAT:192.0.2.0/24" UserPropPut
sacli --user <USER_OR_GROUP> --key "access_to.1" --value "+ROUTE:198.51.100.0/24" UserPropPut
sacli --user <USER_OR_GROUP> --key "access_to.2" --value "+NAT:203.0.113.1:tcp/443" UserPropPut

If you need to force a user to drop its Access Server connection, you can do so using the sacli DisconnectUser function. With this function, you can:

Kick a user off the server.
Send a text string to the VPN client, which will display on the screen or in the log, and explain why the user was kicked off the server.
Kick a user off the server with an invitation to reconnect with their existing session token.

Connect to the console and get root privileges.
Use these commands for disconnecting users:
- Disconnect all VPN connections for a given user name:
```
sacli --user <USER_NAME> DisconnectUser
```
- Disconnect all VPN connections for a given user name with a reason:
```
sacli --user <USER_NAME> --client_reason <TEXT> DisconnectUser
```
- Disconnect all VPN connections for a given user name with an invitation to auto-reconnect:
```
sacli --user <USER_NAME> --restart --psid DisconnectUser
```

When you provide text parameters to the sacli command, such as the --client-reason, ensure you enclose it with double quotes. For example, "You have been disconnected by sysadmin". Spaces tend to upset command line programs, but enclosing a text string with double quotes works correctly.

Some clients and configurations attempt to reconnect automatically, regardless of the method used to disconnect a user from the VPN server. If you want the user to stay disconnected in such a situation, you can additionally set the prop_deny property on the user to true. This effectively bans the user from the server. See below for this.

With the prop_deny property, you can deny access to users. You can lift this restriction at any time. You can set this property on a user name, a group name, or the pseudo name __DEFAULT__, and it can be inherited. The user still exists with Access Server with all its settings and certificates retained, but they can’t sign in to the web services or connect to the VPN. If the user has a current VPN connection, then banning the user doesn’t disconnect them, but only prevents them from making a new connection or signing in to the web interface.

You can kick any existing connections using the sacli DisconnectUser function (above).

Connect to the console and get root privileges.

Use these commands for blocking users or groups:

Deny future logins for a user or group:

sacli --user <USER_OR_GROUP> --key "prop_deny" --value "true" UserPropPut

Specifically, allow future logins for a user or group:

sacli --user <USER_OR_GROUP> --key "prop_deny" --value "false" UserPropPut

Restore to default and have it adhere to any inheritance:

sacli --user <USER_OR_GROUP --key "prop_deny" UserPropDel

By default, unlisted accounts are denied access.

When set to "No" (default):
- Successful authentication with an external system (PAM, LDAP, RADIUS, SAML) is accepted even if the user account is absent from the User Permissions table.
- Users can authenticate even if the username doesn't match the one in the external system.
When set to "Yes":
- Users can't authenticate via external systems (PAM, LDAP, RADIUS, SAML) if their account isn't listed in the User Permissions table.
- Authentication will be denied if the username doesn’t match the one in the external system.

Finding and modifying the "def_deny" setting on the CLI⁠

The "def_deny" setting is found under the user profile named DEFAULT in Access Server’s configuration. To view the current value of this setting, run the following command:
```
sacli --pfilt "__DEFAULT__" UserPropGet
```
- Example output:
```
root@openvpnas2:~# sacli --pfilt "__DEFAULT__" UserPropGet
{
  "__DEFAULT__": {
    "def_deny": "false",
    "prop_autogenerate": "true",
    "prop_force_lzo": "false",
    "type": "user_default"
  }
}
```
  1. This means that, by default, users can authenticate even if they're not listed in the User Permissions table or don't match the external system's username.
If you need to change the value of the "def_deny" setting, follow these steps:
1. Access the console and get root privileges.
2. Modify the "def_deny" value. You can set this value to "true" (to deny authentication when the account isn't listed) or "false" (the default setting, allowing authentication even for unlisted accounts).
  Change the value to false (default):
```
sacli --user "__DEFAULT__" --key "def_deny" --value "false" UserPropPut
```
  Change the value to true:
```
sacli --user "__DEFAULT__" --key "def_deny" --value "true" UserPropPut
```
3. Restart and apply changes:
```
sacli start
```

Admin privileges grant a user access to access the Admin Web UI for Access Server. We recommend you give admin privileges only for the administration of Access Server. While you can use user accounts with admin privileges for VPN connections, they may have special access to configured subnets that can disrupt the inheritance of properties from groups, like access control rules. So if you experience a problem where an admin user in a normal group doesn’t receive certain routes or access to specific subnets, that may be why.

Connect to the console and get root privileges.

Use these commands for setting admin privileges:

To grant a user or group admin privileges:

sacli --user <USER_OR_GROUP> --key "prop_superuser" --value "true" UserPropPut

To specifically revoke admin privileges for a user or group:

sacli --user <USER_OR_GROUP> --key "prop_superuser" --value "false" UserPropPut

Restore to default and have it adhere to any inheritance:

sacli --user <USER_OR_GROUP> --key "prop_superuser" UserPropDel

In Access Server versions prior to 3.0, you could enable or disable compression globally from the Advanced VPN section of the Admin Web UI. In version 3.0 and newer, compression settings are no longer available in the UI, but they can still be configured using the command line.

You can manage compression behavior per user or group using the prop_force_lzo property, as shown in the examples below. This allows you to override the global compression setting, or define compression behavior manually if no global setting exists.

If you remove the prop_force_lzo property from a user or group, compression behavior will follow the global configuration if one has been defined via the command line.

Connect to the console and get root privileges.

Set compression settings with these commands:

Enable compression for a given user or group:

sacli --user <USER_OR_GROUP> --key "prop_force_lzo" --value "true" UserPropPut

Disable compression for a given user or group:

sacli --user <USER_OR_GROUP> --key "prop_force_lzo" --value "false" UserPropPut

In the OpenVPN protocol, the redirect-gateway directive tells a VPN client to send all internet traffic through the VPN tunnel. In Access Server 3.0 and newer, you can manage this setting in the Access Controls page under the Internet Access and DNS tab.

The Internet Gateway setting determines whether connected VPN clients route all traffic through the VPN (Full-Tunnel) or only access specified internal resources (Split-Tunnel). To ensure DNS resolution works correctly in full-tunnel mode, you can enable the Push DNS option and choose either Autodetect (uses the server’s system DNS settings) or Custom (manually specify one or more DNS server IP addresses).

The global internet gateway and DNS push settings apply to all clients by default. You can override the redirect-gateway behavior for individual users or groups using the prop_reroute_gw_override property from the command line. Removing this property causes the user or group to fall back to the global tunnel setting.

Connect to the console and get root privileges.

Use these commands for configuring redirect-gateway and DNS server settings:

Disable redirection of internet traffic, and don’t push DNS servers:

sacli --user <USER_OR_GROUP> --key "prop_reroute_gw_override" --value "disable" UserPropPut

Disable redirection of internet traffic, but still push DNS servers:

sacli --user <USER_OR_GROUP> --key "prop_reroute_gw_override" --value "dns_only" UserPropPut

Use the settings as defined under VPN settings , specifically:

sacli --user <USER_OR_GROUP> --key "prop_reroute_gw_override" --value "global" UserPropPut

Restore to default and have it adhere to any inheritance:

sacli --user <USER_OR_GROUP> --key "prop_reroute_gw_override" UserPropDel

Redirect internet traffic for a user, but don’t change DNS settings:

sacli --user <USER_NAME> --key "type" --value "user_compile" UserPropPut
sacli --user <USER_NAME> --key "access_to.0" --value "+NAT:0.0.0.0/1" UserPropPut
sacli --user <USER_NAME> --key "access_to.1" --value "+NAT:128.0.0.0/1" UserPropPut

Redirect internet traffic for a group, but don’t change DNS settings:

sacli --user <GROUP_NAME> --key "access_to.0" --value "+SUBNET:0.0.0.0/1" UserPropPut
sacli --user <GROUP_NAME> --key "access_to.1" --value "+SUBNET:128.0.0.0/1" UserPropPut

In the last two examples, where 0.0.0.0/1 and 128.0.0.0/1 subnets are used to simulate full internet routing, the examples assume there are no other access rules already assigned to the user or group. If additional access rules exist, use the next available configuration key index (e.g., .2, .3, .4, and so on) when adding rules via the command line.

In Access Server 3.0 and newer, the Admin Web UI fully supports adding and managing multiple access rules per user or group, including a mix of NAT and route rules.

You may also see the user_compile property associated with a user. By default, when a user has no custom access rules, the property user_connect is used. This means the user joins the VPN client subnet without requiring custom routing setup. When you assign specific access rules, Access Server switches to using the user_compile property to instruct the server to apply custom network rules for the user during connection.

Sometimes, people want to bypass or exclude a specific IP address or subnet. For example, you might want to redirect all VPN client internet traffic through the VPN server, except for a specific IP address or range of IP addresses that you want to remain on the client side and not be sent through the VPN tunnel. The OpenVPN protocol does this by sending a route directive with a specific route subnet, but then specifies the keyword net_gateway, translated on the client-side as the default gateway address. Such a directive is pushed from the server and looks like this on the client side:

route 192.51.100.0 255.255.255.0 net_gateway

In the mentioned example, where all client internet traffic is being rerouted, except for the subnet just mentioned above, the routing table on the client side looks like this:

0.0.0.0/0 — goes to the local default gateway on the VPN client.
0.0.0.0/1 and 128.0.0.0/1 — goes to the VPN server subnet gateway address.
192.51.100/24 — goes to the local default gateway on the VPN client side.
192.0.2.0/24 — stays on the VPN client's local network; the VPN client is a part of this network.

Since with routing the smallest subnet, or better put, the most specific route, will win, the result is that internet-directed traffic goes through the 0.0.0.0/1 and 128.0.0.0/1 routes since they 'win' over the default 0.0.0.0/0 route, and 192.51.100.0/24 will go to the local default gateway on the VPN client side and not through the VPN tunnel, and 192.0.2.0/24 is the subnet that the VPN client was already on even before connecting to OpenVPN, so that traffic also remains local, unless you were to specifically override it with rules like 192.0.2.0/25 and 192.0.2.128/25 (not recommended).

Connect to the console and get root privileges.
Create a bypass route:
```
sacli --user <USERNAME> --key "bypass_route.N" --value <SUBNET> UserPropPut
sacli start
```
1. The bypass_route.N is a logically numbered range starting with 0 and going up sequentially. If you leave gaps in the sequence, Access Server may not pick up all the subnets correctly, and you must ensure they're numbered right. The subnet can be a single IP such as 203.0.113.10/32 or a range such as 192.0.2.0/24. You can create the bypass route on a user, group, or global level, by using either the user name, the group name, or the __DEFAULT__ meta user name, where <USERNAME> is shown in the above example.

Define multiple subnets by numbering bypass_route.N logically, for example:

sacli --user <USERNAME> --key "bypass_route.0" --value "192.0.2.0/24" UserPropPut
sacli --user <USERNAME> --key "bypass_route.1" --value "198.51.100.54/32" UserPropPut
sacli --user <USERNAME> --key "bypass_route.2" --value "203.0.113.89/32" UserPropPut
sacli start

The server can send a directive to the OpenVPN client to instruct it to block access to the LAN network. The exception is the local internet gateway, and any more specific routes for the local network in the routing table. OpenVPN detects the local network and routes traffic for this network into the VPN tunnel. You can set this block on a user, group, or global level, by using either the user name, the group name, or the __DEFAULT__ meta username, where <USERNAME> is shown in the example below.

Connect to the console and get root privileges.

Turn on the local network block:

sacli --user <USERNAME> --key "prop_block_local" --value "true" UserPropPut
sacli start

Restore to default and have it adhere to any inheritance:

sacli --user <USERNAME> --key "prop_block_local" UserPropDel

In the Admin Web UI, you're limited to specifying a client-side script on a group and then assigning users to those groups. There is no more granularity than that for client-side scripting. However, on the command line, you can set a script on a user, group, or the __DEFAULT__ special keyword from which the default properties for users and groups are inherited.

Connect to the console and get root privileges.

Use the following commands for specifying client-side script options:

Load an on-connect client-side script for Windows:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.win.user.connect" --value_file "./windows-on-connect.txt" UserPropPut

Load an on-connect client-side script for macOS:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.mac.user.connect" --value_file "./macintosh-on-connect.txt" UserPropPut

Load an on-connect client-side script for Linux:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.linux.user.connect" --value_file "./linux-on-connect.txt" UserPropPut

Load an on-connect client-side script for all three platforms:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.all.user.connect" --value_file "./all-on-connect.txt" UserPropPut

Remove an on-connect client-side script of the four types shown above—note that this does not stop inheriting scripts from a higher level:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.win.user.connect" UserPropDel
sacli --user <USER_OR_GROUP> --key "prop_cli.script.mac.user.connect" UserPropDel
sacli --user <USER_OR_GROUP> --key "prop_cli.script.linux.user.connect" UserPropDel
sacli --user <USER_OR_GROUP> --key "prop_cli.script.all.user.connect" UserPropDel

Load an on-disconnect client-side script for Windows:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.win.user.disconnect" --value_file "./windows-on-disconnect.txt" UserPropPut

Load an on-disconnect client-side script for macOS:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.mac.user.disconnect" --value_file "./macintosh-on-disconnect.txt" UserPropPut

Load an on-disconnect client-side script for Linux:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.linux.user.disconnect" --value_file "./linux-on-disconnect.txt" UserPropPut

Load an on-disconnect client-side script for all three platforms:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.all.user.disconnect" --value_file "./all-on-disconnect.txt" UserPropPut

Remove an on-disconnect client-side script of the four types shown above—note that this does not stop inheriting scripts from a higher level:

sacli --user <USER_OR_GROUP> --key "prop_cli.script.win.user.disconnect" UserPropDel
sacli --user <USER_OR_GROUP> --key "prop_cli.script.mac.user.disconnect" UserPropDel
sacli --user <USER_OR_GROUP> --key "prop_cli.script.linux.user.disconnect" UserPropDel
sacli --user <USER_OR_GROUP> --key "prop_cli.script.all.user.disconnect" UserPropDel

You can set a client-side environment variable in the Admin Web UI on the single group page via the Client Scripting tab. However, in the command line, you can set it per group or user individually. You can push variables to the client program available to the client-side script as specified in the section above.

Connect to the console and get root privileges.
Set a client-side environment variable:
```
sacli --user <USER_OR_GROUP> --key "prop_cli.script_env.win.username" --value "john" UserPropPut
```
1. In this example, we're setting the "username" variable.
2. We set the "username" to "john" on the client.
Tip
As with client-side scripting, you can adjust the "win" to "mac", "linux", or "all", to specify if this should apply to Windows, macOS, Linux, or all three of them. In the above example, the key name contains the variable's name. So if you want to specify a variable name "myvariable" then change "username" to "myvariable" in the above example.

Remove the variable setting shown above:

sacli --user <USER_OR_GROUP> --key "prop_cli.script_env.win.username" UserPropDel

Connect to the console and get root privileges.

Set specific server-side directives for a user or group:

sacli --user <USER_OR_GROUP> --key "prop_cc_cmds" --value 'compress lz4-v2,push "compress lz4-v2"' UserPropPut

Remove the specific directive:

sacli --user <USER_OR_GROUP> --key "prop_cc_cmds" UserPropDel

Tutorial: Manage User and Group Properties from the Command Line⁠

Overview⁠

Was this information helpful?