Verify certificate <-> mac mapping in openldap..

Alexander Clouter alex at
Tue Jan 11 11:41:12 CET 2011

Sorry for the late reply, if you wantmore details, do contact me 

Christ Schlacta <lists at> 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:
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
objectClass: Top
objectClass: dhcpHost
objectClass: Device
objectClass: lanwardenHost
cn: 001122334455

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' 
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)) {

                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"

		# 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.



Alexander Clouter
.sigmonster says: Default, n.:
                  	The hardware's, of course.

More information about the Freeradius-Users mailing list