Re: Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code
On 06/15/2011 10:56 AM, Phil Mayers wrote: On 15/06/11 15:49, g17jimmy wrote: d'oh! it was SElinux. I had disabled it temporarily, but didn't set it as disabled in /etc/selinux/config so it was blocking the authentication. Well, IMHO disabling it altogether is not a good idea. You might want to consider just disabling it for FreeRADIUS: setsebool -P radiusd_disable_trans=1 Your choice of course. Please file a bug for the selinux policy component in the Redhat bugzilla. Dan Walsh is very good about fixing policy problems promptly. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code
On 15/06/11 15:49, g17jimmy wrote: d'oh! it was SElinux. I had disabled it temporarily, but didn't set it as disabled in /etc/selinux/config so it was blocking the authentication. Well, IMHO disabling it altogether is not a good idea. You might want to consider just disabling it for FreeRADIUS: setsebool -P radiusd_disable_trans=1 Your choice of course. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code
d'oh! it was SElinux. I had disabled it temporarily, but didn't set it as disabled in /etc/selinux/config so it was blocking the authentication. Phil Mayers wrote: > > On 06/14/2011 09:44 PM, Jimmy wrote: >> I have Kerberos 1.6 configured to use OpenLDAP 2.3.43 as a back end. I >> am trying to configure Freeradius 2.1.7 to authenticate to Kerberos. > > My advice would be to investigate having FreeRADIUS pull the user info > (secrets etc.) direct from LDAP. It'll save your sanity in the long run > (provided the secrets in LDAP are ones FreeRADIUS can make use of) > > But... > >> >> I am having problems getting Freeradiusto authenticate while started >> in daemon mode. When the process is started in debug mode it seems to >> funciton, but authentications while in daemon mode return the error: >> >>> Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied >>> in replay cache code > > So, in debug mode it's fine, but in daemon mode it's giving permission > denied errors as above? That error sounds like it's coming out of the > kerberos libraries, rather than FreeRADIUS. > > Try this: start it up in daemon mode, then use "strace" to record > syscalls: > > strace -o log -p > > ...do a test authentication, then hunt through the log for open() and > write() calls that fail i.e. return -1. That should tell you what file > it's trying to use as a replay cache. Then, fix the permissions so that > the daemon can access that file. > > Also, if you're running an LSM (SELinux, AppArmor) check their logs > (audit.log in the case of SELinux; no idea for AppArmor) to see if it's > a MAC policy, rather than uid/gid-based perms, that's denying it. > > Alternatively, you might be able to disable the replay cache using > entries in /etc/krb5.conf, but you'd have to do a bit of digging. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > -- View this message in context: http://freeradius.1045715.n5.nabble.com/Auth-rlm-krb5-test1-CSP-BACK-krb5-rd-req-failed-Permission-denied-in-replay-cache-code-tp4489262p4491473.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code
I haven't yet done a test using strace but wanted to add what I did find when I got started this morning. If I attempt to authenticate with the user test1, password `qwer` (the correct password,) I get this response: Wed Jun 15 08:40:19 2011 : Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code *But* if I use the wrong password `qwert` (or anything really) I get this response: Wed Jun 15 08:40:48 2011 : Auth: rlm_krb5: [test1@CSP-BACK] krb5_g_i_t_w_p failed: Decrypt integrity check failed Thanks! -- View this message in context: http://freeradius.1045715.n5.nabble.com/Auth-rlm-krb5-test1-CSP-BACK-krb5-rd-req-failed-Permission-denied-in-replay-cache-code-tp4489262p4491109.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code
On 06/14/2011 09:44 PM, Jimmy wrote: I have Kerberos 1.6 configured to use OpenLDAP 2.3.43 as a back end. I am trying to configure Freeradius 2.1.7 to authenticate to Kerberos. My advice would be to investigate having FreeRADIUS pull the user info (secrets etc.) direct from LDAP. It'll save your sanity in the long run (provided the secrets in LDAP are ones FreeRADIUS can make use of) But... I am having problems getting Freeradiusto authenticate while started in daemon mode. When the process is started in debug mode it seems to funciton, but authentications while in daemon mode return the error: Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req() failed: Permission denied in replay cache code So, in debug mode it's fine, but in daemon mode it's giving permission denied errors as above? That error sounds like it's coming out of the kerberos libraries, rather than FreeRADIUS. Try this: start it up in daemon mode, then use "strace" to record syscalls: strace -o log -p ...do a test authentication, then hunt through the log for open() and write() calls that fail i.e. return -1. That should tell you what file it's trying to use as a replay cache. Then, fix the permissions so that the daemon can access that file. Also, if you're running an LSM (SELinux, AppArmor) check their logs (audit.log in the case of SELinux; no idea for AppArmor) to see if it's a MAC policy, rather than uid/gid-based perms, that's denying it. Alternatively, you might be able to disable the replay cache using entries in /etc/krb5.conf, but you'd have to do a bit of digging. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
