Peter Lambrechtsen <plambrechtsen@gmail.com> wrote:
Then create two OU's under Radius. Elements and Roles OU=Elements,OU=Radius,DC=ACME,DC=COM Elements will hold a record of every NAS in your Network. You will create Group objects based on the IP Address of the NAS and set the "Location" or "l" attribute to the NAS Huntgroup the NAS belongs to allow them to be centrally managed in LDAP. IE CN=10.1.2.3,OU=Elements,OU=Radius,DC=ACME,DC=COM With a "l" value of "CiscoRTR" for a Cisco Router that has a NAS-IP-Address or Source-IP-Address of 10.1.2.3. This will make more sense further on.
Much better would to have 'cn=huntgroup-name' and use something like ipHostNumber (from objectclass iphost) to put multiple NAS's under the same object. Your approach means that if I want to add a new NAS I have to create a new object and make sure all the 'l's match up.
OU=Roles,OU=Radius,DC=ACME,DC=COM Roles will hold Group objects of the LDAP roles that users will be put into to grant them access to the NASs
To be honest, you should have your RADIUS related role groups also along side your normal group memberships.
ldap { # The Server IP Address or DNS name, preferably run FreeRADIUS on the same server as the LDAP directory so then you can use Cleartext non-SSL connections from FreeRADIUS to the LDAP directory. Using SSL slows down the authentication slightly due to needing to setup SSL Connection for the LDAP Bind for the user.
*For the first connection only*. After the first SSL handshake, there is no additional time expense. On our EAP/TTLS-PAP setup we SSL hookup to the LDAP eDirectory service at the backend (to extract the plaintext password from 'universal password'), the *whole* authentication takes less than two seconds including that one off connection. After the initial SSL handshake, things are fast. You approach removes SSL for no benefits and now means you are sending your switch *admin* passwords around in cleartext. I personally would not do this... :)
# Need to support XLAT for HuntGroups do_xlat = yes
Another approach (although you lose the dynamicness) that can help avoid this: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg59481.h...
FILE:/etc/raddb/clients.conf Standard clients.conf where you specify the shared secret password. Since I am lazy just specify "password" for the whole 10.x.x.x network:
I think you will find we all are... :)
-----BEGIN # Below if you are coming from the CiscoRTR NAS Huntgroup, and you are a member of the "Guest" group, you get the below access. DEFAULT Huntgroup-Name == CiscoRTR, Ldap-Group == "cn=CiscoGuest,ou=Roles,ou=Radius,DC=ACME,DC=COM" Service-Type = "NAS-Prompt-User", Idle-Timeout = 600, Cisco-AVPair = "shell:priv-lvl=1" # DEFAULT Huntgroup-Name == CiscoRTR, Ldap-Group == "cn=CiscoAdmin,ou=Roles,ou=Radius,DC=ACME,DC=COM" Service-Type = "NAS-Prompt-User", Idle-Timeout = 600, Cisco-AVPair = "shell:priv-lvl=15" # DEFAULT Huntgroup-Name == Junipers, Ldap-Group == "cn=JuniperAdmin,ou=Roles,ou=Radius,DC=ACME,DC=COM" Service-Type = "Login-User", Idle-Timeout = 600, Juniper-Local-User-Name = "admin" # DEFAULT Auth-Type := Reject
As you us 'groupname_attribute' you should be able to replace 'Ldap-Group == "cn=...."' with just 'Ldap-Group == CiscoGuest'.
As you can see for each Role, or Group of NAS's you need a entry. This file will grow to cater for as many roles as you need. And to get FreeRADIUS to re-read this file you need to "kill -HUP" the radiusd.
You might want to look at amending /etc/freeradius/sites-available/dynamic-clients and make it use something sensible like LDAP rather than SQL. Cheers -- Alexander Clouter .sigmonster says: Give him an evasive answer.