Suse SLES 10SP2 with freeradius 2.x
Hello, has anyone running freeradius v. 2x running on SLES 10 against edirectory? Best regards Boert
Do you have something to ask or are you conducting a survey? Ivan Kalik Kalik Informatika ISP Dana 27/10/2008, "Hubert Kupper" <kupper@uni-landau.de> piše:
Hello,
has anyone running freeradius v. 2x running on SLES 10 against edirectory?
Best regards Boert
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
tnt@kalik.net schrieb:
Do you have something to ask or are you conducting a survey?
Ivan Kalik Kalik Informatika ISP
Dana 27/10/2008, "Hubert Kupper" <kupper@uni-landau.de> piše:
Hello,
has anyone running freeradius v. 2x running on SLES 10 against edirectory?
Best regards Boert
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- I have something to ask. With SLES there comes only freeradius 1.1.0-19.9 and with this version no Vista Clients can authenticate. I found a 1.1.6-2.1 rpm and installed it. Now I will update to a newer version but there is no rpm for SLES 10 available. When I try to compile freeradius v. 2.x then there are problems with shared libraries they are not available in SLES. On a Opensuse 11.0 machine the 2.0.5 version runs fine and authenticate against edirectory.
Boert
I am running FR 2.1.0 OK on SLES10SP1 against edir LDAP backend. The way I did it, I installed the C/C++ Compiler and Tools in the Yast patterned setup. This takes care of a number of dependencies. If you don't want to do this, simply install the required deps later but there will be quite a few of them. Backup your /etc/raddb and uninstall your existing FR 1.x first. I would suggest deleting /etc/raddb and do a clean slate install. As long as you backed up your config you can refer to the old files. Build using rpmbuild having first extracted the freeradius.spec from the archive and placed in the SPECS folder as per the build instructions on freeradius.org. Depending on the archive you are using, you may need to modify the spec file a bit. Search the list for freeradius.spec. The build process should complete successfully. Any errors you need to post here. When you install the rpms you may need to install some dependencies - using Yast you may need to check the "provides" checkbox if you are searching for a .so file. As I recall (fuzzy memory). Once installed you can run radiusd -X and you may need to chown some of the files in /etc/raddb/certs, the debug output will tell you which ones. Done, now you can modify those config files - especially modules/ldap. 2008/10/28 Hubert Kupper <kupper@uni-landau.de>:
I have something to ask. With SLES there comes only freeradius 1.1.0-19.9 and with this version no Vista Clients can authenticate. I found a 1.1.6-2.1 rpm and installed it. Now I will update to a newer version but there is no rpm for SLES 10 available. When I try to compile freeradius v. 2.x then there are problems with shared libraries they are not available in SLES. On a Opensuse 11.0 machine the 2.0.5 version runs fine and authenticate against edirectory.
Boert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Graham Marsh schrieb:
I am running FR 2.1.0 OK on SLES10SP1 against edir LDAP backend.
The way I did it, I installed the C/C++ Compiler and Tools in the Yast patterned setup. This takes care of a number of dependencies. If you don't want to do this, simply install the required deps later but there will be quite a few of them.
Backup your /etc/raddb and uninstall your existing FR 1.x first. I would suggest deleting /etc/raddb and do a clean slate install. As long as you backed up your config you can refer to the old files.
Build using rpmbuild having first extracted the freeradius.spec from the archive and placed in the SPECS folder as per the build instructions on freeradius.org. Depending on the archive you are using, you may need to modify the spec file a bit. Search the list for freeradius.spec.
The build process should complete successfully. Any errors you need to post here.
When you install the rpms you may need to install some dependencies - using Yast you may need to check the "provides" checkbox if you are searching for a .so file. As I recall (fuzzy memory).
Once installed you can run radiusd -X and you may need to chown some of the files in /etc/raddb/certs, the debug output will tell you which ones. Done, now you can modify those config files - especially modules/ldap.
I have build the rpm's without errors. Before I had to edit the freeradius.spec file and comment out autoreconf. After radiusd -X I get the following errors: -------------------------------- conns: 0x81641b0 Module: Linked to module rlm_eap Module: Instantiating eap eap { default_eap_type = "peap" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no } Module: Linked to sub-module rlm_eap_md5 Module: Instantiating eap-md5 Module: Linked to sub-module rlm_eap_leap Module: Instantiating eap-leap Module: Linked to sub-module rlm_eap_gtc Module: Instantiating eap-gtc gtc { challenge = "Password: " auth_type = "PAP" } rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support. Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } rlm_eap: No such sub-type for default EAP type peap /etc/raddb/eap.conf[9]: Instantiation failed for module "eap" /etc/raddb/radiusd.conf[1816]: Failed to find module "eap". /etc/raddb/radiusd.conf[1762]: Errors parsing authenticate section. } Errors initializing modules -------------------------------- eap.conf: # # Whatever you do, do NOT set 'Auth-Type := EAP'. The server # is smart enough to figure this out on its own. The most # common side effect of setting 'Auth-Type := EAP' is that the # users then cannot use ANY other authentication method. # # $Id: eap.conf,v 1.4 2004/04/15 18:34:41 aland Exp $ # eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = peap # A list is maintained to correlate EAP-Response # packetS With EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # timer_expire = 60 # There are many EAP types, but the server has support # for only a limited subset. If the server receives # a request for an EAP type it does not support, then # it normally rejects the request. By setting this # configuration to "yes", you can tell the server to # instead keep processing the request. Another module # MUST then be configured to proxy the request to # another RADIUS server which supports that EAP type. # # If another module is NOT configured to handle the # request, then the request will still end up being # rejected. ignore_unknown_eap_types = no # Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given # a User-Name attribute in an Access-Accept, it copies one # more byte than it should. # # We can work around it by configurably adding an extra # zero byte. cisco_accounting_username_bug = no # Supported EAP-types # # We do NOT recommend using EAP-MD5 authentication # for wireless connections. It is insecure, and does # not provide for dynamic WEP keys. # md5 { } # Cisco LEAP # # We do not recommend using LEAP in new deployments. See: # http://www.securiteam.com/tools/5TP012ACKE.html # # Cisco LEAP uses the MS-CHAP algorithm (but not # the MS-CHAP attributes) to perform it's authentication. # # As a result, LEAP *requires* access to the plain-text # User-Password, or the NT-Password attributes. # 'System' authentication is impossible with LEAP. # leap { } # Generic Token Card. # # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. # gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: " # The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # auth_type = PAP } ## EAP-TLS # # To generate ctest certificates, run the script # # ../scripts/certs.sh # # The documents on http://www.freeradius.org/doc # are old, but may be helpful. # # See also: # # http://www.dslreports.com/forum/remark,9286052~mode=flat # tls { private_key_password = ********* private_key_file = /etc/raddb/certs/hamlet.rz.uni-landau.de.key # If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. certificate_file = /etc/raddb/certs/hamlet.rz.uni-landau.de.cert # Trusted Root CA list CA_file = /etc/raddb/certs/UNI-Landau-CA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = /etc/raddb/certs/random # # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # fragment_size = 1024 # include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # include_length = yes # Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash <CA certs&CRLs Directory>'. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=<CA certs&CRLs directory>' # to radiusd.conf's tls section. # 4) uncomment the line below. # 5) Restart radiusd check_crl = no # # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # check_cert_cn = %{User-Name} } # The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # # The TTLS module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-TTLS does not # require a client certificate. # ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. default_eap_type = md5 # The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} copy_request_to_tunnel = yes # The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} use_tunneled_reply = yes } # # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TLS/PEAP tunnel, we # recommend using EAP-MS-CHAPv2. # # The PEAP module needs the TLS module to be installed # and configured, in order to use the TLS tunnel # inside of the EAP packet. You will still need to # configure the TLS module, even if you do not want # to deploy EAP-TLS in your network. Users will not # be able to request EAP-TLS, as it requires them to # have a client certificate. EAP-PEAP does not # require a client certificate. # peap { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. default_eap_type = mschapv2 } # # This takes no configuration. # # Note that it is the EAP MS-CHAPv2 sub-module, not # the main 'mschap' module. # # Note also that in order for this sub-module to work, # the main 'mschap' module MUST ALSO be configured. # # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. # mschapv2 { } } -------------------------------- Openssl is already installed. Any ideas? Boert
No idea, sorry. You say this is SLES10SP2 which I haven't used, have you tried - FR2.1.0? - clean slate install perhaps in a VM? - fall back to SLES10SP1? Other than that I have nothing to suggest ----- Original Message ----- > rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support.
rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support. Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } rlm_eap: No such sub-type for default EAP type peap /etc/raddb/eap.conf[9]: Instantiation failed for module "eap" /etc/raddb/radiusd.conf[1816]: Failed to find module "eap". /etc/raddb/radiusd.conf[1762]: Errors parsing authenticate section. } Errors initializing modules --------------------------------
-------------------------------- Openssl is already installed. Any ideas?
Boert
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
You probably need to link to openssl in configure. Something like: http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg19160.html Ivan Kalik Kalik Informatika ISP Dana 28/10/2008, "Graham Marsh" <graham@netmarsh.com> piše:
No idea, sorry. You say this is SLES10SP2 which I haven't used, have you tried - FR2.1.0? - clean slate install perhaps in a VM? - fall back to SLES10SP1?
Other than that I have nothing to suggest
----- Original Message ----- > rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support.
rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support. Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } rlm_eap: No such sub-type for default EAP type peap /etc/raddb/eap.conf[9]: Instantiation failed for module "eap" /etc/raddb/radiusd.conf[1816]: Failed to find module "eap". /etc/raddb/radiusd.conf[1762]: Errors parsing authenticate section. } Errors initializing modules --------------------------------
-------------------------------- Openssl is already installed. Any ideas?
Boert
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Interesting the "getting" page only links to the old 1.x versions - an omission? In any case you can just get the old 2.x from here ftp://ftp.freeradius.org/pub/freeradius/old/ ----- Original Message ----- From: "Hubert Kupper" <kupper@uni-landau.de> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, October 28, 2008 9:08 PM Subject: Re: Suse SLES 10SP2 with freeradius 2.x
Graham Marsh schrieb:
No idea, sorry. You say this is SLES10SP2 which I haven't used, have you tried - FR2.1.0? - clean slate install perhaps in a VM? - fall back to SLES10SP1?
Other than that I have nothing to suggest
where can I get FR2.1.0 source?
Boert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Interesting the "getting" page only links to the old 1.x versions - an omission? In any case you can just get the old 2.x from here ftp://ftp.freeradius.org/pub/freeradius/old/
getting an older version wont help - it'll also fail the OpenSSL stuff simply because its a compilation problem. alan
Hi,
I have build the rpm's without errors. Before I had to edit the freeradius.spec file and comment out autoreconf. After radiusd -X I get the following errors:
yep - you build it without openssl-devel package installed - it clearly says in the log
rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support.
see. no OpenSSL support. install the openssl dev/headers package and rebuild alan
A.L.M.Buxey@lboro.ac.uk schrieb:
Hi,
I have build the rpm's without errors. Before I had to edit the freeradius.spec file and comment out autoreconf. After radiusd -X I get the following errors:
yep - you build it without openssl-devel package installed - it clearly says in the log
rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support.
see. no OpenSSL support.
install the openssl dev/headers package and rebuild
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, I reinstalled openssl and openssl-devel then I rebuild FR 2.1 but the errors were the same. Then I installed a FR 2.0.5 rpm which runs fine on OpenSuse 11.0 and get the same errors. When I reinstall FR 1.6 then it works fine!! Boert
I used i386 version of SLES10SP1. Are you using that one or x86_64 version? If using the latter, try the former. On Wed, Oct 29, 2008 at 3:01 PM, Hubert Kupper <kupper@uni-landau.de> wrote:
A.L.M.Buxey@lboro.ac.uk schrieb:
Hi,
I have build the rpm's without errors. Before I had to edit the freeradius.spec file and comment out autoreconf. After radiusd -X I get the following errors:
yep - you build it without openssl-devel package installed - it clearly says in the log
rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support.
see. no OpenSSL support.
install the openssl dev/headers package and rebuild
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I reinstalled openssl and openssl-devel then I rebuild FR 2.1 but the errors were the same. Then I installed a FR 2.0.5 rpm which runs fine on OpenSuse 11.0 and get the same errors. When I reinstall FR 1.6 then it works fine!!
Boert
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Did you rebuild from source obtained from freeradius.org or a src.rpm? The RPMs are maintained by Suse. Sent from my iPhone On 29 Oct 2008, at 07:01, Hubert Kupper <kupper@uni-landau.de> wrote:
A.L.M.Buxey@lboro.ac.uk schrieb:
Hi,
I have build the rpm's without errors. Before I had to edit the freeradius.spec file and comment out autoreconf. After radiusd -X I get the following errors:
yep - you build it without openssl-devel package installed - it clearly says in the log
rlm_eap: Ignoring EAP-Type/tls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/ttls because we do not have OpenSSL support. rlm_eap: Ignoring EAP-Type/peap because we do not have OpenSSL support.
see. no OpenSSL support.
install the openssl dev/headers package and rebuild
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I reinstalled openssl and openssl-devel then I rebuild FR 2.1 but the errors were the same. Then I installed a FR 2.0.5 rpm which runs fine on OpenSuse 11.0 and get the same errors. When I reinstall FR 1.6 then it works fine!!
Boert
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Anders Holm schrieb:
Did you rebuild from source obtained from freeradius.org or a src.rpm? The RPMs are maintained by Suse.
Sent from my iPhone
On 29 Oct 2008, at 07:01, Hubert Kupper <kupper@uni-landau.de> wrote:
I tried both. The source from freeradius.org and a FR2.0.5 rpm from suse. Boert
This a 64 bit system that also has 32 bit libs? Sent from my iPhone On 29 Oct 2008, at 08:09, Hubert Kupper <kupper@uni-landau.de> wrote:
Anders Holm schrieb:
Did you rebuild from source obtained from freeradius.org or a src.rpm? The RPMs are maintained by Suse.
Sent from my iPhone
On 29 Oct 2008, at 07:01, Hubert Kupper <kupper@uni-landau.de> wrote:
I tried both. The source from freeradius.org and a FR2.0.5 rpm from suse.
Boert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
found a 1.1.6-2.1 rpm and installed it. Now I will update to a newer version but there is no rpm for SLES 10 available. When I try to compile freeradius v. 2.x then there are problems with shared libraries they are not available in SLES. On a Opensuse 11.0 machine the 2.0.5 version runs fine and authenticate against edirectory.
they (libraries) are available for SLES - they are standard libraries and headers- they just need to be installed. to install freeradius from source you will need the GCC compiler installed, make, automake, autoconf, openssl-devel, etc. basically, if you do the ./configure method, then just grep the output for warnings...eg ./configure | grep WARN you will see what it cannot find to make certain parts - so include the required devel parts . if you dont want/need eg IKEv2 then dont worry. if you want to SNMP of sniff etc, then install net-snmp packages (and development libraries) and lib-pcap respectively. alternatively, FreeRADIUS source comes with a SUSE .spec file for building with the rpmbuild system. use that. post any errors to the list, other SUSE folk can help you with this... alan
Boert - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Anders Holm -
Graham Marsh -
Hubert Kupper -
tnt＠kalik.net