Hi, administrator account. the account used must have permissions to read other account details. from your error, looks like it cannot

# Administrator account for searching and possibly modifying. identity = “uid=TestUser,ou=Users,dc=myhost,dc=com" password = testing123

(1) WARNING: ldap : Bind with uid=bobsso,ou=Users,dc=myhost,dc=com to ldap.myhost.com:636 failed: Can't contact LDAP server. Got new socket, retrying... (1) WARNING: ldap : No "known good" password added. Ensure the admin user has permission to read the password attribute

alan

On Jan 27, 2016, at 9:12 AM, Alan DeKok <aland@deployingradius.com> wrote:

On Jan 27, 2016, at 11:58 AM, Will W. <will@damagesinc.net> wrote:

...

Question: How can I fix my configuration as I am getting No “known good” password Warning?

That means that the password wasn't found in the LDAP database.

...

This is what I have done:

I have enabled LDAP in /etc/raddb/sites-enabled/default -ldap

I removed this section in /etc/raddb/sites-enabled/default

The ldap module is listed by default. That's good.

...

if ((ok || updated) && User-Password) { update { control:Auth-Type := ldap } }

Delete all of that. it's not necessary.

I said "configure the LDAP module and it will Just Work". I did NOT say "mangle the default virtual server".

...

Created a symbolic line for ldap under /etc/raddb/mods-enabled/ldap

That's good.

...

