Custom State Tables

Tracking Versions

You can embed version information into a state table using the following syntax:

FSMID Version 

Examples

State table modifications can range from simple to more involved customization and offer a great deal of flexibility when configuring the HP-UX AAA software.

Preprocessing Module

An Access-Request message may need to be pre-processed for a variety of reasons. For example, if the client sends a User-Name value with extraneous information, the extraneous information may need to be stripped out before the server authenticates the user. Preprocessing requires that you write or obtain a plug-in that will parse the message and pass the processed A-V pairs to the iaaaUsers action.

Modify the state table to call the preprocessing plug-in when the message is first received. Add a preprocessing state that calls the iaaaUsers action and transitions to the UsersCheck state.

1 START: 2 *.+AUTHEN.ACK PREPROC Preauth 3 *.+AUTHENTICATE.ACK PREPROC Preauth 4 Preauth: 5 *.PREPROC.ACK iaaaUsers UsersCheck 6 *.PREPROC.NAK REPLY Hold 7 . . .

Line 1-3

*.+AUTHEN.ACK or +AUTHENTICATE.ACK indicates that the received message is an Access-Request. PREPROC indicates the action, which calls the custom PREPROC software module. PREPROC is programmed to parse User-Name, strip out the extraneous information, and assign the result to the User-Id attribute. (The server uses User-Id to locate a stored user profile.) If PREPROC is successful it returns an ACK event name; otherwise, it returns a NAK. Preauth indicates the next state the FSM must proceed to, after PREPROC returns an ACK or NAK event name.

Line 4

As described for steps 1 to 3, Preauth is the next state after PREPROC has parsed User-Name and returned an ACK or NAK value.

Line 5

If PREPROC returns an ACK value, handling of the request continues normally with the modified user name.

Line 6

If PREPROC returns a NAK value, the request will be rejected.

	NOTE: When listing an event, you need to specify the last action only if it is required for the finite state table to correctly determine the next action. In this case, the Preauth events *.*.ACK and *.*.NAK on lines 5 and 6 would also work.

Interim Logging

To indicate that a session is still active, the client will send an accounting message at regular intervals (defined by the client) during the session. To generate session logs when the server receives this accounting message, you need to modify one line in the AACTlog state.

*.*.ACCT_ALIVE    LOG     REPLYHold 

The REPLY action has been replaced with LOG, which is the Action that writes the session log. If you want to log other accounting messages, you must change the action to LOG for the event that corresponds to the message that must be logged.

	NOTE: A AAA Server-provided state table, logall.fsm, will log all accounting messages.

Custom Logging Format

Using a custom-logging format requires that you write or obtain a plug-in that will generate a session log. In each instance when you want to use your custom format, you must replace the LOG action in the state table with the name of the appropriate action defined in your plug-in. The ACCTLog state in the following example uses a logging format generated by MYLOG for an ordinary session and uses another format generated by TUNNELLOG for tunnel sessions.

ACCTlog:
    *.*.ACCT_START               REPLY        Hold
    *.*.ACCT_STOP                MYLOG        REPLYHold
    *.*.ACCT_ALIVE               REPLY        Hold
    *.*.ACCT_MSTART              REPLY        Hold
    *.*.ACCT_MSTOP               MYLOG        REPLYHold
    *.*.ACCT_CANCEL              REPLY        Hold
    *.*.ACCT_ON                  MYLOG        REPLYHold
    *.*.ACCT_OFF                 MYLOG        REPLYHold
    *.*.ACCT_TUNNEL_START        REPLY        Hold
    *.*.ACCT_TUNNEL_STOP         TUNNELLOG    REPLYHold
    *.*.ACCT_TUNNEL_REJECT       TUNNELLOG    REPLYHold
    *.*.ACCT_TUNNEL_LINK_START   REPLY        Hold
    *.*.ACCT_TUNNEL_LINK_STOP    TUNNELLOG    REPLYHold
    *.*.ACCT_TUNNEL_LINK_REJECT  TUNNELLOG    REPLYHold 

Proxy Accounting Messages

If you have a distributed network of AAA servers, you can choose to centralize log records for some or all of the accounting logs at a single location. The RAD2RAD action can forward accounting messages to another server, as specified by an Xstring value. If all accounting messages will be forwarded to a remote server, the ACCTlog state in the forwarding server's state table can be removed, or commented out as shown below.

