Smoothwall - Legacy warnings and Major Headache

[mdrabble]

Needed to update our Smoothwall CA as it was due to expire in 11 days - so done that and still getting the annoying red bar! - Go away!!

 

Anyway..... back to my question, went to look at updates and it is telling me I am using Legacy Auth Methods and Legacy Directories - fair enough, but what does this mean.......

 

Well I have Active Directory - in Directories enabled, but since I am now using IDEX on domain joined devices, I can disable Active Directory..... so all good on that part but Wifi connected devices is going to be a major issue.

 

What the warning actually mean is that my Wifi/BYOD setup will no longer be supported by smoothwall.

 

Problem 1

======

 

I currently have our Unifi Wifi setup using NPS for authentication and then depending on AD Group, they are dynamically assigned to the relevant VLAN.

 

NPS server then passes Radius accounting information to Smoothwall, so they can been assigned the correct filtering - but here is the first problem - Radius Accounting is now a legacy Auth Method.

 

 

Problem 2

======

 

Guest Wifi uses HotSpot, single use codes - which when connected is assigned to the guest Wifi IP Range.

 

Becuase Codes are used, no authentication takes place, so on Smoothwall, I have Identification by Location enabled, and Student Filtering applied. - dentification by Location is now a legacy Auth Method.

 

 

So does this mean I now have to use Smoothwalls BYOD function - which doesn't support Dynamic VLANs

 

What are other people who use Unifi Wifi doing?

 

Cheers

Edited January 6, 2023 by mdrabble

[timbo343]

Im on Maiden 4 and got a couple of warnings about Legacy auth method.

 

It's to do with Authentication under Web Proxy > Authentication > Manage Policies and not the directories. We still have AD and Idex listed in Services > Auth > Directories.

 

You'll probably have a Transparent Auth Policy which is set to ident by location as the following Methods are available in Maiden 4

 

Core Auth | Kerberos (via redirect) | NTLM auth (via redirect) | NTLM Ident (via redirect) | Neg Kerberos/NTLM (via redirect) | No Auth | Redirect users to SSL (session cookie) | Redirect users to non-ssl (session cookie)

 

I've had to change my Ident by location to Core Auth and then state for unauthenticated requests give the appropriate level of filtering.

[mdrabble]

That sorted the Legacy Auth Methods

 

Just need to work out how to get around the Radius Account bit now.

[ibpalle]

That sorted the Legacy Auth Methods

 

Just need to work out how to get around the Radius Account bit now.

 

The RADIUS accounting that is referred to as a legacy service is one of the directory methods, not the ability to serve as a RADIUS auth and acc service, which is set under the BYOD header in services - authentication.

 

The CA warning will be gone tomorrow. The check in the UI runs overnight.

[Primus]

When is Maiden going generally available - I don't see it in my available updates - I too got the actions to rectify a little while ago and worked through them so in theory we're ready.

[ibpalle]

Maiden and Leeds are in a bit of a parallel course at the moment and I have no set date for general release of Maiden. We needed the a kernel features due to UEFY only in a new appliance so Maiden is used on those but bug fixes are currently applied to both - Leeds-63 corresponds to Maiden-4 or 5 I believe.

[mdrabble]

The RADIUS accounting that is referred to as a legacy service is one of the directory methods, not the ability to serve as a RADIUS auth and acc service, which is set under the BYOD header in services - authentication.

 

The CA warning will be gone tomorrow. The check in the UI runs overnight.

 

I'm using a Windows NPS as a Radius Server as I can use AD groups to allow/disallow Wifi Access, plus with NPS I can dynamically assigned VLANs to separate Staff and Student devices.

 

As the NPS box authenticates users, the user account information is then passed onto Smoothwall via Radius Accounting so I can assign levels of filtering etc.

 

 

Is that the correct way of doing things? Or is there an easier way of using a NPS box with smoothwall?

 

 

As far as I know, Smoothwall BYOD offering doesn't offer the same features as NPS such as AD Permissions and Dynamic VLAN assignments.

 

Cheers

[ibpalle]

The only thing Smoothwall needs is RADIUS accounting so the way you are using it the way to do it when you need advanced features that the NPS allows you to have. The BYOD settings on Smoothwall allows the Smoothwall to work as a simple RADIUS auth and accounting service for AD accounts but the only thing required for the Smoothwall to log a user in, is the RADIUS accounting message.

 

The legacy method mentioned in the Maiden update notes is the ability for the Smoothwall to use RADIUS as a directory service (Rarely used hence the removal)

[mdrabble]

Sorry - think I am getting confused and possibly being a little thick - hectic morning and little coffee.

 

I have Radius Accounting in my Auth Directories - If Radius Accounting is being removed - how will Smoothwall know how to assign the correct filtering to users/groups?

 

Do I not actually need Radius Accounting in my Auth Directories?

[Aprice]

From memory there are two Radius options in the directories menu, Radius accounting being the one that will not be supported much longer.

 

 

 

Sorry - think I am getting confused and possibly being a little thick - hectic morning and little coffee.

 

I have Radius Accounting in my Auth Directories - If Radius Accounting is being removed - how will Smoothwall know how to assign the correct filtering to users/groups?

 

Do I not actually need Radius Accounting in my Auth Directories?

[mdrabble]

Ahh.... Think I've just had the light bulb moment.....

 

Remove Radius Accounting and use Radius - configuring it to use NPS for authentication

[BadgerPatrol]

Do I not actually need Radius Accounting in my Auth Directories?

In my experience, as long as the Smoothwall can match the username in the Accounting packet with a user in an existing directory (i.e. IDex, Azure AD, etc), then you don't need to use the specific RADIUS Accounting directory type. The main thing to check is that users are using the correct username format for the directory type (e.g. domain\username for IDex, username@domain for AAD).

[mdrabble]

In my experience, as long as the Smoothwall can match the username in the Accounting packet with a user in an existing directory (i.e. IDex, Azure AD, etc), then you don't need to use the specific RADIUS Accounting directory type. The main thing to check is that users are using the correct username format for the directory type (e.g. domain\username for IDex, username@domain for AAD).

 

That I never knew!

 

Thanks for the info

[mdrabble]

After removing all the radius bits from Auth Directories Wi-Fi was still working if the logged on used by Idex (domain\username) or AAD (email address)

 

Wish I had know this info sooner!

 

All warning message now gone.

 

Thanks for everyone’s help :-)