ldap { # Note that this needs to match the name(s) in the LDAP server # certificate, if you're using ldaps. See OpenLDAP documentation # for the behavioral semantics of specifying more than one host. server = “ldap.myhost.com"

Is that the hostname of your LDAP server?

No I scrubbed the names

...

The bind user is working. When I run the readiest for the bind user I get: Sending Access-Accept Id 4 from 127.0.0.1:1812 to 127.0.0.1:42631 in the debug while running radius -X

And what does the debug output say? Is it actually binding to LDAP? Did you check?

#according this this it is opening a total of 5 connections, Kind of stands out that "rlm_ldap (ldap): Could not set random_file: Success” shows up in red. #but all 5 connections come back with a “Bine successful” rlm_ldap (ldap): Opening additional connection (0) rlm_ldap (ldap): Connecting to ldap.myhost.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful #Full out put radiusd: FreeRADIUS Version 3.0.3, for host x86_64-suse-linux-gnu, built on Dec 3 2014 at 10:31 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 /usr/share/freeradius/dictionary including dictionary file /usr/share/freeradius/dictionary.dhcp including dictionary file /usr/share/freeradius/dictionary.vqp 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/always including configuration file /etc/raddb/mods-enabled/files including configuration file /etc/raddb/mods-enabled/detail.log including configuration file /etc/raddb/mods-enabled/linelog including configuration file /etc/raddb/mods-enabled/eap including configuration file /etc/raddb/mods-enabled/unix including configuration file /etc/raddb/mods-enabled/detail including configuration file /etc/raddb/mods-enabled/radutmp including configuration file /etc/raddb/mods-enabled/soh including configuration file /etc/raddb/mods-enabled/sradutmp including configuration file /etc/raddb/mods-enabled/ldap including configuration file /etc/raddb/mods-enabled/mschap including configuration file /etc/raddb/mods-enabled/exec including configuration file /etc/raddb/mods-enabled/unpack including configuration file /etc/raddb/mods-enabled/passwd including configuration file /etc/raddb/mods-enabled/preprocess including configuration file /etc/raddb/mods-enabled/expiration including configuration file /etc/raddb/mods-enabled/chap including configuration file /etc/raddb/mods-enabled/pap including configuration file /etc/raddb/mods-enabled/echo including configuration file /etc/raddb/mods-enabled/replicate including configuration file /etc/raddb/mods-enabled/attr_filter including configuration file /etc/raddb/mods-enabled/cache_eap including configuration file /etc/raddb/mods-enabled/realm including configuration file /etc/raddb/mods-enabled/digest including configuration file /etc/raddb/mods-enabled/utf8 including configuration file /etc/raddb/mods-enabled/logintime including configuration file /etc/raddb/mods-enabled/dynamic_clients including configuration file /etc/raddb/mods-enabled/dhcp including configuration file /etc/raddb/mods-enabled/expr including configuration file /etc/raddb/mods-enabled/ntlm_auth including files in directory /etc/raddb/policy.d/ including configuration file /etc/raddb/policy.d/eap including configuration file /etc/raddb/policy.d/filter including configuration file /etc/raddb/policy.d/cui including configuration file /etc/raddb/policy.d/accounting including configuration file /etc/raddb/policy.d/canonicalization including configuration file /etc/raddb/policy.d/control including configuration file /etc/raddb/policy.d/dhcp including configuration file /etc/raddb/policy.d/operator-name 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 main { security { 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 = yes log { stripped_names = no auth = no auth_badpass = no auth_goodpass = no colourise = yes msg_denied = "You are already logged in - access denied" } security { max_attributes = 200 reject_delay = 1 status_server = yes allow_vulnerable_openssl = "no" } } 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 = <<< secret >>> 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 = <<< secret >>> nas_type = "other" proto = "*" limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } radiusd: #### Instantiating modules #### instantiate { } modules { # Loaded module rlm_always # Instantiating module "reject" from file /etc/raddb/mods-enabled/always always reject { rcode = "reject" simulcount = 0 mpp = no } # Instantiating module "fail" from file /etc/raddb/mods-enabled/always always fail { rcode = "fail" simulcount = 0 mpp = no } # Instantiating module "ok" from file /etc/raddb/mods-enabled/always always ok { rcode = "ok" simulcount = 0 mpp = no } # Instantiating module "handled" from file /etc/raddb/mods-enabled/always always handled { rcode = "handled" simulcount = 0 mpp = no } # Instantiating module "invalid" from file /etc/raddb/mods-enabled/always always invalid { rcode = "invalid" simulcount = 0 mpp = no } # Instantiating module "userlock" from file /etc/raddb/mods-enabled/always always userlock { rcode = "userlock" simulcount = 0 mpp = no } # Instantiating module "notfound" from file /etc/raddb/mods-enabled/always always notfound { rcode = "notfound" simulcount = 0 mpp = no } # Instantiating module "noop" from file /etc/raddb/mods-enabled/always always noop { rcode = "noop" simulcount = 0 mpp = no } # Instantiating module "updated" from file /etc/raddb/mods-enabled/always always updated { rcode = "updated" simulcount = 0 mpp = no } # 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 = "cistron" } reading pairlist file /etc/raddb/mods-config/files/authorize [/etc/raddb/mods-config/files/authorize]:181 Cistron compatibility checks for entry DEFAULT ... [/etc/raddb/mods-config/files/authorize]:188 Cistron compatibility checks for entry DEFAULT ... [/etc/raddb/mods-config/files/authorize]:195 Cistron compatibility checks for entry DEFAULT ... reading pairlist file /etc/raddb/mods-config/files/authorize [/etc/raddb/mods-config/files/authorize]:181 Cistron compatibility checks for entry DEFAULT ... [/etc/raddb/mods-config/files/authorize]:188 Cistron compatibility checks for entry DEFAULT ... [/etc/raddb/mods-config/files/authorize]:195 Cistron compatibility checks for entry DEFAULT ... reading pairlist file /etc/raddb/mods-config/files/accounting reading pairlist file /etc/raddb/mods-config/files/pre-proxy # 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 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 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 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 locking = no log_packet_header = no } # 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 = "messages.%{%{Packet-Type}:-default}" } # Instantiating module "log_accounting" from file /etc/raddb/mods-enabled/linelog linelog log_accounting { filename = "/var/log/radius/linelog-accounting" permissions = 384 format = "" reference = "Accounting-Request.%{%{Acct-Status-Type}:-unknown}" } # 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 = 1024 } # 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 = <<< secret >>> 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_unix # Instantiating module "unix" from file /etc/raddb/mods-enabled/unix unix { radwtmp = "/var/log/radius/radwtmp" } # 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 locking = no log_packet_header = no } # Loaded module rlm_radutmp # 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_soh # Instantiating module "soh" from file /etc/raddb/mods-enabled/soh soh { dhcp = yes } # 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_ldap # Instantiating module "ldap" from file /etc/raddb/mods-enabled/ldap ldap { server = "ldap.myhost.com" port = 636 password = <<< secret >>> identity = "uid=bobsso,ou=Users,dc=myhost,dc=com" edir = no user { filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" scope = "sub" base_dn = "ou=Users,dc=myhost,dc=com" access_positive = yes } group { filter = "(objectClass=posixGroup)" scope = "sub" base_dn = "ou=Users,dc=myhost,dc=com" name_attribute = "cn" membership_attribute = "memberOf" cacheable_name = no cacheable_dn = no } client { filter = "(objectClass=frClient)" scope = "sub" base_dn = "ou=Users,dc=myhost,dc=com" attribute { identifier = "radiusClientIdentifier" shortname = "cn" secret = "radiusClientSecret" } } profile { filter = "(&)" } 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 { ca_file = "/etc/raddb/certs/current/rootCA.pem" ca_path = "/etc/raddb/certs/current" certificate_file = "/etc/raddb/certs/current/radius.crt" private_key_file = "/etc/raddb/certs/current/radius.key" random_file = "/dev/random" 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 = 32 spare = 3 uses = 0 lifetime = 0 cleanup_interval = 30 idle_timeout = 60 retry_delay = 1 spread = no } rlm_ldap (ldap): Opening additional connection (0) rlm_ldap (ldap): Connecting to ldap.myhost.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (1) rlm_ldap (ldap): Connecting to ldap.myhost.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (2) rlm_ldap (ldap): Connecting to ldap.myhost.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (3) rlm_ldap (ldap): Connecting to ldap.myhost.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Opening additional connection (4) rlm_ldap (ldap): Connecting to ldap.myhost.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful # 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_exec # Instantiating module "exec" from file /etc/raddb/mods-enabled/exec exec { wait = no input_pairs = "request" shell_escape = yes timeout = 10 } # Loaded module rlm_unpack # Instantiating module "unpack" from file /etc/raddb/mods-enabled/unpack # 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_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_expiration # Instantiating module "expiration" from file /etc/raddb/mods-enabled/expiration # Loaded module rlm_chap # Instantiating module "chap" from file /etc/raddb/mods-enabled/chap # Loaded module rlm_pap # Instantiating module "pap" from file /etc/raddb/mods-enabled/pap pap { normalise = yes } # 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_replicate # Instantiating module "replicate" from file /etc/raddb/mods-enabled/replicate # 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_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_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_digest # Instantiating module "digest" from file /etc/raddb/mods-enabled/digest # Loaded module rlm_utf8 # Instantiating module "utf8" from file /etc/raddb/mods-enabled/utf8 # Loaded module rlm_logintime # Instantiating module "logintime" from file /etc/raddb/mods-enabled/logintime logintime { minimum_timeout = 60 } # Loaded module rlm_dynamic_clients # Instantiating module "dynamic_clients" from file /etc/raddb/mods-enabled/dynamic_clients # 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.-_: /" } # 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 } } # modules radiusd: #### Loading Virtual Servers #### server { # from file /etc/raddb/radiusd.conf } # server server default { # from file /etc/raddb/sites-enabled/default # Creating Auth-Type = digest # Creating Auth-Type = LDAP # Loading authenticate {...} # Loading authorize {...} # Loading preacct {...} # Loading accounting {...} Ignoring "sql" (see raddb/mods-available/README.rst) # Loading post-proxy {...} # Loading post-auth {...} } # server default server inner-tunnel { # from file /etc/raddb/sites-enabled/inner-tunnel # Loading authenticate {...} # Loading authorize {...} # Loading session {...} # Loading post-proxy {...} # Loading post-auth {...} } # server inner-tunnel radiusd: #### Opening IP addresses and Ports #### 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 } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } Listening on auth address * port 1812 as server default Listening on acct address * port 1813 as server default Listening on auth address 127.0.0.1 port 18120 as server inner-tunnel Opening new proxy socket 'proxy address * port 0' Listening on proxy address * port 49866 Ready to process requests.

...

How ever when I try it again using a test account or any other user account I get: (1) WARNING: ldap : Bind with uid=bobsso,ou=Users,dc=myhost,dc=com to ldap.myhost.com:636 failed: Can't contact LDAP server. Got new socket, retrying...

That indicates a problem. Why does it take multiple tries to contact the LDAP server?

There are multiple ldap hosts behind a load balancer, think the ldap genies are doing maintenance, so nice that they do that with out sending out an e-mail or something to do with the following:

...

(1) ldap : Waiting for bind result... (1) ldap : Bind successful (1) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) (1) ldap : --> (uid=demouser) (1) ldap : EXPAND ou=Users,dc=myhost,dc=com (1) ldap : --> ou=Users,dc=myhoset,dc=com (1) ldap : Performing search in 'ou=Users,dc=yhost,dc=com' with filter '(uid=demouser)', scope 'sub' (1) ldap : Waiting for search result... (1) ldap : User object found at DN "uid=demouser,ou=Users,dc=myhost,dc=com" (1) ldap : Processing user attributes (1) WARNING: ldap : No "known good" password added. Ensure the admin user has permission to read the password attribute (1) WARNING: ldap : PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure)

