Adjustable timeout for Active Directory Authentication?

As far as i know, most OTP protocols rely on Radius for this. 

Can DUO work via AD protocol? As far as i know, they only offer Radius for the authentication to the application, isnt it? 

V18.0 MR4 should give a workaround for this setup.

You should be able to configure a UPN (domain name) for radius. Therefore you can include the Radius UPN, so the username (UPN) for radius and AD should be the same. So you can grap all needed information from AD authentication and use Radius for those services, you want to have OTP. 

To have a AD Timeout, this is more work to do in the access_server (module). 

LuCar ToniI have edited my 'Recommended Read' article to reflect this information.

Do you have any details how exactly this will be implemented?

I can envisage three scenarios:

1. RADIUS server will always return UPN instead of SAN format username.
2. User will be able to specify which format to return in RADIUS Server setup.
3. RADIUS server will return the same format that the user logs in with.

Personally, 2 would be the best option as it is the most flexible.
1. would be an issue for existing people who have already setup SAN format users.
3. would require users to remember to login with UPN format username. Users will forget that requirement and you will still end up with two user accounts and users complaining that their service doesn't work.

Hi JasP,

I posted your idea to the ideas portal.

ideas.sophos.com/.../42133204-adjustable-timeout-for-active-directory-authentica

Hi Bart van der Horst

Thanks, I had spotted that and already voted but if they make the changes to RADIUS as mentioned by LuCar Toni then I suppose that will achieve what we want. It partly depends on how they implement it.

It will be able to specify a Domain per Radius. XG will add the domain to the user after radius authentication. 

That will do it then. Maybe any eta on MR4? This problem makes it difficult for our support staff to troubleshoot user vpn problems.

Hi LuCar Toni

Tested 18.0.4 today on my test rig. Domain set to local domain in radius setup. Works for known AD users, New vpn users are met with no vpn policy in the client. After logging in to the userportal (with AD Auth) the firewall sees the user correctly with Radius login.

One thing user Known and New are placed in the default group after radius login. So one step forward more to take.

Also installed MR4 and although it's nice to have all the other fixes, I'm disappointed that the RADIUS solution doesn't support groups. It's not much improvement over the existing method I posted ,"XG LDAP Server, DUO LDAP client and server" which also supports UPN users but not Groups

It is basically a way to link a AD user to a Radius User and combine both users together. 

To include the radius groups (getting groups by Radius) is a whole different story to follow and implement.

Those changes (unified user accounts) is a quick solution for most customers, as they still have AD and Radius connected to XG. (Some sort of low hanging fruit implementation = low development effort for high output). 

The downside is still: The user needs to be authenticated first by AD to get the current groups by AD. 

"The user needs to be authenticated first by AD to get the current groups by AD."

Either I have misunderstood what you have said or you have misunderstood how this implementation works. Even for existing users, who have been assigned to Groups by AD, their group gets changed to the default Group as soon as they login by RADIUS. So there is no Group support in this RADIUS implementation, it overwrites any AD Group with the default Group.

If they then login by AD, their group goes back to their AD Group.

"The user needs to be authenticated first by AD to get the current groups by AD."

Either I have misunderstood what you have said or you have misunderstood how this implementation works. Even for existing users, who have been assigned to Groups by AD, their group gets changed to the default Group as soon as they login by RADIUS. So there is no Group support in this RADIUS implementation, it overwrites any AD Group with the default Group.

If they then login by AD, their group goes back to their AD Group.

Thats correct, the group will replaced. But this is only the primary group (shown on XG). Still - All features, supporting backend groups, will continue to work with this authentication method, as XG places the backend authentication and store the authentication by AD in the backend. 

Tested this with my users yet. I can still use firewall, webproxy, after authenticated multiple times with Radius (to be transparent: NPS2019 server). 

The primary group (Authentication -> Users) is changed to the Default group. Firewall still let me through my group policies to all resources. Can you test this? 

Mixed results. I don't currently use Group policies in firewall rules but I setup a test and I got the same results as you. Although the user had been changed to the default group, the firewall rule still allowed that user through on the basis of their AD group.

SSL VPN worked as well (OpenVPN on my phone) but IPSEC VPN (also on my phone) failed.

Was going to try it with the Sophos Connect client on a laptop as well but couldn't get it to work at all (never set it up before). I'll return to that later but I have to say that the lack of support for high DPI screens is really irritating, I'm currently working with a postage stamp sized window! You guys do know this is 2020?!

I guess, this IPsec (Sophos Connect) is related to this: https://community.sophos.com/xg-firewall/f/discussions/124756/xg-sophos-connect-ad-groups 

That would make sense. I must admit (as a comparatively new user of XG), I didn't realise that there were Backend Groups, I assumed, from looking at the Users GUI, that a user could only belong to one Group. As well as support for IPSEC, it would be nice if the GUI displayed all Group membership in the future.

There is a feature request to do this. Actually this is something, SG/UTM didnt do either. The visibility of the group membership was never the case. So thats somehow a more complicated request for the future to release. 

But of course you want to be better than SG/UTM, not just match it, or what would be the point of XG!