FreeRadius DHCP against LDAP
Hello, A couple of quick questions. 1. Is DHCP functionality supported against an LDAP Server (in v2.2.0)? 2. If so, is there a planned freeradius ldap schema change (in future versions) to include DHCP-* attributes? Please advise. Thanks, Nick
On 30 Aug 2013, at 19:08, Nikolaos Milas <nmilas@noa.gr> wrote:
Hello,
A couple of quick questions.
1. Is DHCP functionality supported against an LDAP Server (in v2.2.0)?
Yes.
2. If so, is there a planned freeradius ldap schema change (in future versions) to include DHCP-* attributes?
No. But you're welcome to submit a pull request. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 31/8/2013 12:03 πμ, Arran Cudbard-Bell wrote:
1. Is DHCP functionality supported against an LDAP Server (in v2.2.0)? Yes.
2. If so, is there a planned freeradius ldap schema change (in future versions) to include DHCP-* attributes? No. But you're welcome to submit a pull request.
Thanks Arran for your answers. Sorry, I don't know really what a "pull request" is, but googling info makes me think it means I can submit a proposal for schema changes? If so, I might, after I become a bit acquainted to the DHCP FreeRadius component (and to DHCP in general). In the meantime, I've also found that I should be able to set an IP Address to a host (connecting through our Cisco 2950/2960 switches) when doing dot1x/MAB authentication (against FreeRadius), using the "Framed-IP-Address" attribute in the reply (and I've also set "radius-server attribute 8 include-in-access-req" as Cisco advises here: http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrda...). I tried it but the NAS doesn't seem to try to push to the authorized host the IP Address (-yet the host had already a static IP address). Should the host (Win Vista in this test case) specify "Obtain an IP Address automatically"? Would this functionality work without using the FreeRadius Server DHCP component? Also, assuming that the authorized (using MAB) host has already a (manually -or otherwise- preconfigured) static IP address, is there a way FreeRadius can know which that is, so it can reject the host during reauth if that IP Address is different than the one specified in the host's LDAP entry? I would appreciate some clarifications on the above. Best Regards, Nick
Nikolaos Milas wrote:
Sorry, I don't know really what a "pull request" is, but googling info makes me think it means I can submit a proposal for schema changes? If so, I might, after I become a bit acquainted to the DHCP FreeRadius component (and to DHCP in general).
A "pull request" means submitting patches via github.com.
In the meantime, I've also found that I should be able to set an IP Address to a host (connecting through our Cisco 2950/2960 switches) when doing dot1x/MAB authentication (against FreeRadius), using the "Framed-IP-Address" attribute in the reply (and I've also set "radius-server attribute 8 include-in-access-req" as Cisco advises here: http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrda...).
That's only for PPP.
I tried it but the NAS doesn't seem to try to push to the authorized host the IP Address (-yet the host had already a static IP address). Should the host (Win Vista in this test case) specify "Obtain an IP Address automatically"? Would this functionality work without using the FreeRadius Server DHCP component?
"Obtain an IP Address automatically" means "use DHCP".
Also, assuming that the authorized (using MAB) host has already a (manually -or otherwise- preconfigured) static IP address, is there a way FreeRadius can know which that is, so it can reject the host during reauth if that IP Address is different than the one specified in the host's LDAP entry?
Only if the NAS does Accounting packets which contain the Framed-IP-Address attribute. Alan DeKok.
On 31/8/2013 5:57 μμ, Nikolaos Milas wrote:
I'll look into DHCP...
Looking at the sites-available/dhcp example setup (on v2.2.0) I see that the DHCP code is not production-ready. Based on user feedback and on your involvement with next FreeRadius release(s) development, do you expect the DHCP module to be production ready in the next release? I can surely experiment now with the current "experimental" release, but it would be important to have a roadmap as to when the software will be production-ready, so as to prepare some type of deployment schedule. Thanks and regards, Nick
On 11 Sep 2013, at 14:49, Nikolaos Milas <nmilas@noa.gr> wrote:
On 31/8/2013 5:57 μμ, Nikolaos Milas wrote:
I'll look into DHCP...
Looking at the sites-available/dhcp example setup (on v2.2.0) I see that the DHCP code is not production-ready.
Based on user feedback and on your involvement with next FreeRadius release(s) development, do you expect the DHCP module to be production ready in the next release?
I can surely experiment now with the current "experimental" release, but it would be important to have a roadmap as to when the software will be production-ready, so as to prepare some type of deployment schedule.
Define production-ready... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 11/9/2013 5:05 μμ, Arran Cudbard-Bell wrote:
Define production-ready...
Production-ready DHCP Server: A DHCP Server that can be used as such in a real-life, mission-critical, organizational environment, i.e. in a network where clients (hosts) will only get an IP address if and only if the DHCP Server behaves as expected. I was referring to the: # !!!! WARNING !!!! # # This code is experimental, and SHOULD NOT be used in a # production system. It is intended for validation and # experimentation ONLY." My understanding is that the term "production system" implies the definition above. Does the reference to "code" apply to the configuration file only (sites-available/dhcp) or to the DHCP FreeRadius module (as I have probably misunderstood)? Please, clarify. Thanks, Nick
On 11 Sep 2013, at 15:37, Nikolaos Milas <nmilas@noa.gr> wrote:
On 11/9/2013 5:05 μμ, Arran Cudbard-Bell wrote:
Define production-ready...
Production-ready DHCP Server: A DHCP Server that can be used as such in a real-life, mission-critical, organizational environment, i.e. in a network where clients (hosts) will only get an IP address if and only if the DHCP Server behaves as expected.
That you will need to verify yourself.
I was referring to the:
# !!!! WARNING !!!! # # This code is experimental, and SHOULD NOT be used in a # production system. It is intended for validation and # experimentation ONLY."
My understanding is that the term "production system" implies the definition above.
Does the reference to "code" apply to the configuration file only (sites-available/dhcp) or to the DHCP FreeRadius module (as I have probably misunderstood)?
The code is in use on a number of 'production' systems. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Nikolaos Milas wrote:
My understanding is that the term "production system" implies the definition above.
It's just a warning. If it works for you, it works.
Does the reference to "code" apply to the configuration file only (sites-available/dhcp) or to the DHCP FreeRadius module (as I have probably misunderstood)?
"code" means "code", not "configuration files" Alan DeKok.
On 31 Aug 2013, at 13:49, Nikolaos Milas <nmilas@noa.gr> wrote:
On 31/8/2013 12:03 πμ, Arran Cudbard-Bell wrote:
1. Is DHCP functionality supported against an LDAP Server (in v2.2.0)? Yes.
2. If so, is there a planned freeradius ldap schema change (in future versions) to include DHCP-* attributes? No. But you're welcome to submit a pull request.
Thanks Arran for your answers.
Sorry, I don't know really what a "pull request" is, but googling info makes me think it means I can submit a proposal for schema changes?
Yes.
If so, I might, after I become a bit acquainted to the DHCP FreeRadius component (and to DHCP in general).
OK.
In the meantime, I've also found that I should be able to set an IP Address to a host (connecting through our Cisco 2950/2960 switches) when doing dot1x/MAB authentication (against FreeRadius), using the "Framed-IP-Address" attribute in the reply (and I've also set "radius-server attribute 8 include-in-access-req" as Cisco advises here: http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrda...).
No.
I tried it but the NAS doesn't seem to try to push to the authorized host the IP Address (-yet the host had already a static IP address). Should the host (Win Vista in this test case) specify "Obtain an IP Address automatically"? Would this functionality work without using the FreeRadius Server DHCP component?
No. It's for things like PPP tunnels not for 802.1X and Mac-Auth authentication.
Also, assuming that the authorized (using MAB) host has already a (manually -or otherwise- preconfigured) static IP address, is there a way FreeRadius can know which that is, so it can reject the host during reauth if that IP Address is different than the one specified in the host's LDAP entry?
No. With Wired/Wireless 802.1X/Mac-Auth authentication is performed first. Before authentication occurs all traffic (other than EAPOL frames, and wireless management frames) are blocked by the NAS. Once authentication completes the client uses DHCP to acquire an IP address. Some NAS may offer a feature to inspect the SRC IP address of incoming frames after authentication completes. It may then include that value in Accounting data which is sent after authentication completes. The RADIUS server could then in theory use a PoD (RADIUS packet of disconnect) or SNMP to disconnect the client from the NAS if it determined it was using the incorrect IP address when it received one of those accounting packets. FreeRADIUS itself does not offer any user triggable events For this it's sometimes better to use a quarantine VLAN and change that using SNMP, CoA, the Session-Timeout attribute, or PoD, once you're sure the client has the right IP. There is no out of the box solution for this. But FreeRADIUS does provide all the functionality you need. You just need to tie it all together. The solution you choose depends on your clients, your NAS, and the strictness of your policies. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 31/8/2013 12:03 πμ, Arran Cudbard-Bell wrote:
1. Is DHCP functionality supported against an LDAP Server (in v2.2.0)?
Yes.
I am having a hard time trying to adapt the example at: http://wiki.freeradius.org/guide/dhcp-for-static-ip-allocation to work from ldap. We are starting from a point where we have an (LDAP) DIT branch ou=hosts,dc=example,dc=com, where hosts are stored (also used for MAC-Auth), using entries of the form: dn: cn=host1.tech,ou=hosts,dc=example,dc=com cn: host1.tech objectClass: device objectClass: ieee802Device objectClass: top objectClass: radiusprofile objectClass: simpleSecurityObject description: Main Workstation at Tech Dpt ou: tech l: Sierra Nevada userPassword: test123 owner: cn=TechAdmins,ou=Groups,dc=example,dc=com radiusTunnelMediumType: IEEE-802 radiusTunnelType: VLAN radiusNASIpAddress: 10.10.10.125 radiusTunnelPrivateGroupId: 1 macAddress: 00:24:8b:3a:d1:db radiusTerminationAction: 33 radiusHint: 50004 radiusFramedIPAddress: 10.10.10.63 radiusArapSecurity: 10.10.10.1 radiusArapZoneAccess: 255.255.255.128 We are attempting to assign the host (using DHCP) with the macAdress stored at macAddress attribute: - the IP Address defined at radiusFramedIPAddress - the gateway defined at radiusArapSecurity - the mask defined at radiusArapZoneAccess Can we use ldap calls (as when doing auth), in modules/ldap, like: ldap ldap_dhcp { server = "localhost" identity = "uid=auth,ou=AdminAccounts,dc=example,dc=com" password = "mysecret" basedn = "ou=hosts,dc=example,dc=com" filter = "(macAddress=%{DHCP-Client-Hardware-Address})" start_tls = no dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 2 timeout = 4 timelimit = 3 net_timeout = 1 } ...having added in ldap.attr the following (using current unused freeradius schema attributes): replyItem DHCP-Subnet-Mask radiusArapZoneAccess replyItem DHCP-Router-Address radiusArapSecurity replyItem DHCP-Your-IP-Address radiusFramedIPAddress and then modify the example as follows: server dhcp { listen { type = dhcp ipaddr = 127.0.0.1 port = 67 interface = eth0 broadcast = no } dhcp DHCP-Discover { ldap_dhcp update reply { DHCP-Message-Type = DHCP-Offer } update reply { DHCP-Domain-Name-Server := 10.10.10.90 DHCP-Domain-Name-Server := 10.10.10.91 } ok } dhcp DHCP-Request { update reply { DHCP-Message-Type = DHCP-Ack } ldap_dhcp update reply { DHCP-Domain-Name-Server := 10.10.10.90 DHCP-Domain-Name-Server := 10.10.10.91 } ok } dhcp { reject } } ...?? Is it correct as above? Do I have to call ldap_dhcp separately in each section (i.e. twice)? Please clarify! Regards, Nick
Is it correct as above? Do I have to call ldap_dhcp separately in each section (i.e. twice)?
Hopefully someone else will chime in who's actually used it, but this is what I believe the order of operations should be: * Receive DHCP-Discover - Call LDAP to get the IP assignment for the Mac-Address. - Augment the reply list with additional options - Cache the reply attributes you're about to send (see rlm_cache), you probably want to key it on the same attributes as your LDAP search - Set DHCP-Message-Type * Receive DHCP-Request - Pull reply list out of cache - Compare requested IP with that in reply list IP if != IP requested trash the reply list and DHCP-Message-Type := NAK - If request IP == reply IP, DHCP-Message-Type := ACK That way you only have one hit on your LDAP server, and you guarantee consistency across Offer and Request. You can also do it the way you have in your example server (it has the advantage that it'll work behind load balancers, or multiple gateways pointing at different servers), but you should check the IP from LDAP is the same as the one requested, and NAK if appropriate. If you do it the way I suggested I highly recommend you use V3.0.0 (release_branch_3.0.0 or master/HEAD) instead, as the list/attribute handling is much better. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 13/9/2013 8:40 μμ, Arran Cudbard-Bell wrote:
If you do it the way I suggested I highly recommend you use V3.0.0 (release_branch_3.0.0 or master/HEAD) instead, as the list/attribute handling is much better.
Thanks, I'll look into rlm_cache. I wonder if anyone in this list has created a v3.0.0 spec file for RHEL/CentOS 6 rpm builds (or is one included in the source tree)? (I prefer doing installs using RPM files because it helps me a lot in keeping the server -even a test box- tidy.) If not, I might try adapting the v2.2.0 spec file (though I am not an expert on it). Where can I find the v3.0.0 source branch? By the way, is there an expected date for v3.0.0 release? Nick
On 13/9/2013 9:35 μμ, Nikolaos Milas wrote:
Where can I find the v3.0.0 source branch?
Oh, I found it and it includes a spec file for redhat: https://github.com/FreeRADIUS/freeradius-server/tree/release_branch_3.0.0/re... Is the spec file in a well-working condition? (I might test, but knowing beforehand helps things. :-) ) Thanks, Nick
On 13 Sep 2013, at 19:47, Nikolaos Milas <nmilas@noa.gr> wrote:
On 13/9/2013 9:35 μμ, Nikolaos Milas wrote:
Where can I find the v3.0.0 source branch?
Oh, I found it and it includes a spec file for redhat: https://github.com/FreeRADIUS/freeradius-server/tree/release_branch_3.0.0/re...
Is the spec file in a well-working condition? (I might test, but knowing beforehand helps things. :-) )
It is, yes. V3.0.0 was slated for release this week, but were waiting on feedback from one of the testers for a potentially critical bug in proxying code. It would be good to try the DHCP code out with 3.0.0. IIRC the logic hasn't changed significantly, but the change of memory allocator has touched many areas of the code including DHCP. If you're going to try out 3.0.0 then i'd use the release branch, and i'd do it now instead of waiting for the official release. There'll be very few code changes between the release branch and the final released version. The advantage of testing now is that bugs (if there are any) get fixed now, so you can deploy and official version which works for you on your production servers, instead of waiting a couple of months for the next official release. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Nikolaos Milas