At 03:27 PM 11/30/2009, David Mitchell wrote:

1) Don't specify the Auth-Type. You still want to check the password I assume. I think your config will let in any user who is in group "Group1" irrespective of the supplied password.

Sigh. Here I was all excited that I had everything working, and was merrily working on my docs and making them into a HOWTO. And you're right on target. Correct user ID any password permits access. So here's my users file once I take that out: DEFAULT Huntgroup-Name == Cisco_Huntgroup, Ldap-Group == "Infrastructure" Service-Type:=NAS-Prompt-User,cisco-avpair:=shell:priv-lvl=15" DEFAULT Auth-Type = ntlm_auth And now it doesn't work. "Authentication failed". If I switch the order I get: "Authorization failed"

On 11/30/2009 05:07 PM, freeradius@corwyn.net wrote:

...

At 03:27 PM 11/30/2009, David Mitchell wrote:

...

1) Don't specify the Auth-Type. You still want to check the password I assume. I think your config will let in any user who is in group "Group1" irrespective of the supplied password.

Sigh. Here I was all excited that I had everything working, and was merrily working on my docs and making them into a HOWTO. And you're right on target. Correct user ID any password permits access.

So here's my users file once I take that out: DEFAULT Huntgroup-Name == Cisco_Huntgroup, Ldap-Group == "Infrastructure" Service-Type:=NAS-Prompt-User,cisco-avpair:=shell:priv-lvl=15" DEFAULT Auth-Type = ntlm_auth

And now it doesn't work. "Authentication failed".

If I switch the order I get: "Authorization failed"

You need to set fall-through so that you still do per user processing. This is documented in the raddb/users file and you should also read doc/processing_users_file

Or just add Auth-Type := ntlm_auth to the first line (ie. instead of Accept). Fall-Through is more elegant since you don't have to add Auth-Type to every DEFAULT entry. Ivan Kalik Ivan Kalik

What I think is my final problem. I'm now working to authenticate VPN users in the same scenario, using the l2tp client in windows. Looks like everything automatically picks up that it's a MSCHAP request.

Using a similar logic: DEFAULT Huntgroup-Name == VPN_Huntgroup, Ldap-Group == "VPN_Users"

The only problem is that it appears to ignore my LDAP group, and just authenticate ANY user (with a valid User ID/ Password) regardless of LDAP group.

Yes, if that DEFAULT entry doesn't match - it will get ignored. If you want authentication to fail if such conditions are not met you need to add Auth-Type to it. If there is no Fall-Through to DEFAULT forcing ntlm_auth, Auth-Type won't be set and authentication will fail. Ivan Kalik

freeradius@corwyn.net wrote:

so if ./users: DEFAULT Huntgroup-Name == Cisco_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "Infrastructure"

Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15", DEFAULT Huntgroup-Name == VPN_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "VPN_Users"

it should work?

No.

I think even with the Auth-Type specified as ntm_auth, a Auth-Type is being set, as it's finding MSCHAP for me:

Because the NAS is sending MS-CHAP requests.

from my server config, that stops it from being found, but then I lose the password for ntlm_auth I think:

Because you've forced the "ntlm_auth" module to be run. That module ONLY checks clear-text passwords, and there is NO clear-text password in the request. Change the line having ... Auth-Type := ntlm_auth, ... to ... Auth-Type = ntlm_auth, ... And read "man users" to see what the difference is. Alan DeKok.

DEFAULT Huntgroup-Name == VPN_Huntgroup, Auth-Type=ntlm_auth, Ldap-Group == "VPN_Users"

It runs the LDAP group check, but still lets the user log in even when he's not in the VPN_Users group:

Use unlang for better control of what happens: if(Huntrgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { if(!control:Auth-Type) { update control { Auth-Type = "ntlm_auth" } } } else { reject } } Ivan Kalik

If I understand correctly, I don't need to worry about ntlm_auth at all in this case (because with MSCHAP I don't have a cleartext password, and thus ntlm_auth won't do me any good), so I probably don't need to update the Auth-Type?

If you are sure that all requests will be mschap. That if will work just if it's a pap request.

So I think what I need is:

...

if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") {

Put just ok in there. It might not like empty brackets.

...

} else { reject } }

woudl that unlang go into the ./users file? or into the authorization {..} section?

authorize. Ivan Kalik

