MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5

Krause, Kilian krause at tik.uni-stuttgart.de
Mon Mar 2 17:00:19 CET 2015


Hi Alan,

> > I've already implemented a reset of the outer User-Name reply in post-
> auth to the one received in the outer tunnel request. Somewhat that feels
> a bit counter intuitive but it was the logical consequence of the howto
> telling me I'd need use_tunneled_reply for CUI to work at all. I'd love to
> not use use_tunneled_reply, but so far my tests failed to update the outer
> reply with the value from the inner tunnel directly. So, how would I be
> leaking just this info about the "real" user-Name from the inner tunnel
> alone without use_tunneled_reply?
> 
> you can choose which items to copy from the inner to outer rather than
> just copying the
> whole lot (update the outer section in unlang)

I'm trying with the example in sites-available/inner-tunnel and using the update outer.reply. Yet I can see the update happening in the second last request correctly, yet the last requests hits the default (outer) tunnel only and lacks the updated Chargeable-User-Identity attribute again. 

Is there a good example of how to (successfully) update outer reply attributes from the inner tunnel you could point me to? We've followed https://community.ja.net/library/janet-services-documentation/chargeable-user-identity-eduroam-freeradius-implementation which sounded like a pretty straight forward walkthrough.

 
> > So do you reckon it's either CUI or MACSEC working? Can
> use_tunneled_reply be updated dynamically based upon NAS-Port-Type?
> 
> you could proxy to a different virtual-server based on the NAS-Port-
> Type...which could then
> have different configs

Of course. But duplicating the eap module only for something that should be much easier to achieve seems quite a bit of overkill.


> > I'm also still trying to understand what breaks PEAP-MSCHAPv2 when
> pulling authentication from AD rather than using local accounts on the FR
> (the latter works just fine with MACSEC).
> 
> because you are using LDAP to talk to AD and therefore you dont get the
> plain password
> as required?   use ntlm_auth with the system bound to the AD

I'm only using LDAP to verify the msNPAllowDialin attribute. Not the password. So the authentication is already using ntlm_auth. Once I'll have the CUI working, I can put together a full debug log.

Thanks.

Best regards,
Kilian




More information about the Freeradius-Users mailing list