And that's definitive.

Is the LDAP server Active Directory?

no its not AD, its LDAP but I don’t know as I am not allowed to login to it, it is working on our client machines and servers.

What happens when you run the LDAP query manually, with an LDAP client? Do you get a "userPassword" entry back?

output of radtest demouser testing123 localhost 0 testing123 Received Access-Request Id 164 from 127.0.0.1:48644 to 127.0.0.1:1812 length 78 User-Name = 'demouser' User-Password = 'testing123' NAS-IP-Address = 10.0.200.202 NAS-Port = 0 Message-Authenticator = 0x6ec83a1e2fc632a602ffcdd4d8370f01 (1) # Executing section authorize from file /etc/raddb/sites-enabled/default (1) authorize { (1) filter_username filter_username { (1) if (User-Name != "%{tolower:%{User-Name}}") (1) EXPAND %{tolower:%{User-Name}} (1) --> demouser (1) if (User-Name != "%{tolower:%{User-Name}}") -> FALSE (1) if (User-Name =~ / /) (1) if (User-Name =~ / /) -> FALSE (1) if (User-Name =~ /@.*@/ ) (1) if (User-Name =~ /@.*@/ ) -> FALSE (1) if (User-Name =~ /\\.\\./ ) (1) if (User-Name =~ /\\.\\./ ) -> FALSE (1) if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) (1) if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE (1) if (User-Name =~ /\\.$/) (1) if (User-Name =~ /\\.$/) -> FALSE (1) if (User-Name =~ /@\\./) (1) if (User-Name =~ /@\\./) -> FALSE (1) } # filter_username filter_username = notfound (1) [preprocess] = ok (1) auth_log : EXPAND /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (1) auth_log : --> /var/log/radius/radacct/127.0.0.1/auth-detail-20160127 (1) auth_log : /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/127.0.0.1/auth-detail-20160127 (1) auth_log : EXPAND %t (1) auth_log : --> Wed Jan 27 18:27:53 2016 (1) [auth_log] = ok (1) [chap] = noop (1) [mschap] = noop (1) [digest] = noop (1) suffix : No '@' in User-Name = "demouser", looking up realm NULL (1) suffix : No such realm "NULL" (1) [suffix] = noop (1) eap : No EAP-Message, not doing EAP (1) [eap] = noop (1) [files] = noop rlm_ldap (ldap): Reserved connection (4) (1) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) (1) ldap : --> (uid=demouser) (1) ldap : EXPAND ou=Users,dc=myhost,dc=com (1) ldap : --> ou=Users,dc=myhost,dc=com (1) ldap : Performing search in 'ou=Users,dc=myhost,dc=com' with filter '(uid=demouser)', scope 'sub' (1) ldap : Waiting for search result... rlm_ldap (ldap): Reconnecting (4) rlm_ldap (ldap): Connecting to ldap.jumpcloud.com:636 rlm_ldap (ldap): Could not set random_file: Success rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful (1) WARNING: ldap : Search failed: Can't contact LDAP server. Got new socket, retrying... (1) ldap : Waiting for search result... (1) ldap : User object found at DN "uid=demouser,ou=Users,dc=myhost,dc=com" (1) ldap : Processing user attributes (1) WARNING: ldap : No "known good" password added. Ensure the admin user has permission to read the password attribute (1) WARNING: ldap : PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure) rlm_ldap (ldap): Released connection (4) rlm_ldap (ldap): Closing connection (0), from 1 unused connections rlm_ldap (ldap): Closing connection (3): Hit idle_timeout, was idle for 231 seconds rlm_ldap (ldap): You probably need to lower "min" rlm_ldap (ldap): Closing connection (2): Hit idle_timeout, was idle for 231 seconds rlm_ldap (ldap): You probably need to lower "min" rlm_ldap (ldap): Closing connection (1): Hit idle_timeout, was idle for 231 seconds rlm_ldap (ldap): You probably need to lower "min" (1) [ldap] = ok (1) [expiration] = noop (1) [logintime] = noop (1) WARNING: pap : No "known good" password found for the user. Not setting Auth-Type. (1) WARNING: pap : Authentication will fail unless a "known good" password is available. (1) [pap] = noop (1) } # authorize = ok (1) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (1) Failed to authenticate the user. (1) Using Post-Auth-Type Reject (1) # Executing group from file /etc/raddb/sites-enabled/default (1) Post-Auth-Type REJECT { (1) attr_filter.access_reject : EXPAND %{User-Name} (1) attr_filter.access_reject : --> demouser (1) attr_filter.access_reject : Matched entry DEFAULT at line 11 (1) [attr_filter.access_reject] = updated (1) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure (1) [eap] = noop (1) remove_reply_message_if_eap remove_reply_message_if_eap { (1) if (reply:EAP-Message && reply:Reply-Message) (1) if (reply:EAP-Message && reply:Reply-Message) -> FALSE (1) else else { (1) [noop] = noop (1) } # else else = noop (1) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (1) } # Post-Auth-Type REJECT = updated (1) Delaying response for 1 seconds Waking up in 0.9 seconds. (1) Sending delayed response Sending Access-Reject Id 164 from 127.0.0.1:1812 to 127.0.0.1:48644 Waking up in 3.9 seconds. (1) Cleaning up request packet ID 164 with timestamp +229 Ready to process requests. ldap search over port 389 10.0.200.202:~ # ldapsearch -d 1 -H ldap://ldap.myhost.com:389 -x -b "ou=Users,dc=myhost,dc=com" -D "uid=bobsso,ou=Users,dc=myhost,dc=com" -w ‘testing123 "(objectClass=i ldap_url_parse_ext(ldap://ldap.myhost.com:389) ldap_create ldap_url_parse_ext(ldap://ldap.myhost.com:389/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.myhost.com:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.0.200.10:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 95 bytes to sd 3 ldap_result ld 0x7f34425e0c10 msgid 1 wait4msg ld 0x7f34425e0c10 msgid 1 (infinite timeout) wait4msg continue ld 0x7f34425e0c10 msgid 1 all 1 ** ld 0x7f34425e0c10 Connections: * host: ldap.myhost.com port: 389 (default) refcnt: 2 status: Connected last used: Wed Jan 27 18:43:12 2016 ** ld 0x7f34425e0c10 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f34425e0c10 request count 1 (abandoned 0) ** ld 0x7f34425e0c10 Response Queue: Empty ld 0x7f34425e0c10 response count 0 ldap_chkResponseList ld 0x7f34425e0c10 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f34425e0c10 NULL ldap_int_select read1msg: ld 0x7f34425e0c10 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x7f34425e0c10 msgid 1 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x7f34425e0c10 0 new referrals read1msg: mark request completed, ld 0x7f34425e0c10 msgid 1 request done: ld 0x7f34425e0c10 msgid 1 res_errno: 49, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed ip-10-0-200-202:~ # working on getting the ldap search over port 636 right now.