Well, thanks to an inordinate amount of help, I've got my RADIUS server up and running exactly how I want it to. As part of my business process, I've got a detailed doc on how the server is/was constructed. I'd like to contribute that to the wiki, but I don't see that I can create an account. Also, since it drives me nuts when I'm searching on line for a fix, and an email thread ends JUST before I have the data that I need, or a piece is missing, here's that documentation as well Rick Steeves – 091201 freeradius2@corwyn.net Setup and configuration instructions, on CentOS 5.x Goals: o Authentication telnet sessions for Cisco switches against AD for a specific security group (Infrastructure) o Authentication for VPN users using MSCHAP on a sonicwall firewall using a Windows VPN client with L2TP against AD for a specific security group (VPN_Users) Install The linux site for the rpm download of freeradius2 is: http://people.redhat.com/jdennis/freeradius-rhel-centos Create /etc/yum.repos.d/freeradius2.repo: [freeradius2] name=Freeradius2 baseurl=http://people.redhat.com/jdennis/freeradius-rhel-centos enabled=1 gpgenabled=0 Install freeradius2: yum install freeradius2 freeradius2-utils freeradius2-ldap Enable FreeRadius to start on boot: chkconfig radiusd on To start the freeRadius service service radiusd start To run the service in debug mode (which you should be doing until everything works): service radiusd stop radiusd –X Configuration http://deployingradius.com/documents/configuration/active_directory.html Note that the configuring of SAMBA, kerberos, and adding to the domain should already be done as part of the default Linux install, see h:\is\operating system\Linux\Guide_linux.doc Verify that a user in the domain can be authenticated: wbinfo -a user%password Try the same login with the ntlm_auth program, which is what FreeRADIUS will be using: ntlm_auth --request-nt-key --domain=MYDOMAIN --username=user --password=password ./raddb/radiusd.conf (see Appendix C) Update max_requests to # users * 256 Add to the end of the auth listen {..} clients = disambiguate Add to the end of the acct listen {..} clients = disambiguate Add to the end of the modules{..} section: exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=example.com -username=%{mschap:User-Name} --password=%{User-Password}" } In log {..} auth = yes huntgroups huntgroups let you restrict which clients are associated with which user. You will need to add each IP of each device that will be using the RADIUS server, and associate it with the correct huntgroup. This will let the ./users file associate the user with the appropriate device: /etc/radbb/huntgroups: Cisco_Huntgroup NAS-IP-Address == 10.100.0.1 Cisco_Huntgroup NAS-IP-Address == 10.100.0.2 Cisco_Huntgroup NAS-IP-Address == 10.100.0.3 … VPN_Huntgroup NAS-IP-Address == 10.4.1.2 ./raddb/modules/ldap (See appendix D) If this file is missing, you need to install the RPM for freeradius2-ldap. This section is one of the biggest pains to configure, as all of your LDAP strings need to be 100% correct, andt hey will be very specific to the environment. Of course, update server, identify, password, basedn for your own environment. You will need a user account in AD to permit the bind to LDAP. In this example, that account is in: CN=_useraccount,OU=Service Accounts,OU=Special User Accounts,OU=Enterprise,DC=example,DC=com In this example, the Security groups are located in (or below): OU=Enterprise,DC=example,DC=com ldap { server = "example.com" identity = "CN=_useraccount,OU=Service Accounts,OU=Special User Accounts,OU=Enterprise,DC=example,DC=com" password = secretpassword basedn = "OU=Enterprise,DC=example,DC=com" filter = (&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person)) groupmembership_attribute = "memberOf" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no groupname_attribute = cn groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))" } Configuration of different virtual sites For this you'll have 3 general sites, default (used mostly for testing on 127.0.0.1), server_cisco (used to AAA the Cisco users), and server_vpn (used to AAA the VPN users). inner-tunnel Add: ntlm_auth to the end of the authenticate{..} section default Add: ntlm_auth to the end of the authenticate{..} section server_cisco (see Appendix B) We're going to duplicate the default config, and modify it for that particular virtual server: cp /etc/raddb/sites-available/default /etc/raddb/sites-available/server_cisco Edit server_cisco and change it from server{..} to server server_cisco{..} Since we're not using any of these methods for the Ciscos, in authenticate{..} disable: chap, mschap, suffix, ntdomain, unix, pap Add to the end of the authorize{..} section: ntlm_auth server_vpn (see Appendix A) cp /etc/raddb/sites-available/server_cisco /etc/raddb/sites-available/server_vpn Edit server_vpn and change it from server server_cisco {..} to server server_vpn {..} To get it to restrict who gets authorized based on the LDAP group, add to authorize {..}: if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { ok } else { reject } } Link sites-enabled to sites-available: cd /etc/raddb/sites-enabled ln –s ../sites-available/server_cisco server_cisco ln –s ../sites-available/server_vpn server_vpn ./raddb/clients.conf This defines which individual clients connect to which virtual server, letting you differentiate the server config (including the secret) by client Note: The secret needs to match the secret set on the respective client. Change the secret to an actual secret clients disambiguate { client localhost { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no } client VPN { ipaddr = 10.4.1.2 secret = secret virtual_server = server_vpn } client Cisco { ipaddr = 10.100.0.0 netmask = 16 secret = secret virtual_server = server_cisco nastype = cisco }} ./raddb/users This file determines which AAA is done against which device and associates the defined huntgroups with the type of AAA #testuser Huntgroup-Name == Cisco_Huntgroup, Cleartext-Password:="testpass" # Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15" DEFAULT Huntgroup-Name == Cisco_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "Infrastructure" Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15" DEFAULT Huntgroup-Name == VPN_Huntgroup, Ldap-Group == "VPN_Users" Cisco config On each switch, you have to point the authentication, authorization, and accounting to the RADIUS server. You'll want to have defined login and enable passwords already in case you screw up. you can then just bring the RADIUS server down and it will default to the next form of authentication: aaa authentication login default group radius line aaa authentication enable default group radius line aaa authorization exec default group radius none no aaa accounting exec default start-stop group radius no aaa accounting system default start-stop group radius no aaa accounting network default start-stop group radius no aaa accounting connection default start-stop group radius no aaa accounting commands 1 default stop-only group radius no aaa accounting commands 15 default wait-start group radius radius host 10.10.20.24 auth-port 1812 acct-port 1813 timeout 3 radius key <mysharedsecret> radius retransmit 2 sonicwall config Sorry, outside the scope of this document. Different Testing methods From Windows: Ntradping.exe From Linux: radtest testuser testpass localhost 0 testing123 ntlm_auth --request-nt-key --domain=example.com --username=testuser --password=testpass Troubleshooting: If you get an error from the output of radiusd –X along the lines of: Exec-Program output: winbind client not authorized to use winbindd_pam_auth_crap. Ensure permissions on /var/cache/samba/winbindd_privileged are set correctly. (0xc0000022) hen the issue is that radiusd doesn't have access to the winbindd_privileged folder. you can fix with: chgrp radiusd /var/cache/samba/winbindd_privileged chmod g+rw /var/cache/samba/winbindd_privileged Appendix A – server_vpn server server_vpn { authorize { preprocess mschap files ldap if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { ok } else { reject } } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } ntlm_auth } preacct { preprocess acct_unique files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } } Appendix B: server_cisco server server_cisco { authorize { preprocess mschap files ldap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } ntlm_auth } preacct { preprocess acct_unique files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } } Appendix C – radiusd.conf prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = /usr/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct name = radiusd confdir = ${raddbdir} run_dir = ${localstatedir}/run/${name} db_dir = ${raddbdir} libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid user = radiusd group = radiusd max_request_time = 30 cleanup_delay = 5 max_requests = 25600 listen { type = auth ipaddr = * port = 0 clients = disambiguate } listen { ipaddr = * port = 0 type = acct clients = disambiguate } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log { destination = files file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests = yes $INCLUDE proxy.conf $INCLUDE clients.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { $INCLUDE ${confdir}/modules/ exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=example.com --username=%{mschap:User-Name} --password=%{User-Password}" } } instantiate { exec expr expiration logintime } $INCLUDE policy.conf $INCLUDE sites-enabled/

