An access rule defines a restriction, or under what circumstances a service or role should be granted.

An access rule may be thoroughly customized using boolean operators. The 'Access rule' interface provides a series of buttons for use when writing a rule (and, or, not, (, ), true and false). Using these buttons, one can for instance define a service which is only available to two specific clients connecting to one specific server, only during office hours or on holidays, and only to users authenticated with smart cards.

When access rules are saved, a sanity check is done on the expression. If the expression is not valid, the access rule will not be saved to the database, and a detailed error report will be shown to the administrator.

Access rules consist of the following types of statements:

          (not from(*.appgate.com)) and auth(certificate)
        

          from(*.appgate.com) and (auth(certificate) or auth(password))
        

          secure_from_intranet or secure_from_internet
        

The 'Client Check Setup' section of the console allows the administrator to upload and define Client Check Commands.

Client Check Commands are commands which are run on the client machine when the client connects to an AppGate server. The output from these commands is used to set attributes which can be used in Access rules. The commands are stored on the AppGate server and downloaded to the client machine (if they have not already been downloaded when connecting at an earlier time).

The command may be any form of file that may be executed on the designated client platform (e.g a native Win32 binary for Windows, a .bat file for Windows or a Bourne-shell script for Unix). It must return exit code zero if the attribute should be set. The attribute is then set to the last line of output on stdout.

To upload a new command executable, click on the 'Upload...' button and select the file that should be uploaded. By default, the AppGate server has the executable called check.exe already uploaded and ready for use.

To add a new Client Check Command, click on the 'Add...' button and specify which attribute that should be set, which platform the Client Check Command applies to, which executable will be run, and which arguments will be given to the executable.

To edit an existing Client Check Command, either double-click on the Client Check Command or select one from the list and click on the 'Edit...' button.

To remove an existing Client Check Command, select one from the list and click on the 'Delete' button.

Binary commands that have not been assigned an attribute are listed without an attribute and can not be edited, but they can be deleted by selecting them and clicking on the 'Delete' button.

 -fileexists file
 -filesizeis file size
 -filesizelarger file size
 -filesizesmaller file size
 -fileversion file
 -productversion file
 -md5sum file
 -sha1sum file
 -regexists root key value
 -regprint root key value
 -getprivateprofilestring appname key def file 
 -fsecureavversion print | max age in days 
 -sophosmaxage rtime
  where rtime is of the form nn['d'|'h'|'m']
 -process name
 -exec command...
 -isadmin
 -issvcrunning name
 -querysvc name
 -isportbusy port
 -matchoutput command needle1...
 -isnetbtenabled
 -canmountagshares
 -isunitmounted driveletter
 -downloadto url [-hash hash] file
  hash is of the form {md5,sha1}:XXXXX...
 -downloadandrun url [hash]
  hash is of the form {md5,sha1}:XXXXX...
 -downloadandrunasarg url [-hash hash] cmd
  hash is of the form {md5,sha1}:XXXXX...
  cmd may contain #f which will be expanded to the file name
  of the downloaded copy of the file to which the url points.
 -downloadanddo url op [hash]
  where op is one of: edit, explore, find, open or print
  and hash is of the form {md5,sha1}:XXXXX...
 -afiledateis file date
 -afiledatenewer file date
 -afiledateolder file date
  where date is of the form yyyymmdd[hh[mm[ss]]].
 -rfiledatenewer file rtime
 -rfiledateolder file rtime
  where rtime is of the form nn['d'|'h'|'m']
          

 -fileexists %windir%/notepad.exe
 -regexists HKEY_LOCAL_MACHINE "Software/Microsoft/Internet Explorer" Build
 -regprint HKLM "Software/Microsoft/Internet Explorer" Build
 -process mstask.exe
 -afiledateis c:/windows/notepad.exe 20040401
 -afiledatenewer c:/windows/notepad.exe 200404012359
 -afiledateolder %windir%/notepad.exe 20040401235959
 -rfiledatenewer c:/windows/notepad.exe 10d
 -rfiledateolder #REG[HKLM,Software/ACME Software,SomeValue] 10h
          

It is possible to add your own server-defined attributes by writing a small script that the server will run for each user at login. Attributes created this way must be prefixed with "script."

The script is a standalone program, it can be written as a shell script, in perl or be a compiled binary. Existing attributes are available to the script as environment variables. Each attribute is stored in an environment variable with the same name as the attribute except that dots are replaced with underscores. The new attributes should be written to stdout in a space separated form. A newline should follow after each pair. E.g:

script.test1 value_1
script.test2 An other value
      

To add the script to the login process, transfer it to the appgate server and run ag_cfggetset -s agsh.client_attributes_script /path/to/your_script

A net group is a way to define a group of destination hosts for use in multiple components, such as IP Access components and others.

As an example assume a group of servers, named h1, h2 and h3. Access to those servers may be defined in a number of different Services. It means that the list h1,h2,h3 is used as "Destination hosts(s)" in a number of different places. If another host h4 is needed, it is then necessary to modify all occurrences of h1,h2,h3 and make it into h1,h2,h3,h4. This can be tedious and error prone and the use of net groups can help.

As an example, a net group, called $OURSERVERS can be defined, initially with the Hosts value set to h1,h2,h3. In all the Services and their IP Access components, or other components with a Destination hosts(s) field, it is then possible to refer to the net group by typing in $OURSERVERS instead of the actual host list. If it later on is necessary to add the fourth host, h4, it can just be add it to the definition of $OURSERVERS in the net groups panel and it will affect all components referring $OURSERVERS.

Net groups work much like a variable, it is a pure text substitution that is done on the Destination hosts(s) field of a component before it go into action. This means that it is not limited to only a list of hosts, it can be networks ranges and IP-numbers following the same syntax as for the component where it is referenced.

The name of a net group must be begin with a "$", both in the definition and when it is referenced. It is recommended, though not required, to write them in all uppercase letters.