Or do you have a custom LDAP schema, with the password in some other field?

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed ip-10-0-200-202:~ #

working on getting the ldap search over port 636 right now.

That clearly failed, helps to read the output before pasting it to the list. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On Jan 27, 2016, at 3:58 PM, Will W. <will@damagesinc.net> wrote:

had to take the quotes off the password and it now lists all objects

Paste the attribute map from mods-available/ldap, and the attributes returned by ldapsearch. Feel free to redact the values. -Arran

On Jan 27, 2016, at 4:36 PM, Will W. <will@damagesinc.net> wrote:

Question With Start_TLS yes this is enabling the Freeradius to connect to the LDAP server over a TLS tunnel correct?

Yes, the connection starts off as plaintext, then the ldap client requests to establish a TLS tunnel. Map looks OK. You need to run ldapsearch with this invocation to see if the userPassword is being returned: ldapsearch -H ldap://ldap.myhost.com:389 —ZZ x -b "ou=Users,dc=myhost,dc=com" -D "uid=demouser,ou=Users,dc=myhost,dc=com" -w testing123 "(objectClass=posixGroup)" userPassword -Arran

On Jan 27, 2016, at 5:13 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

...

On Jan 27, 2016, at 5:08 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

...

On Jan 27, 2016, at 4:36 PM, Will W. <will@damagesinc.net> wrote:

Question With Start_TLS yes this is enabling the Freeradius to connect to the LDAP server over a TLS tunnel correct?

Yes, the connection starts off as plaintext, then the ldap client requests to establish a TLS tunnel.

Map looks OK. You need to run ldapsearch with this invocation to see if the userPassword is being returned:

ldapsearch -H ldap://ldap.myhost.com:389 —ZZ x -b "ou=Users,dc=myhost,dc=com" -D "uid=demouser,ou=Users,dc=myhost,dc=com" -w testing123 "(objectClass=posixGroup)" userPassword

Here are the headers and what they map to:

/* * For auto-header discovery. * * @note Header comparison is case insensitive. */ static const FR_NAME_NUMBER header_names[] = { { "{clear}", PW_CLEARTEXT_PASSWORD }, { "{cleartext}", PW_CLEARTEXT_PASSWORD }, { "{md5}", PW_MD5_PASSWORD }, { "{base64_md5}", PW_MD5_PASSWORD }, { "{smd5}", PW_SMD5_PASSWORD }, { "{crypt}", PW_CRYPT_PASSWORD }, #ifdef HAVE_OPENSSL_EVP_H /* * It'd make more sense for the headers to be * ssha2-* with SHA3 coming soon but we're at * the mercy of directory implementors. */ { "{sha2}", PW_SHA2_PASSWORD }, { "{sha224}", PW_SHA2_PASSWORD }, { "{sha256}", PW_SHA2_PASSWORD }, { "{sha384}", PW_SHA2_PASSWORD }, { "{sha512}", PW_SHA2_PASSWORD }, { "{ssha224}", PW_SSHA2_224_PASSWORD }, { "{ssha256}", PW_SSHA2_256_PASSWORD }, { "{ssha384}", PW_SSHA2_384_PASSWORD }, { "{ssha512}", PW_SSHA2_512_PASSWORD }, #endif { "{sha}", PW_SHA_PASSWORD }, { "{ssha}", PW_SSHA_PASSWORD }, { "{md4}", PW_NT_PASSWORD }, { "{nt}", PW_NT_PASSWORD }, { "{nthash}", PW_NT_PASSWORD }, { "{x-nthash}", PW_NT_PASSWORD }, { "{ns-mta-md5}", PW_NS_MTA_MD5_PASSWORD }, { "{x- orcllmv}", PW_LM_PASSWORD }, { "{X- orclntv}", PW_NT_PASSWORD }, { NULL, 0 } };

You need to call the pap module in authorize after the LDAP module in order to strip the header and perform the conversion.

It also does a bunch of normalisation. It could be you have the modules in the wrong order, pap then ldap when you need ldap then pap.

Finally, you probably want ssha512 not sha512. It'll be more complex to implement, but in reality sha512 will likely give you less protection than ssha. It's fairly trivial to generate rainbow tables, the bigger hash size just means you need more disk space :) Get sha512 working first though, and worry about the salting later. -Arran

Which of these looks right? authenticate { pap ldap } authenticate { ldap pap }