Having just followed all of those instructions to build out my production systems, I have a few tweaks to fix all those little things that drive one insane when following someone's instructions because they never tested them. Using FreeRADIUS2 Rick Steeves – 091203 freeradius2@corwyn.net Setup, configuration, troubleshooting instructions, on CentOS 5.x Goals: o Authentication telnet sessions for Cisco switches against AD for a specific security group (Infrastructure) o Authentication for VPN users using MSCHAP on a sonicwall firewall using a Windows VPN client with L2TP against AD for a specific security group (VPN_Users) Install The linux site for the rpm download of freeradius2 is: http://people.redhat.com/jdennis/freeradius-rhel-centos Create /etc/yum.repos.d/freeradius2.repo: [freeradius2] name=Freeradius2 baseurl=http://people.redhat.com/jdennis/freeradius-rhel-centos enabled=1 gpgcheck=0 Install freeradius2: yum clean all yum install freeradius2 freeradius2-utils freeradius2-ldap Enable FreeRadius to start on boot: chkconfig radiusd on To start the freeRadius service service radiusd start To run the service in debug mode (which you should be doing until everything works): service radiusd stop radiusd –X Quirks If you get an error from the output of radiusd –X along the lines of: Exec-Program output: winbind client not authorized to use winbindd_pam_auth_crap. Ensure permissions on /var/cache/samba/winbindd_privileged are set correctly. (0xc0000022) then the issue is that radiusd doesn't have access to the winbindd_privileged folder. You can fix with: chgrp radiusd /var/cache/samba/winbindd_privileged chmod g+rw /var/cache/samba/winbindd_privileged Configuration See http://deployingradius.com/documents/configuration/active_directory.html Note that the configuring of SAMBA, kerberos, and adding to the domain should already be done as part of the default Linux install, see h:\is\operating system\Linux\Guide_linux.doc Verify that a user in the domain can be authenticated: wbinfo -a user%password Try the same login with the ntlm_auth program, which is what FreeRADIUS will be using: ntlm_auth --request-nt-key --domain=MYDOMAIN --username=user --password=password /etc/raddb/radiusd.conf (see Appendix C) Update max_requests to # users * 256 Add to the end of the auth listen {..} (to permit groups of clients) clients = disambiguate Add to the end of the acct listen {..} (to permit groups of clients) clients = disambiguate Add to the end of the modules{..} section: (to enable ntlm_auth as an authentication method) exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=example.com -username=%{mschap:User-Name} --password=%{User-Password}" } In log{..} auth = yes (to log authentication requests) /etc/raddb/huntgroups huntgroups let you restrict which clients are associated with which user. You will need to add each IP of each device that will be using the RADIUS server, and associate it with the correct huntgroup. This will let the /etc/raddb/users file associate the user with the appropriate device: /etc/radbb/huntgroups: Cisco_Huntgroup NAS-IP-Address == 10.100.0.1 Cisco_Huntgroup NAS-IP-Address == 10.100.0.2 Cisco_Huntgroup NAS-IP-Address == 10.100.0.3 … VPN_Huntgroup NAS-IP-Address == 10.4.1.2 /etc/raddb/modules/ldap If this file is missing, you need to install the RPM for freeradius2-ldap. This section is one of the biggest pains to configure, as all of your LDAP strings need to be 100% correct, andt hey will be very specific to the environment. Of course, update server, identify, password, basedn for your own environment. You will need a user account in AD to permit the bind to LDAP. In this example, that account is in: CN=_useraccount,OU=Service Accounts,OU=Special User Accounts,OU=Enterprise,DC=example,DC=com In this example, the Security groups are located in (or below): OU=Enterprise,DC=example,DC=com ldap { server = "example.com" identity = "CN=_useraccount,OU=Service Accounts,OU=Special User Accounts,OU=Enterprise,DC=example,DC=com" password = secretpassword basedn = "OU=Enterprise,DC=example,DC=com" filter = (&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person)) groupmembership_attribute = "memberOf" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no groupname_attribute = cn groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))" } Configuration of different virtual sites For this you'll have 3 general sites, default (used mostly for testing on 127.0.0.1), server_cisco (used to AAA the Cisco users), and server_vpn (used to AAA the VPN users). These live in /etc/raddb/sites-available/ inner-tunnel Add: ntlm_auth to the end of the authenticate{..} section default Add: ntlm_auth to the end of the authenticate{..} section server_cisco (see Appendix B) We're going to duplicate the default config, and modify it for that particular virtual server: cp /etc/raddb/sites-available/default /etc/raddb/sites-available/server_cisco Edit server_cisco and change it from server{..} to server server_cisco{..} Since we're not using any of these methods for the Ciscos, in authenticate{..} disable: chap, mschap, suffix, ntdomain, unix, pap Add to the end of the authorize{..} section: ntlm_auth server_vpn (see Appendix A) cp /etc/raddb/sites-available/server_cisco /etc/raddb/sites-available/server_vpn Edit server_vpn and change it from server server_cisco {..} to server server_vpn {..} To get it to restrict who gets authorized based on the LDAP group, add to authorize {..}: if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { ok } else { reject } } Link sites-enabled to sites-available: chown root:radiusd /etc/raddb/sites-available/server_cisco chown root:radiusd /etc/raddb/sites-available/server_vpn cd /etc/raddb/sites-enabled ln –s ../sites-available/server_cisco server_cisco ln –s ../sites-available/server_vpn server_vpn /etc/raddb/clients.conf This defines which individual clients connect to which virtual server, letting you differentiate the server config (including the secret) by client Note: The secret needs to match the secret set on the respective client. Change the secret to an actual secret clients disambiguate { client localhost { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no } client VPN { ipaddr = 10.4.1.2 secret = secret virtual_server = server_vpn } client Cisco { ipaddr = 10.100.0.0 netmask = 16 secret = secret virtual_server = server_cisco nastype = cisco }} /etc/raddb/users This file determines which AAA is done against which device and associates the defined huntgroups with the type of AAA #testuser Huntgroup-Name == Cisco_Huntgroup, Cleartext-Password:="testpass" # Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15" DEFAULT Huntgroup-Name == Cisco_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "Infrastructure" Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15" DEFAULT Huntgroup-Name == VPN_Huntgroup, Ldap-Group == "VPN_Users" /etc/raddb/modules/mschap mschap { ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name} --domain=%{mschap:NT-Domain:-example.com} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" } Cisco config On each switch, you have to point the authentication, authorization, and accounting to the RADIUS server. You'll want to have defined login and enable passwords already in case you screw up. you can then just bring the RADIUS server down and it will default to the next form of authentication: aaa authentication login default group radius line aaa authentication enable default group radius enable aaa authorization exec default group radius if-authenticated aaa accounting exec default start-stop group radius aaa accounting system default start-stop group radius aaa accounting network default start-stop group radius aaa accounting connection default start-stop group radius aaa accounting commands 1 default stop-only group radius aaa accounting commands 15 default wait-start group radius radius host 10.10.20.23 auth-port 1812 acct-port 1813 timeout 3 radius host 10.11.20.25 auth-port 1812 acct-port 1813 timeout 3 radius host 10.10.20.24 auth-port 1812 acct-port 1813 timeout 3 radius-server directed-request restricted radius key <sharedsecret> radius retransmit 0 privilege exec level 1 show configuration For local LAN switches (to control which IP address is used to connect to RADIUS, important since the clients are by IP) ip radius source-interface Vlan100 What this config does is set the sequence of things the Cisco switch tries to use to authenticate (and authorize) the user. Example: aaa authentication login default group radius line means, for login, check: group radius: The defined RADIUS servers line: the password for line input Others are: enable: the password for enable input local: a locally defined AAA user accout, configured with username <username> password <password> SonicWall config Sorry, outside the scope of this document. Adding/changing Devices To add a new Cisco Switch Add the switch to the appropriate huntgroup in /etc/raddb/huntgroups so it associates with the correct user authorization method in /etc/raddb/users Add a new client entry for the switch in /etc/raddb/clients.conf. The name of the client is what's used in the log entries. To add/change user authentication Update the entries in /etc/raddb/users. If you actually need to add a totally new authentication method, you'll have to update the appropriate entries in the individual server config, and likely update the config for the individual authentication module in /etc/raddb/modules Checking Logs Logs for the main RADIUS server are in /var/log/radius/radius.log Logs for Accounting for individual devices are in /var/log/radius/radacct/<ip address of client> Troubleshooting: If you're having problems, the easiest thing to do it stop the service and restart in debug mode: service radiusd stop radiusd –X and then try the thing that's failng again and look at the logs. To authenticate against a specific RADIUS server, you can specify the RADIUS server in the user login with: userid@ip.add.r.ess (this works because of the radius-server directed-request restricted entry on the switch) Different Testing methods From Windows: Ntradping.exe From Linux: radtest testuser testpass localhost 0 testing123 ntlm_auth --request-nt-key --domain=example.com --username=testuser --password=testpass Appendix A – server_vpn server server_vpn { authorize { preprocess mschap files ldap if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { ok } else { reject } } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } ntlm_auth } preacct { preprocess acct_unique files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } } Appendix B: server_cisco server server_cisco { authorize { preprocess mschap files ldap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } ntlm_auth } preacct { preprocess acct_unique files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } } Appendix C – radiusd.conf prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = /usr/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct name = radiusd confdir = ${raddbdir} run_dir = ${localstatedir}/run/${name} db_dir = ${raddbdir} libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid user = radiusd group = radiusd max_request_time = 30 cleanup_delay = 5 max_requests = 25600 listen { type = auth ipaddr = * port = 0 clients = disambiguate } listen { ipaddr = * port = 0 type = acct clients = disambiguate } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log { destination = files file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests = no $INCLUDE proxy.conf $INCLUDE clients.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { $INCLUDE ${confdir}/modules/ exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=example.com --username=%{mschap:User-Name} --password=%{User-Password}" } } instantiate { exec expr } $INCLUDE policy.conf $INCLUDE sites-enabled/ At 06:31 PM 12/1/2009, freeradius@corwyn.net wrote:

