Allowing Access via 'users' when LDAP fails

[Amaru Netapshaak]

________________________________
From: Fajar A. Nugraha <fajar at fajar.net>
To: FreeRadius users mailing list <freeradius-users at 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 at 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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100201/9b80f117/attachment.html>