On 28 Jan 2016, at 6:06 PM, Will W. <will@damagesinc.net> wrote:

Ok, how do I change the order in which ldap and pap are called?

On Wed, Jan 27, 2016 at 2:13 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:

...

...

On Jan 27, 2016, at 5:08 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:

...

On Jan 27, 2016, at 4:36 PM, Will W. <will@damagesinc.net> wrote:

Question With Start_TLS yes this is enabling the Freeradius to connect to the LDAP server over a TLS tunnel correct?

Yes, the connection starts off as plaintext, then the ldap client requests to establish a TLS tunnel.

Map looks OK. You need to run ldapsearch with this invocation to see if the userPassword is being returned:

ldapsearch -H ldap://ldap.myhost.com:389 —ZZ x -b "ou=Users,dc=myhost,dc=com" -D "uid=demouser,ou=Users,dc=myhost,dc=com" -w testing123 "(objectClass=posixGroup)" userPassword

Here are the headers and what they map to:

/* * For auto-header discovery. * * @note Header comparison is case insensitive. */ static const FR_NAME_NUMBER header_names[] = { { "{clear}", PW_CLEARTEXT_PASSWORD }, { "{cleartext}", PW_CLEARTEXT_PASSWORD }, { "{md5}", PW_MD5_PASSWORD }, { "{base64_md5}", PW_MD5_PASSWORD }, { "{smd5}", PW_SMD5_PASSWORD }, { "{crypt}", PW_CRYPT_PASSWORD }, #ifdef HAVE_OPENSSL_EVP_H /* * It'd make more sense for the headers to be * ssha2-* with SHA3 coming soon but we're at * the mercy of directory implementors. */ { "{sha2}", PW_SHA2_PASSWORD }, { "{sha224}", PW_SHA2_PASSWORD }, { "{sha256}", PW_SHA2_PASSWORD }, { "{sha384}", PW_SHA2_PASSWORD }, { "{sha512}", PW_SHA2_PASSWORD }, { "{ssha224}", PW_SSHA2_224_PASSWORD }, { "{ssha256}", PW_SSHA2_256_PASSWORD }, { "{ssha384}", PW_SSHA2_384_PASSWORD }, { "{ssha512}", PW_SSHA2_512_PASSWORD }, #endif { "{sha}", PW_SHA_PASSWORD }, { "{ssha}", PW_SSHA_PASSWORD }, { "{md4}", PW_NT_PASSWORD }, { "{nt}", PW_NT_PASSWORD }, { "{nthash}", PW_NT_PASSWORD }, { "{x-nthash}", PW_NT_PASSWORD }, { "{ns-mta-md5}", PW_NS_MTA_MD5_PASSWORD }, { "{x- orcllmv}", PW_LM_PASSWORD }, { "{X- orclntv}", PW_NT_PASSWORD }, { NULL, 0 } };

You need to call the pap module in authorize after the LDAP module in order to strip the header and perform the conversion.

It also does a bunch of normalisation. It could be you have the modules in the wrong order, pap then ldap when you need ldap then pap.

-Arran

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

OK this is getting fun, two systems up, the first one I get working wins. - original system: SEL 12.1 Freeradius install via repo binaries 3.0.4 I'm familiar with 2.x but 3.x has a few differences. I am guessing that this needs to be changed in /etc/raddb/sites-enabled/default Emailing from my phone is a bit painful. -second system after getting the email about Freeradius 3.1.0 with patch for crypt. Ubuntu x86_64 14.04 cloned from github about three hours ago. Freeradius 3.1.0 Still trying to figure out what is wrong with my /dev/urandom file set in /etc/freeradius/mods-enabled/ldap Seems like on both RHEL 7.x and Ubuntu 14.04 when I compile from source and run either freeradius -X the first thing that it complained about was: random_file = /dev/urandom is world writable. Quick chmod 644 and then I get an unknown error trying to set the random_file. Is there a fix for this? On Jan 28, 2016 00:30, "David Lord" <d.lord@its.uq.edu.au> wrote:

Apologies, I was a bit quick on the retort there. Please disregard.

...

On 28 Jan 2016, at 6:25 PM, David Lord <d.lord@its.uq.edu.au> wrote:

Which of these looks right?

authenticate { pap ldap }

authenticate { ldap pap }

...

On 28 Jan 2016, at 6:06 PM, Will W. <will@damagesinc.net> wrote:

Ok, how do I change the order in which ldap and pap are called?

On Wed, Jan 27, 2016 at 2:13 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:

...

...

On Jan 27, 2016, at 5:08 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:

...

On Jan 27, 2016, at 4:36 PM, Will W. <will@damagesinc.net> wrote:

Question With Start_TLS yes this is enabling the Freeradius to connect to the LDAP server over a TLS tunnel correct?

Yes, the connection starts off as plaintext, then the ldap client requests to establish a TLS tunnel.

Map looks OK. You need to run ldapsearch with this invocation to see

if

...

the userPassword is being returned:

...

ldapsearch -H ldap://ldap.myhost.com:389 —ZZ x -b

"ou=Users,dc=myhost,dc=com" -D "uid=demouser,ou=Users,dc=myhost,dc=com" -w testing123 "(objectClass=posixGroup)" userPassword

Here are the headers and what they map to:

/* * For auto-header discovery. * * @note Header comparison is case insensitive. */ static const FR_NAME_NUMBER header_names[] = { { "{clear}", PW_CLEARTEXT_PASSWORD }, { "{cleartext}", PW_CLEARTEXT_PASSWORD }, { "{md5}", PW_MD5_PASSWORD }, { "{base64_md5}", PW_MD5_PASSWORD }, { "{smd5}", PW_SMD5_PASSWORD }, { "{crypt}", PW_CRYPT_PASSWORD }, #ifdef HAVE_OPENSSL_EVP_H /* * It'd make more sense for the headers to be * ssha2-* with SHA3 coming soon but we're at * the mercy of directory implementors. */ { "{sha2}", PW_SHA2_PASSWORD }, { "{sha224}", PW_SHA2_PASSWORD }, { "{sha256}", PW_SHA2_PASSWORD }, { "{sha384}", PW_SHA2_PASSWORD }, { "{sha512}", PW_SHA2_PASSWORD }, { "{ssha224}", PW_SSHA2_224_PASSWORD }, { "{ssha256}", PW_SSHA2_256_PASSWORD }, { "{ssha384}", PW_SSHA2_384_PASSWORD }, { "{ssha512}", PW_SSHA2_512_PASSWORD }, #endif { "{sha}", PW_SHA_PASSWORD }, { "{ssha}", PW_SSHA_PASSWORD }, { "{md4}", PW_NT_PASSWORD }, { "{nt}", PW_NT_PASSWORD }, { "{nthash}", PW_NT_PASSWORD }, { "{x-nthash}", PW_NT_PASSWORD }, { "{ns-mta-md5}", PW_NS_MTA_MD5_PASSWORD }, { "{x- orcllmv}", PW_LM_PASSWORD }, { "{X- orclntv}", PW_NT_PASSWORD }, { NULL, 0 } };

You need to call the pap module in authorize after the LDAP module in order to strip the header and perform the conversion.

It also does a bunch of normalisation. It could be you have the modules in the wrong order, pap then ldap when you need ldap then pap.

-Arran

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On Jan 28, 2016, at 3:49 AM, Will W. <will@damagesinc.net> wrote:

OK this is getting fun, two systems up, the first one I get working wins.

- original system: SEL 12.1 Freeradius install via repo binaries 3.0.4 I'm familiar with 2.x but 3.x has a few differences. I am guessing that this needs to be changed in /etc/raddb/sites-enabled/default Emailing from my phone is a bit painful.

-second system after getting the email about Freeradius 3.1.0 with patch for crypt. Ubuntu x86_64 14.04 cloned from github about three hours ago. Freeradius 3.1.0 Still trying to figure out what is wrong with my /dev/urandom file set in /etc/freeradius/mods-enabled/ldap

Seems like on both RHEL 7.x and Ubuntu 14.04 when I compile from source and run either freeradius -X the first thing that it complained about was: random_file = /dev/urandom is world writable. Quick chmod 644 and then I get an unknown error trying to set the random_file.

Is there a fix for this?

Unknown error means ldap_set_option returned an error without setting an error on the ldap handle. Reading through the OpenLDAP code, it seems that this particular option is only available as a global, so we're not allowed to pass in an ldap handle. This is undocumented behaviour. I'll push a fix. As for module ordering, edit sites-available/default Remove everything from the authorize section, and just list the modules ldap pap in that order. Remove everything from the auth section, and just list pap. It should work. -Arran

On Jan 28, 2016, at 7:27 PM, Will W. <will@damagesinc.net> wrote:

random_file = "/dev/random" Configuration file /dev/random is globally writable. Refusing to start due to insecure configuration. /usr/local/etc/raddb/mods-enabled/ldap[8]: Invalid configuration for module "ldap"

That's a bug.

so what I gather about the last few e-mail was that I should not change the permissions on things in the /dev folder.

is there a fix for this?

git pull. I've pushed a fix. Alan DeKok.

On 28 Jan 2016, at 21:07, Will W. <will@damagesinc.net> wrote:

I just did the pull and the error has changed to this when I run radiusd -X rlm_ldap (ldap) - Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap) - Connecting to ldap://ldap.myhost.com:389 rlm_ldap (ldap) - Failed setting connection option random_file: Unknown error rlm_ldap (ldap) - Opening connection failed (0) rlm_ldap (ldap) - Removing connection pool /usr/local/etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap"

Yes, that was explained in a previous post in this thread... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On Jan 29, 2016, at 1:41 PM, Will W. <will@damagesinc.net> wrote:

Yes, it is a bug and you pushed a fix, I pulled it and built this on a new system and I still see the same problem.

...

rlm_ldap (ldap) - Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap) - Connecting to ldap://ldap.myhost.com:389 rlm_ldap (ldap) - Failed setting connection option random_file: Unknown error rlm_ldap (ldap) - Opening connection failed (0) rlm_ldap (ldap) - Removing connection pool /usr/local/etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap"

