vlan ldap radiusd

Serge van Namen svnamen at snow.nl
Fri Jul 15 10:09:09 CEST 2011


Op 14 jul 2011, om 21:30 heeft Alexander Clouter het volgende geschreven:

> Serge van Namen <svnamen at snow.nl> wrote:
>> 
>> I'm working on a proof-of-concept for 802.1x and dynamic vlan's on 
>> switches.
>> 
>> All this works perfectly with user at realm, but now I want to read the 
>> vlan ID from a ldap attribute and then send the radius request with 
>> that value in "Tunnel-Private-Group-ID".
>> 
> Reading an attribute for this is argubly silly in the context of LDAP. 
> Better to test for a group membership otherwise you might aswell shovel 
> everything in a relational database like SQL.

In our situation the user is bound to a VLAN, so on every workstation in the building the user authenticates and the switchport
becomes a member of the correct VLAN.

Correct me if I'm wrong but then we have to administer a separate database for hosts ( and in our case users )
Now we have 2 auth-types en autz-type's.

1 connects with cn=x,dc=example,dc=com (VLANid x)
1 connects with cn=y,dc=example,dc=com (VLANid y)

Depending on the realm the user indicates when logging in (user at realm), autheticates and puts the "Tunnel-Private-Group-Id" in the reply with the correct VLAN id.

The problem: When using 'Login Window' based 802.1x.
So when user puts in it's user/pass at the login window, it does it's 802.1x magic.

But with user at realm, LDAP doesnt understands this ofcourse, so the @realm needs to be stripped when authenicating to LDAP.

So:

user at realm ---> radius reads the realm, strips the @realm so LDAP understands, makes it's auth/autz-type.

I hope you catch my drift. :)

> 
> For us we create host LDAP objects, and then those objects are members 
> of a LDAP group which has details regarding the VLAN in it (and 
> subnetting, etc etc).
> 
> I am slowly cobbling bits together on my website[1].  My post-auth looks 
> like:
> ----
> post-auth {
>                ....
> 
>                # defaults
>                update reply {
>                        Tunnel-Type := VLAN
>                        Tunnel-Medium-Type := IEEE-802
>                        Tunnel-Private-Group-Id := "unauthorised"
> 
>                        Termination-Action := RADIUS-Request
>                        Session-Timeout := 300
> 
>                        Acct-Interim-Interval := 3600
>                }
> 
>                if ((EAP-Message) && !(Ldap-UserDn)) {
>                        cache_ldap-userdn
>                }
> 
>                lanwarden_vlan
>                if (!(control:Tunnel-Private-Group-Id) || control:Tunnel-Private-Group-Id == "") {
>                        if (Realm == "DEFAULT") {
>                                update reply {
>                                        Tunnel-Private-Group-Id := "eduroam"
>                                }
>                        }
>                        # to be removed once we register personal workstations
>                        elsif (Realm == "%{config:local.MY.realm}") {
>                                update reply {
>                                        Tunnel-Private-Group-Id := "users-unmanaged"
>                                }
>                        }
>                }
>                else {
>                        update reply {
>                                Tunnel-Private-Group-Id := "%{control:Tunnel-Private-Group-Id}"
>                        }
>                }
>                if (reply:Tunnel-Private-Group-Id != "unauthorised") {
>                        update reply {
>                                # Cisco only support a max of 65535
>                                Session-Timeout := 64800
>                        }
>                }
> 
>                ....
> }
> ----
> 
> 'cache_ldap-userdn' you can find in the archives and the reasoning for 
> it, meanwhile lanwarden_vlan lurks in policy.conf and looks like:
> ----
> lanwarden_vlan {
>        if ((control:Ldap-UserDn)) {
>                if ("%{md5:%{client:secret}%{Calling-Station-Id}%l}" =~ /[0-7]$/) {
>                        update control {
>                                Tunnel-Private-Group-Id := "%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>                        }
>                        if (control:Tunnel-Private-Group-Id == "") {
>                                update control {
>                                        Tunnel-Private-Group-Id := "%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>                                }
>                        }
>                }
>                else {
>                        update control {
>                                Tunnel-Private-Group-Id := "%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>                        }
>                        if (control:Tunnel-Private-Group-Id == "") {
>                                update control {
>                                        Tunnel-Private-Group-Id := "%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}"
>                                }
>                        }
>                }
>        }
> }
> ----
> 
> It looks horrible as xlat does *not* support failover. :(
> 
> Cheers
> 
> [1] http://www.digriz.org.uk/lanwarden
> 
> -- 
> Alexander Clouter
> .sigmonster says: You are so boring that when I see you my feet go to sleep.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html





More information about the Freeradius-Users mailing list