On Sun, Jan 31, 2010 at 10:16 PM, Amaru Netapshaak <postfix_amaru@yahoo.com> wrote:

I need a port to come up IMMEDIATELY on the restricted-vlan, providing my clients with a DHCP-assigned address, and then once they log in, their appropriate VLAN info is found in LDAP via FreeRADIUS and then the switch assigns that port to the right vlan.  I have everything working, except a way to bring the port up on a vlan immediately and still have it dynamically controlled via dot1x.

If I can get FreeRADIUS to return an Access-Accept and a generic VLAN attribute (with a vlan ID that matches my restriced vlan), then  everything should work out.  I hope!

I still think that's a bad idea :P Consider scenario (1): Your user does not know that 802.1x is needed, and just plug in the cable. What would you like to happen? radius will not be involved here (since there are no EAPOL from the client). At this point the "correct" method to get what you want is by setting the switch in a way that it will assign guest VLAN immediately. Consider scenario (2): Your user knows that 802.1x is needed, but enters non-existent/incorrect user/password. What would you like to happen? If it were me, I'd prefer to let the user KNOW something was wrong, in the form that he can't connect at all. That would give him the option to either enter the correct user/password, or disable 802.1x (in which case back to scenario #1). Anyway, if you still need "accept all", Alan's example should work. Put something like this on authorize section ldap if (notfound) { update control { Auth-Type = Accept } update reply { Tunnel-Private-Group-ID = 10 } } that way if the user is NOT in ldap, it will simply return Access-Accept with attribute Tunnel-Private-Group-ID = 10 (you can add other required reply attributes there as well). Now you'll still need to handle user with incorrect password, and I haven't had the time to try it yet :P. You could probably use similar setting in authenticate section. -- Fajar

________________________________ From: Alan Buxey <A.L.M.Buxey@lboro.ac.uk> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Sun, January 31, 2010 12:16:17 PM Subject: Re: Allowing Access via 'users' when LDAP fails Hi, what switches? with Cisco you can use various fallthroughs - and you can ensure that even the non 802.1X clients are catered for.... MAB will allow you to send request to RADIUS server and then its your policy that matters.. eg eg any MAC address, returns an ACCEPT but with a VLAN attribute. the switch then puts the client on the correct, limited network.... or you can use guest-vlan or fail vlan methods on the switch too... ..are you going via the route of 'if not known, then get a network that send them to a web portal with intructions, install program etc' - or are you dealing with these people individually? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html --------------------------------------------------------------------------------------------------------------------------------- Alan, I'm using Cisco 3560G switches. If a client currently doesnt send EAPOL packets to the switch, the 'guest vlan' works perfectly. However, my clients ARE dot1x capable, and DO send EAPOL packets to the switch and that makes the switchport stay unavailable for too long while the switch attempts to reauthenticate the client (takes about 65 seconds), by which time the end users client didnt get an IP address and they cannot login to the AD. I just want a port to come up immediately on a guest/restricted type VLAN, allow the client to receive an IP address via DHCP, allow them to authenticate against the AD, and then be placed into the correct vlan (and have DHCP get a new IP address natrually) The cisco guest-vlan or restricted-vlan or fallback vlan or whatever it is, works.. it just takes too dang long! My end users arent going to just sit at their desktops for two or three minutes staring at the logon window before attempting a login. Can you share with me a sample configuration of how I can accomplish this in IOS? I swear I've been toying with various configuration settings for days now. Thanks! AMARU

________________________________ From: Alan Buxey <A.L.M.Buxey@lboro.ac.uk> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Mon, February 1, 2010 9:51:42 AM Subject: Re: Allowing Access via 'users' when LDAP fails Hi,

I'm using Cisco 3560G switches. If a client currently doesnt send EAPOL packets to the switch, the 'guest vlan' works perfectly.

However, my clients ARE dot1x capable, and DO send EAPOL packets to the switch and that makes the switchport stay unavailable for too long while the switch attempts to reauthenticate the client (takes about 65 seconds), by which time the end users client didnt get an IP address and they cannot login to the AD.

adjust the switch timers then - the default timers will cause the effect you have outlines...too long to fail-through

I just want a port to come up immediately on a guest/restricted type VLAN, allow the client to receive an IP address via DHCP, allow them to authenticate against the AD, and then be placed into the correct vlan (and have DHCP get a new IP address natrually)

how will then authenticate against the AD after they are on this restricted network? captive portal box? the supplicant wont do anything after the first stage you might want to read this guide" http://www.cisco.com/univercd/cc/td/doc/solution/macauthb.pdf this gives more info on timers/timeouts for each part.... simply reduce a few timers like max-req and tx-period and you'll get guest-vlan fall-through within a few seconds alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Alan, Thanks for your quick reply! The plan was to have the guest/restricted VLAN have permissions enough to allow the client to authenticate against my AD, and then be assigned to the appropriate vlan, where full 'network rights' would be granted. I will check out that document right now.. sounds perfect. Thanks! +AMARU

________________________________ From: Fajar A. Nugraha <fajar@fajar.net> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Sun, January 31, 2010 11:43:20 AM Subject: Re: Allowing Access via 'users' when LDAP fails On Sun, Jan 31, 2010 at 10:16 PM, Amaru Netapshaak <postfix_amaru@yahoo.com> wrote:

I need a port to come up IMMEDIATELY on the restricted-vlan, providing my clients with a DHCP-assigned address, and then once they log in, their appropriate VLAN info is found in LDAP via FreeRADIUS and then the switch assigns that port to the right vlan. I have everything working, except a way to bring the port up on a vlan immediately and still have it dynamically controlled via dot1x.

If I can get FreeRADIUS to return an Access-Accept and a generic VLAN attribute (with a vlan ID that matches my restriced vlan), then everything should work out. I hope!

I still think that's a bad idea :P Consider scenario (1): Your user does not know that 802.1x is needed, and just plug in the cable. What would you like to happen? radius will not be involved here (since there are no EAPOL from the client). At this point the "correct" method to get what you want is by setting the switch in a way that it will assign guest VLAN immediately. Consider scenario (2): Your user knows that 802.1x is needed, but enters non-existent/incorrect user/password. What would you like to happen? If it were me, I'd prefer to let the user KNOW something was wrong, in the form that he can't connect at all. That would give him the option to either enter the correct user/password, or disable 802.1x (in which case back to scenario #1). Anyway, if you still need "accept all", Alan's example should work. Put something like this on authorize section ldap if (notfound) { update control { Auth-Type = Accept } update reply { Tunnel-Private-Group-ID = 10 } } that way if the user is NOT in ldap, it will simply return Access-Accept with attribute Tunnel-Private-Group-ID = 10 (you can add other required reply attributes there as well). Now you'll still need to handle user with incorrect password, and I haven't had the time to try it yet :P. You could probably use similar setting in authenticate section. -- Fajar Fajar, Again, thanks for your response! Scenario 1: this is already happening and works fine. When the switch detects activity on the port but receives no EAPOL packets, it puts the port onto a guest-vlan and that works great. Scenario 2: And thats all fine with me. The user would 'know' that something was wrong on my network as the AD authentication would still fail, and barring that, they'd still be on a guest-vlan with almost no access to anything. Perfect! I tried your suggestion, still returns REJECT. I'm going to tinker around with it some more.. another poster is correct, the best place to solve this problem is in my switch, instead of trying to break RADIUS :). I'll get there. Thanks for all your help! AMARU - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html