Greetings, I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest locally as well as remotely and it works great. Now I want to point the server to my /etc/shadow file which lives on the same machine. I have not made any changes to the default config except to change the group ownership of my shadow file to radiusd so the radius daemon can access it. On startup here is the output: [root@labprinter raddb]# radiusd -X FreeRADIUS Version 2.1.7, for host x86_64-redhat-linux-gnu, built on Mar 31 2010 at 00:14:28 Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. 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/radutmp including configuration file /etc/raddb/modules/digest including configuration file /etc/raddb/modules/files including configuration file /etc/raddb/modules/detail.log including configuration file /etc/raddb/modules/mac2vlan including configuration file /etc/raddb/modules/unix including configuration file /etc/raddb/modules/smsotp including configuration file /etc/raddb/modules/linelog including configuration file /etc/raddb/modules/inner-eap including configuration file /etc/raddb/modules/echo including configuration file /etc/raddb/modules/sqlcounter_expire_on_login including configuration file /etc/raddb/modules/sql_log including configuration file /etc/raddb/modules/detail including configuration file /etc/raddb/modules/exec including configuration file /etc/raddb/modules/etc_group including configuration file /etc/raddb/modules/expiration including configuration file /etc/raddb/modules/realm including configuration file /etc/raddb/modules/sradutmp including configuration file /etc/raddb/modules/acct_unique including configuration file /etc/raddb/modules/logintime including configuration file /etc/raddb/modules/perl including configuration file /etc/raddb/modules/ippool including configuration file /etc/raddb/modules/counter including configuration file /etc/raddb/modules/attr_rewrite including configuration file /etc/raddb/modules/policy including configuration file /etc/raddb/modules/passwd including configuration file /etc/raddb/modules/mac2ip including configuration file /etc/raddb/modules/mschap including configuration file /etc/raddb/modules/detail.example.com including configuration file /etc/raddb/modules/preprocess including configuration file /etc/raddb/modules/checkval including configuration file /etc/raddb/modules/chap including configuration file /etc/raddb/modules/pam including configuration file /etc/raddb/modules/expr including configuration file /etc/raddb/modules/always including configuration file /etc/raddb/modules/otp including configuration file /etc/raddb/modules/pap including configuration file /etc/raddb/modules/smbpasswd including configuration file /etc/raddb/modules/cui including configuration file /etc/raddb/modules/attr_filter including configuration file /etc/raddb/modules/wimax 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/inner-tunnel including configuration file /etc/raddb/sites-enabled/default including configuration file /etc/raddb/sites-enabled/control-socket group = radiusd user = radiusd including dictionary file /etc/raddb/dictionary main { prefix = "/usr" localstatedir = "/var" logdir = "/var/log/radius" libdir = "/usr/lib64/freeradius" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 allow_core_dumps = no 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 = no 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 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 #### client localhost { ipaddr = 127.0.0.1 require_message_authenticator = no secret = "testing123" nastype = "other" } client 10.0.10.0/24 { require_message_authenticator = no secret = "testing123" shortname = "wireless" } radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating exec exec { wait = no input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating expr Module: Linked to module rlm_expiration Module: Instantiating expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server inner-tunnel { modules { Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating pap pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating chap Module: Linked to module rlm_mschap Module: Instantiating mschap mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no } Module: Linked to module rlm_unix Module: Instantiating unix unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_eap Module: Instantiating eap eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 2048 } 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 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" make_cert_command = "/etc/raddb/certs/bootstrap" cache { enable = no lifetime = 24 max_entries = 255 } } 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" } Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_realm Module: Instantiating suffix realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating files files { usersfile = "/etc/raddb/users" acctusersfile = "/etc/raddb/acct_users" preproxy_usersfile = "/etc/raddb/preproxy_users" compat = "no" } Module: Checking session {...} for more modules to load Module: Linked to module rlm_radutmp Module: Instantiating radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Linked to module rlm_attr_filter Module: Instantiating attr_filter.access_reject attr_filter attr_filter.access_reject { attrsfile = "/etc/raddb/attrs.access_reject" key = "%{User-Name}" } } # modules } # server server { modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating 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: Checking preacct {...} for more modules to load Module: Linked to module rlm_acct_unique Module: Instantiating 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 detail detail { detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Instantiating attr_filter.accounting_response attr_filter attr_filter.accounting_response { attrsfile = "/etc/raddb/attrs.accounting_response" key = "%{User-Name}" } 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 } listen { type = "acct" ipaddr = * port = 0 } listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" } } Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /var/run/radiusd/radiusd.sock Listening on proxy address * port 1814 Ready to process requests. And on authentication here is the output: Going to the next request Waking up in 4.6 seconds. rad_recv: Access-Request packet from host 10.0.10.201 port 32768, id=54, length=381 Acct-Session-Id = "8ac1d4e8-00000085" NAS-Port = 134 NAS-Port-Type = Wireless-802.11 NAS-Identifier = "SG953UZW3J" NAS-IP-Address = 10.0.10.201 Framed-MTU = 1496 User-Name = "support" Calling-Station-Id = "00-26-C6-85-8C-2A" Called-Station-Id = "00-0F-61-53-12-C1" Service-Type = Framed-User EAP-Message = 0x02390070150017030100203ae1e187237e4b81e6caecff83f72c036840674ebf8a5c5a2cf4be6a0c09ea3217030100403b563821ba513e8a7bd18f1f2afc6f375fa289fdcb9a884eaceae4d248a0e49e4c68f0041de02b04defee03e3c7c257803b5593a4d1f4026128d473f025bccc4 State = 0x288bd15e2db2c488b05aedde474bde37 Colubris-AVPair = "ssid=ccsg" Colubris-AVPair = "incoming-vlan-id=432" Colubris-AVPair = "vsc-unique-id=2" Colubris-AVPair = "phytype=IEEE802dot11g" Colubris-Attr-250 = 0x00000000 Colubris-Attr-249 = 0x00000000 Message-Authenticator = 0xd22b50caa56f4af24ae8594256d41aab +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "support", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 57 length 112 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request User-Name = "support" User-Password = "test" FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request User-Name = "support" User-Password = "test" FreeRADIUS-Proxied-To = 127.0.0.1 server inner-tunnel { +- entering group authorize {...} ++[chap] returns noop ++[mschap] returns noop ++[unix] returns notfound [suffix] No '@' in User-Name = "support", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[control] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Failed to authenticate the user. } # server inner-tunnel [ttls] Got tunneled reply code 3 [ttls] Got tunneled Access-Reject [eap] Handler failed in EAP/ttls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> support attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 8 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 8 Sending Access-Reject of id 54 to 10.0.10.201 port 32768 EAP-Message = 0x04390004 Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 3.6 seconds. Cleaning up request 2 ID 255 with timestamp +166 Cleaning up request 3 ID 167 with timestamp +166 Waking up in 0.2 seconds. Cleaning up request 4 ID 192 with timestamp +166 Cleaning up request 5 ID 246 with timestamp +166 Cleaning up request 6 ID 16 with timestamp +166 Cleaning up request 7 ID 32 with timestamp +166 Waking up in 1.0 seconds. Cleaning up request 8 ID 54 with timestamp +166 Ready to process requests. And yes, there is a user named support with a hashed password that equals "test" Although it looks like the unix module is being queried, it does not look like the server is passing the request to the passwd module The references in the default and inner-tunnel files to shadow are meaningless as they refer to a section in radiusd.comf that does not exist. Any assistance is appreciated. Tom -- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28640012.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 05/21/2010 07:31 PM, sbchem wrote:
Greetings,
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest locally as well as remotely and it works great. Now I want to point the server to my /etc/shadow file which lives on the same machine. I have not made any changes to the default config except to change the group ownership of my shadow file to radiusd so the radius daemon can access it.
It's not a good idea to change the ownership of /etc/shadow from a security and system perspective. Rather than using rlm_unix use rlm_pam instead. PAM is a much cleaner way to authenticate system users, not just for FreeRADIUS but for all applications authenticating system users. It is the preferred methodology for a variety of reasons. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
It's not a good idea to change the ownership of /etc/shadow from a security and system perspective. Rather than using rlm_unix use rlm_pam instead
Understood and agreed. This is not a production environment. I was just trying to understand how the modules worked. That being said, I am now looking at PAM per your suggestion. Installed the pam-radius client per http://freeradius.org/pam_radius_auth/ and made the changes to /etc/pam.d/. Created the file /etc/raddb/server and uncommented pam from the sites-enabled/default and inner-tunnel files. Added Default Auth-Type = PAM to the users file. Now I get this output after running radtest Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 41569, id=33, length=59 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "support", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 203 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = PAM +- entering group authenticate {...} pam_pass: using pamauth string <radiusd> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <support>. Reason: Module is unknown ++[pam] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> support attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated 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 33 to 127.0.0.1 port 41569 Waking up in 4.9 seconds. Cleaning up request 0 ID 33 with timestamp +14 Ready to process requests. Not sure why it sez "pam_pass: using pamauth string <radiusd> for pam.conf lookup" whne it is set to look at /etc/pam.d/radiusd Thoughts? many thanks in advance John Dennis wrote:
On 05/21/2010 07:31 PM, sbchem wrote:
Greetings,
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest locally as well as remotely and it works great. Now I want to point the server to my /etc/shadow file which lives on the same machine. I have not made any changes to the default config except to change the group ownership of my shadow file to radiusd so the radius daemon can access it.
It's not a good idea to change the ownership of /etc/shadow from a security and system perspective. Rather than using rlm_unix use rlm_pam instead. PAM is a much cleaner way to authenticate system users, not just for FreeRADIUS but for all applications authenticating system users. It is the preferred methodology for a variety of reasons.
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28644421.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
sbchem wrote:
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest locally as well as remotely and it works great. Now I want to point the server to my /etc/shadow file which lives on the same machine. I have not made any changes to the default config except to change the group ownership of my shadow file to radiusd so the radius daemon can access it.
On startup here is the output:
You need to edit raddb/sites-available/inner-tunnel, too.
Although it looks like the unix module is being queried, it does not look like the server is passing the request to the passwd module
The references in the default and inner-tunnel files to shadow are meaningless as they refer to a section in radiusd.comf that does not exist.
See raddb/modules/passwd instead Alan DeKok.
You need to edit raddb/sites-available/inner-tunnel, too.
sites-available or sites-enabled? I did edit inner-tunnel in sites-enabled as well as default
See raddb/modules/passwd instead
added the following to passwd: unix { filename = /etc/shadow format = "*User-Name::Crypt-Password::::::" hashsize = 100 ignorenislike = no allowmultiplekeys = no } and here is the output: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 59997, id=170, length=59 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> support attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated 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 170 to 127.0.0.1 port 59997 Waking up in 4.9 seconds. Cleaning up request 0 ID 170 with timestamp +6 Ready to process requests. Alan DeKok-2 wrote:
sbchem wrote:
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest locally as well as remotely and it works great. Now I want to point the server to my /etc/shadow file which lives on the same machine. I have not made any changes to the default config except to change the group ownership of my shadow file to radiusd so the radius daemon can access it.
On startup here is the output:
You need to edit raddb/sites-available/inner-tunnel, too.
Although it looks like the unix module is being queried, it does not look like the server is passing the request to the passwd module
The references in the default and inner-tunnel files to shadow are meaningless as they refer to a section in radiusd.comf that does not exist.
See raddb/modules/passwd instead
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28644933.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
sbchem wrote:
You need to edit raddb/sites-available/inner-tunnel, too.
sites-available or sites-enabled? I did edit inner-tunnel in sites-enabled as well as default
The original debug log you posted shows *no* reference to "unix" in the inner-tunnel server. That's why authentication is failing.
++[unix] returns notfound
So... what can you conclude from that? Alan DeKok.
That's why authentication is failing. ++[unix] returns notfound So... what can you conclude from that?
I would assume it means that the unix module could not find the user. Let's simplify. I am now running radtest locally on the same box with this command: radtest test password 127.0.0.1 0 testing123 I get the same "returns not found" message. rad_recv: Access-Request packet from host 127.0.0.1 port 60057, id=252, length=56 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop No authenticate method (Auth-Type) configuration found for the request: Rejecting the user Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated 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 252 to 127.0.0.1 port 60057 Waking up in 4.9 seconds. Cleaning up request 0 ID 252 with timestamp +7 Ready to process requests. Based on your prior mesage should I be putting the reference to /etc/shadow in the unix module or the passwd module? Alan DeKok-2 wrote:
sbchem wrote:
You need to edit raddb/sites-available/inner-tunnel, too.
sites-available or sites-enabled? I did edit inner-tunnel in sites-enabled as well as default
The original debug log you posted shows *no* reference to "unix" in the inner-tunnel server. That's why authentication is failing.
++[unix] returns notfound
So... what can you conclude from that?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28645608.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
sbchem wrote:
I would assume it means that the unix module could not find the user.
Yes. Is the user in /etc/passwd and /etc/shadow? If so, check permissions, and maybe configure PAM. If not...
Based on your prior mesage should I be putting the reference to /etc/shadow in the unix module or the passwd module?
Which file did I tell you to modify? Alan DeKok.
Is the user in /etc/passwd and /etc/shadow?
Yes
If so, check permissions
/etc/shadow was chgrp'd to radiusd in spite of John Dennis' warnings to the contrary -- BUT I forgot to change the read permission -- my fault totally --
Which file did I tell you to modify?
modules/passwd edited as follows: passwd { filename = /etc/shadow format = "*User-Name::Crypt-Password::::::" hashsize = 100 ignorenislike = no allowmultiplekeys = no and site-enabled/default edited to include passwd in the authorize section and voila' it works -- thanks!! --- BUT ------ you and John Dennis both mentioned PAM so I went ahead and commented out the passwd entires and I am now looking at PAM per your suggestion. Installed the pam-radius client per http://freeradius.org/pam_radius_auth/ and made the changes to /etc/pam.d/. Created the file /etc/raddb/server and uncommented pam from sites-enabled/default. Added Default Auth-Type = PAM to the users file. Now I get this output after running radtest rad_recv: Access-Request packet from host 127.0.0.1 port 49068, id=108, length=56 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns updated [files] users: Matched entry DEFAULT at line 205 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Found existing Auth-Type, not changing it. ++[pap] returns noop Found Auth-Type = PAM +- entering group authenticate {...} pam_pass: using pamauth string <radiusd> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown ++[pam] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated 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 108 to 127.0.0.1 port 49068 Waking up in 4.9 seconds. Cleaning up request 0 ID 108 with timestamp +6 Ready to process requests. Not sure why it sez "pam_pass: using pamauth string <radiusd> for pam.conf lookup" whne it is set to look at /etc/pam.d/radiusd Thoughts? many thanks in advance radiusd -X now yields: [root@labprinter raddb]# radiusd -X FreeRADIUS Version 2.1.7, for host x86_64-redhat-linux-gnu, built on Mar 31 2010 at 00:14:28 Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. 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/radutmp including configuration file /etc/raddb/modules/digest including configuration file /etc/raddb/modules/files including configuration file /etc/raddb/modules/detail.log including configuration file /etc/raddb/modules/mac2vlan including configuration file /etc/raddb/modules/unix including configuration file /etc/raddb/modules/smsotp including configuration file /etc/raddb/modules/linelog including configuration file /etc/raddb/modules/inner-eap including configuration file /etc/raddb/modules/echo including configuration file /etc/raddb/modules/sqlcounter_expire_on_login including configuration file /etc/raddb/modules/sql_log including configuration file /etc/raddb/modules/detail including configuration file /etc/raddb/modules/exec including configuration file /etc/raddb/modules/etc_group including configuration file /etc/raddb/modules/expiration including configuration file /etc/raddb/modules/realm including configuration file /etc/raddb/modules/sradutmp including configuration file /etc/raddb/modules/acct_unique including configuration file /etc/raddb/modules/logintime including configuration file /etc/raddb/modules/perl including configuration file /etc/raddb/modules/ippool including configuration file /etc/raddb/modules/counter including configuration file /etc/raddb/modules/attr_rewrite including configuration file /etc/raddb/modules/policy including configuration file /etc/raddb/modules/passwd including configuration file /etc/raddb/modules/mac2ip including configuration file /etc/raddb/modules/mschap including configuration file /etc/raddb/modules/detail.example.com including configuration file /etc/raddb/modules/preprocess including configuration file /etc/raddb/modules/checkval including configuration file /etc/raddb/modules/chap including configuration file /etc/raddb/modules/pam including configuration file /etc/raddb/modules/expr including configuration file /etc/raddb/modules/always including configuration file /etc/raddb/modules/otp including configuration file /etc/raddb/modules/pap including configuration file /etc/raddb/modules/smbpasswd including configuration file /etc/raddb/modules/cui including configuration file /etc/raddb/modules/attr_filter including configuration file /etc/raddb/modules/wimax 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/inner-tunnel including configuration file /etc/raddb/sites-enabled/default including configuration file /etc/raddb/sites-enabled/control-socket group = radiusd user = radiusd including dictionary file /etc/raddb/dictionary main { prefix = "/usr" localstatedir = "/var" logdir = "/var/log/radius" libdir = "/usr/lib64/freeradius" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 allow_core_dumps = no 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 = no 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 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 #### client localhost { ipaddr = 127.0.0.1 require_message_authenticator = no secret = "testing123" nastype = "other" } client 10.0.10.0/24 { require_message_authenticator = no secret = "testing123" shortname = "wireless" } radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating exec exec { wait = no input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating expr Module: Linked to module rlm_expiration Module: Instantiating expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server inner-tunnel { modules { Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating pap pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating chap Module: Linked to module rlm_mschap Module: Instantiating mschap mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no } Module: Linked to module rlm_pam Module: Instantiating pam pam { pam_auth = "radiusd" } Module: Linked to module rlm_unix Module: Instantiating unix unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_eap Module: Instantiating eap eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 2048 } 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 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" make_cert_command = "/etc/raddb/certs/bootstrap" cache { enable = no lifetime = 24 max_entries = 255 } } 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" } Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_realm Module: Instantiating suffix realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating files files { usersfile = "/etc/raddb/users" acctusersfile = "/etc/raddb/acct_users" preproxy_usersfile = "/etc/raddb/preproxy_users" compat = "no" } Module: Checking session {...} for more modules to load Module: Linked to module rlm_radutmp Module: Instantiating radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Linked to module rlm_attr_filter Module: Instantiating attr_filter.access_reject attr_filter attr_filter.access_reject { attrsfile = "/etc/raddb/attrs.access_reject" key = "%{User-Name}" } } # modules } # server server { modules { Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_passwd Module: Instantiating passwd passwd { filename = "/etc/shadow" format = "*User-Name::Crypt-Password::::::" delimiter = ":" ignorenislike = no ignoreempty = yes allowmultiplekeys = no hashsize = 100 } rlm_passwd: can't build hashtable from passwd file /etc/raddb/modules/passwd[31]: Instantiation failed for module "passwd" /etc/raddb/sites-enabled/default[275]: Failed to find module "passwd". /etc/raddb/sites-enabled/default[234]: Errors parsing authenticate section. I appreciate your time and guidance. Alan DeKok-2 wrote:
sbchem wrote:
I would assume it means that the unix module could not find the user.
Yes. Is the user in /etc/passwd and /etc/shadow?
If so, check permissions, and maybe configure PAM.
If not...
Based on your prior mesage should I be putting the reference to /etc/shadow in the unix module or the passwd module?
Which file did I tell you to modify?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28646112.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
sbchem wrote:
you and John Dennis both mentioned PAM so I went ahead and commented out the passwd entires and I am now looking at PAM per your suggestion.
Installed the pam-radius client per http://freeradius.org/pam_radius_auth/
Uh... no. PLease *read* the documentation for pam_radius_auth. It allows *other* programs to use RADIUS for authentication. It is *not* what you want.
Created the file /etc/raddb/server and uncommented pam from sites-enabled/default.
Please read the PAM module configuration: raddb/modules/pam It explains how to get PAM working with the server. The server includes documentation. If you're configuring a module, it wouldn't hurt to read the configuration file and the documentation for it. Alan DeKok.
pam_radius_auth. It allows *other* programs to use RADIUS for authentication. It is *not* what you want.
Okay, understood and removed all traces of it and changes to files I made except left Auth-Type = pam in the users file
Please read the PAM module configuration: raddb/modules/pam It explains how to get PAM working with the server.
The only "explanation" it gives is that the module points to /etc/pam.d/radiusd. I made sure that a file named radiusd lives in /etc/pam.d and that it has proper ownership (root) and permissions (644) And as John points out, in Redhat distros (mine is CentOS) theres is no need to do any config of that file as it comes prepackaged with the raddb rpm So no further along as this radtest output shows: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 41299, id=112, length=56 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 205 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = PAM +- entering group authenticate {...} pam_pass: using pamauth string <radiusd> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown ++[pam] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated 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 112 to 127.0.0.1 port 41299 Waking up in 4.9 seconds. Cleaning up request 0 ID 112 with timestamp +3 Ready to process requests. So the entry: pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown is obviously supposed to give me the clue I need but I have no idea what it means. The pam module in /etc/raddb/modules is pointing to a file named radiusd in /etc/pam.d That file exists withthe correct ownership and privileges and is suposed to contain whatever it needs straight out of the box. If I omit the Auth-Type = pam from the users files, the pam module error goes away but it also is not checking pam so it looks like I ined to tell the server the auth-type. Stumped. Googling the error message returns a post you made several years ago to wit: <Markus.Wintruff@data...> wrote:
pam_pass: function pam_authenticate FAILED for <wolfmar>. Reason: Module is unknown
And it doesn't tell you which module. Wonderful. People actually use this stuff? And get it to work? Wow...
Is ist possible to debug PAM?
Not really. Now you know why I'm so insistent on adding debugging messages to FreeRADIUS, and on asking people to look at them. Alan DeKok. Which I find slighlty amusing because the debug output is exactly that message -"Module unknown" A more terse reply of yours is less amusing: Alex Wang <[EMAIL PROTECTED]> wrote:
pam_pass: using pamauth string <radiusd-fcums1.dat> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <guest28>. Reason: Module is unknown
That should be fairly clear. Read the PAM docs.
Is anybody kindly can help me figure out where the problem is?
You haven't configured PAM properly. Alan DeKok. So no further along on pam -- illumination anyone or more fog please? Cheers! Alan DeKok-2 wrote:
sbchem wrote:
you and John Dennis both mentioned PAM so I went ahead and commented out the passwd entires and I am now looking at PAM per your suggestion.
Installed the pam-radius client per http://freeradius.org/pam_radius_auth/
Uh... no. PLease *read* the documentation for pam_radius_auth. It allows *other* programs to use RADIUS for authentication. It is *not* what you want.
Created the file /etc/raddb/server and uncommented pam from sites-enabled/default.
Please read the PAM module configuration: raddb/modules/pam
It explains how to get PAM working with the server.
The server includes documentation. If you're configuring a module, it wouldn't hurt to read the configuration file and the documentation for it.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28650127.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 05/22/2010 05:37 PM, sbchem wrote:
you and John Dennis both mentioned PAM so I went ahead and commented out the passwd entires and I am now looking at PAM per your suggestion.
Installed the pam-radius client per http://freeradius.org/pam_radius_auth/
No, that's for authenticating against radius, different beast entirely.
and made the changes to /etc/pam.d/.
If you're using the Red Hat RPM's that shouldn't be necessary, we already include the pam configuration file matched to our systems. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
No, that's for authenticating against radius, different beast entirely
Okay, understood and removed all traces of it and changes to files I made except left Auth-Type = pam in the users file
If you're using the Red Hat RPM's that shouldn't be necessary, we already include the pam configuration >file matched to our systems.
Notes in pam module says that the module points to /etc/pam.d/radiusd. I made sure that a file named radiusd lives in /etc/pam.d and that it has proper ownership (root) and permissions (644) My dostro is CentOS so based on your cmment I assume theres is no need to do any config of that file as it comes prepackaged with the raddb rpm So no further along as this radtest output shows: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 41299, id=112, length=56 User-Name = "test" User-Password = "password" NAS-IP-Address = 10.0.10.21 NAS-Port = 0 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound [files] users: Matched entry DEFAULT at line 205 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = PAM +- entering group authenticate {...} pam_pass: using pamauth string <radiusd> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown ++[pam] returns reject Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated 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 112 to 127.0.0.1 port 41299 Waking up in 4.9 seconds. Cleaning up request 0 ID 112 with timestamp +3 Ready to process requests. So the entry: pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown is obviously supposed to give me the clue I need but I have no idea what it means. The pam module in /etc/raddb/modules is pointing to a file named radiusd in /etc/pam.d That file exists withthe correct ownership and privileges and is suposed to contain whatever it needs straight out of the box. If I omit the Auth-Type = pam from the users files, the pam module error goes away but it also is not checking pam so it looks like I ined to tell the server the auth-type. Stumped. Googling the error message returns a post Alan made several years ago <Markus.Wintruff@data...> wrote:
pam_pass: function pam_authenticate FAILED for <wolfmar>. Reason: Module is unknown
And it doesn't tell you which module. Wonderful. People actually use this stuff? And get it to work? Wow...
Is ist possible to debug PAM?
Not really. Now you know why I'm so insistent on adding debugging messages to FreeRADIUS, and on asking people to look at them. Alan DeKok. Which I find slighlty amusing because the debug output is exactly that message -"Module unknown" A more terse reply of Alan's is less amusing: Alex Wang <[EMAIL PROTECTED]> wrote:
pam_pass: using pamauth string <radiusd-fcums1.dat> for pam.conf lookup pam_pass: function pam_authenticate FAILED for <guest28>. Reason: Module is unknown
That should be fairly clear. Read the PAM docs.
Is anybody kindly can help me figure out where the problem is?
You haven't configured PAM properly. Alan DeKok. So no further along on pam -- illumination anyone or more fog please? Cheers! John Dennis wrote:
On 05/22/2010 05:37 PM, sbchem wrote:
you and John Dennis both mentioned PAM so I went ahead and commented out the passwd entires and I am now looking at PAM per your suggestion.
Installed the pam-radius client per http://freeradius.org/pam_radius_auth/
No, that's for authenticating against radius, different beast entirely.
and made the changes to /etc/pam.d/.
If you're using the Red Hat RPM's that shouldn't be necessary, we already include the pam configuration file matched to our systems.
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28650164.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
sbchem wrote:
So the entry:
pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown
is obviously supposed to give me the clue I need but I have no idea what it means.
<shrug> It's an error produces by the PAM subsystem. Ask them what it means. Blaming FreeRADIUS is the same as blaming Dell because the internet is slow. Alan DeKok.
<shrug> It's an error produces (sic) by the PAM subsystem. Ask them what it means.
<Sigh> It turns out the error is caused by a typo in the radiusd file provided in /redhat/radiusd-pam, NOT by the pam subsystem. In fact, the pam subsystem was merely reporting the error in the freeradius file. The message "module not found" was because the radiusd-pam file was pointing to password.so NOT passwd.so
Blaming FreeRADIUS is the same as blaming Dell
Hmmm--rather defensive are we??? --Alan, no one is blaming anybody for anything....it was a simple and honest question that was also posted a few years ago and remained unanswered -- until now, by me as above. However I do find it interesting that you compare the customer service you provided on this to that provided by Dell -- if the shoe fits..... I am part of a consortium of public and private universities and scientific research facilities and our internal listserv on radius frequently talks people off of freeradius solely because of the sarcastic and chip on the shoulder attitude of "some" of the developers. Quit being such a Mordac Alan, it scares the tourists and devalues the otherwise excellent work done by other people on this project. You can ban me now for such a ghastly breach of etiquette. Cheers! Alan DeKok-2 wrote:
sbchem wrote:
So the entry:
pam_pass: function pam_authenticate FAILED for <test>. Reason: Module is unknown
is obviously supposed to give me the clue I need but I have no idea what it means.
<shrug> It's an error produces by the PAM subsystem. Ask them what it means.
Blaming FreeRADIUS is the same as blaming Dell because the internet is slow.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28699725.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 05/27/2010 04:51 PM, sbchem wrote:
<shrug> It's an error produces (sic) by the PAM subsystem. Ask them what it means.
<Sigh> It turns out the error is caused by a typo in the radiusd file provided in /redhat/radiusd-pam, NOT by the pam subsystem. In fact, the pam subsystem was merely reporting the error in the freeradius file. The message "module not found" was because the radiusd-pam file was pointing to password.so NOT passwd.so
Glad you got it working and sorry for the frustration. Unfortunately the files in /redhat had serious bit rot and had not been maintained for a long time. When you want Red Hat specific files or RPM's it's really best to get them from us because we maintain them. The /etc/pam.d/radiusd is supplied in our freeradius RPM and isn't the same as was found in the freeradius tarball as you unfortunately discovered. FWIW, we just synced our files to /redhat directory in the freeradius 2.1.9 release. So for 2.1.9 they will be pretty close. But they will *diverge*. Why? Because in this instance that does not represent "upstream" (i.e. the definitive source), we are "upstream" for our own files. I have certain misgivings about upstream projects providing packaging files for their project because they inevitably diverge and have bit rot. I realize it's perceived to be friendly to supply packaging files in the upstream distribution, but it comes with a price (divergence & bugs). Getting packaging files from the source (i.e. the specific Linux distribution) isn't that hard and would avoid some of these issues. By the way all this is documented in the FreeRADIUS wiki at http://wiki.freeradius.org/Red_Hat_FAQ Just my 2 cents ... -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Fri 28 May 2010, John Dennis wrote:
On 05/27/2010 04:51 PM, sbchem wrote:
<shrug> It's an error produces (sic) by the PAM subsystem. Ask them
what it means.
<Sigh> It turns out the error is caused by a typo in the radiusd file provided in /redhat/radiusd-pam, NOT by the pam subsystem. In fact, the pam subsystem was merely reporting the error in the freeradius file. The message "module not found" was because the radiusd-pam file was pointing to password.so NOT passwd.so
Glad you got it working and sorry for the frustration.
Unfortunately the files in /redhat had serious bit rot and had not been maintained for a long time. When you want Red Hat specific files or RPM's it's really best to get them from us because we maintain them. The /etc/pam.d/radiusd is supplied in our freeradius RPM and isn't the same as was found in the freeradius tarball as you unfortunately discovered.
FWIW, we just synced our files to /redhat directory in the freeradius 2.1.9 release. So for 2.1.9 they will be pretty close. But they will *diverge*. Why? Because in this instance that does not represent "upstream" (i.e. the definitive source), we are "upstream" for our own files.
I have certain misgivings about upstream projects providing packaging files for their project because they inevitably diverge and have bit rot. I realize it's perceived to be friendly to supply packaging files in the upstream distribution, but it comes with a price (divergence & bugs). Getting packaging files from the source (i.e. the specific Linux distribution) isn't that hard and would avoid some of these issues. By the way all this is documented in the FreeRADIUS wiki at http://wiki.freeradius.org/Red_Hat_FAQ
Hi John Is it happens, I agree with you. I was maintaining some prebuilt RedHat and Mandriva packages for a while in addition to the openSUSE packages (which I use myself) but I stopped doing so as it seems like duplicate effort and a source of extra problems. I maintain "our" FreeRADIUS (latest release) packages for openSUSE under the network:aaa namespace on the build service, but these get synced up with the "official" openSUSE/SLES packages in the Factory namespace before each major distro release. There is a small amount of skew between the packages at present, but we will have them in sync for the 11.3 release. I am not so familar with the dev processes for Fedora/RHEL but I am sure something similar could be arranged. Cheers -- Peter Nixon http://peternixon.net/
sbchem wrote:
<shrug> It's an error produces (sic) by the PAM subsystem. Ask them what it means.
<Sigh> It turns out the error is caused by a typo in the radiusd file provided in /redhat/radiusd-pam, NOT by the pam subsystem. In fact, the pam subsystem was merely reporting the error in the freeradius file. The message "module not found" was because the radiusd-pam file was pointing to password.so NOT passwd.so
OK.. so the error *was* being produced by the PAM subsystem, as I said. Investigating that subsystem found the problem, and the solution. And yes, the FreeRADIUS PAM file needs to be fixed.
Blaming FreeRADIUS is the same as blaming Dell
Selective editing does not help your cause. The quote was:
Blaming FreeRADIUS is the same as blaming Dell because the internet is slow.
The comparison to Dell was because as the computer manufacturer, they get *enormous* numbers of complaints from inexperienced users, sating things like "facebook is slow!" Similarly, a large number of questions on this list are things like "how do I get the NAS to do X". The answer is almost always "read the NAS documentation". Some people end up being offended by this. I have no idea why.
Hmmm--rather defensive are we??? --Alan, no one is blaming anybody for anything....it was a simple and honest question that was also posted a few years ago and remained unanswered -- until now, by me as above.
My response was a simple and honest one; If subsystem X is producing an error message... you should really go investigate subsystem X. The answers will usually be found there. Is that so offensive?
However I do find it interesting that you compare the customer service you provided on this to that provided by Dell -- if the shoe fits.....
If you *intentionally* edit my comments so as to misrepresent them, it shows the paucity of your arguments.
I am part of a consortium of public and private universities and scientific research facilities
Eduroam?
and our internal listserv on radius frequently talks people off of freeradius solely because of the sarcastic and chip on the shoulder attitude of "some" of the developers.
"Some"... but you're not naming names...
Quit being such a Mordac Alan, it scares the tourists and devalues the otherwise excellent work done by other people on this project.
Implying that the only excellent work is done by *other* people, and not me.
You can ban me now for such a ghastly breach of etiquette.
Sadly, I do no such thing, though it's clear you would in a similar situation. You've taken a simple request to investigate the root cause of the problem, and turned it into a personal attack on me. And you're saying *I* have a chip on my shoulder? Please, don't pretend to have the moral high ground here. Alan DeKok.
Alan--thank you for posting your response and proving my point -- diff the tone and content of your response to those of John, Josip and Alan B. -- as the younger set sez, "chill dude" No one is disparaging your work -- but maybe you need to divert some of your considerable energy to working on your social skills BTW *not* eduroam Alan DeKok-2 wrote:
sbchem wrote:
<shrug> It's an error produces (sic) by the PAM subsystem. Ask them what it means.
<Sigh> It turns out the error is caused by a typo in the radiusd file provided in /redhat/radiusd-pam, NOT by the pam subsystem. In fact, the pam subsystem was merely reporting the error in the freeradius file. The message "module not found" was because the radiusd-pam file was pointing to password.so NOT passwd.so
OK.. so the error *was* being produced by the PAM subsystem, as I said. Investigating that subsystem found the problem, and the solution.
And yes, the FreeRADIUS PAM file needs to be fixed.
Blaming FreeRADIUS is the same as blaming Dell
Selective editing does not help your cause. The quote was:
Blaming FreeRADIUS is the same as blaming Dell because the internet is slow.
The comparison to Dell was because as the computer manufacturer, they get *enormous* numbers of complaints from inexperienced users, sating things like "facebook is slow!"
Similarly, a large number of questions on this list are things like "how do I get the NAS to do X". The answer is almost always "read the NAS documentation". Some people end up being offended by this. I have no idea why.
Hmmm--rather defensive are we??? --Alan, no one is blaming anybody for anything....it was a simple and honest question that was also posted a few years ago and remained unanswered -- until now, by me as above.
My response was a simple and honest one; If subsystem X is producing an error message... you should really go investigate subsystem X. The answers will usually be found there.
Is that so offensive?
However I do find it interesting that you compare the customer service you provided on this to that provided by Dell -- if the shoe fits.....
If you *intentionally* edit my comments so as to misrepresent them, it shows the paucity of your arguments.
I am part of a consortium of public and private universities and scientific research facilities
Eduroam?
and our internal listserv on radius frequently talks people off of freeradius solely because of the sarcastic and chip on the shoulder attitude of "some" of the developers.
"Some"... but you're not naming names...
Quit being such a Mordac Alan, it scares the tourists and devalues the otherwise excellent work done by other people on this project.
Implying that the only excellent work is done by *other* people, and not me.
You can ban me now for such a ghastly breach of etiquette.
Sadly, I do no such thing, though it's clear you would in a similar situation.
You've taken a simple request to investigate the root cause of the problem, and turned it into a personal attack on me. And you're saying *I* have a chip on my shoulder? Please, don't pretend to have the moral high ground here.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- View this message in context: http://old.nabble.com/RADDB-2.1.7-and--etc-shadow-tp28640012p28708369.html Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi,
I am part of a consortium of public and private universities and scientific research facilities and our internal listserv on radius frequently talks
...as am I. but I inform people that they should read the documentation and follow the basic information provided about how to troubleshoot and get help before using the list (because there's nothing to show you up better than 'it doesnt work, please help' as the sole contents of your email :-| )
people off of freeradius solely because of the sarcastic and chip on the shoulder attitude of "some" of the developers. Quit being such a Mordac Alan, it scares the tourists and devalues the otherwise excellent work done by other people on this project.
huh? without Alan there wouldnt be the project. PS regarding talking people off FreeRADIUS - you sure theres not some agenda present there - after all, FreeRADIUS is Open Source GPL software - something not favoured by some due to their political leanings. its also free - which is also not favoured by some. There are commercial offerings out there - but , and this is particularly apt with the current financial climate - is it not easier to defend and deploy services which are free and not extra cost than to be talking about ROI/TCO and bottom line of services - especially regarding systems such as 'eduroam' - which are pretty much free if you have 802.1X capable kit and a local 802.1X network already present... alan
On Thu, May 27, 2010 at 01:51:44PM -0700, sbchem wrote:
our internal listserv on radius frequently talks people off of freeradius solely because of the sarcastic and chip on the shoulder attitude of "some" of the developers. Quit being such a Mordac Alan, it scares the tourists and devalues the otherwise excellent work done by other people on this project.
Actually Alan is doing practically all the work. This is a known feature of many open-source projects - there is no separation between support people and programming people, nor an accompanying distinction in the default attitudes. The solution is to treat such projects, including FreeRADIUS, accordingly - this forum is not what you might call a first-level helpdesk venue - it is instead a venue where the user can be expected a lot from, including both a technical proficiency and an ability to take heat for lack thereof. I know that doesn't sound optimal, nor does it fit in with how the rest of the world commonly operates, but that's how it is. On a completely separate note, I think that it would be best if Alan sometimes tried to ignore some of the fuzzier user queries and left that to others, even at the cost of the request looking like it was ignored. It's better to concentrate on more important things. Alan, please consider that :) At the same time, there's a distinct possibility that the fuzzy-question-asking user will get more time to try other venues of problem investigation other than waiting to be helped (even hand-held) by a helpful person on the mailing list. Not everyone exhausts all other venues before asking; often people try some poor man's debugging method just once or twice and after failing immediately ask a new question on a forum, not even trying to e.g. google a few times for similar questions and answers. Overall, I recommend an approach with a bit more lax latencies (less pressure) in responding to *every* query, in the long run it will be better for the stress level of everyone involved. :) -- 2. That which causes joy or happiness.
Josip Rodin wrote:
The solution is to treat such projects, including FreeRADIUS, accordingly - this forum is not what you might call a first-level helpdesk venue - it is instead a venue where the user can be expected a lot from, including both a technical proficiency and an ability to take heat for lack thereof.
Also, RADIUS is a *lot* more complicated than DNS and DHCP. It takes more effort to understand and configure. This results in an increased level of frustration for the new user, compare to DNS or DHCP.
On a completely separate note, I think that it would be best if Alan sometimes tried to ignore some of the fuzzier user queries and left that to others, even at the cost of the request looking like it was ignored. It's better to concentrate on more important things. Alan, please consider that :)
I've actually been doing that for a while now... I've been saying this for nearly 10 years now, and the proof is in public list archives. Nearly anyone who asks a good question and provides the requested information can get their problem solved. The people who *argue* with the answers they receive get ignored, or get told to stop being rude. This is (somehow) perceived as having a hostile list. <sigh> Alan DeKok.
participants (6)
-
Alan Buxey -
Alan DeKok -
John Dennis -
Josip Rodin -
Peter Nixon -
sbchem