i am close, but need a pointer... i am using rlm_krb5 for authentication and rlm_ldap for authorization. when i add a radiusReplyItem of Cisco-AVPair = "shell:priv-lvl=15" to my user object, i am able to log into my switch. i want to have the radiusReplyItem given in a reply when the user is a member of a specific group in ldap, but i seem to be having trouble with that. it seems that when the ldap query is made for the group membership, the "short" version of the uid (uid=brendan) is being used and not matching. the actual member "value" in the group is the "long" version of the uid (uid=brendan,ou=Users,dc=bpk2,dc=com). is there something i can do to use the "long" version? radiusd -X output: FreeRADIUS Version 2.2.0, for host x86_64-redhat-linux-gnu, built on Oct 9 2012 at 17:45:02 Copyright (C) 1999-2012 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/linelog including configuration file /etc/raddb/modules/smsotp including configuration file /etc/raddb/modules/attr_filter including configuration file /etc/raddb/modules/sql_log including configuration file /etc/raddb/modules/checkval including configuration file /etc/raddb/modules/etc_group including configuration file /etc/raddb/modules/krb5 including configuration file /etc/raddb/modules/ntlm_auth including configuration file /etc/raddb/modules/sqlcounter_expire_on_login including configuration file /etc/raddb/modules/preprocess including configuration file /etc/raddb/modules/opendirectory including configuration file /etc/raddb/modules/digest including configuration file /etc/raddb/modules/rediswho including configuration file /etc/raddb/modules/attr_rewrite including configuration file /etc/raddb/modules/cui including configuration file /etc/raddb/modules/policy including configuration file /etc/raddb/modules/mac2vlan skipping config file, invalid characters in name "/etc/raddb/modules/&krb5.orig" including configuration file /etc/raddb/modules/mac2ip including configuration file /etc/raddb/modules/logintime including configuration file /etc/raddb/modules/smbpasswd including configuration file /etc/raddb/modules/sradutmp including configuration file /etc/raddb/modules/radrelay including configuration file /etc/raddb/modules/detail.example.com including configuration file /etc/raddb/modules/expr including configuration file /etc/raddb/modules/pap including configuration file /etc/raddb/modules/ippool including configuration file /etc/raddb/modules/wimax including configuration file /etc/raddb/modules/mschap skipping config file, invalid name "/etc/raddb/modules/ldap.rpmnew" including configuration file /etc/raddb/modules/inner-eap including configuration file /etc/raddb/modules/passwd including configuration file /etc/raddb/modules/unix skipping config file, invalid characters in name "/etc/raddb/modules/&dhcp_sqlippool.orig" including configuration file /etc/raddb/modules/perl including configuration file /etc/raddb/modules/pam including configuration file /etc/raddb/modules/soh including configuration file /etc/raddb/modules/ldap including configuration file /etc/raddb/modules/redis including configuration file /etc/raddb/modules/counter including configuration file /etc/raddb/modules/realm including configuration file /etc/raddb/modules/chap including configuration file /etc/raddb/modules/cache skipping config file, invalid characters in name "/etc/raddb/modules/&ldap.orig" including configuration file /etc/raddb/modules/always including configuration file /etc/raddb/modules/replicate including configuration file /etc/raddb/modules/expiration including configuration file /etc/raddb/modules/radutmp including configuration file /etc/raddb/modules/files including configuration file /etc/raddb/modules/acct_unique including configuration file /etc/raddb/modules/detail.log including configuration file /etc/raddb/modules/detail including configuration file /etc/raddb/modules/exec including configuration file /etc/raddb/modules/echo including configuration file /etc/raddb/modules/otp including configuration file /etc/raddb/modules/dynamic_clients including configuration file /etc/raddb/eap.conf including configuration file /etc/raddb/policy.conf including files in directory /etc/raddb/sites-enabled/ including configuration file /etc/raddb/sites-enabled/default including configuration file /etc/raddb/sites-enabled/inner-tunnel including configuration file /etc/raddb/sites-enabled/control-socket main { user = "radiusd" group = "radiusd" allow_core_dumps = no } including dictionary file /etc/raddb/dictionary main { name = "radiusd" prefix = "/usr" localstatedir = "/var" sbindir = "/usr/sbin" logdir = "/var/log/radius" run_dir = "/var/run/radiusd" libdir = "/usr/lib64/freeradius" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 pidfile = "/var/run/radiusd/radiusd.pid" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = yes log { stripped_names = no auth = yes 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 = "***REMOVED***" response_window = 20 max_outstanding = 65536 require_message_authenticator = yes zombie_period = 40 status_check = "status-server" ping_interval = 30 check_interval = 30 num_answers_to_alive = 3 num_pings_to_alive = 3 revive_interval = 120 status_check_timeout = 4 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server_pool my_auth_failover { type = fail-over home_server = localhost } realm example.com { auth_pool = my_auth_failover } realm LOCAL { } realm BPK2.COM { authhost = server.bpk2.com:1812 accthost = server.bpk2.com:1813 secret = ***REMOVED*** } radiusd: #### Loading Clients #### client localhost { ipaddr = 127.0.0.1 require_message_authenticator = no secret = "***REMOVED***" nastype = "other" } client 192.168.254.253 { require_message_authenticator = no secret = "***REMOVED***" shortname = "switch" nastype = "cisco" } client test.bpk2.com { require_message_authenticator = no secret = "this" shortname = "splunk" nastype = "other" } radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating module "exec" from file /etc/raddb/modules/exec exec { wait = no input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating module "expr" from file /etc/raddb/modules/expr Module: Linked to module rlm_expiration Module: Instantiating module "expiration" from file /etc/raddb/modules/expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating module "logintime" from file /etc/raddb/modules/logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server { # from file /etc/raddb/radiusd.conf modules { Module: Creating Auth-Type = digest Module: Creating Post-Auth-Type = REJECT Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating module "pap" from file /etc/raddb/modules/pap pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating module "chap" from file /etc/raddb/modules/chap Module: Linked to module rlm_mschap Module: Instantiating module "mschap" from file /etc/raddb/modules/mschap mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no allow_retry = yes } Module: Linked to module rlm_krb5 Module: Instantiating module "krb5" from file /etc/raddb/modules/krb5 krb5 { keytab = "/etc/radius.keytab" service_principal = "radius/server.bpk2.com" cache = yes } rlm_krb5: krb5_init ok Module: Linked to module rlm_digest Module: Instantiating module "digest" from file /etc/raddb/modules/digest Module: Linked to module rlm_unix Module: Instantiating module "unix" from file /etc/raddb/modules/unix unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_eap Module: Instantiating module "eap" from file /etc/raddb/eap.conf eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 4096 } Module: Linked to sub-module rlm_eap_md5 Module: Instantiating eap-md5 Module: Linked to sub-module rlm_eap_leap Module: Instantiating eap-leap Module: Linked to sub-module rlm_eap_gtc Module: Instantiating eap-gtc gtc { challenge = "Password: " auth_type = "PAP" } Module: Linked to sub-module rlm_eap_tls Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes rsa_key_length = 512 dh_key_length = 512 verify_depth = 0 CA_path = "/etc/raddb/certs" pem_file_type = yes private_key_file = "/etc/raddb/certs/server.pem" certificate_file = "/etc/raddb/certs/server.pem" CA_file = "/etc/raddb/certs/ca.pem" private_key_password = "whatever" dh_file = "/etc/raddb/certs/dh" random_file = "/etc/raddb/certs/random" fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" cache { enable = no lifetime = 24 max_entries = 255 } verify { } ocsp { enable = no override_cert_url = yes url = "http://127.0.0.1/ocsp/" use_nonce = yes timeout = 0 softfail = no } } Module: Linked to sub-module rlm_eap_ttls Module: Instantiating eap-ttls ttls { default_eap_type = "md5" copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" include_length = yes } Module: Linked to sub-module rlm_eap_peap Module: Instantiating eap-peap peap { default_eap_type = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no } Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no send_error = no } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating module "preprocess" from file /etc/raddb/modules/preprocess preprocess { huntgroups = "/etc/raddb/huntgroups" hints = "/etc/raddb/hints" with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no with_alvarion_vsa_hack = no } reading pairlist file /etc/raddb/huntgroups reading pairlist file /etc/raddb/hints Module: Linked to module rlm_realm Module: Instantiating module "suffix" from file /etc/raddb/modules/realm realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating module "files" from file /etc/raddb/modules/files files { usersfile = "/etc/raddb/users" acctusersfile = "/etc/raddb/acct_users" preproxy_usersfile = "/etc/raddb/preproxy_users" compat = "no" } reading pairlist file /etc/raddb/users reading pairlist file /etc/raddb/acct_users reading pairlist file /etc/raddb/preproxy_users Module: Linked to module rlm_ldap Module: Instantiating module "ldap" from file /etc/raddb/modules/ldap ldap { server = "ldap.bpk2.com" port = 389 password = "***REMOVED***" identity = "cn=Manager,dc=bpk2,dc=com" net_timeout = 1 timeout = 4 timelimit = 3 max_uses = 0 tls_mode = no start_tls = no tls_require_cert = "allow" tls { start_tls = no require_cert = "allow" } basedn = "dc=bpk2,dc=com" 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/raddb/ldap.attrmap" ldap_debug = 0 ldap_connections_number = 5 compare_check_items = no do_xlat = yes set_auth_type = yes keepalive { idle = 60 probes = 3 interval = 3 } } 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/raddb/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 userPassword mapped to RADIUS Password-With-Header 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: 0x7fa3421a5d60 Module: Checking preacct {...} for more modules to load Module: Linked to module rlm_acct_unique Module: Instantiating module "acct_unique" from file /etc/raddb/modules/acct_unique acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Identifier, NAS-Port" } Module: Checking accounting {...} for more modules to load Module: Linked to module rlm_radutmp Module: Instantiating module "radutmp" from file /etc/raddb/modules/radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Linked to module rlm_attr_filter Module: Instantiating module "attr_filter.accounting_response" from file /etc/raddb/modules/attr_filter attr_filter attr_filter.accounting_response { attrsfile = "/etc/raddb/attrs.accounting_response" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/attrs.accounting_response Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Instantiating module "attr_filter.access_reject" from file /etc/raddb/modules/attr_filter attr_filter attr_filter.access_reject { attrsfile = "/etc/raddb/attrs.access_reject" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/attrs.access_reject } # modules } # server server inner-tunnel { # from file /etc/raddb/sites-enabled/inner-tunnel modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load } # modules } # server radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 0 } listen { type = "acct" ipaddr = * port = 0 } listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 34812 Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host 192.168.254.253 port 49181, id=0, length=88 User-Name = "brendan" User-Password = "***REMOVED***" Cisco-AVPair = "shell:priv-lvl=15" NAS-IP-Address = 192.168.254.253 Acct-Session-Id = "0500001C" # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++? if (EAP-Message && Access-Request) ? Evaluating (EAP-Message ) -> FALSE ? Skipping (Access-Request) ++? if (EAP-Message && Access-Request) -> FALSE ++- entering else else {...} +++[chap] returns noop +++[mschap] returns noop +++[digest] returns noop [suffix] No '@' in User-Name = "brendan", looking up realm NULL [suffix] No such realm "NULL" +++[suffix] returns noop [eap] No EAP-Message, not doing EAP +++[eap] returns noop [files] users: Matched entry DEFAULT at line 1 +++[files] returns ok [ldap] performing user authorization for brendan [ldap] expand: %{Stripped-User-Name} -> [ldap] ... expanding second conditional [ldap] expand: %{User-Name} -> brendan [ldap] expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=brendan) [ldap] expand: dc=bpk2,dc=com -> dc=bpk2,dc=com [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] attempting LDAP reconnection [ldap] (re)connect to ldap.bpk2.com:389, authentication 0 [ldap] bind as cn=Manager,dc=bpk2,dc=com/***REMOVED*** to ldap.bpk2.com:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in dc=bpk2,dc=com, with filter (uid=brendan) [ldap] looking for check items in directory... [ldap] userPassword -> Password-With-Header == "{SSHA}***REMOVED***" [ldap] sambaNtPassword -> NT-Password == ***REMOVED*** [ldap] sambaLmPassword -> LM-Password == ***REMOVED*** [ldap] looking for reply items in directory... [ldap] user brendan 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] Normalizing SSHA1-Password from base64 encoding [pap] WARNING: Auth-Type already set. Not setting to PAP +++[pap] returns noop ++- else else returns ok Found Auth-Type = Kerberos # Executing group from file /etc/raddb/sites-enabled/default +- entering group Kerberos {...} ++[krb5] returns ok Login OK: [brendan] (from client switch port 0) # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 0 to 192.168.254.253 port 49181 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 0 with timestamp +11 Ready to process requests.
Brendan Kearney wrote:
i want to have the radiusReplyItem given in a reply when the user is a member of a specific group in ldap, but i seem to be having trouble with that. it seems that when the ldap query is made for the group membership, the "short" version of the uid (uid=brendan) is being used and not matching. the actual member "value" in the group is the "long" version of the uid (uid=brendan,ou=Users,dc=bpk2,dc=com). is there something i can do to use the "long" version?
Edit raddb/modules/ldap to use the DN you want: filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" The configuration files are editable for a reason. Edit them. Alan DeKok.
On Tue, 2014-03-25 at 15:46 -0400, Alan DeKok wrote:
Brendan Kearney wrote:
i want to have the radiusReplyItem given in a reply when the user is a member of a specific group in ldap, but i seem to be having trouble with that. it seems that when the ldap query is made for the group membership, the "short" version of the uid (uid=brendan) is being used and not matching. the actual member "value" in the group is the "long" version of the uid (uid=brendan,ou=Users,dc=bpk2,dc=com). is there something i can do to use the "long" version?
Edit raddb/modules/ldap to use the DN you want:
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
The configuration files are editable for a reason. Edit them.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
i have edited that file, and played with everything i can think of, or can find to try getting this working. hence my question here. for some reason the radiusReplyItem specified as an attribute of the groupOfNames is not being returned to the radius instance: [ldap] looking for reply items in directory... ... the output should be: [ldap] looking for reply items in directory... [ldap] extracted attribute Cisco-AVPair from generic item Cisco-AVPair = "shell:priv-lvl=15" ... i dont know what i should be changing to have the correct query done from the radius side, so that ldap responds with what it already is configured to respond with.
Brendan Kearney wrote:
i have edited that file, and played with everything i can think of, or can find to try getting this working.
That is entirely the wrong approach. You don't "play" with things, or randomly edit files. You update the LDAP "filter" item with the LDAP query string you want to use. You know the query string, why not use it in the "filter" configuration?
for some reason the radiusReplyItem specified as an attribute of the groupOfNames is not being returned to the radius instance:
[ldap] looking for reply items in directory... ...
the output should be:
[ldap] looking for reply items in directory... [ldap] extracted attribute Cisco-AVPair from generic item Cisco-AVPair = "shell:priv-lvl=15"
Yes, that should be there. Unless it can't find the reply items in the LDAP directory. Then it won't find then... and it won't print out the debug message saying that it found them.
i dont know what i should be changing to have the correct query done from the radius side, so that ldap responds with what it already is configured to respond with.
That sentence doesn't make sense. Alan DeKok.
On Tue, 2014-03-25 at 19:47 -0400, Alan DeKok wrote:
Brendan Kearney wrote:
i have edited that file, and played with everything i can think of, or can find to try getting this working.
That is entirely the wrong approach. You don't "play" with things, or randomly edit files. You update the LDAP "filter" item with the LDAP query string you want to use. dont be so literal. i changed what looked like it would make a difference and changed it back when it didnt.
You know the query string, why not use it in the "filter" configuration? not sure i do, but more and more i dont think that is the correct place to be looking.
for some reason the radiusReplyItem specified as an attribute of the groupOfNames is not being returned to the radius instance:
[ldap] looking for reply items in directory... ...
the output should be:
[ldap] looking for reply items in directory... [ldap] extracted attribute Cisco-AVPair from generic item Cisco-AVPair = "shell:priv-lvl=15"
Yes, that should be there. Unless it can't find the reply items in the LDAP directory. Then it won't find then... and it won't print out the debug message saying that it found them.
so, how do i make radius query correctly, so that ldap finds what i want it to?
i dont know what i should be changing to have the correct query done from the radius side, so that ldap responds with what it already is configured to respond with.
That sentence doesn't make sense.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Brendan Kearney wrote:
dont be so literal. i changed what looked like it would make a difference and changed it back when it didnt.
Then say that. The only way I know what you're doing is when you say so.
You know the query string, why not use it in the "filter" configuration? not sure i do, but more and more i dont think that is the correct place to be looking.
Why? The "filter" configuration item is the *only* place where the LDAP "uid" search string is set. Editing anything else won't help.
so, how do i make radius query correctly, so that ldap finds what i want it to?
Read the documentation and configure it as required. This isn't hard. Configure the "filter" item with the LDAP search string you need. If it doesn't work, read the debug output. It will show either an error, or that the user information wasn't found. It's just an LDAP search string... so if the user wasn't found, fix the string. The FreeRADIUS debug mode prints out the LDAP searches it's doing, so you can re-run the searches manually. Use them in "ldapsearch". The problem as I see it is you're saying "I did a bunch of stuff". But you're not saying *exactly* what you did, or what happened. These are computers... they are blatantly literal. Vague statements like "I tried things" aren't good enough. Alan DeKok.
Why? The "filter" configuration item is the *only* place where the LDAP "uid" search string is set. Editing anything else won't help. the uid vs dn may not be the issue (or at least not the only issue).
Read the documentation and configure it as required. i did and its vague. also its contradicted by what is on the freeradius site, which googling around turns up.
This isn't hard. Configure the "filter" item with the LDAP search string you need. If it doesn't work, read the debug output. It will show either an error, or that the user information wasn't found. It's just an LDAP search string... so if the user wasn't found, fix the string. where do i find the different variables that are referenced (Stripped-User-Name, User-Name, control:Ldap-UserDn, etc)? where is the documentation around what %{%{Stripped-User-Name}:-%{User-Name}} does vs %{%{control:Ldap-UserDn}:-%{control:Ldap-UserDn}} (which does not seem to work anyway)
The FreeRADIUS debug mode prints out the LDAP searches it's doing, so you can re-run the searches manually. Use them in "ldapsearch". need the pointer to the above info
The problem as I see it is you're saying "I did a bunch of stuff". But you're not saying *exactly* what you did, or what happened. These are computers... they are blatantly literal. Vague statements like "I tried things" aren't good enough. yes, and a bunch of stuff is all that can be tried/done when no real, comprehensive howtos exist on how to do this. http://www.clearfoundation.com/docs/howtos/setting_up_radius_to_use_ldap is the best i have found, and it does not work, is outdated or does not do everything i am looking for.
Brendan Kearney wrote:
Why? The "filter" configuration item is the *only* place where the LDAP "uid" search string is set. Editing anything else won't help. the uid vs dn may not be the issue (or at least not the only issue).
Pick one problem at a time and solve it. You said you wanted a search string which was more than "uid=...". I told you how to get that. Try it. The problem will be fixed, and you can move on to the next problem. Or, you can ask for more help to solve the uid / filter problem. You WILL NOT do anything useful by randomly switching between 5 separate issues. Only a consistent approach will fix anything. See "man radiusd" for more on this topic.
Read the documentation and configure it as required. i did and its vague.
The configuration items in raddb/modules/ldap are extensively documented. Do you have a SPECIFIC question? If so, why not ask it?
also its contradicted by what is on the freeradius site, which googling around turns up.
i.e. "stuff is wrong". WHAT is wrong? Where? You're again being as vague as possible. This isn't helpful. You did post the debug output in your first message, which was nice: Debug: [ldap] performing search in dc=bpk2,dc=com, with filter (uid=brendan) You: the actual member "value" in the group is the "long" version of the uid (uid=brendan,ou=Users,dc=bpk2,dc=com). is there something i can do to use the "long" version? Me: Edit the "filter" configuration in raddb/modules/ldap You: It doesn't work. Uh... that is a completely useless response. Yes, it does work. Many other people get LDAP filters working. They just edit the configuration item I said. So... did you *try*? WHAT did you try? Is it a secret? Why didn't you post the debug output to the list?
where do i find the different variables that are referenced (Stripped-User-Name, User-Name, control:Ldap-UserDn, etc)?
Those are RADIUS attributes. Go to wiki.freeradius.org, and type "ldap" into the search box. Hit <enter>. Click on the first link. The LDAP-UserDn attribute is documented there. User-Name is a standard RADIUS attribute. Read the specs to see what it is. Really... we are NOT going to document every one of 8000 RADIUS attributes. That's ridiculous. Stripped-User-Name is ... the User-Name, stripped of a realm. Read the debug output to see what's going on.
where is the documentation around what %{%{Stripped-User-Name}:-%{User-Name}} does
$ man unlang Which is referenced from the top comments on radiusd.conf.
vs %{%{control:Ldap-UserDn}:-%{control:Ldap-UserDn}} (which does not seem to work anyway)
If you had read the documentation, you'd understand that the above text makes zero sense. And see the FAQ for "it doesn't work". Really.
yes, and a bunch of stuff is all that can be tried/done when no real, comprehensive howtos exist on how to do this.
Go to wiki.freeradius.org, and type "ldap" into the search box. Hit <enter>. Click on the first link.
http://www.clearfoundation.com/docs/howtos/setting_up_radius_to_use_ldap is the best i have found, and it does not work, is outdated or does not do everything i am looking for.
Yeah... third-party documentation that's 10 years old is preferable to reading the official FreeRADIUS Wiki, or the comments in the configuration files. The FreeRADIUS documentation isn't perfect. But this is your third message complaining about it... with little to no content. If all you say is "you guys suck", you won't solve the problem. If you have *specific* and TECHNICAL questions, we can answer them. All it requires is for you to ask GOOD questions, with CONTENT. It's up to you. Choose to ask useful questions, and you will get useful answers. Alan DeKok.
On Tue, Mar 25, 2014 at 10:41:45PM -0400, Alan DeKok wrote:
You did post the debug output in your first message, which was nice:
Debug: [ldap] performing search in dc=bpk2,dc=com, with filter (uid=brendan)
You: the actual member "value" in the group is the "long" version of the uid (uid=brendan,ou=Users,dc=bpk2,dc=com). is there something i can do to use the "long" version?
Me: Edit the "filter" configuration in raddb/modules/ldap
Should this maybe be the "groupmembership_filter" instead of the "filter"? Could you please post the output of: ldapsearch -h ldap.bpk2.com -D "cn=Manager,dc=bpk2,dc=com" -W -b dc=bpk2,dc=com "(uid=brendan)" and similar for a group search? -jf
Could you please post the output of:
ldapsearch -h ldap.bpk2.com -D "cn=Manager,dc=bpk2,dc=com" -W -b dc=bpk2,dc=com "(uid=brendan)"
and similar for a group search?
[brendan@desktop ~]$ ldapsearch -h ldap1 "(uid=brendan)" SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=bpk2,dc=com> (default) with scope subtree # filter: (uid=brendan) # requesting: ALL # # brendan, Users, bpk2.com dn: uid=brendan,ou=Users,dc=bpk2,dc=com cn: Brendan Kearney displayName: Brendan Kearney gecos: Brendan Kearney,,blah,blah,blah gidNumber: 513 givenName: Brendan homeDirectory: /home/brendan homePhone: blah loginShell: /bin/bash sambaAcctFlags: [U] sambaKickoffTime: 2147483647 sambaLMPassword: ***REMOVED*** sambaLogoffTime: 2147483647 sambaLogonTime: 0 sambaNTPassword: ***REMOVED*** sambaPwdCanChange: 0 sambaPwdLastSet: 1331640042 sambaPwdMustChange: 1335528042 sambaSID: S-1-5-21-xxx-xxx-xxx-xxx sn: Kearney telephoneNumber: uid: brendan uidNumber: 1002 userPassword:: ***REMOVED*** objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: sambaSamAccount objectClass: radiusprofile radiusReplyItem: Cisco-AVPair = "shell:priv-lvl=15" l: blah shadowMax: 45 shadowLastChange: 16112 # search result search: 5 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------ [brendan@desktop ~]$ ldapsearch -h ldap1 "(cn=netEngineers)" SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=bpk2,dc=com> (default) with scope subtree # filter: (cn=netEngineers) # requesting: ALL # # netEngineers, Groups, bpk2.com dn: cn=netEngineers,ou=Groups,dc=bpk2,dc=com cn: netEngineers objectClass: groupOfNames objectClass: top objectClass: radiusprofile radiusReplyItem: Cisco-AVPair = "shell:priv-lvl=15" member: uid=brendan,ou=Users,dc=bpk2,dc=com radiusGroupName: netEngineers # search result search: 5 result: 0 Success # numResponses: 2 # numEntries: 1
I don't quite see why you conclude that it's the shortname "brendan" that's being used when searching for group memberships, but if that's correct, maybe you can work around it by changing the groupmembership_filter to: groupmembership_filter = "(&(objectClass=GroupOfNames)(member=uid=%{User-Name},ou=Users,dc=bpk2,dc=com))" -jf
On Thu, 2014-03-27 at 16:26 +0100, Jan-Frode Myklebust wrote:
I don't quite see why you conclude that it's the shortname "brendan" that's being used when searching for group memberships, but if that's correct, maybe you can work around it by changing the groupmembership_filter to:
groupmembership_filter = "(&(objectClass=GroupOfNames)(member=uid=%{User-Name},ou=Users,dc=bpk2,dc=com))"
-jf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
as defaulted in the config: #groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member= %{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember= %{control:Ldap-UserDn})))" the "groupOfNames" objectClass specifically MUST have the "member" attribute. the "member" attribute has a syntax of "Distinguished Name" (1.3.6.1.4.1.1466.115.121.1.12). Per RFC 2252, that is: 6.9. DN ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known. Examples (from [5]): CN=Steve Kille,O=Isode Limited,C=GB OU=Sales+CN=J. Smith,O=Widget Inc.,C=US CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB CN=Before\0DAfter,O=Test,C=GB 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB SN=Lu\C4\8Di\C4\87 note that the short form (as i have referred to it) is not present in the examples. so, the inappropriately named variable (control:Ldap-UserDn) does not contain a LDAP DN value when that value is not distinguishable or fully qualified. the value therefore, cannot be a called a DN. moreover, that value cannot used to query for group memberships in groupOfNames or groupOfUniqueNames groups. the short form value can be used to query for group memberships in posixGroup groups, though. the short form is a UID string, and implies a posixAccount (unless using RFC2307bis). the "posixGroup" objectClass specifically MAY have a "memberUid" attribute. the "memberUid" attribute has a syntax of "IA5 String" (1.3.6.1.4.1.1466.115.121.1.26). Per RFC 2252, that is: 6.15. IA5 String ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) The encoding of a value in this syntax is the string value itself. its a simple string. take the "uid=" off the string and it leaves the actual uid of "brendan", in my case. this is sometimes the value of the commonName (CN). the inappropriately named variable (control:Ldap-UserDn) should be called something more along the lines of UID and not DN if it contains the UID string. to sum it up: uid=brendan when used in a query will not match anything in a groupOfNames/groupOfUniqueNames group. the variable populated with that value should not be call anything to do with a DN (Distinguished Name) because it is not a DN. the group type being queried and the member type have to match. example: ldapsearch -h ldap1 "(&(objectClass=groupOfNames)(member=uid=brendan,ou=users,dc=bpk2,dc=com))" the above will work and return the grouOfNames groups i am a member of. ldapsearch -h ldap1 "(&(objectClass=groupOfNames)(member=uid=brendan))" and ldapsearch -h ldap1 "(&(objectClass=groupOfNames)(memberUid=brendan))" both fail to return any matches. uid=brendan when used in a query will match appropriately in a posixAccount group. the variable populated with that value should be called something along the lines of a UID, because thats what it is. the group type being queried and the member type have to match. example: ldapsearch -h ldap1 "(&(objectClass=posixGroup)(memberUid=brendan))" the above will work and return the posixGroup groups that i am a member of. i hope this clears up the ambiguity i have found in the configs. what remains, is what i need to do to correctly lookup groupOfNames memberships of users by their DN. while your proposed filter does seem to accomplish that, i would like to know if a more dynamically formulated string can be put together, to create the DN out of concatenated variables. just a more scalable solution. man unlang is where i plan to look, now that i know that is the relevant place to be reading up on it. i will point out at this time that "tens of thousands of others" who are using FreeRADIUS with LDAP successfully either got lucky and have posixGroup groups being matched, figured this out and have not sought/provided clarification on the subject, or are not doing what i am doing with LDAP.
Brendan Kearney wrote:
as defaulted in the config: #groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member= %{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember= %{control:Ldap-UserDn})))"
The LDAP-UserDn attribute is populated by the rlm_ldap module, with the user's DN. The intention is that the DN can be used to identify the user in later queries. i.e. the rlm_ldap module takes User-Name = 'bob' as one of the inputs, does a search with that in the "filter", and gets a unique entry. It finds the DN in that entry, and uses it to create the LDAP-UserDn attribute. Caching the LDAP-UserDn attribute means that the ldap module can do faster ldap searches, as it knows the user's DN. It doesn't have to find the user during every search. It can just grab the users information directly... because it has a DN.
the "groupOfNames" objectClass specifically MUST have the "member" attribute. the "member" attribute has a syntax of "Distinguished Name" (1.3.6.1.4.1.1466.115.121.1.12). Per RFC 2252, that is:
6.9. DN
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known.
Examples (from [5]): CN=Steve Kille,O=Isode Limited,C=GB OU=Sales+CN=J. Smith,O=Widget Inc.,C=US CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB CN=Before\0DAfter,O=Test,C=GB 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB SN=Lu\C4\8Di\C4\87
note that the short form (as i have referred to it) is not present in the examples. so, the inappropriately named variable (control:Ldap-UserDn) does not contain a LDAP DN value when that value is not distinguishable or fully qualified.
I don't know what you mean by "short form". The LDAP-UserDn contains the full DN as returned by the LDAP server. If your LDAP server returns a "short form", then that's the source of the problem. i.e. FreeRADIUS just queries LDAP. If the LDAP server returns crap... don't blame FreeRADIUS. That message is a difficult one to get across. A lot of people get upset at me for being "unhelpful", because "Don't blame FreeRADIUS" is nearly a mantra here. Yet I'm giving them all the help that's possible to give. FreeRADIUS depends on databases for it's data. If the databases return crap... don't blame FreeRADIUS. FreeRADIUS depends on the NAS to enforce post-authentication network access. If access fails when it should succeed, or succeed when it should fail... don't blame FreeRADIUS. FreeRADIUS depends on the NAS to supply accounting data. If the NAS doesn't send it... don't ask "How do I configure FreeRADIUS to get X in accounting packets?" Much of your hostility is due to the above issues. FreeRADIUS is working the way it's designed to work. Yet something is going wrong. You're blaming FreeRADIUS. I'm trying to convince you that (in this case), it's very likely something else. And yes, I do sometimes say that FreeRADIUS has bugs. I'm not completely soulless. When people report a bug, the turn-around time for a fix is often measure in *minutes*. Try having any commercial product beat that.
the value therefore, cannot be a called a DN.
It's *intended* to be the DN. If the database supplies crap for that field... why would you blame FreeRADIUS? Think about it. There is NO configuration entry for LDAP-UserDN in FreeRADIUS. The ONLY place it comes from is the database. Yet it's filled with crap. So... which piece of the puzzle is to blame?
moreover, that value cannot used to query for group memberships in groupOfNames or groupOfUniqueNames groups.
the short form value can be used to query for group memberships in posixGroup groups, though. the short form is a UID string, and implies a posixAccount (unless using RFC2307bis).
That's all true... provided that the LDAP-UserDN is filled with crap.
its a simple string. take the "uid=" off the string and it leaves the actual uid of "brendan", in my case. this is sometimes the value of the commonName (CN). the inappropriately named variable (control:Ldap-UserDn) should be called something more along the lines of UID and not DN if it contains the UID string.
Only if your LDAP server returns a UID instead of a DN when FreeRADIUS asks it for the users DN. If you run Version 3, it has MUCH better debugging for LDAP. It will print out the exact DN returned by the LDAP server. That should help with debugging. Try that. If the DN is crap... go fix your database. Or, update the FreeRADIUS queries to work with a crap DN. That's why the queries are editable.
to sum it up:
uid=brendan when used in a query will not match anything in a groupOfNames/groupOfUniqueNames group. the variable populated with that value should not be call anything to do with a DN (Distinguished Name) because it is not a DN.
Likely because the LDAP server returned something unexpected for the users DN. Again, FreeRADIUS isn't a database. It isn't magic. It asks the LDAP server for information, and then uses that information in later LDAP queries. All of the LDAP queries used by FreeRADIUS are documented in the rlm_ldap module configuration file. They're printed out in debugging mode. All of this is to tell you *exactly* what it's doing.
ldapsearch -h ldap1 "(&(objectClass=posixGroup)(memberUid=brendan))" the above will work and return the posixGroup groups that i am a member of.
You can use that in group membership filters. That's why the configuration is text and editable... so you can edit it.
while your proposed filter does seem to accomplish that, i would like to know if a more dynamically formulated string can be put together, to create the DN out of concatenated variables. just a more scalable solution. man unlang is where i plan to look, now that i know that is the relevant place to be reading up on it.
You can create *any* string out of concatenated variables. String expansion is documented extensively in "man unlang", and there are hundreds of examples in the config files. i.e. the debug log you posted previous shows the INPUT strings before expansion, and the OUTPUT strings after expansion. This should make it *very* clear how to create dynamically formulated strings.
i will point out at this time that "tens of thousands of others" who are using FreeRADIUS with LDAP successfully either got lucky and have posixGroup groups being matched, figured this out and have not sought/provided clarification on the subject, or are not doing what i am doing with LDAP.
I would bet the second. The default configuration files are designed to work in as many situations as possible. Many people have used the default ldap config unmodified (only setting hostname), and had it work with OpenLDAP, Active Directory, Sun DS, and other LDAP servers. If a new release didn't do LDAP searches correctly, we would be *inundated* with complaints. Since that hasn't happened, I can only conclude that the 10s of 1000s of people using FreeRADIUS with LDAP don't have the problems you're seeing. And therefore there's nothing wrong with FreeRADIUS. Alan DeKok.
On Thu, Mar 27, 2014 at 08:07:17PM -0400, Brendan Kearney wrote:
while your proposed filter does seem to accomplish that, i would like to know if a more dynamically formulated string can be put together, to create the DN out of concatenated variables. just a more scalable solution.
So my suggested filter works? I wasn't expecting that.. Guess that should mean that your Ldap-UserDn is somehow broken.
i will point out at this time that "tens of thousands of others" who are using FreeRADIUS with LDAP successfully either got lucky and have posixGroup groups being matched, figured this out and have not sought/provided clarification on the subject, or are not doing what i am doing with LDAP.
Count me as one of the lucky ones who's gotten it working with my posixGroup groups, and who don't fetch avpairs from the groups. I agree that freeradius definitely doesn't pass the grandma test. 113 files in /etc/raddb seems a but much, so I've been struggeling for a very long time trying to understand which files needs changes to achive what. But I guess this also is part of the power of freeradius. A lot of stuff is implemented, and is tweakable in the modules/ and sites-*/ files. I'm getting ready to dig into "unlang" myself to try to define a access regime of groups of NAS'es and groups of people. It looks like it should be able to do just about anything. -jf
i will point out at this time that "tens of thousands of others" who are using FreeRADIUS with LDAP successfully either got lucky and have posixGroup groups being matched, figured this out and have not sought/provided clarification on the subject, or are not doing what i am doing with LDAP.
Count me as one of the lucky ones who's gotten it working with my posixGroup groups, and who don't fetch avpairs from the groups.
I agree that freeradius definitely doesn't pass the grandma test.
The majority of configuration files are well documented. For the one's which aren't, feel free to send pull requests. You don't even need to understand git, github has a built in text editor, just fork the server, make your changes, and whack the pull request button. The barrier to contributing couldn't be much lower.
113 files in /etc/raddb seems a but much,
There a metric shit ton (51 in master) modules for the server, and several sub-modules. Should we merge all the configs into one big monolithic file, would that make the server easier to manage?
so I've been struggeling for a very long time trying to understand which files needs changes to achive what.
Global server configuration options: radiusd.conf Policy: sites-enabled/default Modules: mods-available/* Things used by modules: mods-config/*
But I guess this also is part of the power of freeradius. A lot of stuff is implemented, and is tweakable in the modules/ and sites-*/ files.
I'm getting ready to dig into "unlang" myself to try to define a access regime of groups of NAS'es and groups of people. It looks like it should be able to do just about anything.
Yes, and if you can't do it in unlang, you can do it in perl, python, or ruby (don't do it in ruby), or, with recent versions, write a web API in your favourite crappy web development language and write all your logic there instead. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Jan-Frode Myklebust wrote:
I agree that freeradius definitely doesn't pass the grandma test.
For some things. For basic authentication? Add a "client" definition, add a user / password in the "users" file, and about 15 authentication methods will Just Work. The rest of this rant isn't directed at you... it's just an explanation as to WHY things are they way they are. For more complex authentication, see my web page, http://deployingradius.com/. The only complaints I've gotten in 10 years have been people pointing out typos or spelling mistakes. Are there basic howtos on SQL, LDAP, etc.? No. Why? No one has submitted them. In 15 years of people complaining about the "bad documentation", not one single complainer has ever said: "You know, I don't want anyone else to go through the same pain I did. So to help people like me, I'm going to write a quick howto, and put it on the Wiki". No. Every single complainer cares only about their problems, and cares nothing for anyone else. They complain that other people have to do MORE work for them, for free. They refuse to contribute anything themselves. It's pretty obvious after 15 years, the more someone complains, the less they follow instructions, and the less they get done. The people who DO get work done fit another personality type. They just get things done. They submit patches, documentation fixes, etc., and generally have empathy for other people.
113 files in /etc/raddb seems a but much,
It's called "documentation". The modules don't have module-specific documentation, like http://wiki.nginx.org/Modules. Instead, we supply *working* configurations as examples. I can't tell you how many times I've installed a piece of software with great documentation, and no examples. When I try to create a working configuration from the documentation, it often doesn't work. Why? It's impossible to find out. The "sites-available" directory is full of working examples for many different scenarios. The comments in each file describe what the problem is, and how the file creates the solution. It describes how to change the example to suit your local configuration. Again, in about 5 years of having those examples, the only complaints have been about typos. So there *is* a lot of FreeRADIUS documentation. It's just not organized into web pages.
so I've been struggeling for a very long time trying to understand which files needs changes to achive what. But I guess this also is part of the power of freeradius. A lot of stuff is implemented, and is tweakable in the modules/ and sites-*/ files.
Exactly. FreeRADIUS ships with more examples, and more working protocols than any comparable server: DNS, DHCP, HTTP, FTP, etc.
I'm getting ready to dig into "unlang" myself to try to define a access regime of groups of NAS'es and groups of people. It looks like it should be able to do just about anything.
Exactly. FreeRADIUS can do just about anything. But for anything past the basic && common configuration... you've got to put the pieces together yourself. The reason is that people want a RADIUS server to do MUCH more than a typical DNS or DHCP server. So configuring DNS or DHCP is trivial. Edit one text file, and you're done. Configuring a RADIUS server means juggling database configurations, schemas, policies, etc. Doing that requires a certain level of competence, and more importantly, a methodical approach. Some people just can't do that. Alan DeKok.
Hi,
Are there basic howtos on SQL, LDAP, etc.? No. Why? No one has submitted them. In 15 years of people complaining about the "bad documentation", not one single complainer has ever said:
"You know, I don't want anyone else to go through the same pain I did. So to help people like me, I'm going to write a quick howto, and put it on the Wiki".
oh...whilst pretty much on the mark I'd say I disagree. you seem to have forgotten those that 1) write up their own web pages with instructions and then dont update them when new stuff comes out (as its no longer things they do) - which then cause problems for future people who use google to find documentation (just look at the history of this list and people quoting random 3rd party web sites. sure, the people are meaning well - but the documentation really should be centralised and kept up to date 2) post after a long thread with 'I've now got it working' - but actually dont post any further details or feedback alan
A.L.M.Buxey@lboro.ac.uk wrote:
oh...whilst pretty much on the mark I'd say I disagree. you seem to have forgotten those that
I wasn't planning on a an exhaustive list of mistakes. But these comments are good, too.
1) write up their own web pages with instructions and then dont update them when new stuff comes out (as its no longer things they do) - which then cause problems for future people who use google to find documentation (just look at the history of this list and people quoting random 3rd party web sites.
sure, the people are meaning well - but the documentation really should be centralised and kept up to date
Yes. The Wiki exists for a purpose. EDIT IT! Why the heck are they updating their pages, that no one else will ever be able to find?
2) post after a long thread with 'I've now got it working' - but actually dont post any further details or feedback
Yes... very frustrating. Alan DeKok.
Yes. The Wiki exists for a purpose. EDIT IT! Why the heck are they updating their pages, that no one else will ever be able to find?
As someone who has a set of instructions like this, it sometimes is an effort to: a) document SOMETHING that works (or describes specific quirks for some local specifics) b) save others in the same organisation the effort of going through what they've gone though c) limit the audience to specific people For c) one would expect to at least apply some set of permissions (i.e. visible only if logged into the Wiki), but not everyone is as particular about that as others are. In my case specifically, because my work was EU-funded, I've had to have some sort of deliverable (and it had to be sharable with partners elsewhere), and since I had to start from a blank slate, it's easier to write things down. Not saying that EVERYONE must do that, but it's useful. :-)
2) post after a long thread with 'I've now got it working' - but actually dont post any further details or feedback
Yes... although there's also the fear of "this is how I did it" and then getting flamed with "WTF did you do it that way??" This may not be applicable to this list, but unfortunately, human nature tends to veer towards "If one mailing list is that way, then I'll treat most other lists with the same caution, JIC" (case in point, some recent threads that involved some stroppy comments). Now, as for editing the Wiki, you may wish to extend Omnigollum beyond just GitHub and OpenId (who uses OpenId?) to make it easier to log in... not everyone has a Github or OpenId account (I didn't have either for quite a while). That said though, the FR documentation is better than some other efforts I've had the misfor^H^H^H^H^H^Hpleasure to work with in the past ;-) Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 28 Mar 2014, at 15:59, <stefan.paetow@diamond.ac.uk> <stefan.paetow@diamond.ac.uk> wrote:
Yes. The Wiki exists for a purpose. EDIT IT! Why the heck are they updating their pages, that no one else will ever be able to find?
As someone who has a set of instructions like this, it sometimes is an effort to:
a) document SOMETHING that works (or describes specific quirks for some local specifics) b) save others in the same organisation the effort of going through what they've gone though c) limit the audience to specific people
For c) one would expect to at least apply some set of permissions (i.e. visible only if logged into the Wiki), but not everyone is as particular about that as others are.
In my case specifically, because my work was EU-funded, I've had to have some sort of deliverable (and it had to be sharable with partners elsewhere), and since I had to start from a blank slate, it's easier to write things down. Not saying that EVERYONE must do that, but it's useful. :-)
2) post after a long thread with 'I've now got it working' - but actually dont post any further details or feedback
Yes... although there's also the fear of "this is how I did it" and then getting flamed with "WTF did you do it that way??"
How you take that sort of response is obviously very personal, but i'd rather get feedback pointing to possible issues before they occur, instead of getting a call at 3am saying the RADIUS service has gone tits up.
This may not be applicable to this list, but unfortunately, human nature tends to veer towards "If one mailing list is that way, then I'll treat most other lists with the same caution, JIC" (case in point, some recent threads that involved some stroppy comments). Now, as for editing the Wiki, you may wish to extend Omnigollum beyond just GitHub and OpenId (who uses OpenId?)
The person who requested we add it, and then complained bitterly that it was broken until they figured out it was a problem with their OpenID service.
to make it easier to log in... not everyone has a Github or OpenId account (I didn't have either for quite a while).
Suggestions? It uses omniauth so it's absolutely trivial to add other auth methods supported by omniauth. Really, it's a one line config change per auth method. It even adds the little pretty auth icons to the selection page for you automatically. We tried facebook and twitter, but it increased levels of spam and nastiness.
That said though, the FR documentation is better than some other efforts I've had the misfor^H^H^H^H^H^Hpleasure to work with in the past ;-)
:) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
How you take that sort of response is obviously very personal, but i'd rather get feedback pointing to possible issues before they occur, instead of getting a call at 3am saying the RADIUS service has gone tits up.
Absolutely :-)
Suggestions? It uses omniauth so it's absolutely trivial to add other auth methods supported by omniauth. Really, it's a one line config change per auth method. It even adds the little pretty auth icons to the selection page for you automatically.
*cough*OAuth*cough* (covers the Chocolate Factory at the very least)
We tried facebook and twitter, but it increased levels of spam and nastiness.
Ahhh, that explains why OAuth's not in there. In which case, do ignore my ramblings. :-) Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
I think one of the problems with user contributed doc is it ends up being: "A How-To of how to solve my unique problem exactly the way I did" Many of the thorny problems that trip up users are directly related to their unique deployment requirements. One of the great things about FreeRADIUS is it's enormous flexibility, but that's also it's liability when it comes to documentation. There are often multiple ways to accomplish the same thing and the final solution is often dictated by constraints unique to the deployment or personal taste. Usually these How-To's do not serve as a good generic guide. To my mind the fundamental documentation problem is not the lack of specific documentation detailing the details, there is plenty of that. What's missing is an overarching explanation of how all the pieces fit together and/or can be assembled. My general observation is many users have problems because they do not understand how the server works in broad terms and how that behavior can be adjusted to meet certain deployment requirements. Until folks have a working mental model of what's going on any documentation about pulling a specific lever or turning a certain knob isn't going to help them because they don't understand the "why" behind the recommendation. -- John
On 28 Mar 2014, at 17:17, John Dennis <jdennis@redhat.com> wrote:
I think one of the problems with user contributed doc is it ends up being:
"A How-To of how to solve my unique problem exactly the way I did"
Many of the thorny problems that trip up users are directly related to their unique deployment requirements. One of the great things about FreeRADIUS is it's enormous flexibility, but that's also it's liability when it comes to documentation. There are often multiple ways to accomplish the same thing and the final solution is often dictated by constraints unique to the deployment or personal taste. Usually these How-To's do not serve as a good generic guide.
To my mind the fundamental documentation problem is not the lack of specific documentation detailing the details, there is plenty of that. What's missing is an overarching explanation of how all the pieces fit together and/or can be assembled. My general observation is many users have problems because they do not understand how the server works in broad terms and how that behaviour can be adjusted to meet certain deployment requirements.
Until folks have a working mental model of what's going on any documentation about pulling a specific lever or turning a certain knob isn't going to help them because they don't understand the "why" behind the recommendation.
I agree, there needs to be more documentation around fundamental concepts as opposed to specific scenarios. The behaviour of the server is actually really simple. Just an expanded version of http://wiki.freeradius.org/guide/Concepts with some diagrams would be nice. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 28 Mar 2014, at 18:39, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 28 Mar 2014, at 17:17, John Dennis <jdennis@redhat.com> wrote:
I think one of the problems with user contributed doc is it ends up being:
"A How-To of how to solve my unique problem exactly the way I did"
Many of the thorny problems that trip up users are directly related to their unique deployment requirements. One of the great things about FreeRADIUS is it's enormous flexibility, but that's also it's liability when it comes to documentation. There are often multiple ways to accomplish the same thing and the final solution is often dictated by constraints unique to the deployment or personal taste. Usually these How-To's do not serve as a good generic guide.
To my mind the fundamental documentation problem is not the lack of specific documentation detailing the details, there is plenty of that. What's missing is an overarching explanation of how all the pieces fit together and/or can be assembled. My general observation is many users have problems because they do not understand how the server works in broad terms and how that behaviour can be adjusted to meet certain deployment requirements.
Until folks have a working mental model of what's going on any documentation about pulling a specific lever or turning a certain knob isn't going to help them because they don't understand the "why" behind the recommendation.
I agree, there needs to be more documentation around fundamental concepts as opposed to specific scenarios.
The behaviour of the server is actually really simple.
Just an expanded version of http://wiki.freeradius.org/guide/Concepts with some diagrams would be nice.
Hmm, but people here are notoriously bad at taking things and running them so in the interim I've compiled this comprehensive flow chart that should cover pretty much every scenario. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
Just an expanded version of http://wiki.freeradius.org/guide/Concepts with some diagrams would be nice.
Basic concepts: http://networkradius.com/doc/FreeRADIUS%20Technical%20Guide.pdf how PAP works: http://networkradius.com/doc/FreeRADIUS-Implementation-Ch5.pdf More to come. Alan DeKok.
Arran, I think you're onto a very important point... especially for those of us who benefit from the visual in our learning habits. I personally benefited a lot by drawing out the basics of RADIUS in general and the FreeRADIUS server in particular, so that I could communicate with our network team and get our old servers updated to support the roll-out of eduroam on our campus. Your suggestion of some expansion and graphic help for the overall layout resonates with me... mental models, concept maps, and all that. A picture can help cement the basic landscape, and make more advanced conversations easier to sustain. I'm in a busy mode and it will take me a while (no promises before summer?), but I'll commit to putting this kind of thing together. Steve ======================== Steven Lovaas IT Security Manager Colorado State University Steven.Lovaas@ColoState.edu ======================== -----Original Message----- From: freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org [mailto:freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Friday, March 28, 2014 12:39 PM To: FreeRadius users mailing list Subject: Re: Why documentation is the way it is On 28 Mar 2014, at 17:17, John Dennis <jdennis@redhat.com> wrote:
I think one of the problems with user contributed doc is it ends up being:
"A How-To of how to solve my unique problem exactly the way I did"
Many of the thorny problems that trip up users are directly related to their unique deployment requirements. One of the great things about FreeRADIUS is it's enormous flexibility, but that's also it's liability when it comes to documentation. There are often multiple ways to accomplish the same thing and the final solution is often dictated by constraints unique to the deployment or personal taste. Usually these How-To's do not serve as a good generic guide.
To my mind the fundamental documentation problem is not the lack of specific documentation detailing the details, there is plenty of that. What's missing is an overarching explanation of how all the pieces fit together and/or can be assembled. My general observation is many users have problems because they do not understand how the server works in broad terms and how that behaviour can be adjusted to meet certain deployment requirements.
Until folks have a working mental model of what's going on any documentation about pulling a specific lever or turning a certain knob isn't going to help them because they don't understand the "why" behind the recommendation.
I agree, there needs to be more documentation around fundamental concepts as opposed to specific scenarios. The behaviour of the server is actually really simple. Just an expanded version of http://wiki.freeradius.org/guide/Concepts with some diagrams would be nice. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 28 Mar 2014, at 19:24, Lovaas,Steven <Steven.Lovaas@ColoState.EDU> wrote:
Arran, I think you're onto a very important point... especially for those of us who benefit from the visual in our learning habits. I personally benefited a lot by drawing out the basics of RADIUS in general and the FreeRADIUS server in particular, so that I could communicate with our network team and get our old servers updated to support the roll-out of eduroam on our campus. Your suggestion of some expansion and graphic help for the overall layout resonates with me... mental models, concept maps, and all that. A picture can help cement the basic landscape, and make more advanced conversations easier to sustain.
I'm in a busy mode and it will take me a while (no promises before summer?), but I'll commit to putting this kind of thing together.
Simple stuff like this is good. That took about two hours. Even I don't know the intricacies of all the flows within the server. The dotted lines represent when the request can loop back into a section. As far I can tell Authorize and Post-Auth are the only places this can happen. It happens when the request starts off in one section and then something happens that requires it to run through a different part of the same section. For authorize that's setting control:Autz-Type to something, and then the request leaving the section. For Post-Auth, it's rejecting the request. Oddly, if you start off in the main Pre-Proxy-Type section, and set control:Pre-Proxy-Type it doesn't loop back round into the Pre-Proxy-Type you set, it just carries on and proxies the request. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 29 Mar 2014, at 18:10, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 28 Mar 2014, at 19:24, Lovaas,Steven <Steven.Lovaas@ColoState.EDU> wrote:
Arran, I think you're onto a very important point... especially for those of us who benefit from the visual in our learning habits. I personally benefited a lot by drawing out the basics of RADIUS in general and the FreeRADIUS server in particular, so that I could communicate with our network team and get our old servers updated to support the roll-out of eduroam on our campus. Your suggestion of some expansion and graphic help for the overall layout resonates with me... mental models, concept maps, and all that. A picture can help cement the basic landscape, and make more advanced conversations easier to sustain.
I'm in a busy mode and it will take me a while (no promises before summer?), but I'll commit to putting this kind of thing together.
Simple stuff like this is good. That took about two hours. Even I don't know the intricacies of all the flows within the server. The dotted lines represent when the request can loop back into a section. As far I can tell Authorize and Post-Auth are the only places this can happen. It happens when the request starts off in one section and then something happens that requires it to run through a different part of the same section. For authorize that's setting control:Autz-Type to something, and then the request leaving the section. For Post-Auth, it's rejecting the request. Oddly, if you start off in the main Pre-Proxy-Type section, and set control:Pre-Proxy-Type it doesn't loop back round into the Pre-Proxy-Type you set, it just carries on and proxies the request. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
John Dennis wrote:
I think one of the problems with user contributed doc is it ends up being:
"A How-To of how to solve my unique problem exactly the way I did"
Very true.
Many of the thorny problems that trip up users are directly related to their unique deployment requirements.
Yes. TBH, the configuration is documented well enough to show people how to put the pieces together. Heck, after 15 years and 1000's of configuration items... *I* read the documentation to see how it works. I can't be bothered to remember each individual configuration option.
To my mind the fundamental documentation problem is not the lack of specific documentation detailing the details, there is plenty of that. What's missing is an overarching explanation of how all the pieces fit together and/or can be assembled. My general observation is many users have problems because they do not understand how the server works in broad terms and how that behavior can be adjusted to meet certain deployment requirements.
Well... we've tried to document that in the doc/ directory, the Wiki, and the comments in radiusd.conf, and sites-enabled/default. It's not perfect, but it's correct. The various books I've seen are lacking, TBH.
Until folks have a working mental model of what's going on any documentation about pulling a specific lever or turning a certain knob isn't going to help them because they don't understand the "why" behind the recommendation.
Hence my continual "unhelpful" replies of "What PROBLEM are you trying to solve? Don't ask how to configure X, describe the PROBLEM". And the complaints from a subset of users who don't understand that I can't help them until they answer my questions. Alan DeKok.
On Fri, Mar 28, 2014 at 01:17:55PM -0400, John Dennis wrote:
To my mind the fundamental documentation problem is not the lack of specific documentation detailing the details, there is plenty of that. What's missing is an overarching explanation of how all the pieces fit together and/or can be assembled.
I think this is exactlty what I'm struggeling with. I.e. where is the equivalent to postfix' Architecture Overview for freeradius? http://www.postfix.org/OVERVIEW.html I.e., an overview over how a packet flows, and where it can/should be manipulated. That postfix architecture overview has been very helpful, and is often used when debugging/trying to understand where tings are happening in a mail flow. -jf
Jan-Frode Myklebust wrote:
I think this is exactlty what I'm struggeling with. I.e. where is the equivalent to postfix' Architecture Overview for freeradius?
http://www.postfix.org/OVERVIEW.html
I.e., an overview over how a packet flows, and where it can/should be manipulated. That postfix architecture overview has been very helpful, and is often used when debugging/trying to understand where tings are happening in a mail flow.
I'll see if I can put one up on freeradius.org. To be clear: the documentation in the git repository *will* continue to be updated. Any and all documentation patches will be accepted (so long as they're useful). Contributions are always welcome. For anyone who wants to download a 200 page PDF... that is available, too. Alan DeKok.
On Tue, 2014-03-25 at 22:41 -0400, Alan DeKok wrote:
Brendan Kearney wrote:
Why? The "filter" configuration item is the *only* place where the LDAP "uid" search string is set. Editing anything else won't help. the uid vs dn may not be the issue (or at least not the only issue).
Pick one problem at a time and solve it. You said you wanted a search string which was more than "uid=...". I told you how to get that. Try it.
The problem will be fixed, and you can move on to the next problem. Or, you can ask for more help to solve the uid / filter problem.
You WILL NOT do anything useful by randomly switching between 5 separate issues. Only a consistent approach will fix anything. See "man radiusd" for more on this topic.
Read the documentation and configure it as required. i did and its vague.
The configuration items in raddb/modules/ldap are extensively documented. Do you have a SPECIFIC question? If so, why not ask it?
also its contradicted by what is on the freeradius site, which googling around turns up.
i.e. "stuff is wrong". WHAT is wrong? Where?
You're again being as vague as possible. This isn't helpful. your reputation for being *ahem* difficult precedes you, but i think it should be amened to include being a hypocrite, too. how does it feel? you have been nothing but obtuse and dodgy yourself.
You did post the debug output in your first message, which was nice:
Debug: [ldap] performing search in dc=bpk2,dc=com, with filter (uid=brendan)
You: the actual member "value" in the group is the "long" version of the uid (uid=brendan,ou=Users,dc=bpk2,dc=com). is there something i can do to use the "long" version?
Me: Edit the "filter" configuration in raddb/modules/ldap
You: It doesn't work.
Uh... that is a completely useless response. Yes, it does work. Many other people get LDAP filters working. They just edit the configuration item I said.
So... did you *try*? WHAT did you try? Is it a secret? Why didn't you post the debug output to the list?
where do i find the different variables that are referenced (Stripped-User-Name, User-Name, control:Ldap-UserDn, etc)?
Those are RADIUS attributes. Go to wiki.freeradius.org, and type "ldap" into the search box. Hit <enter>. Click on the first link. The LDAP-UserDn attribute is documented there. quoting:
For instance it can be set through the users file in the authorize section: ... well then, the authorize section has been moved out of the users file and into the modules/ldap file, AND IS NOT DOCUMENTED FURTHER. Moreover, my DN in LDAP is fully qualified: uid=brendan,ou=Users,dc=bpk2,dc=com. How you are determining the wrong value and populating a variable with that wrong value is a broken process. if a variable named Ldap-UserDn is going to be used, then the value of the DN in the tree is what i expect to find. what about you? i should not have to cobble together a value that claims to be collected already.
User-Name is a standard RADIUS attribute. Read the specs to see what it is. Really... we are NOT going to document every one of 8000 RADIUS attributes. That's ridiculous. why not? how are folks to know what they are? given the berating they get from the supposed help answering the mailing list, i doubt anyone would every really get answers if they had to find out something in particular. oh, and the attributes... the ones found here: http://freeradius.org/rfc/attributes.html THERE IS NOTHING ABOUT LDAP ANYTHING. disjointed documentation much? in fact it seems that most rlm_* attributes are not there at all. so, whats the deal with that? again, the users file references that, so why isnt it a complete reference?
Stripped-User-Name is ... the User-Name, stripped of a realm. Read the debug output to see what's going on.
where is the documentation around what %{%{Stripped-User-Name}:-%{User-Name}} does
$ man unlang
Which is referenced from the top comments on radiusd.conf.
vs %{%{control:Ldap-UserDn}:-%{control:Ldap-UserDn}} (which does not seem to work anyway)
If you had read the documentation, you'd understand that the above text makes zero sense. and thanks to the effort i have spent pulling your teeth, and rubbing your ego, i now have some place to turn for research. thanks. this could have been accomplished without you being a fuckchop 3 DAYS AGO.
And see the FAQ for "it doesn't work". Really.
yes, and a bunch of stuff is all that can be tried/done when no real, comprehensive howtos exist on how to do this.
Go to wiki.freeradius.org, and type "ldap" into the search box. Hit <enter>. Click on the first link.
http://www.clearfoundation.com/docs/howtos/setting_up_radius_to_use_ldap is the best i have found, and it does not work, is outdated or does not do everything i am looking for.
Yeah... third-party documentation that's 10 years old is preferable to reading the official FreeRADIUS Wiki, or the comments in the configuration files. well, if the info was not contradictory and was written to start at some point, provided clear steps to perform and ended with an accomplished goal, maybe 10 year old docs would not be better than the official wiki, but alas...
The FreeRADIUS documentation isn't perfect. But this is your third message complaining about it... with little to no content.
If all you say is "you guys suck", you won't solve the problem. isnt perfect? the technical writing is utter rubbish. example/correlation:
i took 4 years of spanish in school, and learned nothing but vocabulary and verb conjugation. i cant speak the language to save my life, and thats not for lack of effort. i have read docs, comments, wiki pages, mailing lists, etc and have some points that i know i can get to/through. but, in no way, shape or form can i call myself competent because no fundamental teachings exist on where to start, what to do and how to get to a specific configuration and successful implementation. at best a hodge-podge of hacked together directives are documented, isolated and atomically independent of any larger effort to be undertaken. i have been around the block. i support several technologies for a fortune 25 company. our golden rule is the "grandma" test. can the docs i put together for a process/effort/change be given to my grandmother and the work be done by her? take a starting point, perform deliberate steps (which include breakdowns of the commands with examples or the actual command to be run), achieve the desired result, and include a process to validate what is expected to be in place. my grandma + your docs != work getting done.
If you have *specific* and TECHNICAL questions, we can answer them. All it requires is for you to ask GOOD questions, with CONTENT.
It's up to you. Choose to ask useful questions, and you will get useful answers.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
your reputation for being *ahem* difficult precedes you, but i think it should be amened to include being a hypocrite, too. how does it feel? you have been nothing but obtuse and dodgy yourself.
If you have grievances, please address them with Alan using unicast email, there's no need to do it on a public forum. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Brendan Kearney wrote:
your reputation for being *ahem* difficult precedes you, but i think it should be amened to include being a hypocrite, too. how does it feel? you have been nothing but obtuse and dodgy yourself.
I have given you specific recommendations, and ask for specific information. I said *explicitly* that I can't give good answers to vague questions. Your response was to (a) give more vague questions, and (b) complain some more. I'll make it easy for you. Post a TECHNICAL question, and you'll get a technical answer. If you keep whining about crap, you will be unsubscribed and permanently banned from the list.
well then, the authorize section has been moved out of the users file and into the modules/ldap file, AND IS NOT DOCUMENTED FURTHER.
Well, no. The "authorize" section can't be moved out of the "users" file. If you read raddb/sites-available/default, you'll see that the "authorize" section is... a section. It contains things like the "files" module. The "files" module in turn contains configuration in raddb/modules/file... which points to the "users" file. See? Specific. All of this is documented if you read the configuration files.
Moreover, my DN in LDAP is fully qualified: uid=brendan,ou=Users,dc=bpk2,dc=com. How you are determining the wrong value and populating a variable with that wrong value is a broken process.
You can (a) believe that FreeRADIUS is broken and that tens of thousands of others *cannot* use it with LDAP, or (b) believe that you misconfigured something. Which one is more likely to be true?
User-Name is a standard RADIUS attribute. Read the specs to see what it is. Really... we are NOT going to document every one of 8000 RADIUS attributes. That's ridiculous. why not? how are folks to know what they are?
Read the RFCs. That's why they're included in the FreeRADIUS distribution. i.e. things which are NOT PART OF FREERADIUS are not documented by FreeRADIUS. That's not a complex concept.
given the berating they get from the supposed help answering the mailing list, i doubt anyone would every really get answers if they had to find out something in particular.
Whine, whine, whine. Your focus is complaining, not solving your problem. Stop it, or else.
oh, and the attributes... the ones found here: http://freeradius.org/rfc/attributes.html THERE IS NOTHING ABOUT LDAP ANYTHING.
Because that page documents the attributes defined in the RFCs. LDAP-UserDn isn't defined in an RFC. And you're welcome to submit updates to the documentation. But like all whiners, you don't.
disjointed documentation much? in fact it seems that most rlm_* attributes are not there at all.
Correction: NONE of them are.
so, whats the deal with that? again, the users file references that, so why isnt it a complete reference?
Because it doesn't document all of the 8000 vendor attributes. Doing so would be stupid. Demanding that WE document OTHER vendors attributes is stupid. The attributes defined by FreeRADIUS are documented where they're used. It's not perfect, but most people can figure it out.
If you had read the documentation, you'd understand that the above text makes zero sense. and thanks to the effort i have spent pulling your teeth, and rubbing your ego, i now have some place to turn for research. thanks. this could have been accomplished without you being a fuckchop 3 DAYS AGO.
I can ban you now, you know...
i have read docs, comments, wiki pages, mailing lists, etc and have some points that i know i can get to/through. but, in no way, shape or form can i call myself competent because no fundamental teachings exist on where to start, what to do and how to get to a specific configuration and successful implementation. at best a hodge-podge of hacked together directives are documented, isolated and atomically independent of any larger effort to be undertaken.
Nonsense. Every configuration file, and everything in every configuration file is exhaustively documented. You're complaining that you've bought a car, and it doesn't include directions for getting to grandma's house. That's not a productive attitude.
i have been around the block. i support several technologies for a fortune 25 company.
How very wonderful for you.
our golden rule is the "grandma" test. can the docs i put together for a process/effort/change be given to my grandmother and the work be done by her? take a starting point, perform deliberate steps (which include breakdowns of the commands with examples or the actual command to be run), achieve the desired result, and include a process to validate what is expected to be in place.
Exactly. FreeRADIUS does NOT include documentation for how to get your configuration working on your system. RADIUS is too damned complicated for that to be possible. I'm glad you understand that.
If you have *specific* and TECHNICAL questions, we can answer them. All it requires is for you to ask GOOD questions, with CONTENT.
It's up to you. Choose to ask useful questions, and you will get useful answers.
Exactly... your message is nothing more than whining. You've shown you don't want to solve the problem. You just want to complain about how a product which you got for FREE sucks terribly. You've also made it clear (like every other complainer) that you have no interest in contributing anything to make it better. I'll make it easy for you. Post a TECHNICAL question, and you'll get a technical answer. If you keep whining about crap, you will be unsubscribed and permanently banned from the list. Alan DeKok.
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Brendan Kearney -
Jan-Frode Myklebust -
John Dennis -
Lovaas,Steven -
stefan.paetow＠diamond.ac.uk