EAP-TTLS (PAP) not working with NT domain - debian freeradius 1.1.7
Okey, i've searched and searched for a hint, hopefully this isn't one of those RTFM messages, and hopefully I didn't read an invalid FM ;-) I'm trying to "emulate" the edunet network wireless roaming network, which primarily uses (in this order): EAP-TTLS PEAP EAP-MSCHAPv2 My Access point is a router running the DD-WRT firmware which AFAICT should work fine for 802.1x support. I first started on this page: http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-... which provides instructions on rebuilding the debian freeradius 1.1.7 package with ttls/peap/etc.. I'm authenticating from our local NT domain since we already have it, and in theory, these particular auth choices all work fine with the ntdomain password - according to the "Deploying Radius: The Book" chart I found online. With that, and a few configuration options (like making sure the host was connected to the domain and ntlm_auth functioned as required), i've managed to get PEAP and EAP-MSCHAPv2 working fine to the ntdomain. EAP-TTLS works fine with an account in the "users" file that has a clear text password, as well as a local /etc/password account. Ideally this should work with the ntdomain as well. I'm testing with a laptop running XP, with the secureW2 package installed to provide TTLS. I've also installed "NTRadPing" which provides the same failure result. Hopefully someone will have an idea, or a swift kick in the head pointing to a better direction. ---------------------------------- dns1:/etc/freeradius# freeradius -X Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /etc/freeradius/proxy.conf Config: including file: /etc/freeradius/clients.conf Config: including file: /etc/freeradius/snmp.conf Config: including file: /etc/freeradius/eap.conf Config: including file: /etc/freeradius/sql.conf main: prefix = "/usr" main: localstatedir = "/var" main: logdir = "/var/log/freeradius" main: libdir = "/usr/lib/freeradius" main: radacctdir = "/var/log/freeradius/radacct" main: hostname_lookups = no main: snmp = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/var/log/freeradius/radius.log" main: log_auth = yes main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/var/run/freeradius/freeradius.pid" main: user = "freerad" main: group = "freerad" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/sbin/checkrad" main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = no proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/lib/freeradius Module: Loaded exec exec: wait = yes exec: program = "(null)" exec: input_pairs = "request" exec: output_pairs = "(null)" exec: packet_type = "(null)" rlm_exec: Wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded PAP pap: encryption_scheme = "crypt" pap: auto_header = yes Module: Instantiated pap (pap) Module: Loaded MS-CHAP mschap: use_mppe = no mschap: require_encryption = yes mschap: require_strong = yes mschap: with_ntdomain_hack = yes mschap: passwd = "(null)" mschap: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{Stripped-User-Name:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" Module: Instantiated mschap (mschap) Module: Loaded System unix: cache = no unix: passwd = "(null)" unix: shadow = "/etc/shadow" unix: group = "(null)" unix: radwtmp = "/var/log/freeradius/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) Module: Loaded eap eap: default_eap_type = "ttls" eap: timer_expire = 60 eap: ignore_unknown_eap_types = no eap: cisco_accounting_username_bug = no rlm_eap: Loaded and initialized type md5 rlm_eap: Loaded and initialized type leap gtc: challenge = "Password: " gtc: auth_type = "PAP" rlm_eap: Loaded and initialized type gtc tls: rsa_key_exchange = no tls: dh_key_exchange = yes tls: rsa_key_length = 512 tls: dh_key_length = 512 tls: verify_depth = 0 tls: CA_path = "(null)" tls: pem_file_type = yes tls: private_key_file = "/etc/freeradius/certs/radius.key.pem" tls: certificate_file = "/etc/freeradius/certs/radius.pem" tls: CA_file = "/etc/freeradius/certs/newca.pem" tls: private_key_password = "(null)" tls: dh_file = "/etc/freeradius/certs/dh" tls: random_file = "/etc/freeradius/certs/random" tls: fragment_size = 1024 tls: include_length = yes tls: check_crl = no tls: check_cert_cn = "(null)" tls: cipher_list = "(null)" tls: check_cert_issuer = "(null)" rlm_eap_tls: Loading the certificate file as a chain rlm_eap: Loaded and initialized type tls ttls: default_eap_type = "gtc" ttls: copy_request_to_tunnel = no ttls: use_tunneled_reply = no rlm_eap: Loaded and initialized type ttls peap: default_eap_type = "mschapv2" peap: copy_request_to_tunnel = no peap: use_tunneled_reply = no peap: proxy_tunneled_request_as_eap = yes rlm_eap: Loaded and initialized type peap mschapv2: with_ntdomain_hack = no rlm_eap: Loaded and initialized type mschapv2 Module: Instantiated eap (eap) Module: Loaded preprocess preprocess: huntgroups = "/etc/freeradius/huntgroups" preprocess: hints = "/etc/freeradius/hints" preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = yes preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = no preprocess: with_alvarion_vsa_hack = no Module: Instantiated preprocess (preprocess) Module: Loaded realm realm: format = "suffix" realm: delimiter = "@" realm: ignore_default = no realm: ignore_null = no Module: Instantiated realm (suffix) realm: format = "prefix" realm: delimiter = "\" realm: ignore_default = no realm: ignore_null = no Module: Instantiated realm (ntdomain) Module: Loaded files files: usersfile = "/etc/freeradius/users" files: acctusersfile = "/etc/freeradius/acct_users" files: preproxy_usersfile = "/etc/freeradius/preproxy_users" files: compat = "no" Module: Instantiated files (files) Module: Loaded Acct-Unique-Session-Id acct_unique: key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" Module: Instantiated acct_unique (acct_unique) Module: Loaded detail detail: detailfile = "/var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d" detail: detailperm = 384 detail: dirperm = 493 detail: locking = no Module: Instantiated detail (detail) Module: Loaded radutmp radutmp: filename = "/var/log/freeradius/radutmp" radutmp: username = "%{User-Name}" radutmp: case_sensitive = yes radutmp: check_with_nas = yes radutmp: perm = 384 radutmp: callerid = yes Module: Instantiated radutmp (radutmp) Listening on authentication *:1812 Listening on accounting *:1813 Ready to process requests. These are failed tests from NTRadPing - let me know if you'd prefer to see something from the actual failed wireless AP session (which is much longer due to the eap/ssl encryption, etc..). rad_recv: Access-Request packet from host 172.16.13.254:2752, id=6, length=46 User-Name = "jamesm" User-Password = "*******" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "jamesm", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_realm: No '\' in User-Name = "jamesm", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "ntdomain" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 159 modcall[authorize]: module "files" returns ok for request 0 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 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 modcall[authenticate]: module "unix" returns notfound for request 0 modcall: leaving group authenticate (returns notfound) for request 0 auth: Failed to validate the user. Login incorrect: [jamesm] (from client moodie port 0) Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 6 to 172.16.13.254 port 2752 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 6 with timestamp 47e13ada Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 172.16.13.254:2753, id=7, length=53 User-Name = "jamesm@MOODIE" User-Password = "*********" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: Looking up realm "MOODIE" for User-Name = "jamesm@MOODIE" rlm_realm: No such realm "MOODIE" modcall[authorize]: module "suffix" returns noop for request 1 rlm_realm: No '\' in User-Name = "jamesm@MOODIE", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "ntdomain" returns noop for request 1 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 1 users: Matched entry DEFAULT at line 159 modcall[authorize]: module "files" returns ok for request 1 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 1 modcall: leaving group authorize (returns ok) for request 1 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 modcall[authenticate]: module "unix" returns notfound for request 1 modcall: leaving group authenticate (returns notfound) for request 1 auth: Failed to validate the user. Login incorrect: [jamesm@MOODIE] (from client moodie port 0) Delaying request 1 for 1 seconds Finished request 1 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 7 to 172.16.13.254 port 2753 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 1 ID 7 with timestamp 47e13b09 Nothing to do. Sleeping until we see a request. -- James A. McOrmond Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
Hi,
Okey, i've searched and searched for a hint, hopefully this isn't one of those RTFM messages, and hopefully I didn't read an invalid FM ;-)
I'm trying to "emulate" the edunet network wireless roaming network, which primarily uses (in this order):
EAP-TTLS PEAP EAP-MSCHAPv2
My Access point is a router running the DD-WRT firmware which AFAICT should work fine for 802.1x support.
I first started on this page: http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-... which provides instructions on rebuilding the debian freeradius 1.1.7 package with ttls/peap/etc..
I'm authenticating from our local NT domain since we already have it, and in theory, these particular auth choices all work fine with the ntdomain password - according to the "Deploying Radius: The Book" chart I found online.
With that, and a few configuration options (like making sure the host was connected to the domain and ntlm_auth functioned as required), i've managed to get PEAP and EAP-MSCHAPv2 working fine to the ntdomain.
EAP-TTLS works fine with an account in the "users" file that has a clear text password, as well as a local /etc/password account. Ideally this should work with the ntdomain as well. I'm testing with a laptop running XP, with the secureW2 package installed to provide TTLS.
if you are using EAP-TTLS/PAP then you'll need a plain text password - this can be done via kerberos to the AD. otherwise EAP-TTLS/MSCHAPv2 should work just like PEAP i'd advise to get id of the DEFAULT Auth := System line from the users file alan
With that, and a few configuration options (like making sure the host was connected to the domain and ntlm_auth functioned as required), i've managed to get PEAP and EAP-MSCHAPv2 working fine to the ntdomain.
EAP-TTLS works fine with an account in the "users" file that has a clear text password, as well as a local /etc/password account. Ideally this should work with the ntdomain as well. I'm testing with a laptop running XP, with the secureW2 package installed to provide TTLS.
if you are using EAP-TTLS/PAP then you'll need a plain text password - this can be done via kerberos to the AD. This is a Samba NT domain, not AD. I do not have access to the plain text password through Samba or LDAP.
The "Protocol and Password Compatibility" chart and the "Authenticaiton Systems and Password Compatibility" chart from the "Deploying RADIUS: The Book" page specifically says PAP/ntlm_auth is functional. Regular CHAP is not because it requires the clear-text password.
otherwise EAP-TTLS/MSCHAPv2 should work just like PEAP
except when testing whether EAP-TTLS works, it doesn't help much.
i'd advise to get id of the DEFAULT Auth := System line from the users file
Done.. auth to the /etc/passwd accounts doesn't make much sense. -- James A. McOrmond (jamesm@xandros.com) Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
James McOrmond wrote:
This is a Samba NT domain, not AD. I do not have access to the plain text password through Samba or LDAP.
Samba is a lot friendlier about passwords than AD is.
The "Protocol and Password Compatibility" chart and the "Authenticaiton Systems and Password Compatibility" chart from the "Deploying RADIUS: The Book" page specifically says PAP/ntlm_auth is functional. Regular CHAP is not because it requires the clear-text password.
The issue is convincing the database to give FreeRADIUS *something* to use for authetnication. The web page lists ntlm_auth only because of AD limitations. With Samba, you just map the LDAP "ntpasswd" or "sambantpasswd" attribute to the RADIUS attribute. See ldap.attrmap. Alan DeKok.
Alan DeKok wrote:
James McOrmond wrote:
This is a Samba NT domain, not AD. I do not have access to the plain text password through Samba or LDAP.
Samba is a lot friendlier about passwords than AD is.
Of course it is.. <G> I probably should have mentioned samba in the original message.
The "Protocol and Password Compatibility" chart and the "Authenticaiton Systems and Password Compatibility" chart from the "Deploying RADIUS: The Book" page specifically says PAP/ntlm_auth is functional. Regular CHAP is not because it requires the clear-text password.
The issue is convincing the database to give FreeRADIUS *something* to use for authetnication. The web page lists ntlm_auth only because of AD limitations.
With Samba, you just map the LDAP "ntpasswd" or "sambantpasswd" attribute to the RADIUS attribute. See ldap.attrmap.
OK. definitely progress. It's authenticating with EAP-TTLS now as well.. But.. Using secureW2 in the windows client - if I put anything in the DOMAIN field, it doesn't work well - likely because my userid is still jamesm@MOODIE when it attempts to connect to ldap. possibly I have the ntdomain hack stuff wrong? or maybe some realm settings missing? suffix is enabled.. -- James A. McOrmond (jamesm@xandros.com) Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
James McOrmond wrote:
Using secureW2 in the windows client - if I put anything in the DOMAIN field, it doesn't work well - likely because my userid is still jamesm@MOODIE when it attempts to connect to ldap.
possibly I have the ntdomain hack stuff wrong? or maybe some realm settings missing? suffix is enabled..
You could add MOODIE as a LOCAL realm. See proxy.conf. Alan DeKok.
Okey, i've searched and searched for a hint, hopefully this isn't one of those RTFM messages, and hopefully I didn't read an invalid FM ;-)
Not hard enough ;-) http://lists.freeradius.org/pipermail/freeradius-users/2008-March/070076.htm... Ivan Kalik Kalik Informatika ISP
Hi,
I'm trying to "emulate" the edunet network wireless roaming network, which primarily uses (in this order):
what exactly is "edunet"? The only wireless roaming network in the educational sector I know of is * eduroam *. Are you speaking of that or something completely different? Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
Hi,
I'm trying to "emulate" the edunet network wireless roaming network, which primarily uses (in this order):
what exactly is "edunet"? The only wireless roaming network in the educational sector I know of is * eduroam *. Are you speaking of that or something completely different?
Yes, Eduroam is what i'm looking at now. Edunet is a project I worked on for dialup access at some of the local schools some 8+ years ago which was the last time I setup Radius (brain slip). -- James A. McOrmond (jamesm@xandros.com) Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
James McOrmond wrote:
With that, and a few configuration options (like making sure the host was connected to the domain and ntlm_auth functioned as required), i've managed to get PEAP and EAP-MSCHAPv2 working fine to the ntdomain.
The guides for *that* are online.
EAP-TTLS works fine with an account in the "users" file that has a clear text password, as well as a local /etc/password account. Ideally this should work with the ntdomain as well.
Yes. You will need to configure a *separate* module to do ntlm_auth authentication via PAP. Something like: exec ntlm_auth_pap { wait = yes input_pairs = request shell_escape = yes output = none program = "/path/to/ntlm_auth --username=%{User-Name} --domain=DOMAIN --password=%{User-Password}" } See 'exec echo' example for more docs. Then in the authenticate section, do; Auth-Type PAP { ntlm_auth_pap } That will force *all* PAP requests to use ntlm_auth, but it will work. Alan DeKok.
Alan DeKok wrote:
James McOrmond wrote:
With that, and a few configuration options (like making sure the host was connected to the domain and ntlm_auth functioned as required), i've managed to get PEAP and EAP-MSCHAPv2 working fine to the ntdomain.
The guides for *that* are online.
that's what made it easier :-)
EAP-TTLS works fine with an account in the "users" file that has a clear text password, as well as a local /etc/password account. Ideally this should work with the ntdomain as well.
Yes. You will need to configure a *separate* module to do ntlm_auth authentication via PAP.
Something like:
As per previous emails, since i'm using samba/ldap i'm able to pull the nt/lmpassword fields directly out of the ldap. Should this method negate the use of the ntlm_auth method? -- James A. McOrmond (jamesm@xandros.com) Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
As per previous emails, since i'm using samba/ldap i'm able to pull the nt/lmpassword fields directly out of the ldap. Should this method negate the use of the ntlm_auth method?
Yes. PAP can use nt hashed password. For password attribute mapping see ldap.attrmap. Ivan Kalik Kalik Informatika ISP
James McOrmond wrote:
As per previous emails, since i'm using samba/ldap i'm able to pull the nt/lmpassword fields directly out of the ldap. Should this method negate the use of the ntlm_auth method?
Yes. See ldap.attrmap. The LDAP module uses this to map LDAP attributes to RADIUS attributes. Once FreeRADIUS has an NT hash, it can authenticate users. Alan DeKok.
Alan DeKok wrote:
James McOrmond wrote:
As per previous emails, since i'm using samba/ldap i'm able to pull the nt/lmpassword fields directly out of the ldap. Should this method negate the use of the ntlm_auth method?
Yes.
See ldap.attrmap. The LDAP module uses this to map LDAP attributes to RADIUS attributes. Once FreeRADIUS has an NT hash, it can authenticate users.
Ok, so should I comment out the mschap section where the ntlm_auth command/method is defined? What about the other auth types? ms-chap/peap/eap-mschapv2,eap-gtc, will they work with the ntpassword pulled from ldap? -- James A. McOrmond (jamesm@xandros.com) Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
James McOrmond wrote:
Ok, so should I comment out the mschap section where the ntlm_auth command/method is defined?
Yes.
What about the other auth types? ms-chap/peap/eap-mschapv2,eap-gtc, will they work with the ntpassword pulled from ldap?
Yes. Alan DeKok.
Ok, it's me again.. back at this project.. it was working well enough for initial testing by others so I'd moved on.. I'm back at it.. At this point various auth methods work fine with the ntpasswords pulled from the domain ldap. What they'd like now is a generic "test" account - something not even in ldap. So, I figured the users file was a logical place.. I added a line like this: radiustester User-Password := "xoageifo" but it's complaining it's not in ldap.. Wed Apr 9 16:07:22 2008 : Info: rlm_eap_mschapv2: Issuing Challenge Wed Apr 9 16:07:22 2008 : Auth: Login incorrect (rlm_ldap: User not found): [radiustester] (from client localhost port 0) Wed Apr 9 16:07:22 2008 : Auth: Login incorrect (rlm_ldap: User not found): [radiustester] (from client moodie port 29 cli 001302038917) Alan DeKok wrote:
James McOrmond wrote:
What about the other auth types? ms-chap/peap/eap-mschapv2,eap-gtc, will they work with the ntpassword pulled from ldap?
Yes.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- James A. McOrmond (jamesm@xandros.com) Network Administrator Xandros Corporation, Ottawa, Canada. Morpheus: ...after a century of war I remember that which matters most: *We are still HERE!*
I added a line like this:
radiustester User-Password := "xoageifo"
And that's not going to match as there is no User-Password in the request. Read the instructions in users file which password attribute should be used.
but it's complaining it's not in ldap..
Wed Apr 9 16:07:22 2008 : Info: rlm_eap_mschapv2: Issuing Challenge Wed Apr 9 16:07:22 2008 : Auth: Login incorrect (rlm_ldap: User not found): [radiustester] (from client localhost port 0) Wed Apr 9 16:07:22 2008 : Auth: Login incorrect (rlm_ldap: User not found): [radiustester] (from client moodie port 29 cli 001302038917)
What information about users file (that is where you entered users details) does this peace of debug give? By removing relevant information from the debug you make it hard(er) for people to help you. Ivan Kalik Kalik Informatika ISP
James McOrmond wrote:
So, I figured the users file was a logical place..
Yes, if it's used, and if the rest of the policy is fine.
I added a line like this:
radiustester User-Password := "xoageifo"
but it's complaining it's not in ldap..
Run it in debugging mode: radiusd -X. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Ivan Kalik -
James McOrmond -
Stefan Winter