1 . . .
2 ACCTwait:
3 *.*.ACK RAD2RAD REPLYHold Xstring="default.accounting.proxy.server"
4 IPPool:
5 *.*.ACK POSTLAS Tunneling
6 *.*.NAK POSTLAS REPLYHold
7 . . .
8 REPLYHold:
9 *.*.ACK REPLY Hold
10 *.*.NAK REPLY Hold
11 *.*.ACC_CHAL REPLY Hold
12 *.*.ACCT_DUP RAD2RAD REPLYHold Xstring="default.accounting.proxy.server"
13 Hold:
14 *.*.TIMEOUT NULL End
15 End:

	NOTE: This example appears in the AAA Server-provided template file, proxyacct.fsm.

DNIS Routing

In a typical DNIS routing scheme, requests are handled according to the Calling-Station-Id and Called-Station-Id attributes. This conditional handling of requests can be accomplished by invoking the POLICY action with an Xstring value at the beginning of the finite state table. The Xstring value must refer to the place where policy is stored. In this example, the policy is stored in a decision file named DNIS.grp.

The POLICY action matches the Calling-Station-Id and Called-Station-Id attribute values in the Access-Request to a group of conditions defined in the decision file, see “Decision Files ”. Depending on the results of the match, a set of reply items is attached to the request and an event value is returned.

1  %event Forward
2  %event Abandon
3  Start:
4      *.+AUTHEN.ACK          POLICY         Start2 Xstring=decisionfile:DNIS.grp
5      *.+AUTH_ONLY.ACK       POLICY         Start2 Xstring=decisionfile:DNIS.grp
6      *.+AUTHENTICATE.ACK    POLICY         Start2 Xstring=decisionfile:DNIS.grp
7      *.+ACCT.ACK            POLICY         Start2 Xstring=decisionfile:DNIS.grp
8      *.+LAS_ACCT.ACK        POLICY         Start2 Xstring=decisionfile:DNIS.grp
9      *.+LASCP.ACK           LASCP          End
10     *.+MGT_POLL.ACK        SRV_STATUS     REPLYHold
11     *.*.NAK                REPLY          Hold
12 Start2:
13     *.*.Forward            RAD2RAD        REPLYHold Xstring=flatland.com
14     *.*.Abandon            NULL           End
15     *.*.AUTHEN             iaaaUsers      UsersCheck
16     *.*.AUTH_ONLY          iaaaUsers      AuthOnly
17     *.*.AUTHENTICATE       iaaaUsers      UsersCheck
18     *.*.ACCT               LAS_ACCT       ACCTwait
19     *.*.LAS_ACCT           LAS_ACCT       ACCTwait
20     *.*.LASCP              LASCP          End
21     *.*.MGT_POLL           SRV_STATUS     REPLYHold
22     *.*.NAK                REPLY          Hold
23 ...

	NOTE: This example appears in the template file, DNIS.fsm.

Dynamic Access Control

You can control when users can access your services. This conditional handling of requests can be accomplished by creating two authentication states and invoking the POLICY action with an Xstring value in the first Authen state. The Xstring value must refer to the place where policy is stored. In this example, the policy is stored in a decision file named DAC.grp.

The POLICY action matches the system time with time-based conditions defined with dynamic access control attributes in the decision file. Depending on the results of the match, an ACK or NAK event value will be returned and the FSM will handle the value accordingly in the next authentication state.

Start:
*.+AUTHEN.ACK        POLICY      Start2    Xstring=decisionfile:DAC.grp
*.+AUTH_ONLY.ACK     iaaaUsers   AuthOnly
*.+AUTHENTICATE.ACK  POLICY      Start2    Xstring=decisionfile:DAC.grp
*.+ACCT.ACK          LAS_ACCT    AcctWait
*.+LAS_ACCT.ACK      LAS_ACCT    AcctWait
*.+LASCP.ACK         LASCP       End
*.+MGT_POLL.ACK      SRV_STATUS  ReplyHold
*.*.NAK              REPLY       End
 
Start2:
*.*.ACK              iaaaUsers   UsersCheck
*.*.NAK              REPLY       Hold
 
AuthOnly:
*.*.RETRIEVE_SUCCESS iaaaAuthenticate  ReplyHold
*.*.RETRIEVE_ERROR   iaaaRealm         AuthOnly2       Xvalue=1
*.*.ACK              REPLY             Hold

	NOTE: This example appears in the template file, DAC.fsm.