Well, thanks to an inordinate amount of help, I've got my RADIUS server up and running exactly how I want it to.

As part of my business process, I've got a detailed doc on how the server is/was constructed. I'd like to contribute that to the wiki, but I don't see that I can create an account.

Also, since it drives me nuts when I'm searching on line for a fix, and an email thread ends JUST before I have the data that I need, or a piece is missing, here's that documentation as well

Rick Steeves ­ 091201 freeradius2@corwyn.net

Setup and configuration instructions, on CentOS 5.x Goals: o Authentication telnet sessions for Cisco switches against AD for a specific security group (Infrastructure) o Authentication for VPN users using MSCHAP on a sonicwall firewall using a Windows VPN client with L2TP against AD for a specific security group (VPN_Users) Install The linux site for the rpm download of freeradius2 is: http://people.redhat.com/jdennis/freeradius-rhel-centos

Create /etc/yum.repos.d/freeradius2.repo:

[freeradius2] name=Freeradius2 baseurl=http://people.redhat.com/jdennis/freeradius-rhel-centos enabled=1 gpgenabled=0

Install freeradius2: yum install freeradius2 freeradius2-utils freeradius2-ldap

Enable FreeRadius to start on boot: chkconfig radiusd on

To start the freeRadius service service radiusd start

To run the service in debug mode (which you should be doing until everything works): service radiusd stop radiusd ­X Configuration http://deployingradius.com/documents/configuration/active_directory.html

