Authenticating groups via LDAP
I really didn't want to post here, but I just can't make any headway with my radius implementation. I am very new at this and still quite confused on how the various config files function and interact with each other. So, I'm not surprised that my implementation is only sort of working. I have installed freeradius 2.1.8 on Ubuntu Server 8.04 by making deb packages from the source and installing the deb packages. Radius is relying on an LDAP server for authentication of wireless clients. Only clients with valid usernames and passwords in LDAP will get authenticated. What I would really like to do (other than actually be able to understand the concepts behind the config files) is require clients to be in a particular LDAP group (e.g., wireless-users) in order to successfully authenticate. I don't understand how to make that happen. I've tried creating group filters like this in "modules/ldap": groupname_attribute = cn groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))" groupmembership_attribute = memberUid and this in "users": DEFAULT LDAP-GROUP == vpn-users Service-Type = Administrative-User But the output seems to indicate that it is not even considering my radiusd.conf config when it comes to the filter. (see output below). I would so welcome assistance with this. In addition, is there any resource that is particularly good at explaining how radius and its config files really works? Thanks. John # freeradius -X FreeRADIUS Version 2.1.8, for host i486-pc-linux-gnu, built on May 14 2010 at 09:29:10 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/freeradius/radiusd.conf including configuration file /etc/freeradius/proxy.conf including configuration file /etc/freeradius/clients.conf including files in directory /etc/freeradius/modules/ including configuration file /etc/freeradius/modules/unix including configuration file /etc/freeradius/modules/detail including configuration file /etc/freeradius/modules/ldap.dpkg-old including configuration file /etc/freeradius/modules/ntlm_auth including configuration file /etc/freeradius/modules/sql_log including configuration file /etc/freeradius/modules/sradutmp including configuration file /etc/freeradius/modules/attr_filter including configuration file /etc/freeradius/modules/realm including configuration file /etc/freeradius/modules/echo including configuration file /etc/freeradius/modules/pap including configuration file /etc/freeradius/modules/radutmp including configuration file /etc/freeradius/modules/ldap including configuration file /etc/freeradius/modules/ippool including configuration file /etc/freeradius/modules/files including configuration file /etc/freeradius/modules/linelog including configuration file /etc/freeradius/modules/pam including configuration file /etc/freeradius/modules/mac2ip including configuration file /etc/freeradius/modules/perl including configuration file /etc/freeradius/modules/chap including configuration file /etc/freeradius/modules/checkval including configuration file /etc/freeradius/modules/smsotp including configuration file /etc/freeradius/modules/etc_group including configuration file /etc/freeradius/modules/digest including configuration file /etc/freeradius/modules/always including configuration file /etc/freeradius/modules/detail.example.com including configuration file /etc/freeradius/modules/krb5 including configuration file /etc/freeradius/modules/expiration including configuration file /etc/freeradius/modules/mschap including configuration file /etc/freeradius/modules/exec including configuration file /etc/freeradius/modules/policy including configuration file /etc/freeradius/modules/counter including configuration file /etc/freeradius/modules/sqlcounter_expire_on_login including configuration file /etc/freeradius/modules/otp including configuration file /etc/freeradius/modules/mac2vlan including configuration file /etc/freeradius/modules/acct_unique including configuration file /etc/freeradius/modules/wimax including configuration file /etc/freeradius/modules/passwd including configuration file /etc/freeradius/modules/smbpasswd including configuration file /etc/freeradius/modules/attr_rewrite including configuration file /etc/freeradius/modules/expr including configuration file /etc/freeradius/modules/detail.log including configuration file /etc/freeradius/modules/inner-eap including configuration file /etc/freeradius/modules/cui including configuration file /etc/freeradius/modules/logintime including configuration file /etc/freeradius/modules/preprocess including configuration file /etc/freeradius/eap.conf including configuration file /etc/freeradius/policy.conf including files in directory /etc/freeradius/sites-enabled/ including configuration file /etc/freeradius/sites-enabled/inner-tunnel including configuration file /etc/freeradius/sites-enabled/default main { user = "freerad" group = "freerad" allow_core_dumps = no } including dictionary file /etc/freeradius/dictionary main { prefix = "/usr" localstatedir = "/var" logdir = "/var/log/freeradius" libdir = "/usr/lib/freeradius" radacctdir = "/var/log/freeradius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 pidfile = "/var/run/freeradius/freeradius.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.12.88.0/23 { require_message_authenticator = no secret = "********" shortname = "ap" } 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/freeradius/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 = 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 pem_file_type = yes private_key_file = "/etc/freeradius/certs/radiuskey.pem" certificate_file = "/etc/freeradius/certs/radiuscert.pem" CA_file = "/etc/freeradius/certs/cacert.pem" private_key_password = "********" dh_file = "/etc/freeradius/certs/dh" random_file = "/dev/urandom" fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" make_cert_command = "/etc/freeradius/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/freeradius/users" acctusersfile = "/etc/freeradius/acct_users" preproxy_usersfile = "/etc/freeradius/preproxy_users" compat = "no" } Module: Linked to module rlm_ldap Module: Instantiating ldap ldap { server = "auth.chem.umass.edu" port = 389 password = "*********" identity = "cn=admin,dc=cns" net_timeout = 1 timeout = 4 timelimit = 3 tls_mode = no start_tls = no tls_require_cert = "allow" tls { start_tls = no require_cert = "allow" } basedn = "dc=cns" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" auto_header = no access_attr_used_for_allow = yes groupname_attribute = "cn" groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" dictionary_mapping = "/etc/freeradius/ldap.attrmap" ldap_debug = 0 ldap_connections_number = 5 compare_check_items = no do_xlat = yes edir_account_policy_check = no set_auth_type = yes } rlm_ldap: Registering ldap_groupcmp for Ldap-Group rlm_ldap: Registering ldap_xlat with xlat_name ldap rlm_ldap: Over-riding set_auth_type, as there is no module ldap listed in the "authenticate" section. rlm_ldap: reading ldap<->radius mappings from file /etc/freeradius/ldap.attrmap rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS Calling-Station-Id rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP ntPassword mapped to RADIUS NT-Password rlm_ldap: LDAP sambaLmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP sambaNtPassword mapped to RADIUS NT-Password rlm_ldap: LDAP dBCSPwd mapped to RADIUS LM-Password rlm_ldap: LDAP acctFlags mapped to RADIUS SMB-Account-CTRL-TEXT rlm_ldap: LDAP radiusExpiration mapped to RADIUS Expiration rlm_ldap: LDAP radiusNASIpAddress mapped to RADIUS NAS-IP-Address rlm_ldap: LDAP radiusServiceType mapped to RADIUS Service-Type rlm_ldap: LDAP radiusFramedProtocol mapped to RADIUS Framed-Protocol rlm_ldap: LDAP radiusFramedIPAddress mapped to RADIUS Framed-IP-Address rlm_ldap: LDAP radiusFramedIPNetmask mapped to RADIUS Framed-IP-Netmask rlm_ldap: LDAP radiusFramedRoute mapped to RADIUS Framed-Route rlm_ldap: LDAP radiusFramedRouting mapped to RADIUS Framed-Routing rlm_ldap: LDAP radiusFilterId mapped to RADIUS Filter-Id rlm_ldap: LDAP radiusFramedMTU mapped to RADIUS Framed-MTU rlm_ldap: LDAP radiusFramedCompression mapped to RADIUS Framed-Compression rlm_ldap: LDAP radiusLoginIPHost mapped to RADIUS Login-IP-Host rlm_ldap: LDAP radiusLoginService mapped to RADIUS Login-Service rlm_ldap: LDAP radiusLoginTCPPort mapped to RADIUS Login-TCP-Port rlm_ldap: LDAP radiusCallbackNumber mapped to RADIUS Callback-Number rlm_ldap: LDAP radiusCallbackId mapped to RADIUS Callback-Id rlm_ldap: LDAP radiusFramedIPXNetwork mapped to RADIUS Framed-IPX-Network rlm_ldap: LDAP radiusClass mapped to RADIUS Class rlm_ldap: LDAP radiusSessionTimeout mapped to RADIUS Session-Timeout rlm_ldap: LDAP radiusIdleTimeout mapped to RADIUS Idle-Timeout rlm_ldap: LDAP radiusTerminationAction mapped to RADIUS Termination-Action rlm_ldap: LDAP radiusLoginLATService mapped to RADIUS Login-LAT-Service rlm_ldap: LDAP radiusLoginLATNode mapped to RADIUS Login-LAT-Node rlm_ldap: LDAP radiusLoginLATGroup mapped to RADIUS Login-LAT-Group rlm_ldap: LDAP radiusFramedAppleTalkLink mapped to RADIUS Framed-AppleTalk-Link rlm_ldap: LDAP radiusFramedAppleTalkNetwork mapped to RADIUS Framed-AppleTalk-Network rlm_ldap: LDAP radiusFramedAppleTalkZone mapped to RADIUS Framed-AppleTalk-Zone rlm_ldap: LDAP radiusPortLimit mapped to RADIUS Port-Limit rlm_ldap: LDAP radiusLoginLATPort mapped to RADIUS Login-LAT-Port rlm_ldap: LDAP radiusReplyMessage mapped to RADIUS Reply-Message rlm_ldap: LDAP radiusTunnelType mapped to RADIUS Tunnel-Type rlm_ldap: LDAP radiusTunnelMediumType mapped to RADIUS Tunnel-Medium-Type rlm_ldap: LDAP radiusTunnelPrivateGroupId mapped to RADIUS Tunnel-Private-Group-Id conns: 0x818e078 Module: Checking session {...} for more modules to load Module: Linked to module rlm_radutmp Module: Instantiating radutmp radutmp { filename = "/var/log/freeradius/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/freeradius/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/freeradius/huntgroups" hints = "/etc/freeradius/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/freeradius/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/freeradius/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 } Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on proxy address * port 1814 Ready to process requests. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The following displays when a client connects. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% rad_recv: Access-Request packet from host 10.12.88.13 port 2048, id=0, length=125 User-Name = "jmaher" NAS-IP-Address = 10.12.88.13 Called-Station-Id = "002129a58514" Calling-Station-Id = "001cbf31b3b5" NAS-Identifier = "002129a58514" NAS-Port = 55 Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0200000b016a6d61686572 Message-Authenticator = 0x97f3c529d6f8cd6d67afdf5fa8a122c2 +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "jmaher", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 0 length 11 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[unix] returns updated [ldap] Entering ldap_groupcmp() [files] expand: dc=cns -> dc=cns [files] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details [files] ... expanding second conditional [files] expand: %{User-Name} -> jmaher [files] expand: (uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=jmaher) [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] attempting LDAP reconnection [ldap] (re)connect to auth.chem.umass.edu:389, authentication 0 [ldap] bind as cn=admin,dc=cns/**********wcibk@mD to auth.chem.umass.edu:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in dc=cns, with filter (uid=jmaher) [ldap] ldap_release_conn: Release Id: 0 [files] expand: (|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))) -> (|(&(objectClass=GroupOfNames)(member=))(&(objectClass=GroupOfUniqueNames)(uniquemember=))) [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] performing search in dc=cns, with filter (&(cn=vpn-users)(|(&(objectClass=GroupOfNames)(member=))(&(objectClass=GroupOfUniqueNames)(uniquemember=)))) [ldap] object not found [ldap] ldap_release_conn: Release Id: 0 rlm_ldap::ldap_groupcmp: Group vpn-users not found or user is not a member. ++[files] returns noop [ldap] performing user authorization for jmaher [ldap] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details [ldap] ... expanding second conditional [ldap] expand: %{User-Name} -> jmaher [ldap] expand: (uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=jmaher) [ldap] expand: dc=cns -> dc=cns [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] performing search in dc=cns, with filter (uid=jmaher) [ldap] No default NMAS login sequence [ldap] looking for check items in directory... [ldap] sambaNtPassword -> NT-Password == 0x4537353238434135323632453745303645438324444363635383830453042333 [ldap] sambaLmPassword -> LM-Password == 0x3743414639453142313632453745303645463337453431343231373532384341 [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user jmaher authorized to use remote access [ldap] ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Normalizing NT-Password from hex encoding [pap] Normalizing LM-Password from hex encoding [pap] Found existing Auth-Type, not changing it. ++[pap] returns noop Found Auth-Type = EAP +- entering group authenticate {...} [eap] EAP Identity [eap] processing type md5 rlm_eap_md5: Issuing Challenge ++[eap] returns handled Sending Access-Challenge of id 0 to 10.12.88.13 port 2048 EAP-Message = 0x01010016041093940db5446be686982b01b8674bc247 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xa5171280a516162260366d28d5bb6b66 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 0 with timestamp +57 Ready to process requests.
On 05/20/2010 05:44 PM, John Maher wrote:
I really didn't want to post here, but I just can't make any headway with my radius implementation. I am very new at this and still quite confused on how the various config files function and interact with each other. So, I'm not surprised that my implementation is only sort of working.
I have installed freeradius 2.1.8 on Ubuntu Server 8.04 by making deb packages from the source and installing the deb packages.
Radius is relying on an LDAP server for authentication of wireless clients. Only clients with valid usernames and passwords in LDAP will get authenticated.
What I would really like to do (other than actually be able to understand the concepts behind the config files) is require clients to be in a particular LDAP group (e.g., wireless-users) in order to successfully authenticate. I don't understand how to make that happen. I've tried creating group filters like this in "modules/ldap":
groupname_attribute = cn groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))" groupmembership_attribute = memberUid
and this in "users":
DEFAULT LDAP-GROUP == vpn-users Service-Type = Administrative-User
But the output seems to indicate that it is not even considering my radiusd.conf config when it comes to the filter. (see output below).
I would so welcome assistance with this. In addition, is there any resource that is particularly good at explaining how radius and its config files really works?
I feel your pain, the ldap module is poorly documented and hard to use. There is doc in doc/ldap_howto.txt, not sure where that might be installed on Ubuntu though. Just a caveat about that ldap_howto.txt, it's a bit out of date and was written with a particular configuration in mind, but you do need to wrap your head around it to understand where values are coming from. ldap-group isn't very meaningful to set in the users file because it's an attribute in the ldap directory. In fact using the users file isn't generally useful in combination with with ldap because your users are in ldap, not a flat file, right? The users file can be useful when you want to match on the NAS via huntgroups, the ldap_howto does a fair job of illustrating that. So anyway you won't ever find "vpn-users" defined via the users file because the line you have won't be matched by anything Why? Because group gets set via ldap lookups using the groupmembership_filter and asking for the groupname_attribute for what the filter matched. So one question to ask is: is your ldap directory populated with the object classes and attributes this filter is searching for? As an aside one of the very first things I noticed looking at your debug output is the ldap module was built to use the Novell eDirectory server (which is a compile time switch). Unless you're using the Novell eDirectory server rather than a generic directory server things are going to behave a bit weird. Any idea why it's built to use Novell? Anyway that's probably not the crux of your problem at the moment, just a data point. I don't know why the eDirectory #ifdef's are even in rlm_ldap, to be honest they seem to be "odd" to put it politely. I don't have time at the moment to fully analyze what's going on in your set up but one of the very first things I noticed was this: (|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))) -> (|(&(objectClass=GroupOfNames)(member=))(&(objectClass=GroupOfUniqueNames)(uniquemember=))) Notice something? Ldap-UserDn was replaced by the empty string and that search filter isn't going to do you much good is it? So where does Ldap-UserDn come from? From doing a search in LDAP for the user. If the user is found then Ldap-UserDn is set to the location at which the user was found (think of a dn (i.e. distinguished name) as an address or pointer in an LDAP directory). So how was the search done to find the user? Well that's just a couple of lines above in the debug output: [ldap] performing search in dc=cns, with filter (uid=jmaher) One of the frustrating things about rlm_ldap is it doesn't provide debug output on successful searches, only failures. There is no failure, so we assume the search succeeded, but we really don't know what the result was :-( As a debugging tip I would suggest running ldapsearch on the command line with the same filter and see what you get back. You should get back a ldap search result with exactly one match with a specific dn, that dn is what should be showing up as Ldap-UserDn in rlm_ldap. So for starters you need to either populate your directory such that ldapsearch finds your user using the same parameters you configured in rlm_ldap, or you need to modify the parameters in rlm_ldap to match your directory such that it can find the user. That's a good starting place from which you can build further functionality. Hope that helps, -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
This is how I did it. Works well for me. http://lists.freeradius.org/mailman/htdig/freeradius-users/2009-November/msg... On Fri, May 21, 2010 at 5:26 PM, John Dennis <jdennis@redhat.com> wrote:
On 05/20/2010 05:44 PM, John Maher wrote:
I really didn't want to post here, but I just can't make any headway with my radius implementation. I am very new at this and still quite confused on how the various config files function and interact with each other. So, I'm not surprised that my implementation is only sort of working.
I have installed freeradius 2.1.8 on Ubuntu Server 8.04 by making deb packages from the source and installing the deb packages.
Radius is relying on an LDAP server for authentication of wireless clients. Only clients with valid usernames and passwords in LDAP will get authenticated.
What I would really like to do (other than actually be able to understand the concepts behind the config files) is require clients to be in a particular LDAP group (e.g., wireless-users) in order to successfully authenticate. I don't understand how to make that happen. I've tried creating group filters like this in "modules/ldap":
groupname_attribute = cn groupmembership_filter =
"(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))" groupmembership_attribute = memberUid
and this in "users":
DEFAULT LDAP-GROUP == vpn-users Service-Type = Administrative-User
But the output seems to indicate that it is not even considering my radiusd.conf config when it comes to the filter. (see output below).
I would so welcome assistance with this. In addition, is there any resource that is particularly good at explaining how radius and its config files really works?
I feel your pain, the ldap module is poorly documented and hard to use. There is doc in doc/ldap_howto.txt, not sure where that might be installed on Ubuntu though. Just a caveat about that ldap_howto.txt, it's a bit out of date and was written with a particular configuration in mind, but you do need to wrap your head around it to understand where values are coming from.
ldap-group isn't very meaningful to set in the users file because it's an attribute in the ldap directory. In fact using the users file isn't generally useful in combination with with ldap because your users are in ldap, not a flat file, right? The users file can be useful when you want to match on the NAS via huntgroups, the ldap_howto does a fair job of illustrating that. So anyway you won't ever find "vpn-users" defined via the users file because the line you have won't be matched by anything Why? Because group gets set via ldap lookups using the groupmembership_filter and asking for the groupname_attribute for what the filter matched. So one question to ask is: is your ldap directory populated with the object classes and attributes this filter is searching for?
As an aside one of the very first things I noticed looking at your debug output is the ldap module was built to use the Novell eDirectory server (which is a compile time switch). Unless you're using the Novell eDirectory server rather than a generic directory server things are going to behave a bit weird. Any idea why it's built to use Novell? Anyway that's probably not the crux of your problem at the moment, just a data point. I don't know why the eDirectory #ifdef's are even in rlm_ldap, to be honest they seem to be "odd" to put it politely.
I don't have time at the moment to fully analyze what's going on in your set up but one of the very first things I noticed was this:
(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))) ->
(|(&(objectClass=GroupOfNames)(member=))(&(objectClass=GroupOfUniqueNames)(uniquemember=)))
Notice something? Ldap-UserDn was replaced by the empty string and that search filter isn't going to do you much good is it? So where does Ldap-UserDn come from? From doing a search in LDAP for the user. If the user is found then Ldap-UserDn is set to the location at which the user was found (think of a dn (i.e. distinguished name) as an address or pointer in an LDAP directory). So how was the search done to find the user? Well that's just a couple of lines above in the debug output:
[ldap] performing search in dc=cns, with filter (uid=jmaher)
One of the frustrating things about rlm_ldap is it doesn't provide debug output on successful searches, only failures. There is no failure, so we assume the search succeeded, but we really don't know what the result was :-( As a debugging tip I would suggest running ldapsearch on the command line with the same filter and see what you get back.
You should get back a ldap search result with exactly one match with a specific dn, that dn is what should be showing up as Ldap-UserDn in rlm_ldap. So for starters you need to either populate your directory such that ldapsearch finds your user using the same parameters you configured in rlm_ldap, or you need to modify the parameters in rlm_ldap to match your directory such that it can find the user. That's a good starting place from which you can build further functionality.
Hope that helps,
-- 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
Hello, I am trying to run JRadius client Simulator against FreeRADIUS using EAP-TLS authentication. I was under the impression that these two offerings worked together right out of the box. I have tested my certs against FreeRADIUS using Microsoft supplicant and all is well. Will someone tell me what they think might be the problem. Please see the FreeRADIUS TLS messages, below. Your help will be greatly appreciated. Bill --> User-Name = user1 [tls] --> BUF-Name = 3eTI Test Cert (rsa1) [tls] --> subject = /C=US/ST=Maryland/O=3eTI/OU=Engineering/CN=3eTI Test Cert (rsa1)/emailAddress=wbickford@efjohnson.com [tls] --> issuer = /C=US/ST=Maryland/O=3eTI/OU=Engineering/CN=3eTI RSA Engineering Test Intermediate CA/emailAddress=wbickford@efjohnson.com [tls] --> verify return:1 [tls] TLS_accept: SSLv3 read client certificate A [tls] <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange [tls] TLS_accept: SSLv3 read client key exchange A [tls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [tls] <<< TLS 1.0 Handshake [length 0010], Finished [tls] >>> TLS 1.0 Alert [length 0002], fatal unexpected_message TLS Alert write:fatal:unexpected_message TLS_accept:failed in SSLv3 read certificate verify B rlm_eap: SSL error error:140880AE:SSL routines:SSL3_GET_CERT_VERIFY:missing verify message SSL: SSL_read failed inside of TLS (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls
William Rettig wrote:
TLS_accept:failed in SSLv3 read certificate verify B
rlm_eap: SSL error error:140880AE:SSL routines:SSL3_GET_CERT_VERIFY:missing verify message
SSL: SSL_read failed inside of TLS (-1), TLS session fails.
The JRadius client is broken. Alan DeKok.
On 05/21/2010 01:26 AM, John Dennis wrote: John, Thank you very much for responding with such detail and clarity. And thanks for pointing me to ldap_howto.txt. I'll be studying this to understand it better. Please see below for other comments.
As an aside one of the very first things I noticed looking at your debug output is the ldap module was built to use the Novell eDirectory server (which is a compile time switch). Unless you're using the Novell eDirectory server rather than a generic directory server things are going to behave a bit weird. Any idea why it's built to use Novell? Anyway that's probably not the crux of your problem at the moment, just a data point. I don't know why the eDirectory #ifdef's are even in rlm_ldap, to be honest they seem to be "odd" to put it politely.
I have no idea why that is the case. I did the following to create and install freeradius on Ubuntu (as suggested by this page: http://wiki.freeradius.org/Build#Building_Debian_packages): $ tar zxf freeradius-server-2.X.Y.tar.gz $ cd freeradius-server-2.X.Y $ fakeroot dpkg-buildpackage -b -uc $ sudo dpkg -i ../freeradius_2.X.Y-0_i386.deb
I don't have time at the moment to fully analyze what's going on in your set up but one of the very first things I noticed was this:
(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
->
(|(&(objectClass=GroupOfNames)(member=))(&(objectClass=GroupOfUniqueNames)(uniquemember=)))
Notice something?
I didn't notice what you pointed out, but it's telling. Actually, the thing I noticed and am confused by is that the filter I have in /etc/freeradius/modules/ldap (is that simply the configuration file for rlm_ldap?) is this: groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))" So why is the filter in the output this: (|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))) That filter is VERY similar to the commented out line in /etc/freeradius/modules/ldap. It appears to be hard coded in rlm_ldap, which is not likely, right? That commented out line is this: # groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))" I'm going to think through your other comments now. Thanks again. John -- * - - - - * - - - - * - - - - * - - - - * - - - - * - - - - * - - - - * John Maher Senior Systems and Network Administrator Department of Biochemistry & Molecular Biology and Department of Chemistry University of Massachusetts - Amherst voice: 413-577-3120 fax: 413-545-4490 OpenPGP Key ID: 0x2970A144 Want your email to be private? http://enigmail.mozdev.org
On 05/21/2010 10:44 AM, John Maher wrote:
I didn't notice what you pointed out, but it's telling. Actually, the thing I noticed and am confused by is that the filter I have in /etc/freeradius/modules/ldap (is that simply the configuration file for rlm_ldap?) is this:
groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))"
So why is the filter in the output this:
(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
I just figured this part out. The radiusd.conf file has an Include /etc/freeradius/modules statement, and there was a file in the modules directory called ldap.dpkg-old in that directory that was overiding the ldap config file. That doesn't mean everything works, but at least that mystery is solved. John
On 05/21/2010 05:10 PM, John Maher wrote:
On 05/21/2010 10:44 AM, John Maher wrote:
I didn't notice what you pointed out, but it's telling. Actually, the thing I noticed and am confused by is that the filter I have in /etc/freeradius/modules/ldap (is that simply the configuration file for rlm_ldap?) is this:
groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))"
So why is the filter in the output this:
(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
I just figured this part out. The radiusd.conf file has an Include /etc/freeradius/modules statement, and there was a file in the modules directory called ldap.dpkg-old in that directory that was overiding the ldap config file. That doesn't mean everything works, but at least that mystery is solved.
I think Josip Rodin is maintaining the deb packages. If somehow the old config files are overriding the new config files in the deb packages then you and Josip might want to work out what the problem is, sounds like a packaging bug. I've cc'ed Josip on this email, I know he reads this list but might not be paying attention to this thread. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Fri, May 21, 2010 at 05:19:55PM -0400, John Dennis wrote:
I just figured this part out. The radiusd.conf file has an Include /etc/freeradius/modules statement, and there was a file in the modules directory called ldap.dpkg-old in that directory that was overiding the ldap config file. That doesn't mean everything works, but at least that mystery is solved.
I think Josip Rodin is maintaining the deb packages. If somehow the old config files are overriding the new config files in the deb packages then you and Josip might want to work out what the problem is, sounds like a packaging bug. I've cc'ed Josip on this email, I know he reads this list but might not be paying attention to this thread.
Thanks. The real problem here is that FreeRADIUS includes *all* files in the modules/ directory, whereas excess files are really legitimate - *.dpkg-* conffile resolution backups, editor lock files and backup files, etc. This will be fixed either with code changes to reduce the filename pattern matched (e.g. *.conf) or by moving to modules-{available,enabled}/, like Apache does it. Until then, users need to be extra careful to keep modules/ clean. This applies everywhere (not just on Debian). -- 2. That which causes joy or happiness.
On 05/22/2010 04:34 AM, Josip Rodin wrote:
On Fri, May 21, 2010 at 05:19:55PM -0400, John Dennis wrote:
I just figured this part out. The radiusd.conf file has an Include /etc/freeradius/modules statement, and there was a file in the modules directory called ldap.dpkg-old in that directory that was overiding the ldap config file. That doesn't mean everything works, but at least that mystery is solved.
I think Josip Rodin is maintaining the deb packages. If somehow the old config files are overriding the new config files in the deb packages then you and Josip might want to work out what the problem is, sounds like a packaging bug. I've cc'ed Josip on this email, I know he reads this list but might not be paying attention to this thread.
Thanks. The real problem here is that FreeRADIUS includes *all* files in the modules/ directory, whereas excess files are really legitimate - *.dpkg-* conffile resolution backups, editor lock files and backup files, etc.
This will be fixed either with code changes to reduce the filename pattern matched (e.g. *.conf) or by moving to modules-{available,enabled}/, like Apache does it.
Until then, users need to be extra careful to keep modules/ clean. This applies everywhere (not just on Debian).
Oh, that's right, I had forgotten FreeRADIUS reads all files in the modules directory irrespective of it's name or extension. That's a serious problem. RPM installations will also leave old config files in those directories (.rpmsave files) when the package is updated. Alan I didn't see any open bugs on this, should we open one? Is this a planned modification for 2.2? I recall some discussion of this a while back on the mailing list. I suppose changing this is 2.1 would be a version violation. But it has such serious negative consequences I wonder if we shouldn't bite the bullet and change it in 2.1.9 before more people get bitten by this. But to be honest I'm not sure which is worse, an unexpected config file change on upgrade or mysterious *silent* failures after upgrade. I think the RPM spec file (and the deb files) could include a script which would detect the an old modules directory layout and convert it to modules-{available,enabled} layout automatically during a package upgrade. Also, I was just looking at our RPM spec file and I noticed that files in /etc/raddb/sites-enabled (which should just be symlinks) are marked as config(noreplace) which means RPM will leave backup files there instead of treating sites-enabled as just a collection of symlinks to be left alone. I think this represents a packaging bug on my end. However I noticed the suse freeradius.spec file in the freeradius-server tarballs also have the exact same config(noreplace) in raddb/sites-enabled so that packaging bug seems universal. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Alan I didn't see any open bugs on this, should we open one? Is this a planned modification for 2.2?
Yes.
I recall some discussion of this a while back on the mailing list. I suppose changing this is 2.1 would be a version violation. But it has such serious negative consequences I wonder if we shouldn't bite the bullet and change it in 2.1.9 before more people get bitten by this. But to be honest I'm not sure which is worse, an unexpected config file change on upgrade or mysterious *silent* failures after upgrade.
I'd make the change in 2.1.10, if at all. It's a relatively rare problem compared to other issues seen regularly on the list.
I think the RPM spec file (and the deb files) could include a script which would detect the an old modules directory layout and convert it to modules-{available,enabled} layout automatically during a package upgrade.
Sure...
Also, I was just looking at our RPM spec file and I noticed that files in /etc/raddb/sites-enabled (which should just be symlinks) are marked as config(noreplace) which means RPM will leave backup files there instead of treating sites-enabled as just a collection of symlinks to be left alone. I think this represents a packaging bug on my end. However I noticed the suse freeradius.spec file in the freeradius-server tarballs also have the exact same config(noreplace) in raddb/sites-enabled so that packaging bug seems universal.
Sure. Not everyone uses symlinks in sites-enabled. Some put files there directly. Alan DeKok.
Alan, John Maher at the first post asked if there is any resource that is particularly good at explaining how radius and its config files really works. I want just to ask it again, if possible, it there is any thread or link illustrating how all files in /etc/radb interact to each other. Thank U. On Sat, May 22, 2010 at 4:32 PM, Alan DeKok <aland@deployingradius.com>wrote:
John Dennis wrote:
Alan I didn't see any open bugs on this, should we open one? Is this a planned modification for 2.2?
Yes.
I recall some discussion of this a while back on the mailing list. I suppose changing this is 2.1 would be a version violation. But it has such serious negative consequences I wonder if we shouldn't bite the bullet and change it in 2.1.9 before more people get bitten by this. But to be honest I'm not sure which is worse, an unexpected config file change on upgrade or mysterious *silent* failures after upgrade.
I'd make the change in 2.1.10, if at all. It's a relatively rare problem compared to other issues seen regularly on the list.
I think the RPM spec file (and the deb files) could include a script which would detect the an old modules directory layout and convert it to modules-{available,enabled} layout automatically during a package upgrade.
Sure...
Also, I was just looking at our RPM spec file and I noticed that files in /etc/raddb/sites-enabled (which should just be symlinks) are marked as config(noreplace) which means RPM will leave backup files there instead of treating sites-enabled as just a collection of symlinks to be left alone. I think this represents a packaging bug on my end. However I noticed the suse freeradius.spec file in the freeradius-server tarballs also have the exact same config(noreplace) in raddb/sites-enabled so that packaging bug seems universal.
Sure. Not everyone uses symlinks in sites-enabled. Some put files there directly.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- ----------------------------------------------------------------- |JJohnny RANDRIAMAMPIONONA | | Phone: +212663682554 | | National School of Applied Sciences | | 1818 TANGIER 90000 | |----------------------------------------------------------------|
Johnny R wrote:
Alan,
John Maher at the first post asked if there is any resource that is particularly good at explaining how radius and its config files really works. I want just to ask it again, if possible, it there is any thread or link illustrating how all files in /etc/radb interact to each other.
radiusd.conf is the "master" file, and reads all of the other ones. The "modules" directory contains module configuration. The "sites-available" directory contains sample virtual servers. The "sites-enabled" directory contains enabled virtual servers. The "dictionary" file references dictionaries. Everything else is usually a file needed by a module. It's really not that complicated, and the filenames are usually descriptive, so you can tell what they do. Alan DeKok.
On 05/22/2010 01:45 PM, Alan DeKok wrote:
Johnny R wrote:
Alan,
John Maher at the first post asked if there is any resource that is particularly good at explaining how radius and its config files really works. I want just to ask it again, if possible, it there is any thread or link illustrating how all files in /etc/radb interact to each other.
radiusd.conf is the "master" file, and reads all of the other ones.
The "modules" directory contains module configuration.
The "sites-available" directory contains sample virtual servers.
The "sites-enabled" directory contains enabled virtual servers.
The "dictionary" file references dictionaries.
Everything else is usually a file needed by a module.
It's really not that complicated, and the filenames are usually descriptive, so you can tell what they do.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, Thanks for this information. Being very new to radius, and a bit sloppy with my wording, I was not clear about what I was looking for. It's true that the function of the different config files not that complicated. What is not clear to me, when looking at the output of freeradius -X that is generated from a user's connection attempt, is the sequencing and reasoning behind the output. For example, the output I posted included this: [ldap] performing user authorization for jmaher [ldap] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details [ldap] ... expanding second conditional [ldap] expand: %{User-Name} -> jmaher [ldap] expand: (uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=jmaher) [ldap] expand: dc=cns -> dc=cns [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] performing search in dc=cns, with filter (uid=jmaher) [ldap] No default NMAS login sequence [ldap] looking for check items in directory... [ldap] sambaNtPassword -> NT-Password == 0x4537353238434135323632453745303645438324444363635383830453042333 [ldap] sambaLmPassword -> LM-Password == 0x3743414639453142313632453745303645463337453431343231373532384341 [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user jmaher authorized to use remote access [ldap] ldap_release_conn: Release Id: 0 ++[ldap] returns ok I don't understand several things from this, but one example is why does it state: WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? and the next line states: [ldap] user jmaher authorized to use remote access ? Anyway, a good resource for understanding how radius and its modules do their jobs would be good to know about. Thanks. John
John Maher wrote:
Thanks for this information. Being very new to radius, and a bit sloppy with my wording, I was not clear about what I was looking for. It's true that the function of the different config files not that complicated. What is not clear to me, when looking at the output of freeradius -X that is generated from a user's connection attempt, is the sequencing and reasoning behind the output.
Well.. it does a lot. Remember, this isn't... DNS: what is the IP for name X? DHCP: please allocate an IP for MAC Y, I'm on switch X port Y RADIUS is *enormously* more complicated. As a result, the configuration files are more complicated, and the debug output is more complicated.
For example, the output I posted included this: ... I don't understand several things from this, but one example is why does it state:
WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly?
and the next line states:
[ldap] user jmaher authorized to use remote access
?
authorization != authentication If there isn't a password... the user can't be authenticated. The debug log shows this.
Anyway, a good resource for understanding how radius and its modules do their jobs would be good to know about.
doc/rlm_ldap explains how the LDAP module is used, and how the "access" is checked. Again... this *is* documented. The filenames shouldn't be hard to figure out: doc/rlm_ldap should be pretty easy to find. doc/aaa.txt explains how the authentication process works. While the documentation isn't perfect, I'm not sure what you want. The questions you're asking are answered in the existing documentation, which is reasonably well organized. (try: ls doc/*ldap* ...) Alan DeKok.
On 05/23/2010 11:27 AM, Alan DeKok wrote:
authorization != authentication
If there isn't a password... the user can't be authenticated. The debug log shows this.
Yes, obviously an important distinction. But where my mind goes immediately is "why is it that if I enter an incorrect password for that user that the user fails to gain access, but a correct password results in access granted?". But I imagine the answer is more complicated than the difference between authentication and authorization, and probably has something to do with some other authentication routine that takes place later. I have a lot to learn.
Anyway, a good resource for understanding how radius and its modules do their jobs would be good to know about.
doc/rlm_ldap explains how the LDAP module is used, and how the "access" is checked.
Again... this *is* documented. The filenames shouldn't be hard to figure out: doc/rlm_ldap should be pretty easy to find.
doc/aaa.txt explains how the authentication process works.
While the documentation isn't perfect, I'm not sure what you want. The questions you're asking are answered in the existing documentation, which is reasonably well organized. (try: ls doc/*ldap* ...)
Thanks for the direction. I'll study those now. John
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
John Maher wrote:
Yes, obviously an important distinction. But where my mind goes immediately is "why is it that if I enter an incorrect password for that user that the user fails to gain access, but a correct password results in access granted?".
doc/rlm_ldap explains this.
But I imagine the answer is more complicated than the difference between authentication and authorization, and probably has something to do with some other authentication routine that takes place later. I have a lot to learn.
No... it's a historial leftover from ISP authentication. It's not clear, but it does serve a purpose.
Thanks for the direction. I'll study those now.
Remember: DNS (bind) reads config files. DHCP (ISC) reads config files. FreeRADIUS reads config files, LDAP, SQL, DBM, shell scripts, Perl, Python, Java, Ruby, and implements EAP, WiMAX, IP address assignment (i.e. most of DHCP), name lookups (i.e. most of DNS) ... It's not surprising that people find it complicated. But a basic step-by-step approach helps a *lot*. Alan DeKok.
On 05/22/2010 12:32 PM, Alan DeKok wrote:
John Dennis wrote:
Alan I didn't see any open bugs on this, should we open one? Is this a planned modification for 2.2?
Yes.
I recall some discussion of this a while back on the mailing list. I suppose changing this is 2.1 would be a version violation. But it has such serious negative consequences I wonder if we shouldn't bite the bullet and change it in 2.1.9 before more people get bitten by this. But to be honest I'm not sure which is worse, an unexpected config file change on upgrade or mysterious *silent* failures after upgrade.
I'd make the change in 2.1.10, if at all. It's a relatively rare problem compared to other issues seen regularly on the list.
I think the RPM spec file (and the deb files) could include a script which would detect the an old modules directory layout and convert it to modules-{available,enabled} layout automatically during a package upgrade.
Sure...
Also, I was just looking at our RPM spec file and I noticed that files in /etc/raddb/sites-enabled (which should just be symlinks) are marked as config(noreplace) which means RPM will leave backup files there instead of treating sites-enabled as just a collection of symlinks to be left alone. I think this represents a packaging bug on my end. However I noticed the suse freeradius.spec file in the freeradius-server tarballs also have the exact same config(noreplace) in raddb/sites-enabled so that packaging bug seems universal.
Sure. Not everyone uses symlinks in sites-enabled. Some put files there directly.
Well, if that's the case then the current practice of reading every file found in the directory won't work. Why? Because many package managers leave backup files behind for configuration files. Then there is also the issue of editor backup files (e.g. the ~ files from emacs). When this issue originally came up I thought I recalled the argument was rather than renaming all the config files to have a common extension and only loading those files with extension the correct extension the preferred model would be to utilize enabled,available directories. The filenames would stay the same as would the practice of loading every file in the enabled directory. But the enabled directory would contain only symlinks. However that would still probably leave the problem of editor back up files and the naive admin who might copy a file (which invisibly would be a symlink) to a backup name. Bottom line: I think the practice of loading every file found in a directory is inherently risky and bug prone. I think it should only load files with a specific extension, that seems much safer. This still works nicely with the enabled/available split. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Bottom line: I think the practice of loading every file found in a directory is inherently risky and bug prone. I think it should only load files with a specific extension, that seems much safer. This still works nicely with the enabled/available split.
Sure. Is it critical enough to delay 2.1.9? Consider that there have been *sporadic* complaints since 2.0.0 (late 2007). Personally, I'd wait for 2.1.10. This work involves code changes *and* renaming configuration files. That's pretty drastic, and should be well tested before being released. Alan DeKok.
On 05/22/2010 01:56 PM, Alan DeKok wrote:
John Dennis wrote:
Bottom line: I think the practice of loading every file found in a directory is inherently risky and bug prone. I think it should only load files with a specific extension, that seems much safer. This still works nicely with the enabled/available split.
Sure. Is it critical enough to delay 2.1.9? Consider that there have been *sporadic* complaints since 2.0.0 (late 2007).
Personally, I'd wait for 2.1.10. This work involves code changes *and* renaming configuration files. That's pretty drastic, and should be well tested before being released.
Agreed. It should wait. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
Bottom line: I think the practice of loading every file found in a directory is inherently risky and bug prone. I think it should only load files with a specific extension, that seems much safer. This still works nicely with the enabled/available split.
although some would say thats the package people talking - and that the issue is only present because of how package management tools etc work. surely the best way of RPM, APT etc leaving behind all their rubbish/old-files/new-files etc is for them to utilise some revision control system or drop the files into a .special directory, eg .rpmnew for example. moving to a new system where eg module files have a .mod extension and virtual servers have a .vsf extension (virtual server file ;-) ) then any present systems need to have quite a few tweaks to be upgraded from their present situation... you could also argue that the easiest way is to include each file line by line in the radiusd.conf instead of using funky directories and including files wholesale. choices. choices. alan
On Sat, May 22, 2010 at 07:17:29PM +0100, Alan Buxey wrote:
although some would say thats the package people talking - and that the issue is only present because of how package management tools etc work. surely the best way of RPM, APT etc leaving behind all their rubbish/old-files/new-files etc is for them to utilise some revision control system or drop the files into a .special directory, eg .rpmnew for example.
Even if there was no packaging system, you would still have users who aren't excessively pedantic who would leave their own copies of files in the same folder. For example leaving an explicit copy of an old configuration in e.g. ldap-2010-05-23.bak. It still seems best to avoid the greediest match...
moving to a new system where eg module files have a .mod extension and virtual servers have a .vsf extension (virtual server file ;-) ) then any present systems need to have quite a few tweaks to be upgraded from their present situation...
That's why the mods-{available,enabled} idea is IMHO best. All Apache users are used to it, which covers most people anyway, the FR users got used to sites-{available,enabled} already so it's not much of a leap, and the upgrade procedure is simple: mv $confdir/modules $confdir/mods-available mkdir $confdir/mods-enabled cd $confdir/mods-enabled && ln -s ../mods-available/* . That preserves existing functionality to the letter - but it allows people to later disable what they don't want/need easily - just remove some extra symlinks.
you could also argue that the easiest way is to include each file line by line in the radiusd.conf instead of using funky directories and including files wholesale.
This is bad for packaged radiusd.conf's because it requires explicit user intervention into the file contents. The unconditional inclusion of (also packaged) eap.conf is an example of why this is bad - the admin who wants to tweak those settings has to either modify radiusd.conf to comment out the inclusion, or modify eap.conf to adjust the parameters. And either one of those causes the packaging system to notice that the user changed a configuration file upon the next upgrade, and in turn present a possibly confusing choice to the upgrading admin - and that kind of a situation doesn't necessarily end well :) Since this file simply defines the eap module, I don't really see any reason why it should not exist simply as a modules/eap file (or analogous in the future). Same goes for sql.conf, but luckily that one is commented out by default. -- 2. That which causes joy or happiness.
On Sat, May 22, 2010 at 01:45:59PM -0400, John Dennis wrote:
rather than renaming all the config files to have a common extension and only loading those files with extension the correct extension the preferred model would be to utilize enabled,available directories. The filenames would stay the same as would the practice of loading every file in the enabled directory. But the enabled directory would contain only symlinks. However that would still probably leave the problem of editor back up files and the naive admin who might copy a file (which invisibly would be a symlink) to a backup name.
We already have that particular problem with -enabled/ but it's confined to the realm of really sloppy admins who forget to edit in -available/. This is still acceptable and alleviates the original problem sufficiently, and it requires no code changes, just the default configuration changes. IMHO just changing modules to the -enabled/-available scheme would be a good first step and it should be done first, in 2.1.10 or whenever. -- 2. That which causes joy or happiness.
Josip Rodin wrote:
IMHO just changing modules to the -enabled/-available scheme would be a good first step and it should be done first, in 2.1.10 or whenever.
I'd say 2.2.0. And then move eap.conf && sql.conf to raddb/modules*, too. The only reason that eap.conf && sql.conf aren't in the modules directory is that too many documents point to them. And I couldn't take the thought of having raddb/eap.conf say: "look in modules/eap for the real configuration" ... and then getting questions asking "what does that mean?" Alan DeKok.
On Sun, May 23, 2010 at 12:54:49PM +0200, Alan DeKok wrote:
Josip Rodin wrote:
IMHO just changing modules to the -enabled/-available scheme would be a good first step and it should be done first, in 2.1.10 or whenever.
I'd say 2.2.0. And then move eap.conf && sql.conf to raddb/modules*, too.
The only reason that eap.conf && sql.conf aren't in the modules directory is that too many documents point to them. And I couldn't take the thought of having raddb/eap.conf say:
"look in modules/eap for the real configuration"
... and then getting questions asking "what does that mean?"
You already had one such transition, from clients to clients.conf, which was more painful because of a different format, IIRC. IMHO if done right this small change doesn't have to be painful at all. sites-available/enabled is already done in 2.1.x so the groundwork is already laid. -- 2. That which causes joy or happiness.
On Sat, May 22, 2010 at 10:22:12AM -0400, John Dennis wrote:
Alan I didn't see any open bugs on this, should we open one? Is this a planned modification for 2.2? I recall some discussion of this a while back on the mailing list. I suppose changing this is 2.1 would be a version violation. But it has such serious negative consequences I wonder if we shouldn't bite the bullet and change it in 2.1.9 before more people get bitten by this. But to be honest I'm not sure which is worse, an unexpected config file change on upgrade or mysterious *silent* failures after upgrade.
I think the RPM spec file (and the deb files) could include a script which would detect the an old modules directory layout and convert it to modules-{available,enabled} layout automatically during a package upgrade.
The deb package maintenance scripts can and will do the same.
Also, I was just looking at our RPM spec file and I noticed that files in /etc/raddb/sites-enabled (which should just be symlinks) are marked as config(noreplace) which means RPM will leave backup files there instead of treating sites-enabled as just a collection of symlinks to be left alone. I think this represents a packaging bug on my end. However I noticed the suse freeradius.spec file in the freeradius-server tarballs also have the exact same config(noreplace) in raddb/sites-enabled so that packaging bug seems universal.
We had the same problem in Debian packages at one point, but we unmarked them as conffiles already. -- 2. That which causes joy or happiness.
participants (8)
-
Alan Buxey -
Alan DeKok -
John Dennis -
John Maher -
Johnny R -
Josip Rodin -
Peter Lambrechtsen -
William Rettig