Different Radius-Clients <--> Different Realms: Instance-/Realm-Mapping?

Question
1

Hello Community,
I’ve got a specific already-built IT-infrastructure, which should be migrated to privacyIDEA. I just wonder, whether my solution fits or privacyIDEA comes along with another possibility, I just did not find yet.
Scenario:

Two different User-Stores:

  • LDAP-1; userid: a123456.
  • LDAP-2; userid: di123456)

Two different Realms with different authentication-policies:

  • Auth1: User from LDAP-1 have otppin: none.
  • Auth2: User from LDAP-2 have otppin: userstore.
    Auth2-realm is set to standard in PrivacyIdea.

Two different Radius-Clients:

  • ASA-Firewall for user from Auth1 and
  • Checkpoint-Firewall for user from Auth2.

Unfortunately the user login via a123456 instead of a123456@Auth1.

So how can I separate the user with their realms on the freeradius-layer, so that they get forwarded correctly?
Remember: a123456 accesses ASA and just has to enter otp-value, whereas di123456 accesses Checkpoint with ad-pw+otpvalue.

My solution so far (tests seems to be working correctly) is to adapt a few lines in authorize-section in /freeradius/sites-enabled/privacyidea:

if(Packet-Src-IP-Address == 172.xx.xx.xx ) {
                update request{
                        Realm := "Auth1"
                }
        }

So every User accessing through ASA (a123456) gets the specific freeradius-realm, which fits the specific privacyidea-realm “Auth1”. User, which do not “come” from this IP, gets forwarded to the standard-privacyidea-realm “Auth2”.
Till now LinOTP was used and allowed the admins to map (via UI) Radius-Clients to instances and instances to certain LinOTP-Realms.
So picking up my initial question: Is there another way achieving this goal more elegantly?

Kind regards
Axel

2

Hi Axel,

first of all: The LinOTP appliance UI simply generates default FreeRADIUS config files from templates. So you can easily run the very same configuration with privacyIDEA, except you would need to modify the freeradius config files manually. I think these are e.g. the proxy.conf and another one.

But there might also be several another solutions. I try one:

Is the username of all users, who are located in the realm Auth1 starting with an “a”?
And are all users in realm Auth2 (which is the default realm) starting with a “di”?

One solution would be fairly simple: You could use the mangle policy. Configure an action:

user/^a(.*)/a\\1@auth1/

This would result in, that each user, who tries to authenticate and whose username starts with an “a” would be automatically put into realm “auth1”.

There are other ways to use a “setrealm” policy. And also solutions in FreeRADIUS. Without a decent consulting I can not tell, what would actually be the best one for you.
(I pointed out this one, because it contains the awesome mangle-policy! :wink: )

Kind regards
Cornelius

3

Well, you can do this directly in privacyIDEA:
https://privacyidea.readthedocs.io/en/latest/policies/authorization.html#setrealm

This software is totally awesome - isn’t it! \o/

1 Like
4

Hello Cornelius,
unfortunately it can not be assumed, that every user from Auth1 has an id starting with a123456. A few of them might be di123456 (HR and IT might need a bit more synergy) Nevertheless: The solution with the authorization-policy totally fits my needs. A great way to get rid off the troublesome freeradius-configuration for this “problem”…Thank you for your help!
My company will contact you soon :wink:

Kind regards
Axel

1 Like
5

Hello Cornelius,

unfortunately I have to “reopen” this issue since the problem could not be solved by the setrealm-policy (@TaylorAtTempus seemed to have the same problem in his question https://community.privacyidea.org/t/problem-using-setrealm)
User a522126 is not in the default realm (he is in the sag-realm) and has to get the sag-Realm for authentication. Therefore I tested the recommended solution:
Authorization: setrealm=sag; for all user, where realm=sag.
Unfortunately I cannot make use of the mangle-policy, because it cannot be guaranteed that every user from sag-realm has an id starting with “a”.

Anyhow my radius-log:
Reply-Message = "ERR905: The user can not be found in any resolver in this realm!"

privacyidea-log:

 [ERROR][privacyidea.lib.auditmodules.sqlaudit:241] DATA: {'info': u'ERR905: The user can not be found in any resolver in this realm!', 'realm': u'dh', 'success': False, 'privacyidea_serve$
    $_server': 'localhost', 'client_user_agent': None, 'client': '::1', 'user': u'a522126', 'resolver': '', 'action_detail': '', 'action': 'POST /validate/check'}

I would really prefer an elegant policy-solution over hard-changes in freeradius.conf-files, like I did before (and what actually worked)…
Let me know if you need additional information.

Kind regards

Axel Czuck

6

Please understand, that I can not invest to much time into this, here.
Reading the other post it looks like this:

The setrealm only works, if there is a matching user. So you need to have a matching user.
One way would be to create a realm that contains all users. It they come from IP A setrealm them into Realm A, if they come from IP B setrealm them to Realm B.

7

No problem. Thank you anyway.
This thread may help other user, which may get affected by this specific problem, so they can pick one fitting solution.

8

Hi Alex,

this is so nagging. :-/
So I looked into it, why setrealm would behave this way and I found the reason.

So this will change in future, but not right away.
Thanks for asking and pointing to this.

Kind regards
Cornelius

1 Like
9

Until version 3.0 is released with the setrealm fix, here are couple of possible solutions.
Multiple mangle policies for each username “class” (a gets a policy, di gets a policy, etc.)

user/^a(.*)/a\\1@auth1/
user/^di(.*)/a\\1@auth1/

Another possibility (and I use this one) is to create an authorization policy that performs the mangle command for all users, but is limited to specific source IPs.
The command I used was:

user/(.*)/\1@new_realm/

I then limited this policy to IPs starting with 172 (by specifying a client of 172.0.0.0/8).
This effectively placed all users from those IP addresses into the new realm.

2 Likes
10

I think if all users from one Realm come from the ASA and all users from the other Realm come from the Checkpoint, the second approach is the straightforward one: Mangle the realms according to the client IP!

Policy A:

scope=authz
action=user/(.*)/\1@realmA/
client=ASA-IP

Policy B:

scope=authz
action=user/(.*)/\1@realmB/
client=checkpoint-IP

thanks @TaylorAtTempus

1 Like