> -----Original Message----- > From: [email protected] > [mailto:freeradius-users- > [email protected]] 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 DeployingRadius.com, 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 HATCH 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.
smime.p7s
Description: S/MIME cryptographic signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
