When the authentication step says the user the is rejected, the
"Post-Auth-Type" attribute is overwritten with the value "REJECT". It
gives the possibility to alter Access-Accept and Access-Reject replies
with a different list of modules.
The patch is associated with some additional documentation about
post-authentication (see below).
$ cvs diff -u src/main/auth.c
Index: src/main/auth.c
===================================================================
RCS file: /source/radiusd/src/main/auth.c,v
retrieving revision 1.128
diff -u -r1.128 auth.c
--- src/main/auth.c 3 Sep 2003 15:19:28 -0000 1.128
+++ src/main/auth.c 12 Sep 2003 17:11:17 -0000
@@ -376,6 +376,53 @@
}
/*
+ * Post-authentication step process the response before it's
+ * sent to the NAS. It may alter Access-Accept as well as
+ * Access-Reject replies.
+ *
+ * It returns only RLM_MODULE_OK or RLM_MODULE_REJECT when a
+ * module says so.
+ */
+static int rad_postauth(REQUEST *request)
+{
+ int result;
+ int postauth_type = 0;
+ VALUE_PAIR *postauth_type_item = NULL;
+
+ postauth_type_item = pairfind(request->config_items, PW_POST_AUTH_TYPE);
+ if (postauth_type_item)
+ postauth_type = postauth_type_item->lvalue;
+ result = module_post_auth(postauth_type, request);
+ switch (result) {
+ default:
+ break;
+
+ /*
+ * The module failed, or said to reject the user: Do so.
+ */
+ case RLM_MODULE_FAIL:
+ case RLM_MODULE_REJECT:
+ case RLM_MODULE_USERLOCK:
+ case RLM_MODULE_INVALID:
+ request->reply->code = PW_AUTHENTICATION_REJECT;
+ result = RLM_MODULE_REJECT;
+ break;
+
+ /*
+ * The module had a number of OK return codes.
+ */
+ case RLM_MODULE_NOTFOUND:
+ case RLM_MODULE_NOOP:
+ case RLM_MODULE_UPDATED:
+ case RLM_MODULE_OK:
+ case RLM_MODULE_HANDLED:
+ result = RLM_MODULE_OK;
+ break;
+ }
+ return result ;
+}
+
+/*
* Process and reply to an authentication request
*
* The return value of this function isn't actually used right now, so
@@ -390,7 +437,6 @@
VALUE_PAIR *module_msg;
VALUE_PAIR *tmp = NULL;
VALUE_PAIR *autz_type_item = NULL;
- VALUE_PAIR *postauth_type_item = NULL;
int result, r;
char umsg[MAX_STRING_LEN + 1];
const char *user_msg = NULL;
@@ -401,7 +447,6 @@
char buf[1024], logstr[1024];
char autz_retry = 0;
int autz_type = 0;
- int postauth_type = 0;
password = "";
@@ -708,9 +753,22 @@
}
/*
- * Result should be >= 0 here - if not, we return.
+ * Result should be >= 0 here - if not, it means the user
+ * is rejected, so we overwrite the post-auth-type with
+ * the value "REJECT" and call the post-authentication
+ * step.
*/
if (result < 0) {
+ DICT_VALUE *dval;
+
+ dval = dict_valbyname(PW_POST_AUTH_TYPE, "REJECT");
+ if (dval) {
+ pairdelete(&request->config_items, PW_POST_AUTH_TYPE);
+ tmp = paircreate(PW_POST_AUTH_TYPE, PW_TYPE_INTEGER);
+ tmp->lvalue = dval->value;
+ pairadd(&request->config_items, tmp);
+ rad_postauth(request);
+ }
return RLM_MODULE_OK;
}
@@ -888,40 +946,7 @@
if (exec_program)
free(exec_program);
- /*
- * Do post-authentication calls. ignoring the return code.
- * If the post-authentication
- */
- postauth_type_item = pairfind(request->config_items, PW_POST_AUTH_TYPE);
- if (postauth_type_item)
- postauth_type = postauth_type_item->lvalue;
- result = module_post_auth(postauth_type, request);
- switch (result) {
- default:
- break;
-
- /*
- * The module failed, or said to reject the user: Do so.
- */
- case RLM_MODULE_FAIL:
- case RLM_MODULE_REJECT:
- case RLM_MODULE_USERLOCK:
- case RLM_MODULE_INVALID:
- request->reply->code = PW_AUTHENTICATION_REJECT;
- result = RLM_MODULE_REJECT;
- break;
-
- /*
- * The module had a number of OK return codes.
- */
- case RLM_MODULE_NOTFOUND:
- case RLM_MODULE_NOOP:
- case RLM_MODULE_UPDATED:
- case RLM_MODULE_OK:
- case RLM_MODULE_HANDLED:
- result = RLM_MODULE_OK;
- break;
- }
+ result = rad_postauth(request);
return result;
}
$ cat doc/post-authentication
The post-authentication step process the response before it's sent to
the NAS. You should put there a list of modules to alter the reply or
do some logging activities after the authentication step.
These actions are defined in the "post-auth" section of the
"radiusd.conf" file. For example, if you want to do server side IP
pool management:
post-auth {
# Get an address from the IP Pool.
my_ippool
}
The "post-auth" section may contain one or more "Post-Auth-Type"
blocks to select between different lists of modules or between
multiple instances of a module which have been configured differently.
When the authentication step says the user the is rejected, the
"Post-Auth-Type" attribute is overwritten with the value "REJECT". It
gives the possibility to alter Access-Accept and Access-Reject replies
with a different list of modules.
Let's see an example where you want to give an IP address to
authenticated users and write some info in a log file for rejected
users.
The "users" file should look something like this:
DEFAULT Post-Auth-Type := dyn_ip
And the "radiusd.conf" file:
post-auth {
Post-Auth-Type dyn_ip {
# Get an address from the IP Pool.
my_ippool
}
Post-Auth-Type REJECT {
# Write a detailed log.
my_detail
}
}
--
Nicolas Baradakis
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
