Authentication Policy Not Working

1

I’ve had this policy configured for a few months now and was working fine, but suddenly it’s not and I’m not sure what happened.

When a user logs into specific IPs, an authentication policy is configured to mangle anything that is in the realm and replace it with contoso. Checking the freeradius logs, it doesn’t appear as though the mangling is occurring any longer and users are getting Err904: The user can not be found in any resolver in this realm!.

Is my pattern wrong or should something else be getting done?
image

2

Bah…I was looking at the wrong logs…though still a problem somewhere.

Looking at the PrivacyIDEA logs, I DO see the request come in and the realm properly mangled to contoso. However, a follow on policy configured to authenticate if the user doesn’t exist, isn’t working right?? I am having a problem understanding what’s going wrong here.

Here’s the policy:

image

Here’s the log auth request…I see "success": true…doesn’t that mean authentication was successful? But then why the error and failed auth?

{
	"action": "POST /validate/check",
	"action_detail": "",
	"client": "192.168.1.1",
	"client_user_agent": null,
	"duration": "5:00:00.351505",
	"info": "ERR904: The user can not be found in any resolver in this realm!",
	"policies": "Switch_Authentication_Mangle,Switch_Privilege_Access",
	"privacyidea_server": "PrivacyIDEAServer",
	"realm": "wan",
	"resolver": "",
	"serial": null,
	"startdate": "2021-09-14T17:25:34.625717",
	"success": true,
	"timestamp": "2021-09-14T22:25:34.977217",
	"token_type": null,
	"user": "$enab15$"
}
3

The policies are not evaluated like a firewall ruleset.

Every policy has its location when it is evaluated in the request. The user is checked before the mangling. I.e. if a user does not exist, mangling can not occur.
Which makes sense: The mangling policy also depends on the user. If the user object does not exist, the policy can not get evaluated.

4

So if I’m understanding you properly, to get this to work, I would have to remove the conditional user and realm checks?

5

No, privacyIDEA still tries to determine the user. To make this work you need to have an existing user to mangle the user.

6

If the username, that comes in at the RADIUS server is totally bullocks, you might want to consider modifying the username within FreeRADIUS.

1 Like
7

This is the route I’m probably going to have to go. Cisco RADIUS authentication, for some ungodly reason, sends the generic username $enab15$ when elevating the user session to allow configuration of the switch. What was originally working for me for quite some time was, when that request came in, the realm was mangled, and then I had subsequent policies setup to only apply to requests coming from that realm. Why it even worked in the first place, I’m not sure. I’m just glad it was caught before we started pointing hundreds of devices at PrivacyIDEA for radius auth in this way.

8

You could still try the RequestMangler as a pre handler - but I am currently not sure, if it will trigger, before the rest of the handling complains a bout the nonexisting user.

https://privacyidea.readthedocs.io/en/latest/eventhandler/requestmangler.html#set