OK this is getting fun, two systems up, the first one I get working wins. - original system: SEL 12.1 Freeradius install via repo binaries 3.0.4 I'm familiar with 2.x but 3.x has a few differences. I am guessing that this needs to be changed in /etc/raddb/sites-enabled/default Emailing from my phone is a bit painful. -second system after getting the email about Freeradius 3.1.0 with patch for crypt. Ubuntu x86_64 14.04 cloned from github about three hours ago. Freeradius 3.1.0 Still trying to figure out what is wrong with my /dev/urandom file set in /etc/freeradius/mods-enabled/ldap Seems like on both RHEL 7.x and Ubuntu 14.04 when I compile from source and run either freeradius -X the first thing that it complained about was: random_file = /dev/urandom is world writable. Quick chmod 644 and then I get an unknown error trying to set the random_file. Is there a fix for this? On Jan 28, 2016 00:30, "David Lord" <d.lord@its.uq.edu.au> wrote:
Apologies, I was a bit quick on the retort there. Please disregard.
On 28 Jan 2016, at 6:25 PM, David Lord <d.lord@its.uq.edu.au> wrote:
Which of these looks right?
authenticate { pap ldap }
authenticate { ldap pap }
On 28 Jan 2016, at 6:06 PM, Will W. <will@damagesinc.net> wrote:
Ok, how do I change the order in which ldap and pap are called?
On Wed, Jan 27, 2016 at 2:13 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On Jan 27, 2016, at 5:08 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On Jan 27, 2016, at 4:36 PM, Will W. <will@damagesinc.net> wrote:
Question With Start_TLS yes this is enabling the Freeradius to connect to the LDAP server over a TLS tunnel correct?
Yes, the connection starts off as plaintext, then the ldap client requests to establish a TLS tunnel.
Map looks OK. You need to run ldapsearch with this invocation to see
if
the userPassword is being returned:
ldapsearch -H ldap://ldap.myhost.com:389 —ZZ x -b
"ou=Users,dc=myhost,dc=com" -D "uid=demouser,ou=Users,dc=myhost,dc=com" -w testing123 "(objectClass=posixGroup)" userPassword
Here are the headers and what they map to:
/* * For auto-header discovery. * * @note Header comparison is case insensitive. */ static const FR_NAME_NUMBER header_names[] = { { "{clear}", PW_CLEARTEXT_PASSWORD }, { "{cleartext}", PW_CLEARTEXT_PASSWORD }, { "{md5}", PW_MD5_PASSWORD }, { "{base64_md5}", PW_MD5_PASSWORD }, { "{smd5}", PW_SMD5_PASSWORD }, { "{crypt}", PW_CRYPT_PASSWORD }, #ifdef HAVE_OPENSSL_EVP_H /* * It'd make more sense for the headers to be * ssha2-* with SHA3 coming soon but we're at * the mercy of directory implementors. */ { "{sha2}", PW_SHA2_PASSWORD }, { "{sha224}", PW_SHA2_PASSWORD }, { "{sha256}", PW_SHA2_PASSWORD }, { "{sha384}", PW_SHA2_PASSWORD }, { "{sha512}", PW_SHA2_PASSWORD }, { "{ssha224}", PW_SSHA2_224_PASSWORD }, { "{ssha256}", PW_SSHA2_256_PASSWORD }, { "{ssha384}", PW_SSHA2_384_PASSWORD }, { "{ssha512}", PW_SSHA2_512_PASSWORD }, #endif { "{sha}", PW_SHA_PASSWORD }, { "{ssha}", PW_SSHA_PASSWORD }, { "{md4}", PW_NT_PASSWORD }, { "{nt}", PW_NT_PASSWORD }, { "{nthash}", PW_NT_PASSWORD }, { "{x-nthash}", PW_NT_PASSWORD }, { "{ns-mta-md5}", PW_NS_MTA_MD5_PASSWORD }, { "{x- orcllmv}", PW_LM_PASSWORD }, { "{X- orclntv}", PW_NT_PASSWORD }, { NULL, 0 } };
You need to call the pap module in authorize after the LDAP module in order to strip the header and perform the conversion.
It also does a bunch of normalisation. It could be you have the modules in the wrong order, pap then ldap when you need ldap then pap.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html