Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 15339 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN - Radius User Authentication doesn't work

mod2402
Hi all,
I've a Problem with the SSL VPN Client. When I add the Radius Users Group into the SSL VPN Profil, users can't login with this group. The Radius Server is a Celestix Hotpin OTP Server.  

There is no Problem with the User Portal. At this place the Radius Users group work fine. Just the SSL VPN with Radius users dosen't work. Is this a bug? When I use Active Directory Groups, all user could login.

In the SSL VPN Clientlog I see Auth Failures.

Here is the Log from the asg:
2013:11:02-20:24:29 asg-1 openvpn[1787]: 109.41.***.***:52553 TLS: Username/Password authentication deferred for username 'klaus' [CN SET]
2013:11:02-20:24:29 asg-1 openvpn[1787]: 109.41.***.***:52553 TLS Auth Error: --client-config-dir authentication failed for common name 'klaus' file='/etc/openvpn/conf.d/klaus'

Any Suggestion?

Thanks,
mod
UTM 9.106-17 / HA running on Hyper-V


This thread was automatically locked due to age.
Parents
  • 0
    Hi Manfred,
    this was my own fault. I've fetched the new Client config with the Admin account and not with the user account. Now it works like a charm. I don't need to add the autogenerated user to the ssl vpn Profile. I add the radius user Group to the Profile and this works fine for me.

    Now I can use both Authentication modes. AD Authentication for the User Portal and Radius User (OTP) Authentication for the ssl vpn. Both with the same username [:)]

    Thanks Manfred and Bob for your support.

    Regards, 
    mod
  • 0 in reply to mod2402

    Hey ho @all:

    we had the same problem with our UTM and Vasco Token Server.

     

    Specs:

    UTM ASG425 - 9.409-9

    NPS - MS Server 2012

    TOK - Vasco Token Server - MS Server 2012 R2

     

    Config:

    UTM has a configured AD as adirectory (and switched on auto creation of users) and our NPS as radius-server. In case a user want to go to his webportal, he can use the adirectory login. SSL VPN is set to the radius group, which uses the NPS radius server. Our NPS just redirects the NAS identifier "ssl" to our TOK.

     

    We used tcpdump on the UTM and recognized, that our TOK/NPS always replied a successful validation of the SSL VPN user credentials, but the UTM denied the login. We are using the Sophos VPN Client (OpenVPN 2.3.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Jun 25 2016) to connect to our UTM. After a few hour of searching and tcp dumping, we figured out:

    - The users in the "Users & Groups" management only get the "Definitions & Users → Users & Groups → Groups → Radius Users" flag, when they logged into the WebPortal of the UTM or via VPN.

    - The UTM login is CASE SeNsItIvE. We recognized this point by just allowing the users to login via radius and not AD groups to the web portal. we got duplicated users. F.e. User ABC via AD sync and user abc via radius login.

     

    our not so nice solution: if the user doesn't have the Radius Users flag, he has to login with capital letters (ABC). The UTM gets a success message from the NPS and because it's case sensitive, it can update the auto generated AD user ABC and add the Radius User flag. Afterwards it's independant, wether the credentials are captial letters or not ;-) So we tell our users, they should always use capital letters :-) Now the login for ssl vpn works for our users with OTP via radius (NPS/TOK) and for the UTMs user portal via AD.

     

    EDIT: There is already a bug report for this thing: https://community.sophos.com/products/unified-threat-management/astaroorg/f/utm-9-2-beta/65478/9-191-bug-otp-enabled---username-case-sensitive

    It's possible, that in case of a completly fesh installed UTM, this problem will noc occur any more, but we are updating our utm for a long time ;) 

     

    --- sorry for the confusing description, but it was a loooong day until we figured and changed the config. hope it's understandable in some way ;-)

Reply
  • 0 in reply to mod2402

    Hey ho @all:

    we had the same problem with our UTM and Vasco Token Server.

     

    Specs:

    UTM ASG425 - 9.409-9

    NPS - MS Server 2012

    TOK - Vasco Token Server - MS Server 2012 R2

     

    Config:

    UTM has a configured AD as adirectory (and switched on auto creation of users) and our NPS as radius-server. In case a user want to go to his webportal, he can use the adirectory login. SSL VPN is set to the radius group, which uses the NPS radius server. Our NPS just redirects the NAS identifier "ssl" to our TOK.

     

    We used tcpdump on the UTM and recognized, that our TOK/NPS always replied a successful validation of the SSL VPN user credentials, but the UTM denied the login. We are using the Sophos VPN Client (OpenVPN 2.3.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Jun 25 2016) to connect to our UTM. After a few hour of searching and tcp dumping, we figured out:

    - The users in the "Users & Groups" management only get the "Definitions & Users → Users & Groups → Groups → Radius Users" flag, when they logged into the WebPortal of the UTM or via VPN.

    - The UTM login is CASE SeNsItIvE. We recognized this point by just allowing the users to login via radius and not AD groups to the web portal. we got duplicated users. F.e. User ABC via AD sync and user abc via radius login.

     

    our not so nice solution: if the user doesn't have the Radius Users flag, he has to login with capital letters (ABC). The UTM gets a success message from the NPS and because it's case sensitive, it can update the auto generated AD user ABC and add the Radius User flag. Afterwards it's independant, wether the credentials are captial letters or not ;-) So we tell our users, they should always use capital letters :-) Now the login for ssl vpn works for our users with OTP via radius (NPS/TOK) and for the UTMs user portal via AD.

     

    EDIT: There is already a bug report for this thing: https://community.sophos.com/products/unified-threat-management/astaroorg/f/utm-9-2-beta/65478/9-191-bug-otp-enabled---username-case-sensitive

    It's possible, that in case of a completly fesh installed UTM, this problem will noc occur any more, but we are updating our utm for a long time ;) 

     

    --- sorry for the confusing description, but it was a loooong day until we figured and changed the config. hope it's understandable in some way ;-)

Children
No Data
Unfiltered HTML