It works w/o EAP. I can do a radtest with a valid userid and password on the kerberos server and get authorized (and not get authorized with bad information). I can get EAP-TTLS to work if I put a user and a password in the radius users file but that's not what we want. We need the kerberos piece to work. I'd be happy to send some config files along if that would help. I feel like I'm missing something small that's so obvious no one has thought to document it. We can get various parts working at any given moment with kerberos but we can't get it all working. Thanks, LB tnt@kalik.co.yu wrote:

It should be. Use EAP-TTLS/PAP and configure kerberos module in radiusd.conf:

http://wiki.freeradius.org/index.php/Rlm_krb5

Make sure that it works without EAP first.

Ivan Kalik Kalik Informatika ISP

Dana 10/10/2007, "Lisa Besko" <besko@msu.edu> piše:

...

Is there a way to do 802.1x with Kerberos authentication using Freeradius?

If their is can anyone point me in the right direction?

We have been trying eap-ttls most recently with very little luck but everything I have read says this should be possible. What are we missing?

Thanks for the help so far. Part of the problem is we have probably tried so many things we probably messed something up along the way don't remember what is is. I think I have all the right stuff in the config files. I'll do a little cut and paste here and maybe you will spot something I missed. radius.conf (and all the eap parts are uncommented as well): modules { ...... krb5 { # keytab containing the key used by rlm_krb5 keytab = /usr/local/raddb/nmserv.keytab # principal that is used by rlm_krb5 #service_principal = host/our.host.name@MSU.EDU } ..... pap { auto_header = yes } ........ } authenticate { Auth-Type PAP { pap } Auth-Type kerberos { krb5 } } ----------------------- eap.conf: eap { default_eap_type = ttls md5 { } tls { private_key_password = whatever private_key_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/cert-srv.pem CA_file = ${raddbdir}/certs/demoCA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random } ttls { default_eap_type = md5 copy_request_to_tunnel = yes use_tunneled_reply = yes } } users: DEFAULT Freeradius-Proxied-To == 127.0.0.1 Fall-Through = Yes DEFAULT Auth-Type := Kerberos Fall-Through = 1 Debug out put at the moment: rlm_realm: Looking up realm "msu.edu" for User-Name = "testuser@msu.edu" rlm_realm: Found realm "MSU.EDU" rlm_realm: Adding Stripped-User-Name = "testuser" rlm_realm: Proxying request from user testuser to realm MSU.EDU rlm_realm: Adding Realm = "MSU.EDU" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 4 rlm_eap: EAP packet type response id 1 length 18 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 4 users: Matched entry DEFAULT at line 10 modcall[authorize]: module "files" returns ok for request 4 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 4 modcall: leaving group authorize (returns updated) for request 4 rad_check_password: Found Auth-Type Kerberos auth: type "Kerberos" Processing the authenticate section of radiusd.conf modcall: entering group kerberos for request 4 rlm_krb5: Attribute "User-Password" is required for authentication. modcall[authenticate]: module "krb5" returns invalid for request 4 modcall: leaving group kerberos (returns invalid) for request 4 auth: Failed to validate the user. A.L.M.Buxey@lboro.ac.uk wrote:

no. you dont need to use the users file for the userid/password. you simply need to ensure that the krb5 module is in the Authorize section and that you have PAP enabled...and that you are using EAP-TTLS with PAP inner method.

so....your FR config needs at least the following configs...

radiusd.conf

in the authorize section

krb5 {

}

in the authenticate section (radiusd.conf for 1.1.x, sites-enabled/default for 2.x)

Auth-Type krb5 { krb5 }

you MAY configure krb5 in radiusd.... we havent found this actually necessary(!)

# krb5 { # keytab = /path/to/keytab # service_principal = name_of_principle # }

finally. if you are facing issues and you dont help with supplying a log file then please ensure that your RADIUS request isnt being b0rked by something in the users file eg

DEFAULT Auth-Type = System

you can at least change this to....

DEFAULT Auth-Type = krb5

just for checking(!!)

alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Lisa Besko

Lisa Besko wrote:

Thanks for the help so far. Part of the problem is we have probably tried so many things we probably messed something up along the way don't remember what is is.

Stop right there. If you don't keep track of what you're doing, you will NEVER get it to work. Throw away everything you've done, and start with all of the default configuration files. Then, proceed with the following steps: 1) Configure EAP-TTLS i.e. the "tls" and "ttls" sub-sections of eap.conf 2) Put the following at the TOP of the "users" file: bob Cleartext-Password := "bob" 3) Start the server in debug mode 4) validate that you can log in with "bob" using radtest (i.e. PAP) 5) validate that EAP-TTLS works with username/password "bob" and "bob" 6) Configure kerberos in radiusd.conf. 7) Delete the "bob" entry in the "users" file. 8) Replace it with: DEFAULT Auth-Type = Kerberos And it WILL work. ...

authenticate { Auth-Type PAP { pap }

Auth-Type kerberos { krb5 } }

If you don't list "eap" there, it won't work. Again, throw away your existing configuration files, and start from the default ones.

users: DEFAULT Freeradius-Proxied-To == 127.0.0.1 Fall-Through = Yes

That entry does nothing.

DEFAULT Auth-Type := Kerberos Fall-Through = 1

An earlier message in this thread said "Auth-Type = Kerberos". What you have above is different. PLEASE follow instructions carefully. Alan DeKok.

On Mon, 2007-10-15 at 12:22 -0400, Lisa Besko wrote:

Alan DeKok wrote:

...

...

DEFAULT Auth-Type := Kerberos Fall-Through = 1

An earlier message in this thread said "Auth-Type = Kerberos". What you have above is different.

An here in lies the problem. I just went back and tested this. I had been working with Walt Reynolds on the issue and we had shared some files and after that things started working with a Mac client but not with my Win XP client (one of the Xsupplicants we had installed had hosed the system so I couldn't tell when things had gotten better).

According to the man 5 users page:

Auth-Type = Kerberos is allowed for a server configuration variable such as Auth-Type, where as

Auth-Type := Kerberos (note the Colon before the equal sign) is a check item and replaces in the configuration items any attribute of the same name.

Having the colon there or not there made a very big difference in how it behaved.

Slight clarification: "Auth-Type = Kerberos" sets Auth-Type IF AND ONLY IF it's unset "Auth-Type := Kerberos" sets Auth-Type unconditionally The reason the former works and the latter fails is due to the following: authorize { preprocess eap files } authorize { eap Auth-Type Kerberos { krb5 } } ...with this in "users" name Auth-Type = Kerberos The flow through this is: 1. Access-Request/EAP-Message passes through authorize a. preprocess b. eap - sees EAP-Message, sets Auth-Type to EAP c. files - does not match (Auth-Type is already set) 2. Access-Request/EAP-Message passes through authenticate a. Auth-Type is "EAP", eap module runs 3. TTLS tunnel setup starts 4. Access-Challenge sent back to client 5. steps 1-4 repeated several times 6. EAP-TTLS tunnel established - the INNER packet is then looped back to the server as a PAP request 7. PAP request passes through authorize a. preprocess b. eap - does not match, no-op c. files - matches, sets Auth-Type to Kerberos 8. PAP request passes through authenticate a. krb5 called, authenticates PAP request 9. Access-Accept or Access-Reject sent back to TTLS session 10. EAP-TTLS tunnel sends Accept or Reject to client If you use "Auth-Type := Kerberos", this becomes: 1. EAP a. preprocess b. eap - Auth-Type set to EAP c. files - Auth-Type overriden with Kerberos 2. EAP (authenticate) a. Auth-Type is kerberos - krb5 module called b. krb5 module fails, since the packet is an EAP packet (not PAP) Hope that helps.

Having made no changes to the config but using radtest from the command line this is the debug output using kerberos but not EAP: rad_recv: Access-Request packet from host 127.0.0.1:49649, id=40, length=65 User-Name = "testuser@msu.edu" User-Password = "XXXXXXXXXXXX" NAS-IP-Address = 255.255.255.255 NAS-Port = 0 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 33 modcall[authorize]: module "preprocess" returns ok for request 33 modcall[authorize]: module "chap" returns noop for request 33 modcall[authorize]: module "mschap" returns noop for request 33 rlm_realm: Looking up realm "msu.edu" for User-Name = "testuser@msu.edu" rlm_realm: Found realm "MSU.EDU" rlm_realm: Adding Stripped-User-Name = "testuser" rlm_realm: Proxying request from user testuser to realm MSU.EDU rlm_realm: Adding Realm = "MSU.EDU" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 33 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 33 users: Matched entry DEFAULT at line 5 modcall[authorize]: module "files" returns ok for request 33 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 33 modcall: leaving group authorize (returns ok) for request 33 rad_check_password: Found Auth-Type Kerberos auth: type "Kerberos" Processing the authenticate section of radiusd.conf modcall: entering group kerberos for request 33 rlm_krb5: verify_krb_v5_tgt: host key not found : No such file or directory modcall[authenticate]: module "krb5" returns ok for request 33 modcall: leaving group kerberos (returns ok) for request 33 Sending Access-Accept of id 40 to 127.0.0.1 port 49649 Finished request 33 Going to the next request ==================================================== This is from a message I posted earlier with kerberos and EAP. I hope that's enough of it for you since my client started acting up and now I have to beat on it a bit.: rlm_realm: Looking up realm "msu.edu" for User-Name = "testuser@msu.edu" rlm_realm: Found realm "MSU.EDU" rlm_realm: Adding Stripped-User-Name = "testuser" rlm_realm: Proxying request from user testuser to realm MSU.EDU rlm_realm: Adding Realm = "MSU.EDU" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 4 rlm_eap: EAP packet type response id 1 length 18 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 4 users: Matched entry DEFAULT at line 10 modcall[authorize]: module "files" returns ok for request 4 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 4 modcall: leaving group authorize (returns updated) for request 4 rad_check_password: Found Auth-Type Kerberos auth: type "Kerberos" Processing the authenticate section of radiusd.conf modcall: entering group kerberos for request 4 rlm_krb5: Attribute "User-Password" is required for authentication. modcall[authenticate]: module "krb5" returns invalid for request 4 modcall: leaving group kerberos (returns invalid) for request 4 auth: Failed to validate the user. ========================================= tnt@kalik.co.yu wrote:

Can you post the debug (radiusd -X) for the same user with and without EAP (using Kerberos - no users file entry).

Ivan Kalik kalik Informatika ISP

Dana 11/10/2007, "Lisa Besko" <besko@msu.edu> piše:

...

It works w/o EAP. I can do a radtest with a valid userid and password on the kerberos server and get authorized (and not get authorized with bad information).

I can get EAP-TTLS to work if I put a user and a password in the radius users file but that's not what we want. We need the kerberos piece to work. I'd be happy to send some config files along if that would help. I feel like I'm missing something small that's so obvious no one has thought to document it.

We can get various parts working at any given moment with kerberos but we can't get it all working.

Thanks,

LB

...

It should be. Use EAP-TTLS/PAP and configure kerberos module in radiusd.conf:

http://wiki.freeradius.org/index.php/Rlm_krb5

Make sure that it works without EAP first.

Ivan Kalik Kalik Informatika ISP

Dana 10/10/2007, "Lisa Besko" <besko@msu.edu> piše:

...

Is there a way to do 802.1x with Kerberos authentication using Freeradius?

If their is can anyone point me in the right direction?

We have been trying eap-ttls most recently with very little luck but everything I have read says this should be possible. What are we missing?

tnt@kalik.co.yu wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Lisa Besko Systems Administrator 517-432-7317 Network Management besko@msu.edu Academic Computing & Network Services