# A client may belong in multiple groups, and in certain use-cases
# it is needed to switch between them. For these cases the client can
# select prior to authentication. Add multiple entries for multiple groups.
# The group may be followed by a user-friendly name in brackets.
#select-group = group1
#select-group = group2[My special group]

# The name of the (virtual) group that if selected it would assign the user
# to its default group.
#default-select-group = DEFAULT

# Instead of specifying manually all the allowed groups, you may instruct
# ocserv to scan all available groups and include the full list.
#auto-select-group = true

# Configuration files that will be applied per user connection or
# per group. Each file name on these directories must match the username
# or the groupname.
# The options allowed in the configuration files are dns, nbns,
# ipv?-network, ipv4-netmask, rx/tx-per-sec, iroute, route,
# net-priority, deny-roaming, no-udp, user-profile, and cgroup.
#
# Note that the 'iroute' option allows to add routes on the server
# based on a user or group. The syntax depends on the input accepted
# by the commands route-add-cmd and route-del-cmd (see below). The no-udp
# is a boolean option (e.g., no-udp = true), and will prevent a UDP session
# for that specific user or group.

#config-per-user = /etc/ocserv/config-per-user/
#config-per-group = /etc/ocserv/config-per-group/

# When config-per-xxx is specified and there is no group or user that
# matches, then utilize the following configuration.
#default-user-config = /etc/ocserv/defaults/user.conf
#default-group-config = /etc/ocserv/defaults/group.conf

# The system command to use to setup a route. %{R} will be replaced with the
# route/mask and %{D} with the (tun) device.
#
# The following example is from linux systems. %R should be something
# like 192.168.2.0/24 (the argument of iroute).

#route-add-cmd = "ip route add %{R} dev %{D}"
#route-del-cmd = "ip route delete %{R} dev %{D}"

# This option allows to forward a proxy. The special keywords '%{U}'
# and '%{G}', if present will be replaced by the username and group name.
#proxy-url = http://example.com/
#proxy-url = http://example.com/%{U}/

# This option allows you to specify a URL location where a client can
# post using MS-KKDCP, and the message will be forwarded to the provided
# KDC server. That is a translation URL between HTTP and Kerberos.
# In MIT kerberos you'll need to add in realms:
# EXAMPLE.COM = {
# kdc = https://ocserv.example.com/kerberos
# http_anchors = FILE:/etc/ocserv-ca.pem
# }
# This option is available if ocserv is compiled with GSSAPI support.

#kkdcp = SERVER-PATH KERBEROS-REALM PROTOCOL@SERVER:PORT
#kkdcp = /kerberos EXAMPLE.COM [email protected]:88
#kkdcp = /kerberos-tcp EXAMPLE.COM [email protected]:88

#
# The following options are for (experimental) AnyConnect client
# compatibility.

# This option must be set to true to support legacy CISCO clients.
# A side effect of this option is that it will no longer be required
# for clients to present their certificate on every connection.
# That is they may resume a cookie without presenting a certificate
# (when certificate authentication is used).
cisco-client-compat = true

# Client profile xml. A sample file exists in doc/profile.xml.
# It is required by some of the CISCO clients.
# This file must be accessible from inside the worker's chroot.
#user-profile = /etc/ocserv/profile.xml

# Binary files that may be downloaded by the CISCO client. Must
# be within any chroot environment. Normally you don't need
# to use this option.
#binary-files = /path/to/binaries

#Advanced options

# Option to allow sending arbitrary custom headers to the client after
# authentication and prior to VPN tunnel establishment. You shouldn't
# need to use this option normally; if you do and you think that
# this may help others, please send your settings and reason to
# the openconnect mailing list. The special keywords '%{U}'
# and '%{G}', if present will be replaced by the username and group name.
#custom-header = "X-My-Header: hi there"