Note that the configuring of SAMBA, kerberos, and adding to the domain should already be done as part of the default Linux install, see h:\is\operating system\Linux\Guide_linux.doc Verify that a user in the domain can be authenticated: wbinfo -a user%password Try the same login with the ntlm_auth program, which is what FreeRADIUS will be using: ntlm_auth --request-nt-key --domain=MYDOMAIN --username=user --password=password ./raddb/radiusd.conf (see Appendix C)

Update max_requests to # users * 256

Add to the end of the auth listen {..} clients = disambiguate

Add to the end of the acct listen {..} clients = disambiguate

Add to the end of the modules{..} section:

exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=example.com -username=%{mschap:User-Name} --password=%{User-Password}" }

In log {..}

auth = yes huntgroups huntgroups let you restrict which clients are associated with which user. You will need to add each IP of each device that will be using the RADIUS server, and associate it with the correct huntgroup. This will let the ./users file associate the user with the appropriate device:

/etc/radbb/huntgroups: Cisco_Huntgroup NAS-IP-Address == 10.100.0.1 Cisco_Huntgroup NAS-IP-Address == 10.100.0.2 Cisco_Huntgroup NAS-IP-Address == 10.100.0.3 … VPN_Huntgroup NAS-IP-Address == 10.4.1.2 ./raddb/modules/ldap (See appendix D) If this file is missing, you need to install the RPM for freeradius2-ldap.

This section is one of the biggest pains to configure, as all of your LDAP strings need to be 100% correct, andt hey will be very specific to the environment. Of course, update server, identify, password, basedn for your own environment.

You will need a user account in AD to permit the bind to LDAP. In this example, that account is in: CN=_useraccount,OU=Service Accounts,OU=Special User Accounts,OU=Enterprise,DC=example,DC=com

In this example, the Security groups are located in (or below): OU=Enterprise,DC=example,DC=com

ldap { server = "example.com" identity = "CN=_useraccount,OU=Service Accounts,OU=Special User Accounts,OU=Enterprise,DC=example,DC=com" password = secretpassword basedn = "OU=Enterprise,DC=example,DC=com" filter = (&(sAMAccountname=%{Stripped-User-Name:-%{User-Name}})(objectClass=person)) groupmembership_attribute = "memberOf" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no groupname_attribute = cn groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))" } Configuration of different virtual sites For this you'll have 3 general sites, default (used mostly for testing on 127.0.0.1), server_cisco (used to AAA the Cisco users), and server_vpn (used to AAA the VPN users). inner-tunnel Add: ntlm_auth to the end of the authenticate{..} section default Add: ntlm_auth to the end of the authenticate{..} section server_cisco (see Appendix B) We're going to duplicate the default config, and modify it for that particular virtual server:

cp /etc/raddb/sites-available/default /etc/raddb/sites-available/server_cisco

Edit server_cisco and change it from server{..} to server server_cisco{..}

Since we're not using any of these methods for the Ciscos, in authenticate{..} disable: chap, mschap, suffix, ntdomain, unix, pap

Add to the end of the authorize{..} section: ntlm_auth server_vpn (see Appendix A) cp /etc/raddb/sites-available/server_cisco /etc/raddb/sites-available/server_vpn Edit server_vpn and change it from server server_cisco {..} to server server_vpn {..}

To get it to restrict who gets authorized based on the LDAP group, add to authorize {..}: if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { ok } else { reject } }

Link sites-enabled to sites-available: cd /etc/raddb/sites-enabled ln ­s ../sites-available/server_cisco server_cisco ln ­s ../sites-available/server_vpn server_vpn ./raddb/clients.conf This defines which individual clients connect to which virtual server, letting you differentiate the server config (including the secret) by client

Note: The secret needs to match the secret set on the respective client. Change the secret to an actual secret

clients disambiguate { client localhost { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no } client VPN { ipaddr = 10.4.1.2 secret = secret virtual_server = server_vpn }

client Cisco { ipaddr = 10.100.0.0 netmask = 16 secret = secret virtual_server = server_cisco nastype = cisco }}

./raddb/users This file determines which AAA is done against which device and associates the defined huntgroups with the type of AAA

#testuser Huntgroup-Name == Cisco_Huntgroup, Cleartext-Password:="testpass" # Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15" DEFAULT Huntgroup-Name == Cisco_Huntgroup, Auth-Type:=ntlm_auth, Ldap-Group == "Infrastructure" Service-Type:=NAS-Prompt-User,cisco-avpair:="shell:priv-lvl=15" DEFAULT Huntgroup-Name == VPN_Huntgroup, Ldap-Group == "VPN_Users" Cisco config

On each switch, you have to point the authentication, authorization, and accounting to the RADIUS server. You'll want to have defined login and enable passwords already in case you screw up. you can then just bring the RADIUS server down and it will default to the next form of authentication:

aaa authentication login default group radius line aaa authentication enable default group radius line aaa authorization exec default group radius none no aaa accounting exec default start-stop group radius no aaa accounting system default start-stop group radius no aaa accounting network default start-stop group radius no aaa accounting connection default start-stop group radius no aaa accounting commands 1 default stop-only group radius no aaa accounting commands 15 default wait-start group radius radius host 10.10.20.24 auth-port 1812 acct-port 1813 timeout 3 radius key <mysharedsecret> radius retransmit 2 sonicwall config Sorry, outside the scope of this document. Different Testing methods From Windows: Ntradping.exe

From Linux: radtest testuser testpass localhost 0 testing123 ntlm_auth --request-nt-key --domain=example.com --username=testuser --password=testpass

Troubleshooting: If you get an error from the output of radiusd ­X along the lines of:

Exec-Program output: winbind client not authorized to use winbindd_pam_auth_crap. Ensure permissions on /var/cache/samba/winbindd_privileged are set correctly. (0xc0000022)

hen the issue is that radiusd doesn't have access to the winbindd_privileged folder. you can fix with:

chgrp radiusd /var/cache/samba/winbindd_privileged chmod g+rw /var/cache/samba/winbindd_privileged

