FR 3.0.1 and LDAP group membership
i want to authenticate users against my kerberos instance (working now), and authorize them based on LDAP group memebership. i am stuck getting authorization working, because i must be missing something fundamental. i copied mods-available/ldap to mods-available/ldap.orig and made the following edits: changed "server" to test.bpk2.com changed "identity" and "password" to cn=Manger,dc=my-domain,dc=com, and the corresponding password. changed "base_dn" to ou=Users,dc=bpk2,dc=com commented out control:Password-With-Header += 'userPassword' as LDAP will not be managing any passwords changed filter from objectClass=posixGroup to groupOfNames changed membership_filter to be member= and not memberUid= in the second OR'd condition uncommented filter="(objectclass=radiusprofile)" i have created a group in the DIT called netEngineers, added my ID to the group, added the radiusprofile object class and added a radiusreplyitem of "Cisco-AVPair = "shell:priv-lvl=15"" to the group. i have added the radiusprofile object class to my id and added the radiusgroupname attribute, and the value "netEngineers" to the attribute. when i run radiusd -X and then radtest, i run a packet capture. the capture does not show the radiusreplyitem being replied back. it seems that i am not properly configuring the group checking, but dont know where i am going wrong. where am i going wrong? begin radiusd -X output: ------------------------ radiusd: FreeRADIUS Version 3.0.1, for host x86_64-redhat-linux-gnu, built on Feb 26 2014 at 18:49:06 Copyright (C) 1999-2014 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 For more information about these matters, see the file named COPYRIGHT Starting - reading configuration files ... including dictionary file /etc/raddb/dictionary 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/mods-enabled/ including configuration file /etc/raddb/mods-enabled/dynamic_clients including configuration file /etc/raddb/mods-enabled/attr_filter including configuration file /etc/raddb/mods-enabled/realm including configuration file /etc/raddb/mods-enabled/utf8 including configuration file /etc/raddb/mods-enabled/dhcp including configuration file /etc/raddb/mods-enabled/expr including configuration file /etc/raddb/mods-enabled/linelog including configuration file /etc/raddb/mods-enabled/files including configuration file /etc/raddb/mods-enabled/ntlm_auth including configuration file /etc/raddb/mods-enabled/chap including configuration file /etc/raddb/mods-enabled/detail.log including configuration file /etc/raddb/mods-enabled/detail including configuration file /etc/raddb/mods-enabled/exec including configuration file /etc/raddb/mods-enabled/always including configuration file /etc/raddb/mods-enabled/ldap including configuration file /etc/raddb/mods-enabled/sradutmp including configuration file /etc/raddb/mods-enabled/replicate including configuration file /etc/raddb/mods-enabled/krb5 including configuration file /etc/raddb/mods-enabled/echo including configuration file /etc/raddb/mods-enabled/logintime including configuration file /etc/raddb/mods-enabled/digest including configuration file /etc/raddb/mods-enabled/radutmp including configuration file /etc/raddb/mods-enabled/expiration including configuration file /etc/raddb/mods-enabled/eap including configuration file /etc/raddb/mods-enabled/preprocess including configuration file /etc/raddb/mods-enabled/soh including configuration file /etc/raddb/mods-enabled/unix including configuration file /etc/raddb/mods-enabled/mschap including configuration file /etc/raddb/mods-enabled/passwd including configuration file /etc/raddb/mods-enabled/cache_eap including configuration file /etc/raddb/mods-enabled/pap including files in directory /etc/raddb/policy.d/ including configuration file /etc/raddb/policy.d/dhcp including configuration file /etc/raddb/policy.d/control including configuration file /etc/raddb/policy.d/operator-name including configuration file /etc/raddb/policy.d/filter including configuration file /etc/raddb/policy.d/cui including configuration file /etc/raddb/policy.d/canonicalization including configuration file /etc/raddb/policy.d/accounting including configuration file /etc/raddb/policy.d/eap including files in directory /etc/raddb/sites-enabled/ including configuration file /etc/raddb/sites-enabled/inner-tunnel including configuration file /etc/raddb/sites-enabled/default including configuration file /etc/raddb/sites-enabled/control-socket main { security { user = "radiusd" group = "radiusd" allow_core_dumps = no } } 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 = no log { stripped_names = no auth = no auth_badpass = no auth_goodpass = no colourise = yes } 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 zombie_period = 40 status_check = "status-server" ping_interval = 30 check_interval = 30 num_answers_to_alive = 3 revive_interval = 120 status_check_timeout = 4 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } limit { max_connections = 16 max_requests = 0 lifetime = 0 idle_timeout = 0 } } 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 = "***REMOVED***" nas_type = "other" proto = "*" limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } client 192.168.254.253 { require_message_authenticator = no secret = "***REMOVED***" shortname = "switch" nas_type = "cisco" limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } radiusd: #### Instantiating modules #### instantiate { } modules { # Loaded module rlm_dynamic_clients # Instantiating module "dynamic_clients" from file /etc/raddb/mods-enabled/dynamic_clients # Loaded module rlm_attr_filter # Instantiating module "attr_filter.post-proxy" from file /etc/raddb/mods-enabled/attr_filter attr_filter attr_filter.post-proxy { filename = "/etc/raddb/mods-config/attr_filter/post-proxy" key = "%{Realm}" relaxed = no } reading pairlist file /etc/raddb/mods-config/attr_filter/post-proxy # Instantiating module "attr_filter.pre-proxy" from file /etc/raddb/mods-enabled/attr_filter attr_filter attr_filter.pre-proxy { filename = "/etc/raddb/mods-config/attr_filter/pre-proxy" key = "%{Realm}" relaxed = no } reading pairlist file /etc/raddb/mods-config/attr_filter/pre-proxy # Instantiating module "attr_filter.access_reject" from file /etc/raddb/mods-enabled/attr_filter attr_filter attr_filter.access_reject { filename = "/etc/raddb/mods-config/attr_filter/access_reject" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/mods-config/attr_filter/access_reject # Instantiating module "attr_filter.access_challenge" from file /etc/raddb/mods-enabled/attr_filter attr_filter attr_filter.access_challenge { filename = "/etc/raddb/mods-config/attr_filter/access_challenge" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/mods-config/attr_filter/access_challenge # Instantiating module "attr_filter.accounting_response" from file /etc/raddb/mods-enabled/attr_filter attr_filter attr_filter.accounting_response { filename = "/etc/raddb/mods-config/attr_filter/accounting_response" key = "%{User-Name}" relaxed = no } reading pairlist file /etc/raddb/mods-config/attr_filter/accounting_response # Loaded module rlm_realm # Instantiating module "IPASS" from file /etc/raddb/mods-enabled/realm realm IPASS { format = "prefix" delimiter = "/" ignore_default = no ignore_null = no } # Instantiating module "suffix" from file /etc/raddb/mods-enabled/realm realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } # Instantiating module "realmpercent" from file /etc/raddb/mods-enabled/realm realm realmpercent { format = "suffix" delimiter = "%" ignore_default = no ignore_null = no } # Instantiating module "ntdomain" from file /etc/raddb/mods-enabled/realm realm ntdomain { format = "prefix" delimiter = "\" ignore_default = no ignore_null = no } # Loaded module rlm_utf8 # Instantiating module "utf8" from file /etc/raddb/mods-enabled/utf8 # Loaded module rlm_dhcp # Instantiating module "dhcp" from file /etc/raddb/mods-enabled/dhcp # Loaded module rlm_expr # Instantiating module "expr" from file /etc/raddb/mods-enabled/expr expr { safe_characters = "@abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-_: /" } # Loaded module rlm_linelog # Instantiating module "linelog" from file /etc/raddb/mods-enabled/linelog linelog { filename = "/var/log/radius/linelog" permissions = 384 format = "This is a log message for %{User-Name}" reference = "%{%{Packet-Type}:-format}" } # Loaded module rlm_files # Instantiating module "files" from file /etc/raddb/mods-enabled/files files { filename = "/etc/raddb/mods-config/files/authorize" usersfile = "/etc/raddb/mods-config/files/authorize" acctusersfile = "/etc/raddb/mods-config/files/accounting" preproxy_usersfile = "/etc/raddb/mods-config/files/pre-proxy" compat = "no" } reading pairlist file /etc/raddb/mods-config/files/authorize reading pairlist file /etc/raddb/mods-config/files/authorize reading pairlist file /etc/raddb/mods-config/files/accounting reading pairlist file /etc/raddb/mods-config/files/pre-proxy # Loaded module rlm_exec # Instantiating module "ntlm_auth" from file /etc/raddb/mods-enabled/ntlm_auth exec ntlm_auth { wait = yes program = "/path/to/ntlm_auth --request-nt-key --domain=MYDOMAIN --username=%{mschap:User-Name} --password=%{User-Password}" shell_escape = yes } # Loaded module rlm_chap # Instantiating module "chap" from file /etc/raddb/mods-enabled/chap # Loaded module rlm_detail # Instantiating module "auth_log" from file /etc/raddb/mods-enabled/detail.log detail auth_log { filename = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d" header = "%t" permissions = 384 dir_permissions = 493 locking = no log_packet_header = no } rlm_detail (auth_log): 'User-Password' suppressed, will not appear in detail output # Instantiating module "reply_log" from file /etc/raddb/mods-enabled/detail.log detail reply_log { filename = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d" header = "%t" permissions = 384 dir_permissions = 493 locking = no log_packet_header = no } # Instantiating module "pre_proxy_log" from file /etc/raddb/mods-enabled/detail.log detail pre_proxy_log { filename = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/pre-proxy-detail-%Y%m%d" header = "%t" permissions = 384 dir_permissions = 493 locking = no log_packet_header = no } # Instantiating module "post_proxy_log" from file /etc/raddb/mods-enabled/detail.log detail post_proxy_log { filename = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/post-proxy-detail-%Y%m%d" header = "%t" permissions = 384 dir_permissions = 493 locking = no log_packet_header = no } # Instantiating module "detail" from file /etc/raddb/mods-enabled/detail detail { filename = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d" header = "%t" permissions = 384 dir_permissions = 493 locking = no log_packet_header = no } # Instantiating module "exec" from file /etc/raddb/mods-enabled/exec exec { wait = no input_pairs = "request" shell_escape = yes timeout = 10 } # Loaded module rlm_always # Instantiating module "fail" from file /etc/raddb/mods-enabled/always always fail { rcode = "fail" simulcount = 0 mpp = no } # Instantiating module "reject" from file /etc/raddb/mods-enabled/always always reject { rcode = "reject" simulcount = 0 mpp = no } # Instantiating module "noop" from file /etc/raddb/mods-enabled/always always noop { rcode = "noop" simulcount = 0 mpp = no } # Instantiating module "handled" from file /etc/raddb/mods-enabled/always always handled { rcode = "handled" simulcount = 0 mpp = no } # Instantiating module "updated" from file /etc/raddb/mods-enabled/always always updated { rcode = "updated" simulcount = 0 mpp = no } # Instantiating module "notfound" from file /etc/raddb/mods-enabled/always always notfound { rcode = "notfound" simulcount = 0 mpp = no } # Instantiating module "ok" from file /etc/raddb/mods-enabled/always always ok { rcode = "ok" simulcount = 0 mpp = no } # Loaded module rlm_ldap # Instantiating module "ldap" from file /etc/raddb/mods-enabled/ldap ldap { server = "test.bpk2.com" port = 389 password = "***REMOVED***" identity = "cn=Manager,dc=my-domain,dc=com" user { filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" scope = "sub" base_dn = "ou=Users,dc=bpk2,dc=com" access_positive = yes } group { filter = "(objectClass=groupOfNames)" scope = "sub" base_dn = "ou=Users,dc=bpk2,dc=com" name_attribute = "cn" membership_attribute = "memberOf" membership_filter = "(|(member=%{control:Ldap-UserDn})(member= %{%{Stripped-User-Name}:-%{User-Name}}))" cacheable_name = no cacheable_dn = no } client { filter = "(objectClass=frClient)" scope = "sub" base_dn = "ou=Users,dc=bpk2,dc=com" attribute { identifier = "radiusClientIdentifier" shortname = "cn" secret = "radiusClientSecret" } } profile { filter = "(objectclass=radiusprofile)" } options { ldap_debug = 40 chase_referrals = yes rebind = yes net_timeout = 1 res_timeout = 20 srv_timelimit = 20 idle = 60 probes = 3 interval = 3 } tls { start_tls = no } } accounting { reference = "%{tolower:type.%{Acct-Status-Type}}" } post-auth { reference = "." } rlm_ldap (ldap): Initialising connection pool pool { start = 5 min = 4 max = 10 spare = 3 uses = 0 lifetime = 0 cleanup_delay = 5 idle_timeout = 60 spread = no } rlm_ldap (ldap): Opening additional connection (0) rlm_ldap (ldap): Connecting to test.bpk2.com:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (1) rlm_ldap (ldap): Connecting to test.bpk2.com:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (2) rlm_ldap (ldap): Connecting to test.bpk2.com:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (3) rlm_ldap (ldap): Connecting to test.bpk2.com:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (4) rlm_ldap (ldap): Connecting to test.bpk2.com:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful # Loaded module rlm_radutmp # Instantiating module "sradutmp" from file /etc/raddb/mods-enabled/sradutmp radutmp sradutmp { filename = "/var/log/radius/sradutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes permissions = 420 caller_id = no } # Loaded module rlm_replicate # Instantiating module "replicate" from file /etc/raddb/mods-enabled/replicate # Loaded module rlm_krb5 # Instantiating module "krb5" from file /etc/raddb/mods-enabled/krb5 krb5 { keytab = "/etc/raddb/radius.keytab" service_principal = "radius/test.bpk2.com" } Using MIT Kerberos library rlm_krb5 (krb5): Using service principal "radius/test.bpk2.com@BPK2.COM" rlm_krb5 (krb5): Using keytab "FILE:/etc/raddb/radius.keytab" rlm_krb5 (krb5): Initialising connection pool pool { start = 10 min = 4 max = 10 spare = 3 uses = 0 lifetime = 0 cleanup_delay = 5 idle_timeout = 60 spread = no } rlm_krb5 (krb5): Opening additional connection (0) rlm_krb5 (krb5): Opening additional connection (1) rlm_krb5 (krb5): Opening additional connection (2) rlm_krb5 (krb5): Opening additional connection (3) rlm_krb5 (krb5): Opening additional connection (4) rlm_krb5 (krb5): Opening additional connection (5) rlm_krb5 (krb5): Opening additional connection (6) rlm_krb5 (krb5): Opening additional connection (7) rlm_krb5 (krb5): Opening additional connection (8) rlm_krb5 (krb5): Opening additional connection (9) # Instantiating module "echo" from file /etc/raddb/mods-enabled/echo exec echo { wait = yes program = "/bin/echo %{User-Name}" input_pairs = "request" output_pairs = "reply" shell_escape = yes } # Loaded module rlm_logintime # Instantiating module "logintime" from file /etc/raddb/mods-enabled/logintime logintime { minimum_timeout = 60 } # Loaded module rlm_digest # Instantiating module "digest" from file /etc/raddb/mods-enabled/digest # Instantiating module "radutmp" from file /etc/raddb/mods-enabled/radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes permissions = 384 caller_id = yes } # Loaded module rlm_expiration # Instantiating module "expiration" from file /etc/raddb/mods-enabled/expiration # Loaded module rlm_eap # Instantiating module "eap" from file /etc/raddb/mods-enabled/eap eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no mod_accounting_username_bug = no max_sessions = 4096 } # Linked to sub-module rlm_eap_md5 # Linked to sub-module rlm_eap_leap # Linked to sub-module rlm_eap_gtc gtc { challenge = "Password: " auth_type = "PAP" } # Linked to sub-module rlm_eap_tls tls { tls = "tls-common" } tls-config tls-common { 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" fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" ecdh_curve = "prime256v1" cache { enable = yes 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 = yes } } # Linked to sub-module rlm_eap_ttls ttls { tls = "tls-common" default_eap_type = "md5" copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" include_length = yes require_client_cert = no } Using cached TLS configuration from previous invocation # Linked to sub-module rlm_eap_peap peap { tls = "tls-common" default_method = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no require_client_cert = no } Using cached TLS configuration from previous invocation # Linked to sub-module rlm_eap_mschapv2 mschapv2 { with_ntdomain_hack = no send_error = no } # Loaded module rlm_preprocess # Instantiating module "preprocess" from file /etc/raddb/mods-enabled/preprocess preprocess { huntgroups = "/etc/raddb/mods-config/preprocess/huntgroups" hints = "/etc/raddb/mods-config/preprocess/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/mods-config/preprocess/huntgroups reading pairlist file /etc/raddb/mods-config/preprocess/hints # Loaded module rlm_soh # Instantiating module "soh" from file /etc/raddb/mods-enabled/soh soh { dhcp = yes } # Loaded module rlm_unix # Instantiating module "unix" from file /etc/raddb/mods-enabled/unix unix { radwtmp = "/var/log/radius/radwtmp" } # Loaded module rlm_mschap # Instantiating module "mschap" from file /etc/raddb/mods-enabled/mschap mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = yes passchange { } allow_retry = yes } # Loaded module rlm_passwd # Instantiating module "etc_passwd" from file /etc/raddb/mods-enabled/passwd passwd etc_passwd { filename = "/etc/passwd" format = "*User-Name:Crypt-Password:" delimiter = ":" ignore_nislike = no ignore_empty = yes allow_multiple_keys = no hash_size = 100 } rlm_passwd: nfields: 3 keyfield 0(User-Name) listable: no # Loaded module rlm_cache # Instantiating module "cache_eap" from file /etc/raddb/mods-enabled/cache_eap cache cache_eap { key = "%{%{control:State}:-%{%{reply:State}:-%{State}}}" ttl = 15 max_entries = 16384 epoch = 0 add_stats = no } # Loaded module rlm_pap # Instantiating module "pap" from file /etc/raddb/mods-enabled/pap pap { auto_header = no normalise = yes } } # modules radiusd: #### Loading Virtual Servers #### server { # from file /etc/raddb/radiusd.conf } # server server inner-tunnel { # from file /etc/raddb/sites-enabled/inner-tunnel # Loading authenticate {...} # Loading authorize {...} WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) # Loading session {...} # Loading post-proxy {...} # Loading post-auth {...} WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) } # server inner-tunnel server default { # from file /etc/raddb/sites-enabled/default # Creating Auth-Type = digest # Loading authenticate {...} # Loading authorize {...} # Loading virtual module filter_username WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) # Loading preacct {...} # Loading virtual module acct_unique # Loading accounting {...} WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) # Loading post-proxy {...} # Loading post-auth {...} WARNING: Ignoring "sql" (see raddb/mods-available/README.rst) # Loading virtual module remove_reply_message_if_eap # Loading virtual module remove_reply_message_if_eap } # server default radiusd: #### Opening IP addresses and Ports #### listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" mode = "rw" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } listen { type = "auth" ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { type = "acct" ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } Listening on command file /var/run/radiusd/radiusd.sock Listening on auth address 127.0.0.1 port 18120 as server inner-tunnel Listening on auth address * port 1812 as server default Listening on acct address * port 1813 as server default Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 44213, id=37, length=83 User-Name = 'brendan' User-Password = '***REMOVED***' NAS-IP-Address = 192.168.1.152 NAS-Port = 1812 Message-Authenticator = 0x247686804d37e8f526c0e7debd779628 Framed-Protocol = PPP (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) filter_username filter_username { (0) ? if (User-Name != "%{tolower:%{User-Name}}") (0) expand: "%{tolower:%{User-Name}}" -> 'brendan' (0) ? if (User-Name != "%{tolower:%{User-Name}}") -> FALSE (0) ? if (User-Name =~ / /) (0) ? if (User-Name =~ / /) -> FALSE (0) ? if (User-Name =~ /@.*@/ ) (0) ? if (User-Name =~ /@.*@/ ) -> FALSE (0) ? if (User-Name =~ /\\.\\./ ) (0) ? if (User-Name =~ /\\.\\./ ) -> FALSE (0) ? if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) (0) ? if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE (0) ? if (User-Name =~ /\\.$/) (0) ? if (User-Name =~ /\\.$/) -> FALSE (0) ? if (User-Name =~ /@\\./) (0) ? if (User-Name =~ /@\\./) -> FALSE (0) } # filter_username filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix : No '@' in User-Name = "brendan", looking up realm NULL (0) suffix : No such realm "NULL" (0) [suffix] = noop (0) eap : No EAP-Message, not doing EAP (0) [eap] = noop (0) files : users: Matched entry DEFAULT at line 1 (0) [files] = ok rlm_ldap (ldap): Reserved connection (4) (0) ldap : expand: "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" -> '(uid=brendan)' (0) ldap : expand: "ou=Users,dc=bpk2,dc=com" -> 'ou=Users,dc=bpk2,dc=com' (0) ldap : Performing search in 'ou=Users,dc=bpk2,dc=com' with filter '(uid=brendan)' (0) ldap : Waiting for search result... (0) ldap : User object found at DN "uid=brendan,ou=Domain Users,ou=Users,dc=bpk2,dc=com" rlm_ldap (ldap): Released connection (4) rlm_ldap (ldap): Closing connection (0): Too many free connections (5 > 3) (0) [-ldap] = ok (0) [expiration] = noop (0) [logintime] = noop (0) WARNING: pap : No "known good" password found for the user. Not setting Auth-Type. (0) WARNING: pap : Authentication will fail unless a "known good" password is available. (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = Kerberos (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Auth-Type Kerberos { rlm_krb5 (krb5): Reserved connection (9) (0) krb5 : Using client principal "brendan@BPK2.COM" (0) krb5 : Successfully retrieved and decrypted TGT rlm_krb5 (krb5): Released connection (9) rlm_krb5 (krb5): Closing connection (0): Too many free connections (10 > 3) (0) [krb5] = ok (0) } # Auth-Type Kerberos = ok (0) # Executing section post-auth from file /etc/raddb/sites-enabled/default (0) post-auth { (0) [exec] = noop (0) remove_reply_message_if_eap remove_reply_message_if_eap { (0) ? if (reply:EAP-Message && reply:Reply-Message) (0) ? if (reply:EAP-Message && reply:Reply-Message) -> FALSE (0) else else { (0) [noop] = noop (0) } # else else = noop (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (0) } # post-auth = noop Sending Access-Accept of id 37 from 127.0.0.1 port 1812 to 127.0.0.1 port 44213 (0) Finished request 0. Waking up in 0.2 seconds. Waking up in 4.7 seconds. (0) Cleaning up request packet ID 37 with timestamp +10 Ready to process requests.
On 20 May 2014, at 02:03, Brendan Kearney <bpk678@gmail.com> wrote:
i want to authenticate users against my kerberos instance (working now), and authorize them based on LDAP group memebership. i am stuck getting authorization working, because i must be missing something fundamental.
i copied mods-available/ldap to mods-available/ldap.orig and made the following edits:
changed "server" to test.bpk2.com changed "identity" and "password" to cn=Manger,dc=my-domain,dc=com, and the corresponding password. changed "base_dn" to ou=Users,dc=bpk2,dc=com commented out control:Password-With-Header += 'userPassword' as LDAP will not be managing any passwords changed filter from objectClass=posixGroup to groupOfNames changed membership_filter to be member= and not memberUid= in the second OR'd condition uncommented filter="(objectclass=radiusprofile)"
i have created a group in the DIT called netEngineers, added my ID to the group, added the radiusprofile object class and added a radiusreplyitem of "Cisco-AVPair = "shell:priv-lvl=15"" to the group.
Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves. Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object.
i have added the radiusprofile object class to my id and added the radiusgroupname attribute, and the value "netEngineers" to the attribute.
You still have 'attribute' commented out in the profile section. How will it know which attribute contains profiles?
when i run radiusd -X and then radtest, i run a packet capture. the capture does not show the radiusreplyitem being replied back. it seems that i am not properly configuring the group checking, but dont know where i am going wrong. where am i going wrong?
You're meant to check for individual groups. They're not meant to be container objects for attributes. Your policy should contain something like if (LDAP-Group == 'foo') { bar } If you want to check for specific group memberships, but I don't think that's what you're trying to do. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Tue, 2014-05-20 at 06:39 +0100, Arran Cudbard-Bell wrote:
On 20 May 2014, at 02:03, Brendan Kearney <bpk678@gmail.com> wrote:
i want to authenticate users against my kerberos instance (working now), and authorize them based on LDAP group memebership. i am stuck getting authorization working, because i must be missing something fundamental.
i copied mods-available/ldap to mods-available/ldap.orig and made the following edits:
changed "server" to test.bpk2.com changed "identity" and "password" to cn=Manger,dc=my-domain,dc=com, and the corresponding password. changed "base_dn" to ou=Users,dc=bpk2,dc=com commented out control:Password-With-Header += 'userPassword' as LDAP will not be managing any passwords changed filter from objectClass=posixGroup to groupOfNames changed membership_filter to be member= and not memberUid= in the second OR'd condition uncommented filter="(objectclass=radiusprofile)"
i have created a group in the DIT called netEngineers, added my ID to the group, added the radiusprofile object class and added a radiusreplyitem of "Cisco-AVPair = "shell:priv-lvl=15"" to the group.
Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves.
Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object.
i have added the radiusprofile object class to my id and added the radiusgroupname attribute, and the value "netEngineers" to the attribute.
You still have 'attribute' commented out in the profile section. How will it know which attribute contains profiles?
when i run radiusd -X and then radtest, i run a packet capture. the capture does not show the radiusreplyitem being replied back. it seems that i am not properly configuring the group checking, but dont know where i am going wrong. where am i going wrong?
You're meant to check for individual groups. They're not meant to be container objects for attributes.
Your policy should contain something like
if (LDAP-Group == 'foo') { bar }
If you want to check for specific group memberships, but I don't think that's what you're trying to do.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
backing up a bit... users, groups and profiles. i want to have a group that i add users to, and when users are added to that group, they inherit radius attributes which allow them access to a resource. the means would be the value of a radiusreplyitem. i have created a user, uid=brendan,ou=Domain Users,ou=Users,dc=bpk2,dc=com i have created a group, cn=netEngineers,ou=Domain Groups,ou=Groups,dc=bpk2,dc=com i have created a profile, cn=netReadWrite,cn=radius,ou=Daemons,dc=bpk2,dc=com the profile has a radiusreplyitem with a value of Cisco-AVPair = "shell:priv-lvl=15" how do i go about tying group membership to the profile (or vice versa, if that is what i am supposed to do)? i have uncommented the attribute line in the profile section, and changed its value to memberOf. i see in a capture that the groups i am a member of are queried for the radiusprofile objectclass. the netEngineers group has that objectclass and a radiusprofiledn attribute pointing to the profile that has the radiusreplyitem. i do not see the query for the profile or the radiusreplyitem string in the radiusd -X output or in the radtest output. what are the appropriate ways of tying this all together? thanks, brendan
backing up a bit...
users, groups and profiles.
i want to have a group that i add users to, and when users are added to that group, they inherit radius attributes which allow them access to a resource. the means would be the value of a radiusreplyitem.
i have created a user, uid=brendan,ou=Domain Users,ou=Users,dc=bpk2,dc=com i have created a group, cn=netEngineers,ou=Domain Groups,ou=Groups,dc=bpk2,dc=com i have created a profile, cn=netReadWrite,cn=radius,ou=Daemons,dc=bpk2,dc=com the profile has a radiusreplyitem with a value of Cisco-AVPair = "shell:priv-lvl=15"
how do i go about tying group membership to the profile (or vice versa, if that is what i am supposed to do)?
i have uncommented the attribute line in the profile section, and changed its value to memberOf. i see in a capture that the groups i am a member of are queried for the radiusprofile objectclass. the netEngineers group has that objectclass and a radiusprofiledn attribute pointing to the profile that has the radiusreplyitem. i do not see the query for the profile or the radiusreplyitem string in the radiusd -X output or in the radtest output. what are the appropriate ways of tying this all together?
Without code patches you'd need to add radiusreplyItem attributes directly to the groups objects. The group objects and the profile objects would be one and the same. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Tue, 2014-05-27 at 20:37 +0100, Arran Cudbard-Bell wrote:
Without code patches you'd need to add radiusreplyItem attributes directly to the groups objects. The group objects and the profile objects would be one and the same.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
what you say contradicts what you have stated previously: Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves. Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object. am i to understand that 3.0.3 changes things or have i again missed something important? originally, i had the group configured with the objectclass and the radiusreplyitem attribute, and that did not provide the authorization string in the reply. without undoing the radiusprofiledn and the radiusprofile existing elsewhere in the directory, i added back the radiusreplyitem to the group and tested with radtest. i do not see the string in the reply from radiusd. as soon as i see the 3.0.3 update in the fedora repos, i will be updating to it. maybe that will clear up some of these loose ends.
On 27 May 2014, at 21:18, Brendan Kearney <bpk678@gmail.com> wrote:
On Tue, 2014-05-27 at 20:37 +0100, Arran Cudbard-Bell wrote:
Without code patches you'd need to add radiusreplyItem attributes directly to the groups objects. The group objects and the profile objects would be one and the same.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
what you say contradicts what you have stated previously:
No, it doesn't.
Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves.
An object in LDAP can belong to multiple objectClasses. Without an objectClass an object is is just an object, it's not a group it's not a profile. No an object which is just a member of the posixGroup class can't contain replyItems, or checkItems or any other RADIUS attributes. Yes an object which is a member of the radiusprofile class can contain replyItems, and checkItems and generic radius attributes. Being a member of posixGroup does not mean that the object cannot also be a member of radiusprofile. As I said, to do what you want to do, you actually want the group object to also be a radiusprofile object. Here's the order of operations, hopefully it'll clear things up: 1. enter mod_authorize 2. search in user.base_dn with scope user.scope with filter user.filter Requesting attributes: user.access_attribute (if set) profile.attribute all attributes on the right hand side of the update section Assuming user is found 3. store dn 4. check access_attribute value 5. apply update section mappings 6. foreach of the profile.attribute values Search in profile.attibute.value with filter profile.filter Requesting attributes: all attributes on the right hand side of the update section if object found apply update section mappings 7. return from mod_authorize I'm telling you to set profile.attribute to be 'memberOf' so that the profile code will iterate over all the group objects (which may also happen to be radiusprofile objects), performing attribute mappings. Note: Your memberOf attribute values must be DNs instead of group CN (or whichever attribute you use as group.name_attribute). If you want to iterate over a subset of the group objects (which also happen to be radiusprofile objects), then set an appropriate filter for profile.filter. Hint: Profile filter can contain XLAT expansions %{}.
Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object.
am i to understand that 3.0.3 changes things or have i again missed something important?
Not dramatically since 3.0.0, i've tried my best to forget how the v2.x.x module worked. It's a traumatic experience looking over that code, I don't want to relive it again and again. Read: The v2.0.x code is a rats nest, I have no idea how, why or if it works correctly. In theory the same thing should work just fine for v2.0.x, but I don't know, and if it doesn't, you're on your own. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Tue, 2014-05-27 at 22:04 +0100, Arran Cudbard-Bell wrote:
On 27 May 2014, at 21:18, Brendan Kearney <bpk678@gmail.com> wrote:
On Tue, 2014-05-27 at 20:37 +0100, Arran Cudbard-Bell wrote:
Without code patches you'd need to add radiusreplyItem attributes directly to the groups objects. The group objects and the profile objects would be one and the same.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
what you say contradicts what you have stated previously:
No, it doesn't.
Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves.
An object in LDAP can belong to multiple objectClasses.
Without an objectClass an object is is just an object, it's not a group it's not a profile.
No an object which is just a member of the posixGroup class can't contain replyItems, or checkItems or any other RADIUS attributes.
Yes an object which is a member of the radiusprofile class can contain replyItems, and checkItems and generic radius attributes.
Being a member of posixGroup does not mean that the object cannot also be a member of radiusprofile.
As I said, to do what you want to do, you actually want the group object to also be a radiusprofile object.
Here's the order of operations, hopefully it'll clear things up:
1. enter mod_authorize 2. search in user.base_dn with scope user.scope with filter user.filter Requesting attributes: user.access_attribute (if set) profile.attribute all attributes on the right hand side of the update section Assuming user is found 3. store dn 4. check access_attribute value 5. apply update section mappings 6. foreach of the profile.attribute values Search in profile.attibute.value with filter profile.filter Requesting attributes: all attributes on the right hand side of the update section if object found apply update section mappings 7. return from mod_authorize
I'm telling you to set profile.attribute to be 'memberOf' so that the profile code will iterate over all the group objects (which may also happen to be radiusprofile objects), performing attribute mappings.
Note: Your memberOf attribute values must be DNs instead of group CN (or whichever attribute you use as group.name_attribute).
If you want to iterate over a subset of the group objects (which also happen to be radiusprofile objects), then set an appropriate filter for profile.filter.
Hint: Profile filter can contain XLAT expansions %{}.
Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object.
am i to understand that 3.0.3 changes things or have i again missed something important?
Not dramatically since 3.0.0, i've tried my best to forget how the v2.x.x module worked. It's a traumatic experience looking over that code, I don't want to relive it again and again.
Read: The v2.0.x code is a rats nest, I have no idea how, why or if it works correctly.
In theory the same thing should work just fine for v2.0.x, but I don't know, and if it doesn't, you're on your own.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ok. i took what you said too literally. i thought that groups and profiles had to be separate. with the group created and the additional objectclass of radiusprofile added to the group, i now have the group created in the way you said. i started a packet capture, then started radiusd -X and tried to sign into my switch. the switch requested a specific VSA, radius looked up my group memberships, found all of them, including the one with the radiusreplyitem, and replies with an Access-Accept. what is missing is the radiusreplyitem value/string in the Access-Accept message. the group i am member of has the attribute, and the value is correct, but radius is not replying with it. where am supposed to tell radius to reply with the replyitem?
On 30 May 2014, at 02:39, Brendan Kearney <bpk678@gmail.com> wrote:
On Tue, 2014-05-27 at 22:04 +0100, Arran Cudbard-Bell wrote:
On 27 May 2014, at 21:18, Brendan Kearney <bpk678@gmail.com> wrote:
On Tue, 2014-05-27 at 20:37 +0100, Arran Cudbard-Bell wrote:
Without code patches you'd need to add radiusreplyItem attributes directly to the groups objects. The group objects and the profile objects would be one and the same.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
what you say contradicts what you have stated previously:
No, it doesn't.
Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves.
An object in LDAP can belong to multiple objectClasses.
Without an objectClass an object is is just an object, it's not a group it's not a profile.
No an object which is just a member of the posixGroup class can't contain replyItems, or checkItems or any other RADIUS attributes.
Yes an object which is a member of the radiusprofile class can contain replyItems, and checkItems and generic radius attributes.
Being a member of posixGroup does not mean that the object cannot also be a member of radiusprofile.
As I said, to do what you want to do, you actually want the group object to also be a radiusprofile object.
Here's the order of operations, hopefully it'll clear things up:
1. enter mod_authorize 2. search in user.base_dn with scope user.scope with filter user.filter Requesting attributes: user.access_attribute (if set) profile.attribute all attributes on the right hand side of the update section Assuming user is found 3. store dn 4. check access_attribute value 5. apply update section mappings 6. foreach of the profile.attribute values Search in profile.attibute.value with filter profile.filter Requesting attributes: all attributes on the right hand side of the update section if object found apply update section mappings 7. return from mod_authorize
I'm telling you to set profile.attribute to be 'memberOf' so that the profile code will iterate over all the group objects (which may also happen to be radiusprofile objects), performing attribute mappings.
Note: Your memberOf attribute values must be DNs instead of group CN (or whichever attribute you use as group.name_attribute).
If you want to iterate over a subset of the group objects (which also happen to be radiusprofile objects), then set an appropriate filter for profile.filter.
Hint: Profile filter can contain XLAT expansions %{}.
Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object.
am i to understand that 3.0.3 changes things or have i again missed something important?
Not dramatically since 3.0.0, i've tried my best to forget how the v2.x.x module worked. It's a traumatic experience looking over that code, I don't want to relive it again and again.
Read: The v2.0.x code is a rats nest, I have no idea how, why or if it works correctly.
In theory the same thing should work just fine for v2.0.x, but I don't know, and if it doesn't, you're on your own.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ok. i took what you said too literally. i thought that groups and profiles had to be separate. with the group created and the additional objectclass of radiusprofile added to the group, i now have the group created in the way you said.
i started a packet capture, then started radiusd -X and tried to sign into my switch. the switch requested a specific VSA, radius looked up my group memberships, found all of them, including the one with the radiusreplyitem, and replies with an Access-Accept. what is missing is the radiusreplyitem value/string in the Access-Accept message. the group i am member of has the attribute, and the value is correct, but radius is not replying with it. where am supposed to tell radius to reply with the replyitem?
The update block in the LDAP module config. update { reply: += 'replyItem' } There's already an example line, you just need to uncomment it. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, 2014-05-30 at 08:45 +0100, Arran Cudbard-Bell wrote:
On 30 May 2014, at 02:39, Brendan Kearney <bpk678@gmail.com> wrote:
On Tue, 2014-05-27 at 22:04 +0100, Arran Cudbard-Bell wrote:
On 27 May 2014, at 21:18, Brendan Kearney <bpk678@gmail.com> wrote:
On Tue, 2014-05-27 at 20:37 +0100, Arran Cudbard-Bell wrote:
Without code patches you'd need to add radiusreplyItem attributes directly to the groups objects. The group objects and the profile objects would be one and the same.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
what you say contradicts what you have stated previously:
No, it doesn't.
Groups don't return replyItems only profiles do. Groups are only used for checking membership, they cannot contain attributes themselves.
An object in LDAP can belong to multiple objectClasses.
Without an objectClass an object is is just an object, it's not a group it's not a profile.
No an object which is just a member of the posixGroup class can't contain replyItems, or checkItems or any other RADIUS attributes.
Yes an object which is a member of the radiusprofile class can contain replyItems, and checkItems and generic radius attributes.
Being a member of posixGroup does not mean that the object cannot also be a member of radiusprofile.
As I said, to do what you want to do, you actually want the group object to also be a radiusprofile object.
Here's the order of operations, hopefully it'll clear things up:
1. enter mod_authorize 2. search in user.base_dn with scope user.scope with filter user.filter Requesting attributes: user.access_attribute (if set) profile.attribute all attributes on the right hand side of the update section Assuming user is found 3. store dn 4. check access_attribute value 5. apply update section mappings 6. foreach of the profile.attribute values Search in profile.attibute.value with filter profile.filter Requesting attributes: all attributes on the right hand side of the update section if object found apply update section mappings 7. return from mod_authorize
I'm telling you to set profile.attribute to be 'memberOf' so that the profile code will iterate over all the group objects (which may also happen to be radiusprofile objects), performing attribute mappings.
Note: Your memberOf attribute values must be DNs instead of group CN (or whichever attribute you use as group.name_attribute).
If you want to iterate over a subset of the group objects (which also happen to be radiusprofile objects), then set an appropriate filter for profile.filter.
Hint: Profile filter can contain XLAT expansions %{}.
Note that your profile attribute could be the same as your group attribute i.e. memberOf, in which case you'd just need to add the group objects to the radiusprofile object.
am i to understand that 3.0.3 changes things or have i again missed something important?
Not dramatically since 3.0.0, i've tried my best to forget how the v2.x.x module worked. It's a traumatic experience looking over that code, I don't want to relive it again and again.
Read: The v2.0.x code is a rats nest, I have no idea how, why or if it works correctly.
In theory the same thing should work just fine for v2.0.x, but I don't know, and if it doesn't, you're on your own.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ok. i took what you said too literally. i thought that groups and profiles had to be separate. with the group created and the additional objectclass of radiusprofile added to the group, i now have the group created in the way you said.
i started a packet capture, then started radiusd -X and tried to sign into my switch. the switch requested a specific VSA, radius looked up my group memberships, found all of them, including the one with the radiusreplyitem, and replies with an Access-Accept. what is missing is the radiusreplyitem value/string in the Access-Accept message. the group i am member of has the attribute, and the value is correct, but radius is not replying with it. where am supposed to tell radius to reply with the replyitem?
The update block in the LDAP module config.
update { reply: += 'replyItem' }
There's already an example line, you just need to uncomment it.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HUZZAH TO THE ARRAN FOR HIS INSIGHT AND ASSISTANCE!!! HowTo doc to follow in a separate thread.
participants (2)
-
Arran Cudbard-Bell -
Brendan Kearney