Need to change response type to Access-Challenge from rlm_perl
Hi,
Looking through archives for this exact question, I see a post from 2008 (
http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg47423.html)
where this exact question was previously asked.
Here is my server version info:
radiusd: FreeRADIUS Version 2.2.0, for host x86_64-unknown-linux-gnu, built
on Feb 17 2013 at 03:34:41
Here's my code:
# Construct HTTP request
my $authresult =
authamis($RAD_REQUEST{'User-Name'},$RAD_REQUEST{'User-Password'});
radiusd::radlog(L_DBG, Result after authamis call -
$authresult);
if($authresult eq true) {
$RAD_CHECK{'Response-Packet-Type'} = Access-Challenge;
$RAD_REPLY{'Reply-Message'} = authentication successful;
for (keys %RAD_REPLY) {
radiusd::radlog(L_DBG, RAD_REPLY: $_ =
$RAD_REPLY{$_});
}
for (keys %RAD_CHECK) {
radiusd::radlog(L_DBG, RAD_CHECK: $_ =
$RAD_CHECK{$_});
}
for (keys %RAD_CONFIG) {
radiusd::radlog(L_DBG, RAD_CONFIG: $_ =
$RAD_CONFIG{$_});
}
return RLM_MODULE_OK
}
else {
$RAD_REPLY{'Reply-Message'} = authentication failure;
return RLM_MODULE_REJECT;
}
Here is the relevant debug output:
Found Auth-Type = perl
# Executing group from file
/opt/app/freeradius/etc/raddb/sites-enabled/default
+- entering group perl {...}
rlm_perl: RAD_REQUEST: User-Name = test
rlm_perl: RAD_REQUEST: User-Password = 42594190
rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.65.1
rlm_perl: AMIS request:
http://amis.jdt.com:8080/auth/authenticate/test/42594190
rlm_perl: Result after authamis call - true
rlm_perl: RAD_REPLY: Reply-Message = authentication successful
rlm_perl: RAD_CHECK: Response-Packet-Type = Access-Challenge
rlm_perl: RAD_CHECK: Auth-Type = perl
rlm_perl: RAD_CONFIG: Auth-Type = perl
rlm_perl: Added pair User-Name = test
rlm_perl: Added pair User-Password = 42594190
rlm_perl: Added pair NAS-IP-Address = 192.168.65.1
rlm_perl: Added pair Reply-Message = authentication successful
rlm_perl: Added pair Response-Packet-Type = Access-Challenge
rlm_perl: Added pair Auth-Type = perl
++[perl] returns ok
# Executing section post-auth from file
/opt/app/freeradius/etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 81 to 192.168.65.1 port 53504
Reply-Message = authentication successful
Finished request 0.
Going to the next request
Clearly the Access-Challenge setting is not being honored by the server. Is
there another attribute that must be set to configure the response type?
Thanks,
Walter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Need to change response type to Access-Challenge from rlm_perl
To answer my own question, I found that using the return code RLM_MODULE_OK
triggers the server to respond back with Access-Accept. If I used
RLM_MODULE_HANDLED instead, the response packet type was set to what I
expected it to be. This makes sense since I expect the client to exchange
several messages with me before I finally trigger the Access-Accept message.
On Mon, Feb 18, 2013 at 9:00 AM, Walter Goulet wgou...@gmail.com wrote:
Hi,
Looking through archives for this exact question, I see a post from 2008 (
http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg47423.html)
where this exact question was previously asked.
Here is my server version info:
radiusd: FreeRADIUS Version 2.2.0, for host x86_64-unknown-linux-gnu,
built on Feb 17 2013 at 03:34:41
Here's my code:
# Construct HTTP request
my $authresult =
authamis($RAD_REQUEST{'User-Name'},$RAD_REQUEST{'User-Password'});
radiusd::radlog(L_DBG, Result after authamis call -
$authresult);
if($authresult eq true) {
$RAD_CHECK{'Response-Packet-Type'} = Access-Challenge;
$RAD_REPLY{'Reply-Message'} = authentication successful;
for (keys %RAD_REPLY) {
radiusd::radlog(L_DBG, RAD_REPLY: $_ =
$RAD_REPLY{$_});
}
for (keys %RAD_CHECK) {
radiusd::radlog(L_DBG, RAD_CHECK: $_ =
$RAD_CHECK{$_});
}
for (keys %RAD_CONFIG) {
radiusd::radlog(L_DBG, RAD_CONFIG: $_ =
$RAD_CONFIG{$_});
}
return RLM_MODULE_OK
}
else {
$RAD_REPLY{'Reply-Message'} = authentication failure;
return RLM_MODULE_REJECT;
}
Here is the relevant debug output:
Found Auth-Type = perl
# Executing group from file
/opt/app/freeradius/etc/raddb/sites-enabled/default
+- entering group perl {...}
rlm_perl: RAD_REQUEST: User-Name = test
rlm_perl: RAD_REQUEST: User-Password = 42594190
rlm_perl: RAD_REQUEST: NAS-IP-Address = 192.168.65.1
rlm_perl: AMIS request:
http://amis.jdt.com:8080/auth/authenticate/test/42594190
rlm_perl: Result after authamis call - true
rlm_perl: RAD_REPLY: Reply-Message = authentication successful
rlm_perl: RAD_CHECK: Response-Packet-Type = Access-Challenge
rlm_perl: RAD_CHECK: Auth-Type = perl
rlm_perl: RAD_CONFIG: Auth-Type = perl
rlm_perl: Added pair User-Name = test
rlm_perl: Added pair User-Password = 42594190
rlm_perl: Added pair NAS-IP-Address = 192.168.65.1
rlm_perl: Added pair Reply-Message = authentication successful
rlm_perl: Added pair Response-Packet-Type = Access-Challenge
rlm_perl: Added pair Auth-Type = perl
++[perl] returns ok
# Executing section post-auth from file
/opt/app/freeradius/etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 81 to 192.168.65.1 port 53504
Reply-Message = authentication successful
Finished request 0.
Going to the next request
Clearly the Access-Challenge setting is not being honored by the server.
Is there another attribute that must be set to configure the response type?
Thanks,
Walter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Design question - proxying RADIUS auth request to a backend webservice
Hi, I'm looking for some input from the experts to help validate a solution approach that I've come up with. The problem I'm trying to solve is that allow NAS equipment and other RADIUS clients to authenticate users against a proprietary authentication service that uses REST APIs over HTTP. The solution that I've put together is to use rlm_perl which allows me to use standard Perl modules to interact with the authentication service. I'm pretty happy with the results so far in that I am able to build exactly what I need and authentication against the webservice works just fine. The question to the list, are there other solution approaches that might be better? Any significant disadvantages to using rlm_perl as I've described? Would it be better to write a custom module instead, hoping that by doing so there may be some performance improvements? Any input is greatly appreciated. Walter Goulet - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Design question - proxying RADIUS auth request to a backend webservice
Oh wow; that's even cooler! I'll give that module a shot. Thanks! On Sun, Feb 17, 2013 at 4:12 PM, a.l.m.bu...@lboro.ac.uk wrote: Hi, The question to the list, are there other solution approaches that might be better? Any significant disadvantages to using rlm_perl as I've described? Would it be better to write a custom module instead, hoping that by doing so there may be some performance improvements? PERL method should be fine...the alternative is the latest HEAD (3.x) pre-release code which actually has an rlm_rest module (so no writing of a module to be done!) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Design question - proxying RADIUS auth request to a backend webservice
Thanks for your input; your descriptions of limitations you ran into is helpful. I think I will stick with using rlm_perl for now; I definitely don't want to tackle writing my own stripped down RADIUS server. If performance or scale become problems I will investigate other options at that time. On Sun, Feb 17, 2013 at 5:35 PM, Alexandr Kovalenko alexandr.kovale...@gmail.com wrote: On Sun, Feb 17, 2013 at 11:05 PM, Walter Goulet wgou...@gmail.com wrote: I'm looking for some input from the experts to help validate a solution approach that I've come up with. The problem I'm trying to solve is that allow NAS equipment and other RADIUS clients to authenticate users against a proprietary authentication service that uses REST APIs over HTTP. The solution that I've put together is to use rlm_perl which allows me to use standard Perl modules to interact with the authentication service. I'm pretty happy with the results so far in that I am able to build exactly what I need and authentication against the webservice works just fine. The question to the list, are there other solution approaches that might be better? Any significant disadvantages to using rlm_perl as I've described? Would it be better to write a custom module instead, hoping that by doing so there may be some performance improvements? Any input is greatly appreciated. Not exactly your case, but. Here is my story. I had a need to proxy/convert DHCP requests from equipment (and later - end user's routers/computers (I worked @ISP)) to RADIUS. First version was using FreeRADIUS's rlm_perl for handling incoming DHCP requests and it did work pretty cool, while sometimes it had problems with duplicated requests, didn't scale well (probably my fault, but I didn't wish to find this out) and so on, so I analyzed request patterns, read RFC 2131, and reimplemented DHCP server on pure perl, without using FreeRADIUS's DHCP feature. As a backend RADIUS client (to connect to closed source commercial billing system) I used Authen::Radius first (leftover from quick-n-dirty rlm_perl version), but it didn't work well for me and was not powerful enough, so I used Net::Radius::Packet/Net::Radius::Dictionary and implemented stripped down radius client myself. So, as for your question, besides using rlm_rest (which is devel as of now, as I understand) you may try writing stripped down RADIUS server combined with REST client for your auth service. But for that you either have to reimplement full radius server (which is not an option, I think), or implement just a subset, which works only for your specific equipment. It may be an option. Cheers, Just my $0.02. -- Alexandr Kovalenko http://uafug.org.ua/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[no subject]
Ssee ee - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Patch to update the default CA certificates to use SHA1 instead of MD5
Ah, I never considered that other people's gear (besides my own) wouldn't support SHA1. Would you consider then the following patch to the README file so that people can make an informed decision? --- README.orig2009-08-09 18:31:53.0 -0500 +++ README2009-08-09 18:42:06.0 -0500 @@ -200,3 +200,17 @@ - Someone needs to ask Microsoft to please stop making life hard for their customers. + +SECURITY CONSIDERATIONS + +The default certificate configuration files specify the use of the +MD5/RSA signature algorithm to maintain compatibility with network +equipment that only supports this algorithm. + +MD5/RSA has known weaknesses and is discouraged in favor of SHA1/RSA +(see http://www.kb.cert.org/vuls/id/836068 for details). If your +network equipment supports the SHA1/RSA signature algorithm, it is +recommended that you change the configuration files to specify the use +of SHA1/RSA for the certificates. To do this, change the 'default_md' +entry in the ca.cnf/server.cnf/client.cnf files from 'md5' to 'sha1'. + On Sun, Aug 9, 2009 at 8:47 AM, Alan T DeKok al...@freeradius.org wrote: Walter Goulet wrote: While I was building a version of FreeRADIUS 2.1.6 from source I was testing the certificates that are created using the certs makefile. I noticed that the CA certs (as well as server and client certs) use the default OpenSSL md5rsa signature algorithm. From the recently announced vulnerabilities against certs using this signature algorithm (http://www.kb.cert.org/vuls/id/836068), it would be better if these certificates used the sha1rsa signature algorithm instead. Except a lot of systems still don't support certificates with SHA1 hashes. We had made that change a while ago, and it caused problems. So we changed it back. It's easier to leave it as MD5. If people need SHA1 for security, they can edit the files and create better certificates. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Patch to update the default CA certificates to use SHA1 instead of MD5
Hi, While I was building a version of FreeRADIUS 2.1.6 from source I was testing the certificates that are created using the certs makefile. I noticed that the CA certs (as well as server and client certs) use the default OpenSSL md5rsa signature algorithm. From the recently announced vulnerabilities against certs using this signature algorithm ( http://www.kb.cert.org/vuls/id/836068), it would be better if these certificates used the sha1rsa signature algorithm instead. Note that while the README explicitly states that the default test certificates shouldn't be used, it does tell users to generate their own certificates using the same certificate configuration files. The result is that users following these defaults will end up using md5rsa certificates. The following patches to the ca.cnf, server.cnf, and client.cnf files update them to use sha1rsa. Thanks, Walter --- ca.cnf.orig2009-08-08 22:48:01.0 -0500 +++ ca.cnf2009-08-08 22:49:44.0 -0500 @@ -16,7 +16,7 @@ cert_opt= ca_default default_days= 365 default_crl_days= 30 -default_md= md5 +default_md= sha1 preserve= no policy= policy_match --- client.cnf.orig2009-08-08 22:48:08.0 -0500 +++ client.cnf2009-08-08 22:49:33.0 -0500 @@ -16,7 +16,7 @@ cert_opt= ca_default default_days= 365 default_crl_days= 30 -default_md= md5 +default_md= sha1 preserve= no policy= policy_match --- server.cnf.orig2009-08-08 22:48:16.0 -0500 +++ server.cnf2009-08-08 22:49:56.0 -0500 @@ -16,7 +16,7 @@ cert_opt= ca_default default_days= 365 default_crl_days= 30 -default_md= md5 +default_md= sha1 preserve= no policy= policy_match - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Support for WiMAX VSA
Hi Nitin, Question on your planned contribution to FreeRADIUS: Does your module support the key generation algorithms for the WiMAX mobility keys? Specifically, is your module able to correctly generate the MN-HA-MIP4-KEY and related key material from the EMSK derived as part of the EAP exchange? Personally this was seen as the biggest challenge towards building NWG compliance into FreeRADIUS as opposed to VSA format. Thanks, Walter On 7/18/07, Nitin Naveen [EMAIL PROTECTED] wrote: Hello All, Hi I am Nitin Naveen working with HUGHES SYSTIQUE. We have been working to enhance freeradius to support WiMAX VSA (as per WiMAX NWG forum). WiMAX VSA are not the typical type-length-value rather they have type-length-controlinfo-value. We have enhanced the dictionary but we were not able to generate the attributes as per the WiMAX NWG format. For now we have developed our own rlm_hsc_wimax module. We like to contribute to freeradius so that the WiMAX VSA are supported as part of the standard distribution. To this end we can share our code. But before that we would like to follow the correct procedure for releasing the code. Your inputs and suggestion are awaited. Regards Nitin Naveen Principal Engineer HUGHES SYSTIQUE D-8, Infocity-11 Sector-33, Gugaon Haryana, India tel: +91-124-3045400 fax: +91-124-4039301 [EMAIL PROTECTED] www.hsc.com *DISCLAIMER* This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately and delete the message. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Algorithm used by FreeRADIUS to choose cipher suite used with EAP-TLS/TTLS
Alan DeKok wrote: Walter Goulet wrote: How does FreeRADIUS's rlm_eap module choose the cipher suite used for EAP-TLS/TTLS sessions? It relies on OpenSSL to do the negotiation. RFC 2246 for TLS states that the client presents the list of ciphersuites supported to the server and the server picks one that it supports. Is there a way to configure FreeRADIUS to only use a specific set of ciphersuites? The goal is that in some cases it may be desireable to restrict incoming clients to use a particular suite. Yes. See cipher_list in eap.conf. It's documented. 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/users.html Thanks much Alan; I was looking at my older FreeRADIUS install (1.1.1!) which didn't have this described in eap.conf. I see it in the latest version. Walter - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Algorithm used by FreeRADIUS to choose cipher suite used with EAP-TLS/TTLS
Hi, How does FreeRADIUS's rlm_eap module choose the cipher suite used for EAP-TLS/TTLS sessions? RFC 2246 for TLS states that the client presents the list of ciphersuites supported to the server and the server picks one that it supports. Is there a way to configure FreeRADIUS to only use a specific set of ciphersuites? The goal is that in some cases it may be desireable to restrict incoming clients to use a particular suite. Thanks, Walter - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: When EAP-AKA can be supported by FreeRADIUS?
On 2/2/07, Jeffrey Sewell [EMAIL PROTECTED] wrote: (2). How does FreeRADIUS support WiMAX? No idea. What does the server have to do in order to support WiMAX? Please be specific. :) So far (since WiMAX isn't fully defined yet) all it has to do is support EAP-TLS and EAP-TTLS. EAP-AKA is on the list for WiMAX and will probably be a required EAP method (as well as EAP-SIM) but right now, given the state of WiMAX, FreeRADIUS does support it! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Not only would FreeRADIUS have to support the required EAP methods, but new dictionary files would have to be defined to specify the WiMAX specific VSAs needed to fully enable a WiMAX device. As the previous poster said, WiMAX is not fully defined from a RADIUS perspective at this point. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: parsing certificate fields ?
Alan DeKok wrote: Riccardo Veraldi [EMAIL PROTECTED] wrote: I would like to parse for Locality L field. the new version 1.0.5 support this ? No. As always, patches are welcome. I wonder about this actually; I submitted a patch to pam_radius_auth and didn't get any comments or feedback of any kind. Maybe the diff was too big or something, but I would have expected to get at least a gruff 'your patch sucks' if that was the case... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RadZap
You're not typing in the IP address of the server; 1645 is not the IP address of the server! -N 63.215.26.177 is the IP address of the NAS. On 12/1/05, Radius [EMAIL PROTECTED] wrote: Your man says this. radzap [-d raddb_directory] [-N nas_ip_address] [-P nas_port] [-u user] [-U user] server[:port] secret radzap -d /usr/local/etc/raddb -N 63.215.26.177 -P S406 -u rod 1645 secret Still brings me back to the help screen. - Original Message - From: Alan DeKok [EMAIL PROTECTED] To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Thursday, December 01, 2005 1:06 PM Subject: Re: RadZap Radius [EMAIL PROTECTED] wrote: I would type radzap -N 63.215.26.177 S406 secret Which is wrong. Please READ the help the man page. It keeps telling me it can't locate that IP address. Yes, you're using the command incorrectly. S406 is NOT the IP address of the RADIUS server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Adding a realm to username with pam_radius_auth
Alan DeKok wrote:
Walter Goulet [EMAIL PROTECTED] wrote:
Quick question regarding pam_radius_auth. Since you have to have a
local account on the client machine using pam_radius_auth to
authenticate ssh sessions, how would you go about adding a realm to
the username portion of the authentication request?
Edit the source code to the PAM module, and re-compile.
Can I specify this with the client-id option in the pam_radius_auth
configuration file?
No.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I took a stab at adding support for specifying a realm as an additional
option to the pam module configuration. You can specify the realm that
will be appended to all outgoing RADIUS access requests in the
application specific pam config files in /etc/pam.d.
auth sufficient pam_radius_auth.so debug realm=test.com
I tested this configuration by using openbsd's port of the
radius-cistron 1.6.7 server as my RADIUS proxy server and freeradius
1.0.5 as the radius authenticator that owns the realm. Seems to work ok;
I took a peek at the RADIUS dialog via Ethereal and the access request
is routed correctly to the freeradius server.
I haven't really programmed in C in a while, so please forgive any silly
errors I may have made in the code. Also note that I used svn locally to
keep track of my work, so my revision 1 corresponds to 1.3.16 downloaded
from the freeradius site.
Patch text follows.
Thanks,
Walter
Index: pam_radius_auth.c
===
--- pam_radius_auth.c (revision 1)
+++ pam_radius_auth.c (revision 6)
@@ -25,6 +25,7 @@
* no options. Patch from Jon Nelson [EMAIL PROTECTED]
* 1.3.14 - Don't use PATH_MAX, so it builds on GNU Hurd.
* 1.3.15 - Implement retry option, miscellanous bug fixes.
+
*
*
* This program is free software; you can redistribute it and/or modify
@@ -83,12 +84,12 @@
va_start(args, format);
vsprintf(buffer, format, args);
-/* don't do openlog or closelog, but put our name in to be friendly */
+// don't do openlog or closelog, but put our name in to be friendly
syslog(err, %s: %s, pam_module_name, buffer);
va_end(args);
+printf(Debug Err: %s: %s,pam_module_name,buffer);
}
-/* argument parsing */
static int _pam_parse(int argc, CONST char **argv, radius_conf_t *conf)
{
int ctrl=0;
@@ -131,6 +132,8 @@
} else {
conf-client_id = (char *) *argv+10; /* point to the client-id */
}
+} else if (!strncmp(*argv, realm=, 6)) {
+ conf-client_realm = (char *) *argv+6; /* point to the
client-realm */
} else if (!strcmp(*argv, accounting_bug)) {
conf-accounting_bug = TRUE;
@@ -1050,6 +1053,7 @@
PAM_EXTERN int
pam_sm_authenticate(pam_handle_t *pamh,int flags,int argc,CONST char
**argv)
{
+ char *user_and_realm;
CONST char *user;
char *password = NULL;
CONST char *rhost;
@@ -1063,10 +1067,13 @@
AUTH_HDR *response = (AUTH_HDR *) recv_buffer;
radius_conf_t config;
int tries;
+ int realm_specified = 0;
ctrl = _pam_parse(argc, argv, config);
tries = ((ctrl PAM_RETRY) 4) + 1;
+ realm_specified = strlen(config.client_realm);
+
/* grab the user name */
retval = pam_get_user(pamh, user, NULL);
PAM_FAIL_CHECK;
@@ -1084,6 +1091,16 @@
DPRINT(LOG_DEBUG, Got user name %s, user);
+ if(realm_specified)
+ {
+ user_and_realm = malloc(strlen(user) + MAXPWNAM); /* making
maxlen of realm value MAXPWNAM seems
+ reasonable. */
+ memset(user_and_realm, 0, strlen(user_and_realm));
+ strncat(user_and_realm,user,strlen(user));
+ strncat(user_and_realm,@,1);
+
strncat(user_and_realm,config.client_realm,strlen(config.client_realm));
+ }
+
/*
* Get the IP address of the authentication server
* Then, open a socket, and bind it to a port
@@ -1133,7 +1150,14 @@
}
} /* end of password == NULL */
- build_radius_packet(request, user, password, config);
+ if(realm_specified)
+ {
+ build_radius_packet(request, user_and_realm, password, config);
+ }
+ else
+ {
+ build_radius_packet(request, user_and_realm, password, config);
+ }
/* not all servers understand this service type, but some do */
add_int_attribute(request, PW_USER_SERVICE_TYPE, PW_AUTHENTICATE_ONLY);
@@ -1183,7 +1207,14 @@
retval = rad_converse(pamh, PAM_PROMPT_ECHO_ON, challenge,
resp2challenge);
/* now that we've got a response, build a new radius packet */
-build_radius_packet(request, user, resp2challenge, config);
+if(realm_specified)
+{
+build_radius_packet(request, user_and_realm, resp2challenge,
config);
+}
+else
+{
+build_radius_packet(request, user, resp2challenge, config);
+}
/* request-code is already PW_AUTHENTICATION_REQUEST */
request-id++; /* one up from
Adding a realm to username with pam_radius_auth
Hi, Quick question regarding pam_radius_auth. Since you have to have a local account on the client machine using pam_radius_auth to authenticate ssh sessions, how would you go about adding a realm to the username portion of the authentication request? Reason I'm asking is because I'd like to use pam_radius_auth on a client machine that talks to a AAA proxy server. The proxy server needs to use the realm name to figure out which AAA server to route the request to. Can I specify this with the client-id option in the pam_radius_auth configuration file? Thanks, Walter - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
