SSL-VPN Radius issue

[darrencarr]

Hi all, I am faced with this issue. Prior to today I was running Fortigate v4 MR1 Patch 10. I' ve since upgraded successfully to MR2 Patch 9. We are still testing MR3. Previously to access our SSL-VPN portal you would simply enter the URL and log in using your AD username i.e joej Since the upgrade to login I now I have to enter the domain name before the user i.e test\joej We have a reasonably large user base and I don' t want to have to communicate with everyone that they now need to do this to log in. I am thinking that this may be a radius issue and not a Fortigate issue. Is there a setting on the Fortigate or Radius server that can pipe this before the username before sending to the IAS server? Thanks

[Carl_Wallmark]

Hi, I have used radius with alot of servers and AD, and never had to type the domain, and i use MR1, MR2 and MR3. So check the server first and the events log

[darrencarr]

Hi, Thanks for the reply. As I say it was working fine prior to the upgrade. Nothing has changed on the server either. Can you give me any starting points as to where to look? Thanks

[Carl_Wallmark]

what radius server are you using ?

[darrencarr]

Hi, Sorry for the late reply. I am using a Windows 2008 Server (NPS). Something very odd is happening. I thought there was a issue that was affecting all users but it isn' t. Only selected users are unable to connect. My ' user' account along with several others can' t. This was working fine prior to the upgradre. Now in the logs there is an error that reads ' no matching policy' . I only have one policy for the SSLVPN (outside -> sslvpn). Nothing else has changed. If I run the command in the console ' diag test authserver radius....my username and password' it succeeds against the radius server? Any idea what could be causing this? Thks

[darrencarr]

I did remove the client from my machine and then downloaded the new one from the appliance, this still did not work. I still get the error ' no_matching_policy' as the reason for the failure to connect. The one AD security group that controls acccess I am a member of. Other users who cannot connect are also in this group. There is no obvious difference between an account that works and one that doesn' t?

[Carl_Wallmark]

Can you try to debug the authentication daemon ? I think its: Diag debug app fnbmd 255 Diag debug enable

[darrencarr]

Hi, I' ve made a bit of progress. Prior to the upgrade the username was never case sensitive. I' ve now tried logging in with the specific ' User logon name' in the ' Account' tab of the user properties. This works for my account. Other users can however logon using either format (case sensitive/non-case sensitive)? Thanks for the tip regarding the debugging. I' ll continue to look into this.