On 19/10/2016 12:01, Brian Candler wrote:
I set a location and permissions to make it readable:
# ls -l /etc/radiusd.keytab
-rw-r----- 1 root freerad 386 Oct 19 10:59 /etc/radiusd.keytab
and now:
KRB5_CLIENT_KTNAME=/etc/radiusd.keytab freeradius -X
works just fine
There is a nasty risk though. The way I have it set up, the service principal in /etc/radiusd.keytab has special rights in the LDAP server to read the NT password hash; something which no other user has. However if I "kinit admin" so that I have an existing Kerberos ticket, and then start radiusd, it uses the existing ticket. And this means that user lookups fail: (0) Auth-Type MS-CHAP { (0) mschap: WARNING: No Cleartext-Password configured. Cannot create NT-Password (0) mschap: WARNING: No Cleartext-Password configured. Cannot create LM-Password (0) mschap: Client is using MS-CHAPv1 with NT-Password (0) mschap: ERROR: FAILED: No NT/LM-Password. Cannot perform authentication (0) mschap: ERROR: MS-CHAP2-Response is incorrect (0) [mschap] = reject The solution is to override the credentials cache type: KRB5CCNAME=MEMORY: KRB5_CLIENT_KTNAME=/etc/radiusd.keytab radiusd -X or: [Service] Environment=KRB5_CLIENT_KTNAME=/etc/radiusd.keytab Environment=KRB5CCNAME=MEMORY: (note: capital 'S' in Service appears to be required) Regards, Brian.