At 02:54 PM 11/25/2009, you wrote:
Just make it anothe file in the modules directory (like all the others). Any file placed in that directory is authomatically included as a module.
Can you provide an example of that file? Also, on the web page for AD config it has: ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{mschap:NT-Domain:-MYDOMAIN} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" the "-" is bolded in the NT-Domain such that it indicates that it should be replaced, but should it be --domain=%{mschap:NT-Domain:example.com} or --domain=%{mschap:NT-Domain:-example.com} Rick
At 02:54 PM 11/25/2009, you wrote:
Just make it anothe file in the modules directory (like all the others). Any file placed in that directory is authomatically included as a module.
Can you provide an example of that file?
Example for exec ntlm_auth is in the guide.
Also, on the web page for AD config it has: ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{mschap:NT-Domain:-MYDOMAIN} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
the "-" is bolded in the NT-Domain such that it indicates that it should be replaced, but should it be --domain=%{mschap:NT-Domain:example.com} or --domain=%{mschap:NT-Domain:-example.com}
The second one. But that's for mschap requests. Ivan Kalik
At 05:04 PM 11/25/2009, tnt@kalik.net wrote:
At 02:54 PM 11/25/2009, you wrote:
Just make it anothe file in the modules directory (like all the others). Any file placed in that directory is authomatically included as a module.
Can you provide an example of that file?
Example for exec ntlm_auth is in the guide.
In the guide there are two separate ntlm_auth lines. The first one says it should go in radiusd.conf. Where does that relate to a module? It would be helpful to see what the module file would look like. Rick
Hi,
In the guide there are two separate ntlm_auth lines. The first one says it should go in radiusd.conf. Where does that relate to a module?
in latest 2.1.x you will find ntlm_auth living in the mschap module - you can coopy/read that method and command line alan
freeradius@corwyn.net wrote:
At 05:04 PM 11/25/2009, tnt@kalik.net wrote:
At 02:54 PM 11/25/2009, you wrote:
Just make it anothe file in the modules directory (like all the others). Any file placed in that directory is authomatically included as a module.
Can you provide an example of that file?
Example for exec ntlm_auth is in the guide.
In the guide there are two separate ntlm_auth lines. The first one says it should go in radiusd.conf. Where does that relate to a module? That's a leftover from old version. Modules now go into raddb/modules.
It would be helpful to see what the module file would look like. There are dozens of them there. Just save what is quoted in the guide (with adjusted text) as a file into raddb/modules directory.
Ivan Kalik
At 06:15 PM 11/25/2009, you wrote:
There are dozens of them there. Just save what is quoted in the guide (with adjusted text) as a file into raddb/modules directory.
Yeah, and in tinkering with module files I clearly haven't had success. so you're saying create a (adjusted for my environment) file in ../modules: rick_ntlm { ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{mschap:NT-Domain:-MYDOMAIN} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" } and it should work? In part I ask because the examples for radiusd.conf and mschap.conf are different. I suspect I also have to put the reference to that new file (ntlm_rick in this case) into inner-tunnel as well? And in the virtual server config? In both the authorize{} and authenticate {} sections? Rick
freeradius@corwyn.net wrote:
At 06:15 PM 11/25/2009, you wrote:
There are dozens of them there. Just save what is quoted in the guide (with adjusted text) as a file into raddb/modules directory.
Yeah, and in tinkering with module files I clearly haven't had success.
so you're saying create a (adjusted for my environment) file in ../modules: rick_ntlm { exec rick_ntlm { ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{mschap:NT-Domain:-MYDOMAIN} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
} No, that's for mschap. Forget that section. You just want the first section for pap requests. and it should work? In part I ask because the examples for radiusd.conf and mschap.conf are different.
Yes they are. One is for processing pap and other for processing mschap requests.
I suspect I also have to put the reference to that new file (ntlm_rick in this case) into inner-tunnel as well? And in the virtual server config? In both the authorize{} and authenticate {} sections? Just authenticate and default virtual server. Inner tunnel is for peap.
Ivan Kalik
Hi all, Thanks to everyone for their help. I seem to have generated quite a bit of discussion so I thought I'd summarise where I'm "up to" in case it helps. I have a server successfully authenticating users using eap-mschapv2 or eap-ttls for eduroam and wired 802.1x. I'm now trying to expand the system to include authorisation/authentication for console and telnet access to cisco switches. For telnet access, I now have: A new file modules/ntlm_auth which contains, exec ntlm_auth { wait = yes program = "/usr/sfw/bin/ntlm_auth --request-nt-key --username=%{User-Name} --password=%{User-Password}" } At the end of the users file, DEFAULT NAS-Port-Type = Virtual, NAS-IP-Address = x.x.x.x, Auth-Type := ntlm_auth And at the end of the sites-enabled/default and sites-enabled/inner-tunnel authenticate sections, immediately after eap ntlm_auth It works though interestingly (for me at least) if I comment out ntlm_auth from the inner-tunnel file, the server fails to start with an "Unknown value ntlm_auth for attribute Auth-Type" error. I don't understand that as I don't want to use this authentication method with peap! Obviously the users entry above only works for a single switch as the IP address is specified. Next step is to specify groups of switches. Thanks again, Leighton --- This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.
I have a server successfully authenticating users using eap-mschapv2 or eap-ttls for eduroam and wired 802.1x. I'm now trying to expand the system to include authorisation/authentication for console and telnet access to cisco switches.
For telnet access, I now have:
A new file modules/ntlm_auth which contains,
exec ntlm_auth { wait = yes program = "/usr/sfw/bin/ntlm_auth --request-nt-key --username=%{User-Name} --password=%{User-Password}" }
At the end of the users file,
DEFAULT NAS-Port-Type = Virtual, NAS-IP-Address = x.x.x.x, Auth-Type := ntlm_auth
Put this after pap in authorize section of default virtual server instead: if(!control:Auth-Type) { update control { Auth-Type - "ntlm_auth" } }
And at the end of the sites-enabled/default and sites-enabled/inner-tunnel authenticate sections, immediately after eap
ntlm_auth
It works though interestingly (for me at least) if I comment out ntlm_auth from the inner-tunnel file, the server fails to start with an "Unknown value ntlm_auth for attribute Auth-Type" error. I don't understand that as I don't want to use this authentication method with peap!
That's because users file is common for both (all) virtual servers. If you use that unlang you don't need an entry in inner-tunnel server.
Obviously the users entry above only works for a single switch as the IP address is specified. Next step is to specify groups of switches.
Just adapt if statement so it fires when you want it to. You can add Huntgroup-Name oor something like that into it.
participants (5)
-
Alan Buxey -
freeradius＠corwyn.net -
Ivan Kalik -
Leighton Man -
tnt＠kalik.net