Moe, John wrote: > Seriously though, I've found one on PAP, one on ntlm_auth/AD, one on HP, > one on Cisco, but when I've followed each one, they doesn't seem to work > together properly.
So ask *specific* questions about what you expect, what's happening, and what you think is going wrong. > Well, that's what I'm trying to do. I'm just trying to understand the > sequence first, and ensure I'm trying to configure the right thing in > the right place. Then I'll have a look at each piece individually and > configure it properly. Ask small questions, instead of long ones. It really makes a difference. > Well, now that I know that "suffix" is an instance of "realm", yeah, the > debug output does have a few "suffix" lines followed by "rlm_realm". > And now, in hindsight, I can see how the messages go together. Exactly. Reading the debug output helps. > I understand what you're trying to tell me. I've seen you make the > point again and again in my searches for information: "Follow the > guides, and READ (usually emphasized in some way) the debug info". That response is often to questions like "what's going wrong?" And the answer is in the message they posted to the list... in big WARNING messages, or ERROR messages. > But > honestly, I've spent a few weeks now, reading and re-reading config > files, wiki articles, mailing list archives (which if I understand > correctly, need to be treated with suspicion, as many of them are out of > date), and general Googling (also suspect), and I haven't been able to > find out how to configure what I'm trying to do. And that's a failure of *process*. If you don't understand one thing, do some work to investigate, then ask questions. That's a good process. Waiting weeks and reading multiple documents from multiple sources is *bad* process. It means that you can't keep track of what's comeing from where. It means that you're investigating step N+1 when you haven't fully understood step N. The result is a *bad* investigation into step N+1. You don't know the right questions to ask. Even if you did, you don't understand the answers because the mental model you're using is wrong. > a) RADIUS-based authentication against AD using PEAP-MSCHAPv2 to log > users into switches Users don't log into switches. Details matter. The guide on deployingradius.com works. > b) RADIUS-based authentication against AD using PAP to log users into > switches (some of our switches are older and don't support PEAP-MSCHAPv2 > for logon, only for 802.1x, so I'm forced to use PAP) How does someone use PAP to log into a switch? In any case... just configure AD as an LDAP server. Uncomment "ldap" in raddb/sites-enabled/default. It *will* work. And because the server is smart, both step (a) and (b) will now work. > c) 802.1x on the same switches, again using PEAP-MSCHAPv2, to > authenticate computers (and the users on them) and IP phones to the > network and put them in the appropriate VLAN. That's a bit more complicated, but really just step (a) again. There's a little more magic that even I don't understand around machine authentication. > I've gotten b) to work, although in the debug info, it doesn't > explicitly say it's using PAP, only that it's using ntlm_auth to in the > authenticate section. You don't need ntlm_auth for PAP authentication. It's only needed for MS-CHAP to AD. > I'm trying to get a) to work now, but I'm having > trouble working out if I should be using PEAP-TLS, ntlm_auth, another > module, or some combination of all of them. I have no idea why this is a problem. Follow the guide on http://deployingradius.com. It's detailed, and it works. > And to do that, I need to > know what each piece is doing, and how they fit together. No. You need to follow the guide I wrote. It explains in detail what each piece does, why it's there, how it works, and what to do when something goes wrong. It *will* work. > Thanks for taking the time to respond, I appreciate it. If you figure out the correct process, you don't *need* to ask most questions any more. The answers will be easy and obvious. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