Appendix A ­ server_vpn server server_vpn { authorize { preprocess mschap files ldap if(Huntgroup-Name == "VPN_Huntgroup") { if(Ldap-Group == "VPN_Users") { ok } else { reject } } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } ntlm_auth } preacct { preprocess acct_unique files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } }

Appendix B: server_cisco server server_cisco { authorize { preprocess mschap files ldap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } ntlm_auth } preacct { preprocess acct_unique files } accounting { detail radutmp attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } }

Appendix C ­ radiusd.conf

prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = /usr/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct name = radiusd confdir = ${raddbdir} run_dir = ${localstatedir}/run/${name} db_dir = ${raddbdir} libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid user = radiusd group = radiusd max_request_time = 30 cleanup_delay = 5 max_requests = 25600 listen { type = auth ipaddr = * port = 0 clients = disambiguate } listen { ipaddr = * port = 0 type = acct clients = disambiguate } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log { destination = files file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests = yes $INCLUDE proxy.conf $INCLUDE clients.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { $INCLUDE ${confdir}/modules/ exec ntlm_auth { wait = yes program = "/usr/bin/ntlm_auth ntlm_auth --request-nt-key --domain=example.com --username=%{mschap:User-Name} --password=%{User-Password}" } } instantiate { exec expr expiration logintime } $INCLUDE policy.conf $INCLUDE sites-enabled/

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

At 05:27 PM 12/3/2009, Alan Buxey wrote:

note, there are other packages should you need eg SQL support

Not if you're not using SQL support (which I'm not). You'd them also need a lot of instructions on setting up SQL :-)

you didnt note if you were SELinux enabled and any issues that might befall that -

For my own doc purposes that's covered in the Linux guide we use to set up systems, but I'll add a note here.

I'm also not sure ....but does the freeradiusd2 package automatically put the right firewall holes into place too (if not you'd need to add UDP 1812,1813 and 1814 to the incoming rule chain....)

no it does not. FYI I believe 1813 is actually TCP (empirically working through my firewalls that way). 1814 only necessary if you're using proxy I think. Rick

freeradius@corwyn.net wrote:

Having just followed all of those instructions to build out my production systems, I have a few tweaks to fix all those little things that drive one insane when following someone's instructions because they never tested them.

Thanks. Here's a short review.

Note that the configuring of SAMBA, kerberos, and adding to the domain should already be done as part of the default Linux install, see h:\is\operating system\Linux\Guide_linux.doc

This file is... ?

Verify that a user in the domain can be authenticated: wbinfo -a user%password Try the same login with the ntlm_auth program, which is what FreeRADIUS will be using: ntlm_auth --request-nt-key --domain=MYDOMAIN --username=user --password=password /etc/raddb/radiusd.conf (see Appendix C)

Update max_requests to # users * 256

That isn't necessary. It should be no more than "max request/s * max_request_time".

Add to the end of the auth listen {..} (to permit groups of clients) clients = disambiguate

Add to the end of the acct listen {..} (to permit groups of clients) clients = disambiguate

I don't understand why this is necessary. All it does is put the clients into a sub-section. There's no additional value or capabilities in doing this.

Since we're not using any of these methods for the Ciscos, in authenticate{..} disable: chap, mschap, suffix, ntdomain, unix, pap

Add to the end of the authorize{..} section: ntlm_auth

Or to the end of the "authenticate" section?

Note: The secret needs to match the secret set on the respective client. Change the secret to an actual secret

clients disambiguate {

Again, there's no reason for this. Alan DeKok.

freeradius@corwyn.net wrote:

...

Update max_requests to # users * 256 That isn't necessary. It should be no more than "max request/s * max_request_time".

Well the docs say: # max_requests: The maximum number of requests which the server keeps # track of. This should be 256 multiplied by the number of clients. # e.g. With 4 clients, this number should be 1024.

so I was just doing what this said.

No. "users" are not "clients". Users are people logging in. RADIUS clients are NAS machines.

I probably picked this up from one of the random docs while trying to puzzle things out that weren't clear. Since it helps show how to use a subsection, it's useful to me.

The problem for a *public* document is that unnecessary pieces confuse people. Alan DeKok.

Hi, I would need LDAP and Mysql. Should I install two RPMSs? freeradius-ldap-2.1.7-2.fc12.i686.rpm freeradius-mysql-2.1.7-2.fc12.i686.rpm What is i686 means? I have a dell laptop IBM clone. thx, Alex __________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

I guess I got lucky - I *think* I opted to get the FR source and compile. For ONCE it was easy! I guess all the dependencies were already installed and current enough! -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.or g] On Behalf Of Tim Sylvester Sent: Friday, December 04, 2009 3:09 PM To: 'FreeRadius users mailing list' Subject: RE: Which RPM Should I use Alex, Here's the link to the RedHAT FAQ on the FreeRADIUS site that describes how to install FreeRADIUS on Red Hat Enterprise Linux (RHEL), CentOS and Fedora: http://wiki.freeradius.org/Red_Hat_FAQ You actually need several of the RPMs including the src RPM. Then you would need to install the following: freeradius-libs-2.1.7-2.fc12.i686.rpm freeradius-2.1.7-2.fc12.i686.rpm freeradius-ldap-2.1.7-2.fc12.i686.rpm freeradius-mysql-2.1.7-2.fc12.i686.rpm freeradius-utils-2.1.7-2.fc12.i686.rpm An alternative would be switching to CentOS which will be easier. You can move to CentOS and follow the directions on the FreeRADIUS web site on how to install in a RedHat environment. This would allow you to use the "yum" utility which automatically downloads the dependencies for you. Tim

-----Original Message----- From: freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org [mailto:freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org] On Behalf Of Alex Bahoor Sent: Friday, December 04, 2009 12:36 PM To: 'FreeRadius users mailing list' Subject: Which RPM Should I use

Hi,

I would need LDAP and Mysql. Should I install two RPMSs? freeradius-ldap-2.1.7-2.fc12.i686.rpm freeradius-mysql-2.1.7-2.fc12.i686.rpm