this is off the new system with the latest code from github.

It's a bug, I haven't pushed a fix yet, I said I would, I didn't say I had :) I'm working on something else related to this to definitively determine the capabilities of the directory server on startup and give better warnings. The fix will be pushed at the same time as that. -Arran

Ok Still having issues, I have the lasted pull from this morning running on CentOS 7.2 It seems that I can only see it trying cleartext, is there a way to get the PAP module to a higher debug level so I can see what cipher it is trying against the LDAP server? Config file for default after putting in the changes http://pastebin.com/Z7H3tjxm Here is the output from radtest http://pastebin.com/GfBkbFxY On Thu, Jan 28, 2016 at 9:53 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:

...

On Jan 28, 2016, at 3:49 AM, Will W. <will@damagesinc.net> wrote:

OK this is getting fun, two systems up, the first one I get working wins.

- original system: SEL 12.1 Freeradius install via repo binaries 3.0.4 I'm familiar with 2.x but 3.x has a few differences. I am guessing that this needs to be changed in /etc/raddb/sites-enabled/default Emailing from my phone is a bit painful.

-second system after getting the email about Freeradius 3.1.0 with patch for crypt. Ubuntu x86_64 14.04 cloned from github about three hours ago. Freeradius 3.1.0 Still trying to figure out what is wrong with my /dev/urandom file set in /etc/freeradius/mods-enabled/ldap

Seems like on both RHEL 7.x and Ubuntu 14.04 when I compile from source and run either freeradius -X the first thing that it complained about was: random_file = /dev/urandom is world writable. Quick chmod 644 and then I get an unknown error trying to set the random_file.

Is there a fix for this?

Unknown error means ldap_set_option returned an error without setting an error on the ldap handle.

Reading through the OpenLDAP code, it seems that this particular option is only available as a global, so we're not allowed to pass in an ldap handle.

This is undocumented behaviour.

I'll push a fix.

As for module ordering, edit sites-available/default

Remove everything from the authorize section, and just list the modules

ldap pap

in that order.

Remove everything from the auth section, and just list pap.

It should work.

