I am struggling a little here to figure out realms and the best way to have policies, the documentation says the realm name should match the domain? well that isnt true, you can call your Realm anything, as I have, so why does it state this? The realm to me, is just the AUTH mechanism is it not?
The reason I ask is, I have a realm called "bob" and that used an LDAP server and chained with an additional RSA server to allow SSLVPN users, this all works fine (hence my question on the name of the realm being irrelevant)
I now need to add a Policy for WIFI users, that uses the same LDAP server but not chaining, so I create a new realm called "fred" and just untick the chaining, the policy looks for the Radius Attr of SSID and then looks up LDAP as normal, is this the right way to do it? if not? why not!
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Correct. With otherwise equal RADIUS policies (in terms of which clients they apply to), they're evaluated top-down, the first match processing the request fully to its end. (The optional filtering is done on contents of the first Access-Request; if not matched, the next policy is checked for a match)
It is not a hard requirement. The realm should simply match whatever string you're expected to receive from clients. E.g. if you're expecting to see login attempts in the format "cookies\johndoe", then the realm should be named "cookies".
The recommendation to match the real domain stems from the fact that manual and automated login attempts are typically most likely to use the actual name of the domain during logon attempts (if they specify the realm/domain at all).
And if you're not expecting to "route" attempts to specific remote auth servers based on the realm pre-/suffix at all (just using only one/default realm in each rule), the specific realm names will become completely irrelevant.
I'm not expecting anything, just a username, that's it, my realm name does not match the domain, but it works fine? so that explains that, What about using the same LDAP server, but it doesn't need chaining, create a new realm? the documentation is very poor for this product.
I have 2 Realms, and a policy for each, 1st policy looks for Radius attribute, and if its there, it uses my "fred" realm which uses LDAP Server and no chaining, the next policy for SSLVPN uses "bob" realm using same LDAP but with chaining, is this right?
Created on 04-24-2024 04:21 AM Edited on 04-24-2024 04:21 AM
If you're receiving plain usernames only, such attempts will always match the default realm (set per-RADIUS-policy).
The RADIUS chaining feature is configurable only in the realm settings, so if you want to use one LDAP for both "chained" and "non-chained" scenarios, you will necessarily need to have two realms referencing the same LDAP server/domain. (unless your FAC firmware version is new enough, has the feature to optionally apply the chaining only to selected LDAP group(s), and the group based distinction is suficient for your use-case)
This is good information, thank you, it seems my reasoning and set up will do what is required, I have put the Radius Attribute policy above the SSLVPN policy, I assume thats correct, as if the radius attr is not present, it drops down to the next policy?
Correct. With otherwise equal RADIUS policies (in terms of which clients they apply to), they're evaluated top-down, the first match processing the request fully to its end. (The optional filtering is done on contents of the first Access-Request; if not matched, the next policy is checked for a match)
Thank you for good advice, much appreciated
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.