Trying to wrap my head around FreeRadius config

Moe, John jmoe at
Thu Jul 21 02:56:56 CEST 2011

> -----Original Message-----
> From: at
> [mailto:freeradius-users-
> at] On Behalf Of Gary
> Gatten
> Sent: Thursday, 21 July 2011 9:29 AM
> To: 'FreeRadius users mailing list'
> Subject: RE: Trying to wrap my head around FreeRadius config
> Let me TRY to address a couple points here.
> 1.) Admins "logging in" to network devices: telnet, ssh, etc.
> The Network Device, if "properly" configured, sends a RADIUS request to
> the RADIUS server.  If you run FR in debug mode you'll see the request
> come in and all the attributes thereof.  FR, based on the "policy" you
> configure will pick one of several methods to authenticate the user.
> Could be the users file, MySQL, LDAP, ntlm_auth, etc.  Personally I use
> ntlm_auth because: 1.) I'm not very skilled in the details of LDAP and
> "thought" it would be more difficult to get up and running correctly.
> 2.) Like you my understanding was / is certain types of RADIUS auth
> requests (such as 802.1x type stuff) "needs" ntlm_auth as LDAP / AD
> typically doesn't store passwords in the proper format...  Which leads
> me to scenario 2.)
> 2.) ntlm_auth is "typically" required for 802.1x (*EAP) stuff as LDAP /
> AD doesn't typically store the passwords in a ... "compatible" format.
> I too have read where you *can* use LDAP to authenticate *EAP IF you
> store the user passwords in a certain format.  BUT, getting AD admins
> to do that is not likely when a viable alternative exists; ie:
> ntlm_auth.

Oh good, I'm glad I'm not the only one, for a bit there I was starting to
wonder if I'd read anything correctly.

> My suggestion - just to get things "working" so you can play with it
> and learn more by actually seeing valid request / reply convos:

Well, like I said before, I've gotten certain things working previously, and
had learned as much as I could by staring at a screen, so I turned to this
mailing list.

> 1.) Use only ntlm_auth.  If necessary you can use "require-membership-
> of" (I forget exact syntax) to ensure only members of "Network Admins"
> can get a cli on your network gear.  It will also work for 802.1x

>From what I've read, require-membership-of is a switch to ntlm_auth, and (if
I've understood these things properly) I'm going to need to create multiple
instances of the "exec" module, one for each group I'm going to want to use
as a check.  Hopefully, someone can tell me if I've got this right.

> 2.) If necessary set your default auth type to ntlm_auth.  This is
> discussed in docs and suggested only for testing.  As I've mentioned
> before I had to leave it in place as I probably don't have something
> configured "correctly", BUT, right now 100% of my auth uses ntlm_auth -
> so it works.

Yeah, from what I've seen, I haven't been able to get FR to determine it
needs to use ntlm_auth on its own, only when I explicitly tell it so.

> This has grown into quite a thread and it's spawned some VERY useful
> info from some of the FR veterans that has helped me a lot.  I have
> lost track of where you are / what probs you're still having...  I will
> have more time next week and will try to help you more if you still
> need it.
> G

Well, on advice in the previous replies, I've a) scrapped my previous
installation, and b) upgraded FR from 2.0.5 to 2.1.7 (the latest in my
distribution; apparently, the previous maintainer isn't doing so anymore and
no-one has stepped up to take his place), and begun afresh with following
only the guides on, and am going to see where I get to.
When I run into problems, instead of trying to make assumptions and test
things out on my own, I'm going to ask questions on this list.  So don't
worry too much about what was written before.

Thanks for the reply.

John H. Moe
Network Support - Hatch IT
Tel: +61 (7) 3166 7777
Direct: +61 (7) 3166 7684
Fax: +61 (7) 3368 3754
Mobile: +61 438 772 425
61 Petrie Terrace, Brisbane, Queensland Australia 4011

NOTICE - This message from Hatch is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential or proprietary. 
Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. By communicating with us via e-mail, you accept such risks.  When addressed to our clients, any information, drawings, opinions or advice (collectively, "information") contained in this e-mail is subject to the terms and conditions expressed in the governing agreements.  Where no such agreement exists, the recipient shall neither rely upon nor disclose to others, such information without our written consent.  Unless otherwise agreed, we do not assume any liability with respect to the accuracy or completeness of the information set out in this e-mail.  If you have received this message in error, please notify us immediately by return e-mail and destroy and delete the message from your computer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5549 bytes
Desc: not available
URL: <>

More information about the Freeradius-Users mailing list