On Jun 6, 2024, at 9:31 PM, Jon Gerdes <gerdesj@blueloop.net> wrote:
I am trying to get a MFA setup working with an initial LDAP direct bind against Microsoft AD (MAD) and then a second pass with the same username and a OTP. I can get both the LDAP and OTP working fine individually.
That's good.
I am using the wiki Howto: https://wiki.freeradius.org/guide/2FA-Active-Directory-plus-Proxy as a model. This howto uses "State" to determine which Auth-Type it is at in the process. At the end of the howto there is a section that describes filtering out the State attribute for Pre-Proxy and I think this is where I am getting things wrong.
If you're not proxying, then you don't need to do anything in the pre-proxy section.
I'm not sure what "State" is. I am unable to find docs about it but it is the only input difference I can see when running "freeradius -fX" so I think I need to filter it out. I'm not sure why I should filter it out either!
The State attribute is defined in RFC 2865. It's just a magic cookie which the server uses to track a multi-packet authentication session. i.e. if step one is "get password", and step two is "get OTP", then the server uses State in the reply to step (1) in order to know that it's at step (2).
If attr_filter is what I should do to get this to work, I'd be grateful for some help. I've also deviated from the howto example by trying to decompose "challenge" into what it actually does:
update control { Response-Packet-Type := Access-Challenge {
That should be OK.
With the site-enabled config below, the debug logs show that the initial user/pass against LDAP works fine and State gets set to a 16 random char. Then it tries to do a second pass and I can see the username and password (which is now the PIN for the OTP) passed through and so is the "State" that got set by stage one. This second pass fails
What does that mean? "fails" is so generic as to be useless for debugging.
and when I compare the logs against just the OTP method that works, "State" is the only additional input.
Don't compare the logs. *Understand* them.
server active-directory {
http://wiki.freeradius.org/list-help Which says (a) post the debug output, and (b) don't post configs. Please read the documentation and follow it. We ask for the debug logs because they tell us what the server is actually doing. The configuration tells us what you told the server to do. But the configuration files do *not* include packets received by the server. So they're missing a critical piece which is required to debug the problem. Alan DeKok.