Sorry for the late reply, if you wantmore details, do contact me offline. Christ Schlacta <lists@aarcane.org> wrote:
I've done a little independent research, and I think I can use a definition for a host as a "device" with a cn, and an "ieee802Device" with a mac address. I can create a group of unique names, or is there some other mechanism I have to use for groups to work with freeradius? will this scheme work with freeradius? is there some better, more established standard to store this mapping of hostname from certificate to mac address?
I started off down that route, then noticed rolling dNSZone[1] and dhcpService[2] would make things a lot nicer for us. I created my own objectClass (it only took a week for us to register[3] for our own enterprise number) and borged other handy objectClass's and hocked together something I call LanWarden. Our LDAP objects look like: ---- cn=001122334455,ou=soas-reg,ou=Hosts,ou=LanWarden,o=soas lanwardenHostState: enable lanwardenHostNotes: 20100614081331Z - general - registered via LWadd lanwardenHostRegisteredTC: SOAS lanwardenHostRegisteredTC: JANET lanwardenHostRegisteredTime: 20100614081331Z lanwardenHostRegisteredBy: cn=ac56,ou=Staff,ou=Active,ou=Accounts,o=soas dhcpHWAddress: ethernet 00:11:22:33:44:55 lanwardenHostAuthenticateMethod: mac <----- PERMIT MAC-AUTH serialNumber: 1234 owner: cn=Helpdesk,ou=Staff,ou=Active,ou=Accounts,o=soas o: soas.ac.uk objectClass: Top objectClass: dhcpHost objectClass: Device objectClass: lanwardenHost cn: 001122334455 cn=users-staff,ou=Networks,ou=LanWarden,o=soas o: soas ou: 76 objectClass: Top objectClass: dhcpService objectClass: lanwardenNetwork member: cn=001122334455,ou=soas-reg,ou=Hosts,ou=LanWarden,o=soas member: ... cn: users-staff <----- VLAN ID ----
and last, but not least, what do I have to do to make sure that an absence of mac address doesn't trigger a failure, but the presence of a wrong mac address does?
I default to a particular 'quarantine' VLAN and have a group membership lookup amend the VLAN to it's final resting place. If there is no group match (as the user does not exist), they stay in the 'unauthorised' VLAN. ---- post-auth { ... # defaults update reply { Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 Tunnel-Private-Group-Id := "unauthorised" Termination-Action := RADIUS-Request # Cisco only support a max of 65535 Session-Timeout := 64800 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" } } } elsif (!ok) { update reply { Reply-Message := "LW: failed lanwardenNetwork" } reject } # here 'Tunnel-Private-Group-Id' is possibly different # from it's default ... } ---- Unfortunately there is a lot of complexity in the policy.conf defined 'lanwarden_vlan' and the unlang bit trailing it as FreeRADIUS does not support xlat with virtual failover modules. Cheers [1] http://bind9-ldap.bayour.com/ [2] https://github.com/dcantrell/ldap-for-dhcp/wiki [3] http://pen.iana.org/pen/PenApplication.page -- Alexander Clouter .sigmonster says: Default, n.: The hardware's, of course.