-Arran

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Alan, I do appreciate everyones help, but as there are multiple people responding and not just you, I am address multiple people helping me. Now I am sorry if I seem to be ignoring what has been told to me but looking at the thread of this e-mail you will that actually the radtest output is from the debug output from radiusd -X, provided as instructed due to a push that was done a few days ago. Sorry about miss labeling it. Per previous e-mail in thread from for modifying /usr/local/etc/raddb/site-enabled/default *Arran Cudbard-Bell <a.cudbardb@freeradius.org <a.cudbardb@freeradius.org>>* *Unknown error means ldap_set_option returned an error without setting an erroron the ldap handle.Reading through the OpenLDAP code, it seems that this particular option is onlyavailable as a global, so we're not allowed to pass in an ldap handle.This is undocumented behaviour.I'll push a fix.As for module ordering, edit sites-available/defaultRemove everything from the authorize section, and just list the modulesldappapin that order.Remove everything from the auth section, and just list pap.It should work.-Arran* The config file is being modified and I am only posting progress update as I am not seeing anything from the PAP modules other than the following rlm_ldap (ldap) - Bind successful (0) ldap (ok) (0) pap - WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap - WARNING: Authentication will fail unless a "known good" password is available (0) pap (noop) When I am seeing the following from the bind user rlm_ldap (ldap) - Bind successful (1) ldap - Reserved connection (6) (1) ldap - EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) (1) ldap - --> (uid=demouser) (1) ldap - Performing search in "ou=Users,dc=myhost,dc=com" with filter "(uid=bind-user)", scope "sub" (1) ldap - Waiting for search result... (1) ldap - User object found at DN "uid=bind-user,ou=Users,dc=myhost,dc=com" (1) ldap - Processing user attributes (1) ldap - &control:Password-With-Header += {CRYPT}$6$cbea6d7932dfa76b$YgORZH6XtDXmFEDrcBnX3Ao6JDxACy.BRMTNZ8DkF0idg3cM2D3gPEHRfA05f8dQx14o/4Fi575xXJ.2yDkDA/ (1) ldap - Released connection (6) ... rlm_ldap (ldap) - Bind successful (1) ldap (updated) (1) pap - Converted: Password-With-Header -> Crypt-Password (1) pap - Removing &control:Password-With-Header (1) pap (updated) True putting things into the e-mail thread seeming rude, so I tried to put it in pastebin so that it would not show up in the e-mails. On Tue, Feb 2, 2016 at 12:02 PM, Alan DeKok <aland@deployingradius.com> wrote:

On Feb 2, 2016, at 3:00 PM, Will W. <will@damagesinc.net> wrote:

...

Ok Still having issues, I have the lasted pull from this morning running

on

...

CentOS 7.2 It seems that I can only see it trying cleartext, is there a way to get the PAP module to a higher debug level so I can see what cipher it is trying against the LDAP server?

Config file for default after putting in the changes http://pastebin.com/Z7H3tjxm

We've told you that we don't need the configuration files.

...

Here is the output from radtest http://pastebin.com/GfBkbFxY

We've told you that we don't need the output of radtest.

We've told you we need to see the debug output.

Not to be rude.. but you're being rude.

Follow instructions, or stop asking questions on this list.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

You need to provide the rest of the debug output up to the point where it sends an Access-Challenge.

or reject -Arran

On Feb 2, 2016, at 3:45 PM, Will W. <will@damagesinc.net> wrote:

it is the radiusd -X out of the radtast here are the fail and success

This ends up not being complicated. Reading the debug output helps.

Success ... rlm_ldap (ldap) - Bind successful (1) ldap (updated) (1) pap - Converted: Password-With-Header -> Crypt-Password

That's clear.

Fail ... (0) ldap - User object found at DN "uid=user,ou=Users,dc=myhost,dc=com" (0) ldap - Processing user attributes (0) ldap - WARNING: No "known good" password added. Set 'identity' to the dn of an account that has permission to read the user's password attribute

If only the server produced useful error messages. This isn't rocket science. For the "success" case, the user has a password in LDAP. For the "fail" case, the user doesn't have a password in LDAP. Or, the user doesn't have permission to read the password. Have you tried checking the user entries in LDAP? Alan DeKok.

On Feb 2, 2016, at 3:58 PM, Will W. <will@damagesinc.net> wrote:

LDAP server is already service up for VPN access and all users authenticate but to clarifiy both user accounts are identical other than username. The only difference I can see is that the bind-user is the user account that is binding the freeradius server to LDAP. So the bind user can look himself up isn’t really a win as none of the other users in the system can be authenticated.

<sigh> You were told to configure a read-only administrator account. That account should have permissions to read everyones passwords. Then, FreeRADIUS should be configured to use that account when binding to LDAP. The majority of problems you're running into are because you fail to follow instructions. It's not complicated. You're making it complicated. You're trying all kinds of different things, essentially randomly. When instead, following the instructions would have gotten this solved a LONG time ago. It's time to stop asking questions, and to start following instructions. If you don't care enough to follow instructions, we can help you by unsubscribing you from the list. We don't have any interest in helping people who waste everyones time. Alan DeKok.

On Feb 2, 2016, at 7:13 PM, Will W. <will@damagesinc.net> wrote:

both accounts are read only administrators..... both have bind rights, both accounts are being used in other places for LDAP authentication.

That may be so. But... FreeRADIUS isn't an LDAP server. And we didn't implement an LDAP client. We just use the normal LDAP APIs. If a *NORMAL LDAP QUERY* returns "no data", then the problem is (a) the query, or (b) the permissions of the user doing the query. As such, and fix is mostly LDAP. Not FreeRADIUS. We don't run your LDAP server, and we don't have access to it. All we know is that normal LDAP queries return data. We've been trying to convince you of that, and are having a hard time. This is common. Everyone blames FreeRADIUS for everything. It's still inappropriate and frustrating for us.

I am following everyones instructions, here is a recap since I came here for help. problem 1 needed help with LDAP and SHA512, resolution not supported on version 2.x and goto version 3.x

Version 2 has been officially end of life for over a year.

problem 2 went to version 3.0.11, had an issue with /dev/urandom,

You were apparently the only one who used the "random" thing in the LDAP module configuration. That's why no one ever saw it before.