What is i686 means? I have a dell laptop IBM clone. thx,

Alex

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>

Tim, What do you mean by the first line? Which RPMs and what is the source RPM? Rgrds, Alex -----Original Message----- You actually need several of the RPMs including the src RPM. Then you would need to install the following: freeradius-libs-2.1.7-2.fc12.i686.rpm freeradius-2.1.7-2.fc12.i686.rpm freeradius-ldap-2.1.7-2.fc12.i686.rpm freeradius-mysql-2.1.7-2.fc12.i686.rpm freeradius-utils-2.1.7-2.fc12.i686.rpm An alternative would be switching to CentOS which will be easier. You can move to CentOS and follow the directions on the FreeRADIUS web site on how to install in a RedHat environment. This would allow you to use the "yum" utility which automatically downloads the dependencies for you. Tim

-----Original Message----- From: freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org [mailto:freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org] On Behalf Of Alex Bahoor Sent: Friday, December 04, 2009 12:36 PM To: 'FreeRadius users mailing list' Subject: Which RPM Should I use

Hi,

I would need LDAP and Mysql. Should I install two RPMSs? freeradius-ldap-2.1.7-2.fc12.i686.rpm freeradius-mysql-2.1.7-2.fc12.i686.rpm

What is i686 means? I have a dell laptop IBM clone. thx,

Alex

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

Hi Alex, RADIUS uses port 1812 for authentication and 1813 for accounting. Since these are well known ports, netstat -a will not explicitly show you the port #s being used but the name of the protocol instead for easy identification. See sample below: agalnx-srv-01:~ # netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:ftp *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 localhost:ipp *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 10.10.10.13:ssh 10.10.10.11:49177 ESTABLISHED tcp 0 0 10.10.10.13:ssh 10.10.10.11:49172 ESTABLISHED udp 0 0 *:49710 *:* udp 0 0 *:bootps *:* udp 0 0 *:tftp *:* udp 0 0 *:985 *:* udp 0 0 *:mdns *:* udp 0 0 *:sunrpc *:* udp 0 0 *:ipp *:* udp 0 0 *:radius *:* udp 0 0 *:radius-acct *:* udp 0 0 *:tdp-suite *:* raw 0 0 *:icmp *:* 7 Active UNIX domain sockets (servers and established) ... The output you've been seeing is what you should expect. In regarding configuration examples for the client.conf the file itself has the information you're looking for. You either edit the samples and uncomment the lines (not really recommended) or you copy one of the example and place it to the end of the file and edit it to attend your needs. For example: The example below was extracted from the clients.conf itself: #client 192.168.0.0/16 { # secret = testing123-2 # shortname = private-network-2 #} You may copy it to the end of the file and replace the suggested IP address to the IP address of your NAS (switch, Access-Point...etc.). client 10.10.10.1/32 { secret = mysecret-01 shortname = my-switch } I hope it helps. Highest regards, AG On 12/5/09 3:07 AM, "Alex Bahoor" <alexbahoor@sbcglobal.net> wrote:

Greetings,

I got freeradius running on F12. I see the radiusd.conf file uses ports 0 instead of 1812 and 1813. Netstat -a does not tells me which ports numbers Radius is listening on, instead I see two ports with *:* in the port number.

Is there config examples on this cofig file and client.conf? I take it there is no GUI for freeradius, correct?

Thx,

Alex

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

Ivan, I red that. Assigning dynamic ports other than the specific ones, could be to resolve conflict incase the ports are assigned to different processes. But that does not make sense, there must be other reasons, otherwise, tftp, ftp, mail, telnet, bootp...etc would have this option too. Alex -----Original Message----- From: freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.org [mailto:freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.o rg] On Behalf Of tnt@kalik.net Sent: Saturday, December 05, 2009 5:57 AM To: FreeRadius users mailing list Subject: Re: Config Examples

I got freeradius running on F12. I see the radiusd.conf file uses ports 0 instead of 1812 and 1813.

Now go back and read comments above port = 0 entry. Ivan Kalik - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

They do? Networking would not work, when the ports would be dynamic. Inetd would not be functional or useful...etc. Alex -----Original Message----- From: freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.org [mailto:freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.o rg] On Behalf Of freeradius@corwyn.net Sent: Saturday, December 05, 2009 10:10 AM To: FreeRadius users mailing list; 'FreeRadius users mailing list' Subject: RE: Config Examples At 12:55 PM 12/5/2009, Alex Bahoor wrote:

Ivan,

I red that. Assigning dynamic ports other than the specific ones, could be to resolve conflict incase the ports are assigned to different processes. But that does not make sense, there must be other reasons, otherwise, tftp, ftp, mail, telnet, bootp...etc would have this option too.

They do. Rick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

It seems that we agree on the concept. However, netstat -a on the server shows *:* for the port numbers of RADIUS, when it's dynamically assigned. What is that mean? Alex -----Original Message----- From: freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.org [mailto:freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.o rg] On Behalf Of Bob Franklin Sent: Saturday, December 05, 2009 11:15 AM To: FreeRadius users mailing list Subject: RE: Config Examples On Sat, 5 Dec 2009, Alex Bahoor wrote:

They do? Networking would not work, when the ports would be dynamic. Inetd would not be functional or useful...etc.

"Dynamic" as in you can change them from the default, in case something else is already using the port, or you want to move it for other reasons (running a second server, "security", testing, etc.). [In much the same way that people get confused by what the "Dynamic" in "Dynamic Host Configuration Protocol" means -- not that the address is necessarily different each time, but that the client dynamically configures its address based on the information sent by the server.]

From radiusd.conf, in the block above the 'port = 0' line:

# The port is defined here to be 0 so that the server will pick up # the machine's local configuration for the radius port, as defined # in /etc/services. - Bob -- Bob Franklin <rcf34@cam.ac.uk> +44 1223 748479 Network Division, University of Cambridge Computing Service - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

