Differences

This shows you the differences between two versions of the page.

--- siteadmin:freeradius_operator-name_setting [2020/11/20 12:03] – admin
+++ siteadmin:freeradius_operator-name_setting [2025/03/11 15:39] (current) – admin
@@ Line 2: / Line 2: @@
 =====Basic O-N setting=====
+This configuration simply updates the Operator-Name value in the request packets and is appropriate for Individual Organisations (not RFOs):
 <code>
@@ Line 16: / Line 18: @@
 =====RFO O-N Setting=====
-As an RFO you're in a position to rewrite the Operator-Name in the outer RADIUS tunnel. This can be useful if your connected sites aren't setting it themselves, or are setting it wrongly. Ideally each site should it appropriately because some sites might have multiple O-Ns in use and are in the best position to set them accurately. However, some RADIUS servers (NPS in particular) can't set O-N.
+As an RFO you're in a position to rewrite the Operator-Name in the outer RADIUS tunnel. This can be useful if your connected sites aren't setting it themselves, or are setting it wrongly. Ideally each site should set it appropriately because some sites might have multiple O-Ns in use and are in the best position to set them accurately. However, some RADIUS servers (NPS in particular) can't set O-N.
-Best case is that all sites everywhere set the correct O-N and it's proxied untouched to Jisc. This requires that all connect sites run appropriate software which is configured correctly.
+Best case is that all sites everywhere set the correct O-N and it's proxied untouched to Jisc. This requires that all connected sites run appropriate software which is configured correctly.
 Second best case is that the RFO sets the missing O-N for sites as the packets are proxied through them.
-Next best case is that the RFO sets a single O-N for all packets proxied. (see above section on Basic O-N setting.
+Next best case is that the RFO sets a single O-N for all packets proxied. (see above section on Basic O-N setting).
 Worst case is that the O-N isn't set and proxied packets contain no identification.
@@ Line 29: / Line 31: @@
 First challenge is how to identify which site is which when proxying. Incoming connections can only be identified by their IP address. Fortunately FreeRADIUS provides a way to add attributes internally to incoming connections.
+<code>
+client holby-nhs-uk-0 {
+        ipaddr = server1.holby.nhs.uk
+        secret = charlieisaseriealkiller
+        operator = "1holby.nhs.uk" # Add this internal variable
+        require_message_authenticator = yes
+}
+client holby-nhs-uk-1 {
+        ipaddr = server2.holby.nhs.uk
+        secret = lisaisaseriealkiller
+        operator = "1holby.nhs.uk" # Add this internal variable
+        require_message_authenticator = yes
+}
+</code>
+Now
+<code>
+%{client:operator}
+</code>
+is available in the main configuration as a variable containing an O-N for each client.
+Now use
+<code>
+                update request {
+                        Operator-Name = "%{%{client:operator}:-1nhs.uk}"
+                }
+</code>
+which will set, in preference, the existing O-N ('=' means 'assign unless already set'), the client operator and then a default of '1nhs.uk', if neither of the others are set. The default should be your own site in form of '1<realm>' where the <realm> is your primary realm.
+Set the 'operator' in the config for each client you want to override the O-N for. You can set the same 'operator' multiple times.