I have reloaded the server and started from scratch again. I was able to authenticate with the default config, when adding client and user info. In my effort to try and convert each client to use a separate virtual so separate user files can be used I am not able to authenticate. I see the auth attempt match an entry in my second_users file, but I get a WARNING message. I would appreciate if you could look at the following output ant point me in the right direction of how to resolve what I am missing. Thanks. Starting - reading configuration files ... including configuration file /etc/raddb//radiusd.conf including configuration file /etc/raddb//proxy.conf including configuration file /etc/raddb//clients.conf including files in directory /etc/raddb//modules/ including configuration file /etc/raddb//modules/linelog including configuration file /etc/raddb//modules/acct_unique including configuration file /etc/raddb//modules/redis including configuration file /etc/raddb//modules/ippool including configuration file /etc/raddb//modules/soh including configuration file /etc/raddb//modules/wimax including configuration file /etc/raddb//modules/ntlm_auth including configuration file /etc/raddb//modules/sradutmp including configuration file /etc/raddb//modules/inner-eap including configuration file /etc/raddb//modules/pam including configuration file /etc/raddb//modules/detail.example.com including configuration file /etc/raddb//modules/perl including configuration file /etc/raddb//modules/replicate including configuration file /etc/raddb//modules/exec including configuration file /etc/raddb//modules/expr including configuration file /etc/raddb//modules/opendirectory including configuration file /etc/raddb//modules/smbpasswd including configuration file /etc/raddb//modules/attr_rewrite including configuration file /etc/raddb//modules/realm including configuration file /etc/raddb//modules/passwd including configuration file /etc/raddb//modules/detail including configuration file /etc/raddb//modules/unix including configuration file /etc/raddb//modules/checkval including configuration file /etc/raddb//modules/digest including configuration file /etc/raddb//modules/pap including configuration file /etc/raddb//modules/echo including configuration file /etc/raddb//modules/mac2vlan including configuration file /etc/raddb//modules/counter including configuration file /etc/raddb//modules/always including configuration file /etc/raddb//modules/cui including configuration file /etc/raddb//modules/logintime including configuration file /etc/raddb//modules/otp including configuration file /etc/raddb//modules/files including configuration file /etc/raddb//modules/detail.log including configuration file /etc/raddb//modules/sqlcounter_expire_on_login including configuration file /etc/raddb//modules/rediswho including configuration file /etc/raddb//modules/dynamic_clients including configuration file /etc/raddb//modules/chap including configuration file /etc/raddb//modules/attr_filter including configuration file /etc/raddb//modules/sql_log including configuration file /etc/raddb//modules/preprocess including configuration file /etc/raddb//modules/mschap including configuration file /etc/raddb//modules/smsotp including configuration file /etc/raddb//modules/expiration including configuration file /etc/raddb//modules/radutmp including configuration file /etc/raddb//modules/etc_group including configuration file /etc/raddb//modules/policy including configuration file /etc/raddb//modules/mac2ip including configuration file /etc/raddb//eap.conf including configuration file /etc/raddb//policy.conf including files in directory /etc/raddb//sites-enabled/ including configuration file /etc/raddb//sites-enabled/default including configuration file /etc/raddb//sites-enabled/control-socket including configuration file /etc/raddb//sites-enabled/smoothtest including configuration file /etc/raddb//sites-enabled/inner-tunnel main { user = "radiusd" group = "radiusd" allow_core_dumps = no } including dictionary file /etc/raddb//dictionary main { name = "radiusd" prefix = "/usr" localstatedir = "/var" sbindir = "/usr/sbin" logdir = "/var/log/radius" run_dir = "/var/run/radiusd" libdir = "/usr/lib64/freeradius" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 pidfile = "/var/run/radiusd/radiusd.pid" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = yes log { stripped_names = no auth = no auth_badpass = no auth_goodpass = no } security { max_attributes = 200 reject_delay = 1 status_server = yes } } radiusd: #### Loading Realms and Home Servers #### proxy server { retry_delay = 5 retry_count = 3 default_fallback = no dead_time = 120 wake_all_if_all_dead = no } home_server localhost { ipaddr = 127.0.0.1 port = 1812 type = "auth" secret = "testing123" response_window = 20 max_outstanding = 65536 require_message_authenticator = yes zombie_period = 40 status_check = "status-server" ping_interval = 30 check_interval = 30 num_answers_to_alive = 3 num_pings_to_alive = 3 revive_interval = 120 status_check_timeout = 4 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server_pool my_auth_failover { type = fail-over home_server = localhost } realm example.com { auth_pool = my_auth_failover } realm LOCAL { } radiusd: #### Loading Clients #### radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating module "exec" from file /etc/raddb//modules/exec exec { wait = no input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating module "expr" from file /etc/raddb//modules/expr Module: Linked to module rlm_expiration Module: Instantiating module "expiration" from file /etc/raddb//modules/expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating module "logintime" from file /etc/raddb//modules/logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server { # from file /etc/raddb//radiusd.conf modules { Module: Creating Auth-Type = digest Module: Creating Post-Auth-Type = REJECT Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating module "pap" from file /etc/raddb//modules/pap pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating module "chap" from file /etc/raddb//modules/chap Module: Linked to module rlm_mschap Module: Instantiating module "mschap" from file /etc/raddb//modules/mschap mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no allow_retry = yes } Module: Linked to module rlm_digest Module: Instantiating module "digest" from file /etc/raddb//modules/digest Module: Linked to module rlm_unix Module: Instantiating module "unix" from file /etc/raddb//modules/unix unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_eap Module: Instantiating module "eap" from file /etc/raddb//eap.conf eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 4096 } Module: Linked to sub-module rlm_eap_md5 Module: Instantiating eap-md5 Module: Linked to sub-module rlm_eap_leap Module: Instantiating eap-leap Module: Linked to sub-module rlm_eap_gtc Module: Instantiating eap-gtc gtc { challenge = "Password: " auth_type = "PAP" } Module: Linked to sub-module rlm_eap_tls Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes rsa_key_length = 512 dh_key_length = 512 verify_depth = 0 CA_path = "/etc/raddb//certs" pem_file_type = yes private_key_file = "/etc/raddb//certs/server.pem" certificate_file = "/etc/raddb//certs/server.pem" CA_file = "/etc/raddb//certs/ca.pem" private_key_password = "whatever" dh_file = "/etc/raddb//certs/dh" random_file = "/etc/raddb//certs/random" fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" cache { enable = no lifetime = 24 max_entries = 255 } verify { } ocsp { enable = no override_cert_url = yes url = "http://127.0.0.1/ocsp/" } } Module: Linked to sub-module rlm_eap_ttls Module: Instantiating eap-ttls ttls { default_eap_type = "md5" copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" include_length = yes } Module: Linked to sub-module rlm_eap_peap Module: Instantiating eap-peap peap { default_eap_type = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no } Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no send_error = no } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating module "preprocess" from file /etc/raddb//modules/preprocess preprocess { huntgroups = "/etc/raddb//huntgroups" hints = "/etc/raddb//hints" with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no with_alvarion_vsa_hack = no } Module: Linked to module rlm_realm Module: Instantiating module "suffix" from file /etc/raddb//modules/realm realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating module "files" from file /etc/raddb//modules/files files { usersfile = "/etc/raddb//users" acctusersfile = "/etc/raddb//acct_users" preproxy_usersfile = "/etc/raddb//preproxy_users" compat = "no" } Module: Checking preacct {...} for more modules to load Module: Linked to module rlm_acct_unique Module: Instantiating module "acct_unique" from file /etc/raddb//modules/acct_unique acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } Module: Checking accounting {...} for more modules to load Module: Linked to module rlm_detail Module: Instantiating module "detail" from file /etc/raddb//modules/detail detail { detailfile = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Linked to module rlm_radutmp Module: Instantiating module "radutmp" from file /etc/raddb//modules/radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Linked to module rlm_attr_filter Module: Instantiating module "attr_filter.accounting_response" from file /etc/raddb//modules/attr_filter attr_filter attr_filter.accounting_response { attrsfile = "/etc/raddb//attrs.accounting_response" key = "%{User-Name}" relaxed = no } Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Instantiating module "attr_filter.access_reject" from file /etc/raddb//modules/attr_filter attr_filter attr_filter.access_reject { attrsfile = "/etc/raddb//attrs.access_reject" key = "%{User-Name}" relaxed = no } } # modules } # server server smoothtest { # from file /etc/raddb//sites-enabled/smoothtest modules { Module: Checking authorize {...} for more modules to load Module: Instantiating module "second_files" from file /etc/raddb//modules/files files second_files { usersfile = "/etc/raddb//second_users" acctusersfile = "/etc/raddb//second_acct_users" preproxy_usersfile = "/etc/raddb//second_preproxy_users" compat = "cistron" } [/etc/raddb//second_users]:1 Cistron compatibility checks for entry vin001 ... [/etc/raddb//second_users]:174 Cistron compatibility checks for entry DEFAULT ... [/etc/raddb//second_users]:181 Cistron compatibility checks for entry DEFAULT ... [/etc/raddb//second_users]:188 Cistron compatibility checks for entry DEFAULT ... } # modules } # server server inner-tunnel { # from file /etc/raddb//sites-enabled/inner-tunnel modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load } # modules } # server radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 0 clients = "disambiguate" client TEST1 { ipaddr = 172.16.22.7 require_message_authenticator = no secret = "test" nastype = "cisco" virtual_server = "smoothtest" } client localhost { ipaddr = 127.0.0.1 require_message_authenticator = no secret = "testing123" nastype = "other" } } listen { type = "acct" ipaddr = * port = 0 clients = "disambiguate" } listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 60134 Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host 172.16.22.7 port 1645, id=39, length=76 User-Name = "vin001" User-Password = "admin123" NAS-Port-Type = Virtual NAS-Port = 182 NAS-Port-Id = "72.1.94.34" NAS-IP-Address = 172.16.22.7 server smoothtest { # Executing section authorize from file /etc/raddb//sites-enabled/smoothtest +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "vin001", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [second_files] users: Matched entry vin001 at line 1 ++[second_files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP WARNING: Unknown value specified for Auth-Type. Cannot perform requested action. Failed to authenticate the user. } # server smoothtest Using Post-Auth-Type Reject WARNING: Unknown value specified for Post-Auth-Type. Cannot perform requested action. Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 39 to 172.16.22.7 port 1645 Waking up in 4.9 seconds. Cleaning up request 0 ID 39 with timestamp +156 Ready to process requests.
Vincent Rusilowicz wrote:
I have reloaded the server and started from scratch again. I was able to authenticate with the default config, when adding client and user info. In my effort to try and convert each client to use a separate virtual so separate user files
You still haven't explained *why* you need that. You're focusing on a solution. Instead, talk about the problem. Maybe there's another solution which is better.
can be used I am not able to authenticate. I see the auth attempt match an entry in my second_users file, but I get a WARNING message.
Yes, because you butchered the configuration, and broke it. You deleted the "pap" module from the "authenticate" section. Why? Just... why? What possible benefit is there from destroying the "authenticate" section? If you *do* want "users" files which are unique per client, there are a few ways to do it. The choice of solutions can depend on how many clients you have. One way may be this: - create multiple instances of the "files" module, one for each client. - name them after the clients, so that you can keep track of which module matches which client. i.e. name them after the client IP address, for simplicity. i.e. files files_192.168.1.2 { ... } - select them dynamically at run-time via a "switch" statement. - i.e. remove the "files" reference from "authorize", and replace it with a switch: switch "%{Client-IP-Address}" { case { files } case 192.168.1.2 { files_192.168.1.2 } ... } And don't change *anything* else. Butchering random things in the configuration files is a guaranteed way to break the server. Alan DeKok.
I have a Multi Tennant VPN gateway that I terminate multiple customers on. If I authenticate sessions to local database on router there is no segregation, so one customer can authenticate to another customers VPN (inserting the connection into that specific VRF) with any local username password on the router. I can source radius auth requests from IP's specific to individual customer VRF's and need to use a segregated username password database to service these requests. I would like the solution to be able to scale to at least 100 clients that use individual username/password files. Is the solution you recommended above the best way to handle this. For the pap configuration in the model I tried to get working I copied the default file in sites-available and the only changes I made were adding server smoothtest { ... } and changing files to second_files in authorize { ... } and preacct { ... }. Did this cause the pap authentication to break? So I can understand what you are suggesting: - create multiple instances of the "files" module, one for each client. - name them after the clients, so that you can keep track of which module matches which client. i.e. name them after the client IP address, for simplicity. i.e. files files_192.168.1.2 { ... } Are you saying make multiple instances inside the existing files module, like how "second_files" was created, or copy the files module multiple times to creating client specifi file names and modify its content to files files_192.168.1.2 { . - select them dynamically at run-time via a "switch" statement. - i.e. remove the "files" reference from "authorize", and replace it with a switch: switch "%{Client-IP-Address}" { case { files } case 192.168.1.2 { files_192.168.1.2 } ... } . If I use the above I would only need to add the : case 192.168.1.2 { files_192.168.1.2 section for each additional client correct and files module created right? For this method I should remove the virtual server I created and add the lines you suggest to the default file in sites-available in the authorize section? Thanks for the help. From: Alan DeKok-2 [via FreeRADIUS] [mailto:ml-node+s1045715n5720335h18@n5.nabble.com] Sent: Wednesday, May 22, 2013 10:17 AM To: Vincent Rusilowicz Subject: Re: Virtual server setup Vincent Rusilowicz wrote:
I have reloaded the server and started from scratch again. I was able to authenticate with the default config, when adding client and user info. In my effort to try and convert each client to use a separate virtual so separate user files
You still haven't explained *why* you need that. You're focusing on a solution. Instead, talk about the problem. Maybe there's another solution which is better.
can be used I am not able to authenticate. I see the auth attempt match an entry in my second_users file, but I get a WARNING message.
Yes, because you butchered the configuration, and broke it. You deleted the "pap" module from the "authenticate" section. Why? Just... why? What possible benefit is there from destroying the "authenticate" section? If you *do* want "users" files which are unique per client, there are a few ways to do it. The choice of solutions can depend on how many clients you have. One way may be this: - create multiple instances of the "files" module, one for each client. - name them after the clients, so that you can keep track of which module matches which client. i.e. name them after the client IP address, for simplicity. i.e. files files_192.168.1.2 { ... } - select them dynamically at run-time via a "switch" statement. - i.e. remove the "files" reference from "authorize", and replace it with a switch: switch "%{Client-IP-Address}" { case { files } case 192.168.1.2 { files_192.168.1.2 } ... } And don't change *anything* else. Butchering random things in the configuration files is a guaranteed way to break the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ________________________________ If you reply to this email, your message will be added to the discussion below: http://freeradius.1045715.n5.nabble.com/Virtual-server-setup-tp5720304p57203... To unsubscribe from Virtual server setup, click here<http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5720304&code=dnJ1c2lsb3dpY3pAd2VzdGlwYy5jb218NTcyMDMwNHw0MjEzOTIwOTc=>. NAML<http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
Vincent Rusilowicz wrote:
I have a Multi Tennant VPN gateway that I terminate multiple customers on. If I authenticate sessions to local database on router there is no segregation, so one customer can authenticate to another customers VPN (inserting the connection into that specific VRF) with any local username password on the router. I can source radius auth requests from IP’s specific to individual customer VRF’s and need to use a segregated username password database to service these requests. I would like the solution to be able to scale to at least 100 clients that use individual username/password files. Is the solution you recommended above the best way to handle this.
No. This is what databases are for. Create a database with 3 columns. One is client IP. The second is the user name. The third is the password. When the server receives a request, you can select the password by client IP and user-name. That leaves RADIUS doing RADIUS work, and databases storing data. Using the RADIUS server to store lots of client accounts works, but is best to avoid for complicated situations.
Are you saying make multiple instances inside the existing files module, like how “second_files” was created, or copy the files module multiple times to creating client specifi file names and modify its content to files files_192.168.1.2 { .
Yes.
If I use the above I would only need to add the :
case 192.168.1.2 { files_192.168.1.2
section for each additional client correct and files module created right?
Yes.
For this method I should remove the virtual server I created and add the lines you suggest to the default file in sites-available in the authorize section?
Yes. Alan DeKok.
I figured out why my method did not work. Rookie mistake, in raddb/sites-available/smoothtest I did not put my closing bracket "}' at the end of the entire file, but at the end of the authorize section, sorry about the confusion here. I am still intrigued by your suggestion as it seems a lot less work to meet the same goal. If you have time an can answer my questions regarding the info you posted I would appreciate it. Thanks From: Alan DeKok-2 [via FreeRADIUS] [mailto:ml-node+s1045715n5720335h18@n5.nabble.com] Sent: Wednesday, May 22, 2013 10:17 AM To: Vincent Rusilowicz Subject: Re: Virtual server setup Vincent Rusilowicz wrote:
I have reloaded the server and started from scratch again. I was able to authenticate with the default config, when adding client and user info. In my effort to try and convert each client to use a separate virtual so separate user files
You still haven't explained *why* you need that. You're focusing on a solution. Instead, talk about the problem. Maybe there's another solution which is better.
can be used I am not able to authenticate. I see the auth attempt match an entry in my second_users file, but I get a WARNING message.
Yes, because you butchered the configuration, and broke it. You deleted the "pap" module from the "authenticate" section. Why? Just... why? What possible benefit is there from destroying the "authenticate" section? If you *do* want "users" files which are unique per client, there are a few ways to do it. The choice of solutions can depend on how many clients you have. One way may be this: - create multiple instances of the "files" module, one for each client. - name them after the clients, so that you can keep track of which module matches which client. i.e. name them after the client IP address, for simplicity. i.e. files files_192.168.1.2 { ... } - select them dynamically at run-time via a "switch" statement. - i.e. remove the "files" reference from "authorize", and replace it with a switch: switch "%{Client-IP-Address}" { case { files } case 192.168.1.2 { files_192.168.1.2 } ... } And don't change *anything* else. Butchering random things in the configuration files is a guaranteed way to break the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ________________________________ If you reply to this email, your message will be added to the discussion below: http://freeradius.1045715.n5.nabble.com/Virtual-server-setup-tp5720304p57203... To unsubscribe from Virtual server setup, click here<http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5720304&code=dnJ1c2lsb3dpY3pAd2VzdGlwYy5jb218NTcyMDMwNHw0MjEzOTIwOTc=>. NAML<http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
participants (2)
-
Alan DeKok -
Vincent Rusilowicz