PAM Module Patch and Feature
Greetings, I am working on using FreeRadius with token authentication and ran into a small snag. Under Linux, attempts to authenticate 'su' result in a query to the Radius server for the user 'root'. What we would like to happen is for the query to be for the requesting user. This is how the 'sudo' application handles it's PAM requests. I of course do not want to change the default behavior of the module, so I added an option. I named it 'ruser' since it works by causing the PAM module to authenticate using the value of PAM_RUSER (requesting user). The 'su' application provides this value, so that's an easy place to grab it from. I expect that this patch may need more work. It doesn't do much sanity checking on the values of PAM_RUSER. There may be applications which don't fill it in properly. I haven't checked extensively. Also, I worked from the Debian source version which includes a patch for CVE-2005-0108: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0108 I'm not sure who maintains the PAM portion of FreeRadius, so I'm throwing this out for discussion. Does this seem like something which could be included in the distribution? Or should I plan on using a locally patched version for the foreseeable future? -- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | ----------------------------------------------------------------- --- ./pam_radius_auth.c 2007-03-12 10:18:18.000000000 -0600 +++ ./libpam-radius-auth-1.3.16/pam_radius_auth.c 2007-03-15 13:43:45.000000000 -0600 @@ -134,6 +134,9 @@ } else if (!strcmp(*argv, "accounting_bug")) { conf->accounting_bug = TRUE; + } else if (!strcmp(*argv, "ruser")) { + ctrl |= PAM_RUSER_ARG; + conf->ruser = 1; } else if (!strcmp(*argv, "debug")) { ctrl |= PAM_DEBUG_ARG; conf->debug = 1; @@ -1051,6 +1054,7 @@ pam_sm_authenticate(pam_handle_t *pamh,int flags,int argc,CONST char **argv) { CONST char *user; + CONST char **userinfo; char *password = NULL; CONST char *rhost; char *resp2challenge = NULL; @@ -1084,6 +1088,24 @@ DPRINT(LOG_DEBUG, "Got user name %s", user); + + retval = pam_get_item(pamh, PAM_USER, (CONST void **) &userinfo); + PAM_FAIL_CHECK; + DPRINT(LOG_DEBUG, "Got PAM_USER name %s", userinfo); + retval = pam_get_item(pamh, PAM_RUSER, (CONST void **) &userinfo); + PAM_FAIL_CHECK; + DPRINT(LOG_DEBUG, "Got PAM_RUSER name %s", userinfo); + if (ctrl & PAM_RUSER_ARG) { + if (!strncmp("root",user,5)) { + user = userinfo; + DPRINT(LOG_DEBUG, "Username now %s from ruser", user); + } else { + DPRINT(LOG_DEBUG, "Skipping ruser for non-root auth"); + }; + }; + + + /* * Get the IP address of the authentication server * Then, open a socket, and bind it to a port @@ -1176,6 +1198,9 @@ goto error; } + if (a_reply->length < 2 || a_state->length < 2) + goto error; + memcpy(challenge, a_reply->data, a_reply->length - 2); challenge[a_reply->length - 2] = 0; --- ./pam_radius_auth.h 2007-03-12 10:18:11.000000000 -0600 +++ ./libpam-radius-auth-1.3.16/pam_radius_auth.h 2007-03-13 13:44:09.000000000 -0600 @@ -51,6 +51,7 @@ int accounting_bug; int sockfd; int debug; + int ruser; } radius_conf_t; @@ -82,6 +83,7 @@ #define PAM_SKIP_PASSWD 2 #define PAM_USE_FIRST_PASS 4 #define PAM_TRY_FIRST_PASS 8 +#define PAM_RUSER_ARG 16 #define PAM_RETRY 0x30
@@ -1176,6 +1198,9 @@ goto error; }
+ if (a_reply->length < 2 || a_state->length < 2) + goto error; + memcpy(challenge, a_reply->data, a_reply->length - 2); challenge[a_reply->length - 2] = 0;
What's this bit about? Doesn't the length check done just above this addition make this superfluous? -frank
On March 19, 2007 7:23:16 PM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
@@ -1176,6 +1198,9 @@ goto error; }
+ if (a_reply->length < 2 || a_state->length < 2) + goto error; + memcpy(challenge, a_reply->data, a_reply->length - 2); challenge[a_reply->length - 2] = 0;
What's this bit about? Doesn't the length check done just above this addition make this superfluous?
Ah, nevermind.
Also, I worked from the Debian source version which includes a patch for CVE-2005-0108: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0108
A version of that fix is already in cvs, and the diff is fuzzy enough that it still applied. -frank
On March 15, 2007 2:40:42 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Greetings,
I am working on using FreeRadius with token authentication and ran into a small snag. Under Linux, attempts to authenticate 'su' result in a query to the Radius server for the user 'root'. What we would like to happen is for the query to be for the requesting user. This is how the 'sudo' application handles it's PAM requests.
Interesting. Why don't you just use 'sudo' then? Having 'su' be distinct and accept the actual root password can be useful.
I of course do not want to change the default behavior of the module, so I added an option. I named it 'ruser' since it works by causing the PAM module to authenticate using the value of PAM_RUSER (requesting user).
It actually stands for remote user. ...
I'm not sure who maintains the PAM portion of FreeRadius, so I'm throwing this out for discussion. Does this seem like something which could be included in the distribution?
I don't see why not. I've cleaned up the patch, how does it look? You were stepping on PAM_RETRY, not really your fault, the code for that part is pretty ... awful. Otherwise, I just deferred looking for PAM_RUSER until it might actually be used. I'm happy to put it back the way you had it if you specifically wanted it that way for some reason. -frank
David, Awaiting your feedback. Maybe you didn't realize freeradius-devel responses go to the list [only]. I'm cc'ing you just in case. There might be a pref you can change in your subscription to have replies go to you. Or just set reply-to. -frank On March 19, 2007 7:50:19 PM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
On March 15, 2007 2:40:42 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Greetings,
I am working on using FreeRadius with token authentication and ran into a small snag. Under Linux, attempts to authenticate 'su' result in a query to the Radius server for the user 'root'. What we would like to happen is for the query to be for the requesting user. This is how the 'sudo' application handles it's PAM requests.
Interesting. Why don't you just use 'sudo' then? Having 'su' be distinct and accept the actual root password can be useful.
I of course do not want to change the default behavior of the module, so I added an option. I named it 'ruser' since it works by causing the PAM module to authenticate using the value of PAM_RUSER (requesting user).
It actually stands for remote user.
...
I'm not sure who maintains the PAM portion of FreeRadius, so I'm throwing this out for discussion. Does this seem like something which could be included in the distribution?
I don't see why not.
I've cleaned up the patch, how does it look?
You were stepping on PAM_RETRY, not really your fault, the code for that part is pretty ... awful. Otherwise, I just deferred looking for PAM_RUSER until it might actually be used. I'm happy to put it back the way you had it if you specifically wanted it that way for some reason.
-frank
On Mar 21, 2007, at 7:02 PM, Frank Cusack wrote:
David,
Awaiting your feedback. Maybe you didn't realize freeradius-devel responses go to the list [only]. I'm cc'ing you just in case. There might be a pref you can change in your subscription to have replies go to you. Or just set reply-to.
I just hadn't gotten around to replying yet. I think it looks good. Stomping on the retry value was an accident on my part. Maybe it could be made more explicit by including them in the bit value list? Then it would be more obvious that 128 is the next unused value? #define PAM_DEBUG_ARG 1 #define PAM_SKIP_PASSWD 2 #define PAM_USE_FIRST_PASS 4 #define PAM_TRY_FIRST_PASS 8 #define PAM_RUSER_ARG 16 #define PAM_RETRY 32+64 -David Mitchell
-frank
On March 19, 2007 7:50:19 PM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
On March 15, 2007 2:40:42 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Greetings,
I am working on using FreeRadius with token authentication and ran into a small snag. Under Linux, attempts to authenticate 'su' result in a query to the Radius server for the user 'root'. What we would like to happen is for the query to be for the requesting user. This is how the 'sudo' application handles it's PAM requests.
Interesting. Why don't you just use 'sudo' then? Having 'su' be distinct and accept the actual root password can be useful.
I of course do not want to change the default behavior of the module, so I added an option. I named it 'ruser' since it works by causing the PAM module to authenticate using the value of PAM_RUSER (requesting user).
It actually stands for remote user.
...
I'm not sure who maintains the PAM portion of FreeRadius, so I'm throwing this out for discussion. Does this seem like something which could be included in the distribution?
I don't see why not.
I've cleaned up the patch, how does it look?
You were stepping on PAM_RETRY, not really your fault, the code for that part is pretty ... awful. Otherwise, I just deferred looking for PAM_RUSER until it might actually be used. I'm happy to put it back the way you had it if you specifically wanted it that way for some reason.
-frank
On March 22, 2007 9:43:21 AM -0600 David Mitchell <mitchell@ucar.edu> wrote:
I just hadn't gotten around to replying yet. I think it looks good. Stomping on the retry value was an accident on my part. Maybe it could be made more explicit by including them in the bit value list? Then it would be more obvious that 128 is the next unused value?
great idea. -frnk
Frank Cusack wrote:
On March 22, 2007 10:28:36 AM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
The ruser feature has been commited. Alan, could you roll up a new release? -frank
Actually, hold off on that. I have another change I've been working on for awhile that I'd like to commit.
I would actually like to do a little more testing as well before it's committed. I get very different behavior in 'su' versus 'sudo' which I want to understand better. I think it's something with the clients and not the PAM modules. Either way, I want to make sure I understand it in case it's something my patch is doing. -David
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
David Mitchell wrote:
Frank Cusack wrote:
On March 22, 2007 10:28:36 AM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
The ruser feature has been commited. Alan, could you roll up a new release? -frank Actually, hold off on that. I have another change I've been working on for awhile that I'd like to commit.
I would actually like to do a little more testing as well before it's committed. I get very different behavior in 'su' versus 'sudo' which I want to understand better. I think it's something with the clients and not the PAM modules. Either way, I want to make sure I understand it in case it's something my patch is doing.
I think I figured out the source for the 'odd' behavior I was seeing. In a nutshell, my timeout on the PAM module side was shorter than the delay imposed by the freeradius server for bad passwords. I need to play around more and find out what a 'safe' value is. Do you happen to know where in the freeradius/otpd/lsmd chain the bad password delay is being imposed? I can probably find it, but I'm guessing that you know. -David
-David
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
On March 22, 2007 4:27:44 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
I think I figured out the source for the 'odd' behavior I was seeing. In a nutshell, my timeout on the PAM module side was shorter than the delay imposed by the freeradius server for bad passwords. I need to play around more and find out what a 'safe' value is. Do you happen to know where in the freeradius/otpd/lsmd chain the bad password delay is being imposed? I can probably find it, but I'm guessing that you know.
The radiusd.conf 'reject_delay' option. I always set this to 0. -frank
Frank Cusack wrote:
On March 22, 2007 4:27:44 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
I think I figured out the source for the 'odd' behavior I was seeing. In a nutshell, my timeout on the PAM module side was shorter than the delay imposed by the freeradius server for bad passwords. I need to play around more and find out what a 'safe' value is. Do you happen to know where in the freeradius/otpd/lsmd chain the bad password delay is being imposed? I can probably find it, but I'm guessing that you know.
The radiusd.conf 'reject_delay' option. I always set this to 0.
Here's the really weird part. If I set reject_delay to 0, it works just like I expect. But if I set it to some value like 1, which is the default, it delays for about 30 seconds. Unless I run radiusd with -X to see what's going on in which case it works as expected with a one second delay. I'll keep digging into the cause to see if it's something in my build or what. It seems like if this was a common bug it would be reported by now, but I did a quick search for reject_delay in the bug database and didn't find anything. I'll see if I can figure it out. -David
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
On March 23, 2007 4:37:42 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Frank Cusack wrote:
On March 22, 2007 4:27:44 PM -0600 David Mitchell <mitchell@ucar.edu> wrote:
I think I figured out the source for the 'odd' behavior I was seeing. In a nutshell, my timeout on the PAM module side was shorter than the delay imposed by the freeradius server for bad passwords. I need to play around more and find out what a 'safe' value is. Do you happen to know where in the freeradius/otpd/lsmd chain the bad password delay is being imposed? I can probably find it, but I'm guessing that you know.
The radiusd.conf 'reject_delay' option. I always set this to 0.
Here's the really weird part. If I set reject_delay to 0, it works just like I expect. But if I set it to some value like 1, which is the default, it delays for about 30 seconds.
That sounds suspicously like the cleanup delay kicking in.
Unless I run radiusd with -X to see what's going on in which case it works as expected with a one second delay. I'll keep digging into the cause to see if it's something in my build or what.
It seems like if this was a common bug it would be reported by now, but I did a quick search for reject_delay in the bug database and didn't find anything. I'll see if I can figure it out.
That would be awesome. It's possible that the reject_delay only recently broke. -frank
On 3/24/07, Frank Cusack <fcusack@fcusack.com> wrote:
The radiusd.conf 'reject_delay' option. I always set this to 0.
Here's the really weird part. If I set reject_delay to 0, it works just like I expect. But if I set it to some value like 1, which is the default, it delays for about 30 seconds.
That sounds suspicously like the cleanup delay kicking in.
Right. Try changing value of max_request_time. It should affect time, after which you'll receive reject. However, I'm not sure, if reject received is "original reject" or "new" one generated due to hitting max_request_time. Or configure your client to retry after some time. If retry interval is greater than reject_delay, freeradius will send reject immediately. I guess that's the reason this issue is not noticed very often, since network devices are usually configured to retry after few seconds. You can experiment with radclient and various values of timeout (-t).
Unless I run radiusd with -X to see what's going on in which case it works as expected with a one second delay. I'll keep digging into the cause to see if it's something in my build or what.
Run radiusd -fxx. This problem only seem to appear in multi-threaded mode. Single threaded mode seems to work correctly.
It seems like if this was a common bug it would be reported by now, but I did a quick search for reject_delay in the bug database and didn't find anything. I'll see if I can figure it out.
That would be awesome.
It's possible that the reject_delay only recently broke.
Not really ;). Try searching mailing list archive. This issue has been reported several times. Usually with little or no response. Btw: Similar issue seems to affect proxy scheduler. If you set synchronous to no (which is default), you can set retry_delay and retry_count. However, those values will only be applied if client asks often enough. If retry_delay is set to 5 (default again) and client will send first retry after e.g. 15 seconds, freeradius will also retry after 15 seconds for the first time. Client's retries received before retry_delay are dropped. Is it a bug in event scheduling in multi-threaded mode or design decision to rely on clients' retries to trigger execution of pending events? th.
Frank Cusack wrote:
I didn't design it, but it looks clearly like a bug.
It's a bug. I had thought it was fixed in 1.1.x, but apparently not. I'll change the default "reject_delay" to 0 in 1.1.6. It is fixed in the CVS head, and I have patches pending that delete "request_list.c" and "request_process.c", which contain pretty horrible code. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 3/25/07, Alan DeKok <aland@deployingradius.com> wrote:
Frank Cusack wrote:
I didn't design it, but it looks clearly like a bug.
It's a bug. I had thought it was fixed in 1.1.x, but apparently not.
I'll change the default "reject_delay" to 0 in 1.1.6.
It is fixed in the CVS head, and I have patches pending that delete "request_list.c" and "request_process.c", which contain pretty horrible code.
Is it single issue causing both reject_delay and proxy retry scheduling problems? Can you sched some light on details of the problem? Is any patch planned for 1.1.x? Thanks! th.
Tomas Hoger wrote:
Is it single issue causing both reject_delay and proxy retry scheduling problems? Can you sched some light on details of the problem? Is any patch planned for 1.1.x?
Pretty much. The server *should* have a concept of events, as in "when to do something". Plus, it should have a concept of state, as in "the request is in state FOO". Right now, it just brute-forces through all requests looking for something to do, and it does a bunch of awkward checks to try to figure out what state the request is in. Both current methods are wrong. I'm fixing both in the CVS head, but the patches will *not* go into 1.1.x. They're just too invasive. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 3/26/07, Alan DeKok <aland@deployingradius.com> wrote:
Is it single issue causing both reject_delay and proxy retry scheduling problems? Can you sched some light on details of the problem? Is any patch planned for 1.1.x?
Pretty much. The server *should* have a concept of events, as in "when to do something". Plus, it should have a concept of state, as in "the request is in state FOO". Right now, it just brute-forces through all requests looking for something to do, and it does a bunch of awkward checks to try to figure out what state the request is in.
Thanks for explanation! That's what I was asking for when asking whether it's design decision or just bug. ;)
Both current methods are wrong. I'm fixing both in the CVS head, but the patches will *not* go into 1.1.x. They're just too invasive.
Ok, thanks! th.
Alan DeKok wrote:
Tomas Hoger wrote:
Is it single issue causing both reject_delay and proxy retry scheduling problems? Can you sched some light on details of the problem? Is any patch planned for 1.1.x?
Pretty much. The server *should* have a concept of events, as in "when to do something". Plus, it should have a concept of state, as in "the request is in state FOO". Right now, it just brute-forces through all requests looking for something to do, and it does a bunch of awkward checks to try to figure out what state the request is in.
Both current methods are wrong. I'm fixing both in the CVS head, but the patches will *not* go into 1.1.x. They're just too invasive.
That's cool. Based on that, I will just find values which work well enough for my purposes and not worry about digging too deeply into the cause. Thanks, -David Mitchell
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
On March 22, 2007 10:35:36 AM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
On March 22, 2007 10:28:36 AM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
The ruser feature has been commited. Alan, could you roll up a new release? -frank
Actually, hold off on that. I have another change I've been working on for awhile that I'd like to commit.
It's submitted. Please make a new release whenever you are ready. The new feature is a 'localifdown' option. Previously, you would need to be using Linux-PAM and the extended pam.conf syntax to ignore PAM_AUTHINFO_UNAVAIL return values. Now, with 'localifdown', the module returns PAM_IGNORE instead of PAM_AUTHINFO_UNAVAIL, which works for all pam stacks. -frank
Frank Cusack wrote:
On March 22, 2007 10:35:36 AM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
On March 22, 2007 10:28:36 AM -0700 Frank Cusack <fcusack@fcusack.com> wrote:
The ruser feature has been commited. Alan, could you roll up a new release? -frank Actually, hold off on that. I have another change I've been working on for awhile that I'd like to commit.
It's submitted. Please make a new release whenever you are ready.
The new feature is a 'localifdown' option. Previously, you would need to be using Linux-PAM and the extended pam.conf syntax to ignore PAM_AUTHINFO_UNAVAIL return values. Now, with 'localifdown', the module returns PAM_IGNORE instead of PAM_AUTHINFO_UNAVAIL, which works for all pam stacks.
Nice. Will this be the case for all timeout situations? Or only if the local interface is actually down? I was actually experimenting with the extended syntax last week when I found the timeout problem. -David Mitchell
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
On March 26, 2007 8:57:38 AM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Frank Cusack wrote:
The new feature is a 'localifdown' option. Previously, you would need to be using Linux-PAM and the extended pam.conf syntax to ignore PAM_AUTHINFO_UNAVAIL return values. Now, with 'localifdown', the module returns PAM_IGNORE instead of PAM_AUTHINFO_UNAVAIL, which works for all pam stacks.
Nice. Will this be the case for all timeout situations? Or only if the local interface is actually down? I was actually experimenting with the extended syntax last week when I found the timeout problem.
All timeouts. Is there a different behavior you would like? -frank
Frank Cusack wrote:
On March 26, 2007 8:57:38 AM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Frank Cusack wrote:
The new feature is a 'localifdown' option. Previously, you would need to be using Linux-PAM and the extended pam.conf syntax to ignore PAM_AUTHINFO_UNAVAIL return values. Now, with 'localifdown', the module returns PAM_IGNORE instead of PAM_AUTHINFO_UNAVAIL, which works for all pam stacks. Nice. Will this be the case for all timeout situations? Or only if the local interface is actually down? I was actually experimenting with the extended syntax last week when I found the timeout problem.
All timeouts. Is there a different behavior you would like?
No, that's perfect. It's just the name that threw me off. I was basically doing the exact same thing via the extended syntax. Lke this: auth [success=done authinfo_unavail=ignore default=die] pam_radius_auth.so debug -David
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
On March 26, 2007 10:17:22 AM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Frank Cusack wrote:
On March 26, 2007 8:57:38 AM -0600 David Mitchell <mitchell@ucar.edu> wrote:
Frank Cusack wrote:
The new feature is a 'localifdown' option. Previously, you would need to be using Linux-PAM and the extended pam.conf syntax to ignore PAM_AUTHINFO_UNAVAIL return values. Now, with 'localifdown', the module returns PAM_IGNORE instead of PAM_AUTHINFO_UNAVAIL, which works for all pam stacks. Nice. Will this be the case for all timeout situations? Or only if the local interface is actually down? I was actually experimenting with the extended syntax last week when I found the timeout problem.
All timeouts. Is there a different behavior you would like?
No, that's perfect. It's just the name that threw me off. I was basically doing the exact same thing via the extended syntax. Lke this: auth [success=done authinfo_unavail=ignore default=die] pam_radius_auth.so debug
Right. 'localifdown' does exactly that without the extended syntax. -frank
Frank Cusack wrote:
The ruser feature has been commited. Alan, could you roll up a new release?
OK. I'm in Prague right now, so I'll do it Sunday or Monday. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (4)
-
Alan DeKok -
David Mitchell -
Frank Cusack -
Tomas Hoger