I found this a neat tidbit of knowledge that I thought I should share.
Created a Fortinet SDWAN setup with many sites – works awesome. Fortinet’s SDWAN is simple, but very effective with some really cool features to help with SLAs.
During this setup, I have Radius, and LDAP servers located across one of the members of the SDWAN (An IPSEC tunnel). As before with tunnels, you would modify the source address in CLI for the destination server. This would make sure requests originate from the interface you are expecting, and will go through the tunnel.
After switching the tunnel to be a member of a SDWAN interface the LDAP/RADIUS requests stopped working. I found another command was needed. This command is needed not only for Radius, and LDAP but also for FAZ, Fortiguard, and dns.
In CLI of both Radius and LDAP servers you will see these options:
The trick here is to set the “interface-select-method” to sdwan. This resolved my issue and allowed things to start working. The reason it does this is that Self-originating traffic, such as Syslog, FortiAnalyzer logging, FortiGuard services, remote authentication, and others, relies on routing table lookups to determine the egress interface that is used to initiate the connection. Policy routes generated by SD-WAN rules do not apply to this traffic.
One of the best troubleshooting steps for Radius/NPS is to look in the event viewer to see why you are having failures. This shows if the server is actively denying the user login attempts due to Creds/Certificate/etc.
Sometimes your successes for failures do not show up in Event viewer – this is usually to do with audit logging not including everything. There are a few ways to modify this – but here I will show two easy ones.
The first is to use the NPS settings to make sure these logs are recorded – Even those these might be checked, I have seen the logs not recorded. I do believe the Audit policy overrides these settings. Our first step is to open up NPS, and right click on the NPS server.
Then we can open up properties and make sure all settings are checked.
Our next option is to use the Audit policy CLI commands to set the success or failure to enable (Enable – enables logging).
auditpol /set /subcategory:”Network Policy Server” /success:enable /failure:enable
You can get the current settings by running the following command in Admin CMD.
auditpol /get /subcategory:”Network Policy Server”
Overtime we forget things, especially Shared secret radius keys. This is pretty common, and I run into it a lot. For example – lets say a you setup NPS (Network Policy Server) and a Wireless controller for 802.1x auth, or a ASA doing radius authentication years ago. Some how or another that key was lost – no worries, you can get that back from the NPS server itself.
In just a few simple steps you can get that key back. So lets start by opening up NPS and then selecting “Radius Clients and Servers” and dropping down “Radius Clients”
In this example I am using a Ruckus Smartzone – lets say I forget the password. I can just right click on the client and select “Save and apply as Template.
Next we can create a new radius client by right clicking on “Radius Clients” and once the client info pops up to fill in, we will select to create it from the template, and select the template we made.
To see the *** Password, uncheck the box “Select and existing template” and then select the “Generate” Radio button – and bam! there is the PSK.
I refer back to these commands a lot and thought they might help someone else. This will allow the Ruckus or Brocade ICX switches to authenticate to a radius server for logins to the device.
radius-server host 1.1.1.1 auth-port 1812 acct-port 1813 default key $aWdAblUmc3JuVSY9Z1k= dot1x
A few things to note about this. I am setting the web-server login and SSH logins to use radius, then if radius is not available use local authentication settings.
The login privilege-mode command bypasses the enable password and logs be straight in a privileged.
I’ve blogged on using the SSL VPN to renew passwords if they expire before using LDAPS, but I have not blogged on doing this through Radius authentication.
One awesome aspect of this is that by default, the max LDAP servers you can configure on a Fortigate is 10 – so if you have a lot of different domains – as I do with one client – you might be pushed to go to Fortiauthenticator for the ability to have more, or use dual factor. Using Radius to authenticate can help remedy this issue because you can authenticate as many domains as you like behind 1 radius server. You can also have that server allow users to change their password if it expires, or if you set the policy in AD to make the user change their password.
To authenticate many different groups through radius for the SSL VPN you have to configure a vendor specific option. I wrote an entry not long ago on how to do this found here – https://travelingpacket.com/2016/01/26/fortigate-radius-group-authentication/ That was written for 5.2 but same stuff applies to 5.4 and 5.6 .
Once NPS is setup, the Radius server is created on the FGT, User groups are created on the FGT and of course SSL VPN policies are good to – you can modify the server in CLI and set the options to allow passwords to be change if expired.
In this case my server is called Presrv04 – The below is the setup for that server
Then we need to modify the options in CLI
Next I changed my account to force me to change my password at next login – check this out.
There we go! once I change my password to something that meets the complexity requirements of my organization it will allow me directly into the VPN – and change my password.
Recent Comments