True, I see that all the time, it must have some significance that I don't know. Cuz, dynamic port assignment, are shown in most cases with numbers, however some time it shows *:*. Why? Alex -----Original Message----- From: freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.org [mailto:freeradius-users-bounces+alexbahoor=sbcglobal.net@lists.freeradius.o rg] On Behalf Of Alan DeKok Sent: Saturday, December 05, 2009 11:47 AM To: FreeRadius users mailing list Subject: Re: Config Examples Alex Bahoor wrote:

It seems that we agree on the concept. However, netstat -a on the server shows *:* for the port numbers of RADIUS, when it's dynamically assigned.

No, it doesn't. It shows that the *outgoing* IP and port are "*:*". This is normal for many UDP sockets. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4662 (20091205) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

Alex Bahoor wrote:

Imagine DNS uses dynamic port assignment instead of port 53? Guess what, no one would be able to use the internet. :-)

You can believe that the Internet doesn't work, or you can believe that you don't understand the output of "netstat". Which one is likely to be true? Alan DeKok.

This is a fact--the internet would not work if DNS uses dynamic port to listen to? You must understand, all these known port numbers are used to start up client connections

Ok, let's say you want to use port 1645 for radius authentication. What do you do? Go round the shops and see if they have a device with that one? Or should you have flexibility ot use 1645 or 1812 as you please? Or should 1645 now be banned for use with radius because it confuses you? Ivan Kalik

Alex, You are insulting people that are trying to help you, for FREE. Chill out! When you did netstat -a, you probably did something like this: [root@springy html]# netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:ldap *:* LISTEN tcp 0 0 *:mysql *:* LISTEN tcp 0 0 *:sunrpc *:* LISTEN tcp 0 0 *:ftp *:* LISTEN tcp 0 0 springy.smartcow.com:ipp *:* LISTEN tcp 0 0 springy.smartcow.com:smtp *:* LISTEN tcp 0 0 *:rndc *:* LISTEN tcp 0 0 *:ldap *:* LISTEN tcp 0 0 *:http *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:https *:* LISTEN tcp 0 132 springy.smartcow.com:ssh sporky.smartcow.com:55457 ESTABLISHED tcp 0 0 springy.smartcow.com:ssh sporky.smartcow.com:64928 ESTABLISHED tcp 0 0 springy.smartcow.com:ssh sporky.smartcow.c:ddi-tcp-5 ESTABLISHED tcp 0 0 springy.smartcow.com:ssh sporky.smartcow.com:64026 ESTABLISHED udp 0 0 *:radius *:* udp 0 0 *:radius-acct *:* If you look carefully at the headings, you will see that *:* is the in "Foreign Address" column. Reading the man page for netstat shows that the Local Address and Foreign address column are: Local Address Address and port number of the local end of the socket. Unless the --numeric (-n) option is specified, the socket address is resolved to its canonical host name (FQDN), and the port number is translated into the corresponding service name. Foreign Address Address and port number of the remote end of the socket. Analogous to "Local Address." Since RADIUS uses UDP and is connectionless, the concept of the remote end of the socket doesn't mean much. If you READ the man page, you can use the netstat -an, which will show port numbers and IP address numbers. You will see something like: [root@springy html]# netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:953 0.0.0.0:* LISTEN tcp 0 0 :::389 :::* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::22 :::* LISTEN tcp 0 0 :::443 :::* LISTEN tcp 0 0 ::ffff:10.0.0.91:22 ::ffff:10.0.0.242:55457 ESTABLISHED tcp 0 0 ::ffff:10.0.0.91:22 ::ffff:10.0.0.242:64928 ESTABLISHED tcp 0 0 ::ffff:10.0.0.91:22 ::ffff:10.0.0.242:8892 ESTABLISHED tcp 0 0 ::ffff:10.0.0.91:22 ::ffff:10.0.0.242:64026 ESTABLISHED udp 0 0 0.0.0.0:1812 0.0.0.0:* udp 0 0 0.0.0.0:1813 0.0.0.0:* The last two lines are the entries for the RADIUS server listening on port 1812 for authentication requests and on port 1813 for accounting requests. *:* has nothing to do with dynamic ports. Go back and read the information in the configuration files, man pages, web site, and mailing lists. Then if you have some other questions, send you questions to the mailing list in a respectful, grateful manner. Tim Since radius uses UDP the "F

-----Original Message----- From: freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org [mailto:freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org] On Behalf Of Alex Bahoor Sent: Saturday, December 05, 2009 2:43 PM To: 'FreeRadius users mailing list' Subject: RE: Config Examples

You're missing the point. This is how networking works.

Alex

-----Original Message----- From: freeradius-users- bounces+alexbahoor=sbcglobal.net@lists.freeradius.org [mailto:freeradius-users- bounces+alexbahoor=sbcglobal.net@lists.freeradius.o rg] On Behalf Of tnt@kalik.net Sent: Saturday, December 05, 2009 2:26 PM To: FreeRadius users mailing list Subject: RE: Config Examples

...

This is a fact--the internet would not work if DNS uses dynamic port to listen to? You must understand, all these known port numbers are used to start up client connections

Ok, let's say you want to use port 1645 for radius authentication. What do you do? Go round the shops and see if they have a device with that one? Or should you have flexibility ot use 1645 or 1812 as you please? Or should 1645 now be banned for use with radius because it confuses you?

Ivan Kalik

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

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4663 (20091205) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4663 (20091205) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

Alex Bahoor wrote:

This is a fact--the internet would not work if DNS uses dynamic port to listen to? You must understand, all these known port numbers are used to start up client connections, however dynamic port assignment is part of the process to create connections between clients and servers.

I would suggest not explaining basic networking. Since I work with FreeRADIUS && UDP networking daily, you should presume that I have some minor understanding of it.

So a client starts with port 53 as its destination port, then the DNS, which listen on this port, assign a port dynamically for the end user. When the connection is established between the client and server, port 53 is out of the established connection.

No. That is not how networking works.

But still, why netstat does not show the port numbers?

I explained. Did you read and/or understand it? And "man netstat" might be useful, too. In any case, this list is not the place to discuss netstat, or why you don't understand its output. Please stop. Alan DeKok.