resolution was told there was a bug and pushed a fix goto 3.1.0 problem 3 told to change auth order in default fie, posted radiusd -X out put and config, resolution none problem 4 went to version 3.1.0, for unknow_error message with /dev/urandom, and fixed an issue on the OS side regrading gnutls and openssl as Ubuntu and Debian both seem to be baking gnutls into their latest brews. Now that the freeradius server I have had to build from source can connect over SSL, I am back to the same problem I can not authenticate a user on LDAP. resolution being told I can not follow instructions

And the bugs were fixed within a day, once you gave us the right information. We've been responsive to your questions.

Where have I not followed instruction, I have made several course correction with shrewd comments and that is fine it gets the problem fixed, however the problem is not fixed and I am still having the issue of not being able to authenticate a users password with all the documentation and instruction I have received.

Please suggest to us how we can fix an LDAP database so that it returns the correct data. When we don't have access to the LDAP database. ... We can't. *You* need to do it. It's been hard for us to convince you that this is the case.

Seeing how this LDAP system is working on all my systems in various forms and I am using the same user account to bind, what is so different with this setup?

Ask your LDAP database.

Secondly if it isn't rocket science then you should be able to explain it to anyone, especially since all the modification, which have been minimal were direct by people from your group and by group I am referring to people with @deployingradius.com individuals.

There's only one person with an email address at that domain: me. If you want to berate me, do it directly.

I am not trying to be rude and I have been reading all the documentation I can get my hands on, however I am still stuck.

You did a number of things wrong. Which were against all existing documentation. You then argued for a number of email messages. It took a while for us to convince you that the FreeRADIUS error messages were meaningful.

Coming to the e-mail threads has been a last resort of sorts. As this project started I never planned to build from source or need to do a git pull request to get things working smoothly, but here we are.

I am just asking for help.

We're trying to help you. You're resisting. Stop it. Alan DeKok.

On Feb 2, 2016, at 3:24 PM, Will W. <will@damagesinc.net> wrote:

I do appreciate everyones help, but as there are multiple people responding and not just you, I am address multiple people helping me.

The FAQ, "man" pages, web pages, and messages DAILY on this list say "post the debug output". There is simply no excuse for not posting the debug output.

Now I am sorry if I seem to be ignoring what has been told to me but looking at the thread of this e-mail you will that actually the radtest output is from the debug output from radiusd -X, provided as instructed due to a push that was done a few days ago. Sorry about miss labeling it.

You need to communicate clearly what you're doing. You need to follow instructions. When you show us that you don't care enough to follow instructions, or to accurately describe what you're doing... you're showing us that we shouldn't care, either. Alan DeKok.

Hi,

Ok, how do I change the order in which ldap and pap are called?

-ldap pap or pap -ldap yes. that easy, just list them in the order you need alan

demouser is getting deleted after this anyhow. demouser, Users, myhost.com dn: uid=demouser,ou=Users,dc=myhost,dc=com userPassword:: e0NSWVBUfSQ2JGNiZWE2ZDc5MzJkZmE3NmIkWWdPUlpINlh0RFhtRkVEcmNCblg zQW82SkR4QUN5LkJSTVROWjhEa0YwaWRnM2NNMkQzZ1BFSFJmQTA1ZjhkUXgxNG8vNEZpNTc1eFhK LjJ5RGtEQS8=

On Jan 27, 2016, at 2:08 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

...

On Jan 27, 2016, at 4:36 PM, Will W. <will@damagesinc.net> wrote:

Question With Start_TLS yes this is enabling the Freeradius to connect to the LDAP server over a TLS tunnel correct?

Yes, the connection starts off as plaintext, then the ldap client requests to establish a TLS tunnel.

Map looks OK. You need to run ldapsearch with this invocation to see if the userPassword is being returned:

ldapsearch -H ldap://ldap.myhost.com:389 —ZZ x -b "ou=Users,dc=myhost,dc=com" -D "uid=demouser,ou=Users,dc=myhost,dc=com" -w testing123 "(objectClass=posixGroup)" userPassword

-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

You should be aware that the crypt() function is not threadsafe, and as such is protected by a mutex. If you're only processing a few hundred authentications a second, that's fine, but it will cause issues when you get to thousands or tens of thousands.

Just pushed a fix to v3.1.x branch to use crypt_r. OSX doesn't seem to have it, but Linux does. -Arran

Does the ldapsearch or any utility from this cloned server works? Did you check that?ldap://ldap.myhost.com:389 Is it really your ldap? did you make a change in local hosts file to put an ip to it? Most important does the ldapclient utility work? BR, Anirudh Malhotra 8zero2 Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On 28 Jan 2016, 11:13 +0530, Will W.<will@damagesinc.net>, wrote:

I just cloned freeradius from the github and I was able to build and install it. running freeradius -X I have been getting errors with the random_file

rlm_ldap (ldap) - Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap) - Connecting to ldap://ldap.myhost.com:389 rlm_ldap (ldap) - Failed setting connection option random_file: Unknown error rlm_ldap (ldap) - Opening connection failed (0) rlm_ldap (ldap) - Removing connection pool /etc/freeradius/mods-enabled/ldap[8]: Instantiation failed for module "ldap" root@ns1:/etc/freeradius/certs/current#

running freeradius 3.1.0 on ubuntu 14.04 x86_64 Is there a way to increase the debug level or is there something I need to do in order to get the random_file = /dev/urandom to work properly?

Will

...

On Jan 27, 2016, at 4:55 PM, Arran Cudbard-Bell<a.cudbardb@freeradius.org>wrote:

...

You should be aware that the crypt() function is not threadsafe, and as such is protected by a mutex. If you're only processing a few hundred authentications a second, that's fine, but it will cause issues when you get to thousands or tens of thousands.

Just pushed a fix to v3.1.x branch to use crypt_r. OSX doesn't seem to have it, but Linux does.

-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

utilizing SHA-2 > SHA-512 is what I was just told

On Jan 27, 2016, at 1:10 PM, Michael Ströder <michael@stroeder.com> wrote:

Will W. wrote:

...

Trying to get freeradius 3.0.10 setup with LDAP using SHA512

What does that mean in your case? Do your store userPassword values in your LDAP entries with hashing scheme {ssha512} or similar?

Ciao, Michael.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html