Trying to wrap my head around FreeRadius config
Hello, all Apologies in advance if this isn't the right forum for this, or if it's already been answered somewhere, and my Google-fu just isn't up to the task. Please point me in the right direction if either is the case. I've managed to get a FreeRadius instance up that will authenticate a user's logon into a HP ProCurve switch against our Active Directory using PAP. I'm now trying to get PCs to authenticate to that switch using 802.1x/PEAP-MSCHAPv2. In trying to get this step working, I'm trying to understand how all the various config files and modules all fit together, so that I can understand how to properly setup FreeRadius. I've read through the config files and the Wiki pages, but I'm still not entirely clear that I understand it all, so I'm hoping someone can correct me if I'm on the wrong track. The process below is based on the default install that came with my distro (Gentoo), in case it differs from other distros. The config I'm currently using has been modified from this, of course, but as I'm more interested right now in how it fits together, I figured I'd start with the default config. 1) When a RADIUS request gets received by the server, it first looks up the device in the clients.conf file. If it doesn't exist there, it ignores the request (with a message being logged saying it ignored the request). 2) If it has the client listed in clients.conf, it then runs the request through the sites-enabled/default file. That file seems to say, starting with the authorize section, run it through the preprocess module, then chap, mschap, suffix, eap, unix, files, expiration, logintime and finally, pap. This is where things start to get a bit blurry for me. I understand that the preprocess module is rlm_preprocess, and that the config lives in modules/preprocess, where I can read a description of that module and what it does. Likewise for chap and mschap. However, suffix doesn't appear to be a module; where'd this come from, and what does it do? There also appear to be some modules in /usr/lib64/rlm_* that appear to have neither a man page, nor a config file in the modules directory, nor any sort of description in the Configuration Files section of the Wiki page. 3) The chap, mschap and eap modules seem to all look at the request and decide if the request is using any of these. If so, they add "Auth-Type := <one of them>" to the config item list. The eap module isn't configured under the modules directory, but in the root directory in eap.conf, the others in their respective file in the modules directory. 4) Given the information in the config items, it tries match the request against the unix and files modules, and add/modify config items appropriately. The "files" module is configured by default to read in the entries from the users file, where I should add "DEFAULT" entries to match the various types of authentication and authorization I'm trying to configure. In there, if it matches against any ruleset, it adds the reply items to the request. 5) It then runs the config items against the expiration and logintime modules, which checks the Expiration attribute and some Time attributes for authorization limitations. 6) It finally runs it through the PAP module to see if it's a PAP request, and adds "Auth-Type := PAP" to the config items. Where do the rest of the attributes that get sent with the packet get added to the config item list? Does that happen first? Does that happen later? Or is the incoming request with all its attributes immediately turned into a list of config items? None of the modules listed seem to say they parse the request and add the request's attributes to the config items. After all this, it then runs through the authenticate section of the sites-enable/default file, where it does the user/password checking: 1) It checks to see if the Auth-Type is PAP, CHAP, or MS-CHAP, and then runs them through the appropriate module. 2) It runs the request through the unix module 3) It runs it through the eap module (again, configured in eap.conf) At some point, (I believe in both the authorize and authentication sections, in the eap module), if it finds that a request is using PEAP, it does much the same thing again, but runs the inner "data/packet/encryption/not sure what to call it here" through the sites-enabled/inner-tunnel file, with sections set up similarly to the sites-enabled/default file. Then there are the session and post-auth sections, that I haven't even begun to look into yet; I hope to shortly. I'm skipping the accounting and proxy sections as for the moment, I'm just trying to get RADIUS authentication and authorization working, no accounting or proxying happening. Any assistance would be appreciated. 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.
On 07/19/2011 05:20 AM, Moe, John wrote:
1) When a RADIUS request gets received by the server, it first looks up the device in the clients.conf file. If it doesn't exist there, it ignores the request (with a message being logged saying it ignored the request).
More or less. The full version goes as follows: 1. Packet is received on a socket 2. FreeRADIUS looks up the "clients" for the corresponding "listen { }" section, or the corresponding virtual server, or the global clients if both those unset 3. It gets the shared secret for the client 4. If present, it verifies the Message-Authenticator, dropping the packet if invalid
2) If it has the client listed in clients.conf, it then runs the request through the sites-enabled/default file. That file seems to say, starting with the authorize section, run it through the preprocess module, then chap, mschap, suffix, eap, unix, files, expiration, logintime and finally, pap.
Again, more or less. It actually runs the request through whatever virtual server is specified in the clients or listen block, or "default" if unset. And yes, it processes through the modules one at a time. See doc/configurable_failover for more info.
This is where things start to get a bit blurry for me. I understand that the preprocess module is rlm_preprocess, and that the config lives in modules/preprocess, where I can read a description of that module and what it does. Likewise for chap and mschap. However, suffix doesn't appear to be a module; where'd this come from, and what does it do?
"suffix" is a named instance of the "realm" module; see modules/realm. Basically, you can have >1 instance of a module with different config e.g. realm suffix { ... } In 2.x, the "unlang" feature of the server also allows you to write "conditional" statements that internally are just modules in the processing list, like so: if (User-Name == foo) { sql2 } # note "else" must be on it's own line # because it's a module, see - line-based else { sql1 } ...which is a series of 2 modules - an "if" module, an "else" module (that only runs when the "if" doesn't) and their child module(s). It's all just modules though; all the way down.
There also appear to be some modules in /usr/lib64/rlm_* that appear to have neither a man page, nor a config file in the modules directory, nor any sort of description in the Configuration Files section of the Wiki page.
Possibly. Which ones, specifically?
3) The chap, mschap and eap modules seem to all look at the request and decide if the request is using any of these. If so, they add "Auth-Type :=<one of them>" to the config item list. The eap module isn't
Correct
configured under the modules directory, but in the root directory in eap.conf, the others in their respective file in the modules directory.
Yes, that's historical. In the 3.x versions of the server, the default "eap" module config lives in modules/eap.
4) Given the information in the config items, it tries match the request against the unix and files modules, and add/modify config items appropriately. The "files" module is configured by default to read in the entries from the users file, where I should add "DEFAULT" entries to match the various types of authentication and authorization I'm trying to configure. In there, if it matches against any ruleset, it adds the reply items to the request.
Sort of. Your terminology is a bit confusing. *All* modules work by matching & modifying 3 lists of variables: 1. request - came from the client 2. config - internal to the server 3. reply - sent back to the client Ignoring the "unix" module (which isn't generally that useful) the "files" module basically does this: 1. Expands the "key" variable (defaults to "%{User-Name}") 2. Walk through the entries in the file as follows: * If key matches or key==DEFAULT, process entry If Fall-Through = yes, proceed to next entry The entry process basically works as follows: * All compare/set operations are on the 1st line * Compare operations are made against request variables * Set operations are made against check/control variables e.g. in the "users" file, this: DEFAULT Foo == "bar", Baz := "ban" ...means: compare Foo in the request against "bar"; if it matches set "Baz" in the control items to "ban"
5) It then runs the config items against the expiration and logintime modules, which checks the Expiration attribute and some Time attributes for authorization limitations.
What is "It" in this sentence? The modules themselves do the comparison.
6) It finally runs it through the PAP module to see if it's a PAP request, and adds "Auth-Type := PAP" to the config items.
Again, the "pap" module does this
Where do the rest of the attributes that get sent with the packet get added to the config item list? Does that happen first? Does that happen later? Or is the incoming request with all its attributes immediately turned into a list of config items? None of the modules listed seem to say they parse the request and add the request's attributes to the config items.
They don't. That doesn't happen. Each radius request has 3 lists: 1. Request - populated initially with the AVPs from the packet 2. Config/control - initially empty 3. Reply - initially empty The request variables don't get copied to config/control; that wouldn't make sense. They're control variables after all. Modules are expected to populate the "control" list. The core "control" attributes that matter are: 1. Cleartext-Password - expected to be set in the "authorize" section by one of the "database" or "lookup" modules (e.g. SQL, LDAP). Used later to in the "authenticate" section by "pap", "mschap" etc. 2. XXX-Password - same as above, but various types of password hash that are compatible with the authentication module; e.g. NT-Password for "mschap", Crypt-Password for PAP 3. Auth-Type - set by the relevant module to "itself" in "authorize"; used to "re-run" the module in "authenticate" after the various database modules have had a chance to add XX-Password 4. Proxy-To-Realm - set by the "realm" module, or manually. Used to proxy the request. Stops "authenticate" being run. There are various others, but those are the main ones.
After all this, it then runs through the authenticate section of the sites-enable/default file, where it does the user/password checking:
1) It checks to see if the Auth-Type is PAP, CHAP, or MS-CHAP, and then runs them through the appropriate module.
2) It runs the request through the unix module
3) It runs it through the eap module (again, configured in eap.conf)
Yeah, that's all a bit confusing and historical. Basically the "authenticate" section just works; don't worry about it too much. Provided you don't fiddle with Auth-Type, the right module will be run.
At some point, (I believe in both the authorize and authentication sections, in the eap module), if it finds that a request is using PEAP, it does much the same thing again, but runs the inner "data/packet/encryption/not sure what to call it here" through the sites-enabled/inner-tunnel file, with sections set up similarly to the sites-enabled/default file.
Not quite. EAP is a multi-packet challenge/response mechanism; PEAP in particular basically tunnels TLS over radius, then the "inner" auth over TLS. So the packet flow is as follows: 1. Access-Request from client with TLS inside EAP-Message 2. Access-Challenge from server with TLS 3. Repeat 1/2 several times until TLS is setup 4. Access-Request from client with TLS payload inside EAP-Message a. payload decrypted and turned into a fake radius packet b. fake packet sent to "inner-tunnel" virtual server c. reply comes back - maybe Access-Challenge or Access-Accept d. reply turned back into TLS payload 5. Access-Challenge from server with TLS payload 6. Repeat 4/5 until inner-tunnel succeeds with Access-Accept 7. Access-Request from client with TLS "PEAP success" payload 8. Access-Accept from server ...all the numbered steps run in the "outer" server. All the lettered steps run in the "inner" server. For extra fun, steps 4/5 in the outer server make the "eap" module return "ok" in the "authorize" section, which allows you to stop processing the rest of the "authorize" section, because you know you don't need to - it'll all happen in the inner-tunnel.
Then there are the session and post-auth sections, that I haven't even
post-auth is run for the final Access-Accept or Access-Reject. It allows you to do things which only need to be done on the final packet. For example, really post-auth is where the vlan assignment lookup should be run - though a lot of people do it in "authorize" for various reasons, this can lead to >1 "database" lookup for multi-pass radius exchanges e.g. EAP. session is for Simultaneous-Use; I've never used it, so never bothered to figure out how it works. Really something like the above info should live in the wiki. The request processing pipeline is a common question.
On 07/19/2011 03:09 AM, Phil Mayers wrote:
More or less.
The full version goes as follows:
Excellent write-up Phil! I think we need a wiki page on the server processing pipeline and your content would make a good start. Do you think you might take a stab at it? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Jul 19, 2011, at 2:55 PM, John Dennis wrote:
On 07/19/2011 03:09 AM, Phil Mayers wrote:
More or less.
The full version goes as follows:
Excellent write-up Phil! I think we need a wiki page on the server processing pipeline and your content would make a good start. Do you think you might take a stab at it?
We already do, and IIRC its based on Phil's work too :) http://wiki.freeradius.org/Concepts Maybe a ConceptsAdvanced? -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
On 07/19/2011 09:14 AM, Arran Cudbard-Bell wrote:
On Jul 19, 2011, at 2:55 PM, John Dennis wrote:
On 07/19/2011 03:09 AM, Phil Mayers wrote:
More or less.
The full version goes as follows:
Excellent write-up Phil! I think we need a wiki page on the server processing pipeline and your content would make a good start. Do you think you might take a stab at it?
We already do, and IIRC its based on Phil's work too :)
Actually I wrote that :-) But I think its too sparse and a tad lame. It need more substance. Perhaps Phil and others could use it as a starting point and add their content to it incrementally so over time we build up a more complete pipeline picture. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Jul 19, 2011, at 3:22 PM, John Dennis wrote:
On 07/19/2011 09:14 AM, Arran Cudbard-Bell wrote:
On Jul 19, 2011, at 2:55 PM, John Dennis wrote:
On 07/19/2011 03:09 AM, Phil Mayers wrote:
More or less.
The full version goes as follows:
Excellent write-up Phil! I think we need a wiki page on the server processing pipeline and your content would make a good start. Do you think you might take a stab at it?
We already do, and IIRC its based on Phil's work too :)
Actually I wrote that :-) But I think its too sparse and a tad lame. It need more substance. Perhaps Phil and others could use it as a starting point and add their content to it incrementally so over time we build up a more complete pipeline picture.
Oops apologies. I obviously didn't recall correctly :( Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
-----Original Message----- From: freeradius-users-bounces+jmoe=hatch.com.au@lists.freeradius.org [mailto:freeradius-users- bounces+jmoe=hatch.com.au@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Tuesday, 19 July 2011 5:10 PM To: freeradius-users@lists.freeradius.org Subject: Re: Trying to wrap my head around FreeRadius config
On 07/19/2011 05:20 AM, Moe, John wrote:
1) When a RADIUS request gets received by the server, it first looks up the device in the clients.conf file. If it doesn't exist there, it ignores the request (with a message being logged saying it ignored the request).
More or less.
Well, I wasn't intending to write a full process-flow for this, I was trying to get the basics down first. :-)
The full version goes as follows:
1. Packet is received on a socket 2. FreeRADIUS looks up the "clients" for the corresponding "listen { }" section, or the corresponding virtual server, or the global clients if both those unset 3. It gets the shared secret for the client 4. If present, it verifies the Message-Authenticator, dropping the packet if invalid
I didn't realize that FreeRadius did anything with the Message-Authenticator. Good to keep in mind.
2) If it has the client listed in clients.conf, it then runs the
request
through the sites-enabled/default file. That file seems to say, starting with the authorize section, run it through the preprocess module, then chap, mschap, suffix, eap, unix, files, expiration, logintime and finally, pap.
Again, more or less.
It actually runs the request through whatever virtual server is specified in the clients or listen block, or "default" if unset.
And yes, it processes through the modules one at a time. See doc/configurable_failover for more info.
This is where things start to get a bit blurry for me. I understand that the preprocess module is rlm_preprocess, and that the config
lives
in modules/preprocess, where I can read a description of that module and what it does. Likewise for chap and mschap. However, suffix doesn't appear to be a module; where'd this come from, and what does it do?
"suffix" is a named instance of the "realm" module; see modules/realm.
Ah, I'd wondered how the named instances of a module get called; now I know.
Basically, you can have >1 instance of a module with different config e.g.
realm suffix { ... }
In 2.x, the "unlang" feature of the server also allows you to write "conditional" statements that internally are just modules in the processing list, like so:
if (User-Name == foo) { sql2 } # note "else" must be on it's own line # because it's a module, see - line-based else { sql1 }
...which is a series of 2 modules - an "if" module, an "else" module (that only runs when the "if" doesn't) and their child module(s).
It's all just modules though; all the way down.
There also appear to be some modules in /usr/lib64/rlm_* that appear to have neither a man page, nor a config file in the modules directory, nor any sort of description in the Configuration Files section of the Wiki page.
Possibly. Which ones, specifically?
Well, I didn't have any one in mind. I was just wondering if there was more documentation that I'd missed, and might read up on later, that would give me other modules that would prove useful. Looking back through it now, though, I'm wondering what I was interested in, to be honest. Skip it. The exception to this is the rlm_eap_* modules, but I think they're covered by the eap.conf file, right?
3) The chap, mschap and eap modules seem to all look at the request
and
decide if the request is using any of these. If so, they add "Auth- Type :=<one of them>" to the config item list. The eap module isn't
Correct
configured under the modules directory, but in the root directory in eap.conf, the others in their respective file in the modules directory.
Yes, that's historical. In the 3.x versions of the server, the default "eap" module config lives in modules/eap.
Ah, I was under the impression from my reading that it used to be in the modules folder, but was large and important enough to break out for some reason. I guess I got the wrong impression.
4) Given the information in the config items, it tries match the
request
against the unix and files modules, and add/modify config items appropriately. The "files" module is configured by default to read in the entries from the users file, where I should add "DEFAULT" entries to match the various types of authentication and authorization I'm trying to configure. In there, if it matches against any ruleset, it adds the reply items to the request.
Sort of. Your terminology is a bit confusing.
Which is part of the reason for my questions, so I can learn it properly. :-)
*All* modules work by matching & modifying 3 lists of variables:
1. request - came from the client 2. config - internal to the server 3. reply - sent back to the client
Ignoring the "unix" module (which isn't generally that useful) the "files" module basically does this:
1. Expands the "key" variable (defaults to "%{User-Name}") 2. Walk through the entries in the file as follows: * If key matches or key==DEFAULT, process entry If Fall-Through = yes, proceed to next entry
The entry process basically works as follows:
* All compare/set operations are on the 1st line * Compare operations are made against request variables * Set operations are made against check/control variables
e.g. in the "users" file, this:
DEFAULT Foo == "bar", Baz := "ban"
...means: compare Foo in the request against "bar"; if it matches set "Baz" in the control items to "ban"
5) It then runs the config items against the expiration and
logintime
modules, which checks the Expiration attribute and some Time attributes for authorization limitations.
What is "It" in this sentence?
"It" = the FreeRadius server. And I guess "against" isn't the right word, probably "through" would be better.
The modules themselves do the comparison.
6) It finally runs it through the PAP module to see if it's a PAP request, and adds "Auth-Type := PAP" to the config items.
Again, the "pap" module does this
Where do the rest of the attributes that get sent with the packet
get
added to the config item list? Does that happen first? Does that happen later? Or is the incoming request with all its attributes immediately turned into a list of config items? None of the modules listed seem to say they parse the request and add the request's attributes to the config items.
They don't. That doesn't happen.
Each radius request has 3 lists:
1. Request - populated initially with the AVPs from the packet 2. Config/control - initially empty 3. Reply - initially empty
The request variables don't get copied to config/control; that wouldn't make sense. They're control variables after all.
Modules are expected to populate the "control" list. The core "control" attributes that matter are:
1. Cleartext-Password - expected to be set in the "authorize" section by one of the "database" or "lookup" modules (e.g. SQL, LDAP). Used later to in the "authenticate" section by "pap", "mschap" etc.
2. XXX-Password - same as above, but various types of password hash that are compatible with the authentication module; e.g. NT-Password for "mschap", Crypt-Password for PAP
3. Auth-Type - set by the relevant module to "itself" in "authorize"; used to "re-run" the module in "authenticate" after the various database modules have had a chance to add XX-Password
4. Proxy-To-Realm - set by the "realm" module, or manually. Used to proxy the request. Stops "authenticate" being run.
There are various others, but those are the main ones.
So then, when matching an entry in "users", does it look at the request items, or the config items? When creating an entry, you specify first things to match against on one line separated by commas, and then reply items, each on its own line, separated by commas. Those things to match against, do they match the request items or the config items? I'm trying to understand the difference between request and config.
After all this, it then runs through the authenticate section of the sites-enable/default file, where it does the user/password checking:
1) It checks to see if the Auth-Type is PAP, CHAP, or MS-CHAP, and
then
runs them through the appropriate module.
2) It runs the request through the unix module
3) It runs it through the eap module (again, configured in eap.conf)
Yeah, that's all a bit confusing and historical. Basically the "authenticate" section just works; don't worry about it too much. Provided you don't fiddle with Auth-Type, the right module will be run.
At some point, (I believe in both the authorize and authentication sections, in the eap module), if it finds that a request is using
PEAP,
it does much the same thing again, but runs the inner "data/packet/encryption/not sure what to call it here" through the sites-enabled/inner-tunnel file, with sections set up similarly to the sites-enabled/default file.
Not quite. EAP is a multi-packet challenge/response mechanism; PEAP in particular basically tunnels TLS over radius, then the "inner" auth over TLS. So the packet flow is as follows:
1. Access-Request from client with TLS inside EAP-Message 2. Access-Challenge from server with TLS 3. Repeat 1/2 several times until TLS is setup 4. Access-Request from client with TLS payload inside EAP-Message a. payload decrypted and turned into a fake radius packet b. fake packet sent to "inner-tunnel" virtual server c. reply comes back - maybe Access-Challenge or Access-Accept d. reply turned back into TLS payload 5. Access-Challenge from server with TLS payload 6. Repeat 4/5 until inner-tunnel succeeds with Access-Accept 7. Access-Request from client with TLS "PEAP success" payload 8. Access-Accept from server
...all the numbered steps run in the "outer" server. All the lettered steps run in the "inner" server.
For extra fun, steps 4/5 in the outer server make the "eap" module return "ok" in the "authorize" section, which allows you to stop processing the rest of the "authorize" section, because you know you don't need to - it'll all happen in the inner-tunnel.
... I think I'm going to need to re-read this a few times and play with it on my server to fully get this part. I thought TLS was only one mechanism within PEAP that it could use; another, for example, is MSCHAPv2 (which is what I'm going to be using). Or does it use TLS on the PEAP portion to set up the outer tunnel, regardless of what's used inside?
Then there are the session and post-auth sections, that I haven't even
post-auth is run for the final Access-Accept or Access-Reject. It allows you to do things which only need to be done on the final packet. For example, really post-auth is where the vlan assignment lookup should be run - though a lot of people do it in "authorize" for various reasons, this can lead to >1 "database" lookup for multi-pass radius exchanges e.g. EAP.
I'll have to have a closer look at this then; it's one of the intended uses I have for this.
session is for Simultaneous-Use; I've never used it, so never bothered to figure out how it works.
Really something like the above info should live in the wiki. The request processing pipeline is a common question. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks so much for your response, it's cleared up a few things and helped me along. I'm sure more questions will pop up as I re-read both this and the reply from Alan DeKok (which I'm going to reply to separately), and continue to work on this; I'll repost individual, hopefully smaller, questions when they arise. 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.
On 07/20/2011 03:28 AM, Moe, John wrote:
There are various others, but those are the main ones.
So then, when matching an entry in "users", does it look at the request items, or the config items? When creating an entry, you specify first things to match against on one line separated by commas, and then reply items, each on its own line, separated by commas. Those things to match against, do they match the request items or the config items? I'm trying to understand the difference between request and config.
Well, I thought my example had covered this, but I guess not. The 1st line can contain comparison and set operators e.g. DEFAULT Attr1 == Value1, Attr2 := Value2 Attr3 = Value3 Comparisons are made against the "request" pairs. If everything on the 1st line matches ("set" operations are considered to always match i.e. skipped) then: * any non-comparison (i.e. set) operations from the 1st line are copied into the config pair list * 2nd and subsequent lines are copied to the reply pair list So, the example above says: * if * request:Attr1 == Value1, and * <noop, because := is a set operator> * then * set config:Attr2 := Value2 * set reply:Attr3 := Value3
... I think I'm going to need to re-read this a few times and play with it on my server to fully get this part. I thought TLS was only one mechanism within PEAP that it could use; another, for example, is
No, you've misunderstood how it works I'm afraid. The various EAP methods are complex; by all means put effort into understanding them if it interests you, but take it from me: it might not be as rewarding or useful as you'd hope.
MSCHAPv2 (which is what I'm going to be using). Or does it use TLS on the PEAP portion to set up the outer tunnel, regardless of what's used inside?
PEAP *is* TLS. It's exactly the same protocol as EAP-TLS (i.e. a simple layering of TLS over EAP) except for the following: * EAP number is different * Once the TLS session is setup, additional "inner" data is sent over TLS e.g. EAP-MSCHAPv2
Moe, John wrote: Moe, John wrote:
Apologies in advance if this isn't the right forum for this, or if it's already been answered somewhere, and my Google-fu just isn't up to the task. Please point me in the right direction if either is the case.
doc/aaa.rst helps.
In trying to get this step working, I'm trying to understand how all the various config files and modules all fit together, so that I can understand how to properly setup FreeRadius.
One word: Don't. It's a large complicated piece of software. The complexity is there so that you don't *need* to understand it. Follow the guides (on freeradius.org && deployingradius.com). It *will* work.
I've read through the config files and the Wiki pages, but I'm still not entirely clear that I understand it all, so I'm hoping someone can correct me if I'm on the wrong track.
The wrong track is the desire to understand everything all at the same time. You've posted a series of questions which contain some good information, and some misunderstandings. It's difficult to come up with a good response, as the response is piecemeal: it doesn't form a coherent picture. The simple thing is this. Packets come from clients. The are configured in clients.conf. The server receives the packets. It processes them. It sends a response. That's it. The details of how all of that works can be broken up into independent pieces. i.e. pieces which can be understood without referring to anything else. The "files" module works by receiving a request, processing the "users" file, and updating the request. The "unix" module works by receiving a request, looking the user up in /etc/passwd, and updating the request. The "authorize" section just runs a bunch of modules, one after the other. As for the rest of it. I'll response. Not to give answers, but to give corrections on the process which caused you to ask the questions.
This is where things start to get a bit blurry for me. I understand that the preprocess module is rlm_preprocess, and that the config lives in modules/preprocess, where I can read a description of that module and what it does. Likewise for chap and mschap. However, suffix doesn't appear to be a module; where'd this come from, and what does it do?
It's a module, too. grep the "modules" directory for "suffix". Or read the debug output. It's all there. i.e. don't get confused. The *process* to find the answer is simple: debug output.
There also appear to be some modules in /usr/lib64/rlm_* that appear to have neither a man page, nor a config file in the modules directory, nor any sort of description in the Configuration Files section of the Wiki page.
And why does this matter? You're going out of your way to find problems. This is counter-productive and confusing.
3) The chap, mschap and eap modules seem to all look at the request and decide if the request is using any of these. If so, they add "Auth-Type := <one of them>" to the config item list. The eap module isn't configured under the modules directory, but in the root directory in eap.conf, the others in their respective file in the modules directory.
So? Why does this matter?
4) ... 5) ... 6) ...
A bunch of modules run. Details don't really matter.
Where do the rest of the attributes that get sent with the packet get added to the config item list? Does that happen first? Does that happen later? Or is the incoming request with all its attributes immediately turned into a list of config items? None of the modules listed seem to say they parse the request and add the request's attributes to the config items.
Read the documentation on config items versus request or response. See "man unlang". This is documented.
After all this, it then runs through the authenticate section of the sites-enable/default file, where it does the user/password checking:
1) It checks to see if the Auth-Type is PAP, CHAP, or MS-CHAP, and then runs them through the appropriate module.
2) It runs the request through the unix module
3) It runs it through the eap module (again, configured in eap.conf)
Why do you think (2) and (3) are true? *READ* the debug output! It's all there! Reading it shows that (2) and (3) are false. Honestly, it's that simple Alan DeKok.
-----Original Message----- From: freeradius-users-bounces+jmoe=hatch.com.au@lists.freeradius.org [mailto:freeradius-users- bounces+jmoe=hatch.com.au@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, 20 July 2011 5:53 AM To: FreeRadius users mailing list Subject: Re: Trying to wrap my head around FreeRadius config
Moe, John wrote: Moe, John wrote:
Apologies in advance if this isn't the right forum for this, or if it's already been answered somewhere, and my Google-fu just isn't up to the task. Please point me in the right direction if either is the case.
doc/aaa.rst helps.
I hadn't seen or heard of that file before. Thanks for the pointer. When I unpacked the sources for FreeRadius (freeradius-server-2.0.5.tar.gz) that Gentoo used to build the server, I found a doc directory, and in there was a "aaa.txt" file, but no "aaa.rst" file; I assume the content is the same? It looks more in-depth and more what I'm looking for. In fact, there's alot of info in that directory that I haven't seen, so I'm going to read that next.
In trying to get this step working, I'm trying to understand how all the various config files and modules all fit together, so that I can understand how to properly setup FreeRadius.
One word: Don't.
It's a large complicated piece of software. The complexity is there so that you don't *need* to understand it. Follow the guides (on freeradius.org && deployingradius.com). It *will* work.
Where's the guide on setting up both PAP and PEAP-MSCHAPv2 to authenticate both SSH logons and 802.1x requests coming from both HP and Cisco switches and routers using Active Directory? I haven't seen that one, but if you point me to it, I'll follow it. 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. At which point, I thought I'd try to understand things a bit deeper so I know which bits from each guide I need to end up with the solution I want.
I've read through the config files and the Wiki pages, but I'm still not entirely clear that I understand it all, so I'm hoping someone can correct me if I'm on the wrong track.
The wrong track is the desire to understand everything all at the same time. You've posted a series of questions which contain some good information, and some misunderstandings. It's difficult to come up with a good response, as the response is piecemeal: it doesn't form a coherent picture.
The simple thing is this. Packets come from clients. The are configured in clients.conf. The server receives the packets. It processes them. It sends a response.
That's it.
The details of how all of that works can be broken up into independent pieces. i.e. pieces which can be understood without referring to anything else.
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.
The "files" module works by receiving a request, processing the "users" file, and updating the request.
The "unix" module works by receiving a request, looking the user up in /etc/passwd, and updating the request.
The "authorize" section just runs a bunch of modules, one after the other.
As for the rest of it. I'll response. Not to give answers, but to give corrections on the process which caused you to ask the questions.
This is where things start to get a bit blurry for me. I understand that the preprocess module is rlm_preprocess, and that the config lives in modules/preprocess, where I can read a description of that module and what it does. Likewise for chap and mschap. However, suffix doesn't appear to be a module; where'd this come from, and what does it do?
It's a module, too. grep the "modules" directory for "suffix". Or read the debug output. It's all there.
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.
i.e. don't get confused. The *process* to find the answer is simple: debug output.
There also appear to be some modules in /usr/lib64/rlm_* that appear to have neither a man page, nor a config file in the modules directory, nor any sort of description in the Configuration Files section of the Wiki page.
And why does this matter? You're going out of your way to find problems. This is counter-productive and confusing.
3) The chap, mschap and eap modules seem to all look at the request and decide if the request is using any of these. If so, they add "Auth- Type := <one of them>" to the config item list. The eap module isn't configured under the modules directory, but in the root directory in eap.conf, the others in their respective file in the modules directory.
So? Why does this matter?
4) ... 5) ... 6) ...
A bunch of modules run. Details don't really matter.
Where do the rest of the attributes that get sent with the packet get added to the config item list? Does that happen first? Does that happen later? Or is the incoming request with all its attributes immediately turned into a list of config items? None of the modules listed seem to say they parse the request and add the request's attributes to the config items.
Read the documentation on config items versus request or response. See "man unlang". This is documented.
After all this, it then runs through the authenticate section of the sites-enable/default file, where it does the user/password checking:
1) It checks to see if the Auth-Type is PAP, CHAP, or MS-CHAP, and then runs them through the appropriate module.
2) It runs the request through the unix module
3) It runs it through the eap module (again, configured in eap.conf)
Why do you think (2) and (3) are true?
*READ* the debug output! It's all there!
Reading it shows that (2) and (3) are false. Honestly, it's that simple
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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". 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. Specifically, I want to set up: a) RADIUS-based authentication against AD using PEAP-MSCHAPv2 to log users into switches 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) 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. 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. 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. And to do that, I need to know what each piece is doing, and how they fit together. Thanks for taking the time to respond, I appreciate it. 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.
On 07/20/2011 03:35 AM, Moe, John wrote:
I hadn't seen or heard of that file before. Thanks for the pointer. When I unpacked the sources for FreeRadius (freeradius-server-2.0.5.tar.gz) that Gentoo used to build the server, I
2.0.5 is old. You want to be running a much newer version.
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.
-----Original Message-----
So ask *specific* questions about what you expect, what's happening, and what you think is going wrong.
Ask small questions, instead of long ones. It really makes a difference.
Well, ok, I'll start again, go as far as I can, and then ask questions about what I'm seeing and what I don't understand.
Users don't log into switches. Details matter.
They do if they need to configure the switch. I meant admin users, not general users, but it's still authenticating a user account using RADIUS.
In any case... just configure AD as an LDAP server. Uncomment "ldap" in raddb/sites-enabled/default. It *will* work.
Hang on, this works? I thought I'd read online again and again that if you're authenticating against Active Directory, you must use ntlm_auth, because AD doesn't respond properly to the LDAP and KRB modules? I'd specifically tried to research this very question, and thought I'd come out with the understanding ntlm_auth needed to be used? Will LDAP work properly against AD?
I have no idea why this is a problem. Follow the guide on http://deployingradius.com. It's detailed, and it works.
Which specific guide are you talking about? Or are you talking about the several individual guides I'd mentioned before?
Alan DeKok.
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.
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. My suggestion - just to get things "working" so you can play with it and learn more by actually seeing valid request / reply convos: 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 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. 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 -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Moe, John Sent: Wednesday, July 20, 2011 6:07 PM To: FreeRadius users mailing list Subject: RE: Trying to wrap my head around FreeRadius config
-----Original Message-----
So ask *specific* questions about what you expect, what's happening, and what you think is going wrong.
Ask small questions, instead of long ones. It really makes a difference.
Well, ok, I'll start again, go as far as I can, and then ask questions about what I'm seeing and what I don't understand.
Users don't log into switches. Details matter.
They do if they need to configure the switch. I meant admin users, not general users, but it's still authenticating a user account using RADIUS.
In any case... just configure AD as an LDAP server. Uncomment "ldap" in raddb/sites-enabled/default. It *will* work.
Hang on, this works? I thought I'd read online again and again that if you're authenticating against Active Directory, you must use ntlm_auth, because AD doesn't respond properly to the LDAP and KRB modules? I'd specifically tried to research this very question, and thought I'd come out with the understanding ntlm_auth needed to be used? Will LDAP work properly against AD?
I have no idea why this is a problem. Follow the guide on http://deployingradius.com. It's detailed, and it works.
Which specific guide are you talking about? Or are you talking about the several individual guides I'd mentioned before?
Alan DeKok.
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. <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
-----Original Message----- From: freeradius-users-bounces+jmoe=hatch.com.au@lists.freeradius.org [mailto:freeradius-users- bounces+jmoe=hatch.com.au@lists.freeradius.org] 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.
-----Original Message-----
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.
Actually, looking into this a bit more, I think I need to use an if block. Something like: if (nlm_auth with --require-membership-of testing against an AD group succeeds) { update { # HP ProCurve switches want a Service-Type of Administrative for manager access Service-Type := 6 } # I think/assume this add Access-Accept to the reply items, and marks it as "handled"? ok } elsif (nlm_auth with --require-membership-of testing against another AD group succeeds) { update { # HP ProCurve switches want a Service-Type of NAS Prompt for operator access Service-Type := 7 } # See comment for "ok" above ok } # I don't think this else block is needed at all? else { # Not handled, let processing continue noop } Does this look right? How do I configure the checking in the parenthesis? I'm assuming I don't just put "nlm_auth --require-membership-of=DOMAIN\\GROUP1 --username=%{mschap:User-Name} --password=%{User-Password}" in the parenthesis? 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.
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Gary Gatten -
John Dennis -
Moe, John -
Phil Mayers