On Aug 24, 2017, at 10:24 AM, yani@ecoco.co.uk wrote:

radiusd -v radiusd: FreeRADIUS Version 3.0.4, for host x86_64-redhat-linux-gnu, built on Jan 17 2017 at 18:49:55

I would suggest using 3.0.15. It has a lot of fixes over 3.0.4.

I want to be able to authenticate users to my email service and manage them according to the domain they belong to so fred@domaina.com is not the same as fred@domainb.com. But in both cases the first part is the login user name within the domain.

That's a pretty common requirement.

I have looked at freeradius virtual servers -

Virtual servers are largely for separating functionality. i.e. WiFi rules in one virtual server, DSL rules in another, and VPN rules in a third virtual server.

and have considered using free radius realms dont see how either are actually the way forward - It seems that virtual servers will need a database system creating for every instance( am i actually correct here)

No.

and that realms are really for forwarding requests to other free radius servers - when all i need at the moment is a single server handling multiple domain based login groups.

Realms are often used for forwarding, but they don't need to be.

I understand from the documentation that I can create a local realm like this

realm domaina.com { type= radius authhost= LOCAL accthost= LOCAL

Yes.

I suspect I'm on the right track here - but haven't figured out how to create users in the database/system that reflect this

Please advise on the most appropriate way of configuring freeradius to achieve logins for multiple internet domains.

The bigger question is where are the users stored right now? What kind of database contains the name / password for each user? What is the schema used there? Once you know that, you just configure FreeRADIUS to query the database. It should be about 10 minutes work. I wouldn't suggest creating users via the default SQL schema. That's largely for ISP functionality, and will likely not work well for you. For enterprises we just recommend that FreeRADIUS look at the existing enterprise DB. i.e. you don't mangle your data to make FreeRADIUS happy. That's a lot of work. Instead, you configure 1-2 simple queries in FreeRADIUS, so that it pulls the correct information from your existing database. That's *much* easier. Alan DeKok.