Re: 802.1x, EAP and LDAP
On Tue, Mar 04, 2008 at 07:33:09AM +0100, Alan DeKok wrote: Mike Richardson wrote: I've been making changes for 8 hours a day for over a week so it might differ from the original. Which is a bit of a problem in and of itself. I posted the configs in the original email - was there anything in there which looked completely out of place? How does the config know to use PAP rather than CHAP/MSCHAP? Because all of the experience of the developers working for years with RADIUS is distilled into the configuration files. Is there any documentation on how this works? I would like to know. I've been through every config guide I can find on the net, several times. If it takes more than 10 minutes to get FreeRADIUS authenticating to LDAP, ask a question on the list. Honestly. It's *so* much better to get an answer on the list than to fight for a week... I don't mind fighting for a week if it works at the end and I have a better understanding. At this point it doesn't work but I do have a better understanding. Most software takes more than 10 minutes to understand and configure and I wouldn't be confident in my ability to support it campus wide if I'd only spend 10 mins on it. I don't believe in asking for help without doing as thorough as job as I can in experimenting and learning. Normally between time, trial and error and google things will work. In this case, unfortunately not. It's the first time I've had to post to a mailing list for help in many years and, no offence intended, it feels like I'm admitting defeat. My deployingradius.com site? It has a number of resources. Thanks, I'll take a look. Of course. Only Novell understands how eDirectory works. For LDAP, buy the O'Reilly OpenLDAP book. It has a good section on getting OpenLDAP FreeRADIUS to talk to each other. It's very quick... Thanks again. Mike -- Mike Richardson Networks IT Services, University of Manchester *Plain text only please - attachments stripped on arrival* - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: I posted the configs in the original email - was there anything in there which looked completely out of place? No idea. Honestly, I rarely look at configurations. There's just too much stuff there. I look at debug logs. And if the configuration has big problems, it's *really* not worth my time to look. That's why I keep saying start with the default config How does the config know to use PAP rather than CHAP/MSCHAP? Because all of the experience of the developers working for years with RADIUS is distilled into the configuration files. Is there any documentation on how this works? I would like to know. raddb/radiusd.conf. In short, the RADIUS Access-Request contains all of the information the server needs to determine the authentication method. The only requirement on the local administrator is to somehow tell the server a Cleartext-Password. I don't mind fighting for a week if it works at the end and I have a better understanding. At this point it doesn't work but I do have a better understanding. Most software takes more than 10 minutes to understand and configure and I wouldn't be confident in my ability to support it campus wide if I'd only spend 10 mins on it. I don't believe in asking for help without doing as thorough as job as I can in experimenting and learning. Sure. But the default configuration is *really* that simple for basic things like LDAP, SQL, and 802.1x. And version 2.0 is even easier. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Looks like something odd is going on. I've removed freeradius and
reinstalled it. I added the LDAP config and uncommented the various 'ldap'
lines,
see config.
Defintiely uncommented:
Auth-Type LDAP {
uni_ldap
}
This line still there:
rlm_ldap: Over-riding set_auth_type, as we're not listed in the authenticate
section.
The software is a debian package compiled with --with-rlm_eap as per
http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html
I've tested it with a user in the users file and it works fine.
My next move would be to install the default debian package (without EAP)
support and try that, then to try openldap unless you've got better
suggestions?
Thanks,
radiusd.conf:
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/freeradius
log_file = ${logdir}/radius.log
libdir = /usr/lib/freeradius
pidfile = ${run_dir}/freeradius.pid
user = freerad
group = freerad
max_request_time = 30
delete_blocked_requests = no
cleanup_delay = 5
max_requests = 1024
bind_address = *
port = 0
hostname_lookups = no
allow_core_dumps = no
regular_expressions = yes
extended_expressions= yes
log_stripped_names = no
log_auth = no
log_auth_badpass = no
log_auth_goodpass = no
usercollide = no
lower_user = no
lower_pass = no
nospace_user = no
nospace_pass = no
checkrad = ${sbindir}/checkrad
security {
max_attributes = 200
reject_delay = 1
status_server = no
}
proxy_requests = yes
$INCLUDE ${confdir}/proxy.conf
$INCLUDE ${confdir}/clients.conf
$INCLUDE ${confdir}/imported_clients.cfg
snmp= no
$INCLUDE ${confdir}/snmp.conf
thread pool {
start_servers = 5
max_servers = 32
min_spare_servers = 3
max_spare_servers = 10
max_requests_per_server = 0
}
modules {
pap {
auto_header = yes
}
chap {
authtype = CHAP
}
pam {
pam_auth = radiusd
}
unix {
cache = no
cache_reload = 600
shadow = /etc/shadow
radwtmp = ${logdir}/radwtmp
}
$INCLUDE ${confdir}/eap.conf
mschap {
}
ldap original {
server = ldap.your.domain
basedn = o=My Org,c=UA
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
start_tls = no
access_attr = dialupAccess
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
edir_account_policy_check=no
timeout = 4
timelimit = 3
net_timeout = 1
}
ldap uni_ldap {
server = UK-AC-MAN-MTEST
identity = cn=radiusadmin,ou=dir,o=ac,c=uk
password = radius30
port = 636
basedn = c=uk
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
start_tls = no
tls_cacertfile = /home/doctor/oak-test-publickeycert.pem
tls_require_cert= demand
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
password_attribute = nspmdistributionpassword
edir_account_policy_check=no
timeout = 4
timelimit = 3
net_timeout = 1
}
realm IPASS {
format = prefix
delimiter = /
ignore_default = no
ignore_null = no
}
realm suffix {
format = suffix
delimiter = @
ignore_default = no
ignore_null = no
}
realm realmpercent {
format = suffix
delimiter = %
ignore_default = no
ignore_null = no
}
realm ntdomain {
format = prefix
delimiter = \\
ignore_default = no
ignore_null = no
}
checkval {
item-name = Calling-Station-Id
check-name = Calling-Station-Id
data-type = string
}
preprocess {
huntgroups = ${confdir}/huntgroups
hints = ${confdir}/hints
with_ascend_hack = no
ascend_channels_per_line = 23
with_ntdomain_hack = no
with_specialix_jetstream_hack = no
with_cisco_vsa_hack = no
}
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
preproxy_usersfile =
Re: 802.1x, EAP and LDAP
Mike Richardson wrote:
Looks like something odd is going on. I've removed freeradius and
reinstalled it. I added the LDAP config and uncommented the various 'ldap'
lines,
see config.
You did a bit more than that. That additional effort is where the
problem is coming from.
Defintiely uncommented:
Auth-Type LDAP {
uni_ldap
}
There is no uni_ldap line in the default configuration. It's
ldap. And yes, it makes a difference, for reasons that will become
clear later.
radiusd.conf:
ldap original {
server = ldap.your.domain
basedn = o=My Org,c=UA
...
ldap uni_ldap {
server = UK-AC-MAN-MTEST
identity = cn=radiusadmin,ou=dir,o=ac,c=uk
...
Um... no. When I said uncomment and configure the ldap module, it
did NOT mean re-name the existing ldap module, and add a new one with a
different name.
The extra work you're doing is breaking the server. Stop it. Just
un-comment the original ldap module, and configure it. Don't re-name
it. Don't add a new ldap module.
/usr/sbin/freeradius -X output:
...
Module: Instantiated ldap (uni_ldap)
The module you created is called uni_ldap, not ldap. Hence the
confusion. If you had left it named ldap, it would have Just Worked.
Or, if you changed the authenticate section to:
authenticate {
...
Auth-Type uni_ldap {
uni_ldap
}
...
}
Then it would also have worked. See the comments on module instance
names at the top of the modules section in radiusd.conf. If you
create another instance of the LDAP module, then that instance is NOT
named ldap. You MUST use it's instance name everywhere.
Again, just un-commenting and configuring the LDAP references in
radiusd.conf would have made this work. The extra effort you put into
it *broke* the configuration.
When I say just un-comment and configure, I REALLY MEAN just
un-comment and configure.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
I don't know anything about eDirectory, but could this be a problem for retrieving password and other attributes: rlm_ldap: No default NMAS login sequence Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Tue, Mar 04, 2008 at 10:45:37AM +0100, Alan DeKok wrote:
Um... no. When I said uncomment and configure the ldap module, it
did NOT mean re-name the existing ldap module, and add a new one with a
different name.
The extra work you're doing is breaking the server. Stop it. Just
un-comment the original ldap module, and configure it. Don't re-name
it. Don't add a new ldap module.
Ok, done that now, still doesn't work though unfortunately.
Thanks for the instantiation explanation, that was useful and cleared up
some confusion.
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/freeradius
log_file = ${logdir}/radius.log
libdir = /usr/lib/freeradius
pidfile = ${run_dir}/freeradius.pid
user = freerad
group = freerad
max_request_time = 30
delete_blocked_requests = no
cleanup_delay = 5
max_requests = 1024
bind_address = *
port = 0
hostname_lookups = no
allow_core_dumps = no
regular_expressions = yes
extended_expressions= yes
log_stripped_names = no
log_auth = no
log_auth_badpass = no
log_auth_goodpass = no
usercollide = no
lower_user = no
lower_pass = no
nospace_user = no
nospace_pass = no
checkrad = ${sbindir}/checkrad
security {
max_attributes = 200
reject_delay = 1
status_server = no
}
proxy_requests = yes
$INCLUDE ${confdir}/proxy.conf
$INCLUDE ${confdir}/clients.conf
$INCLUDE ${confdir}/imported_clients.cfg
snmp= no
$INCLUDE ${confdir}/snmp.conf
thread pool {
start_servers = 5
max_servers = 32
min_spare_servers = 3
max_spare_servers = 10
max_requests_per_server = 0
}
modules {
pap {
auto_header = yes
}
chap {
authtype = CHAP
}
pam {
pam_auth = radiusd
}
unix {
cache = no
cache_reload = 600
shadow = /etc/shadow
radwtmp = ${logdir}/radwtmp
}
$INCLUDE ${confdir}/eap.conf
mschap {
}
ldap {
server = UK-AC-MAN-MTEST
identity = cn=radiusadmin,ou=dir,o=ac,c=uk
password = radius30
port = 636
basedn = c=uk
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
start_tls = no
tls_cacertfile = /home/doctor/oak-test-publickeycert.pem
tls_require_cert= demand
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
password_attribute = nspmdistributionpassword
edir_account_policy_check=no
timeout = 4
timelimit = 3
net_timeout = 1
}
realm IPASS {
format = prefix
delimiter = /
ignore_default = no
ignore_null = no
}
realm suffix {
format = suffix
delimiter = @
ignore_default = no
ignore_null = no
}
realm realmpercent {
format = suffix
delimiter = %
ignore_default = no
ignore_null = no
}
realm ntdomain {
format = prefix
delimiter = \\
ignore_default = no
ignore_null = no
}
checkval {
item-name = Calling-Station-Id
check-name = Calling-Station-Id
data-type = string
}
preprocess {
huntgroups = ${confdir}/huntgroups
hints = ${confdir}/hints
with_ascend_hack = no
ascend_channels_per_line = 23
with_ntdomain_hack = no
with_specialix_jetstream_hack = no
with_cisco_vsa_hack = no
}
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
preproxy_usersfile = ${confdir}/preproxy_users
compat = no
}
detail {
detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d
detailperm = 0600
}
acct_unique {
key = User-Name, Acct-Session-Id, NAS-IP-Address,
Client-IP-Address, NAS-Port
}
$INCLUDE ${confdir}/sql.conf
radutmp {
filename = ${logdir}/radutmp
username = %{User-Name}
case_sensitive = yes
check_with_nas = yes
perm = 0600
callerid = yes
}
radutmp sradutmp {
filename = ${logdir}/sradutmp
perm = 0644
Re: 802.1x, EAP and LDAP
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap 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
The ldap module didn't find a password for the user, thus the PAP module
couldn't authenticate the user.
I don't know enough about eDirectory to help much more; I can say that a
normal LDAP server might contain entries of the form:
dn: cn=user,ou=
cn: user
objectClass: top
objectClass: person
userPassword: {CRYPT}
...or similar, and the ldap module is smart enough to figure it out.
As Ivan has pointed out, I suspect this line higher up is the issue:
rlm_ldap: No default NMAS login sequence
A quick read through the source code indicates the mysterious NMAS is
novell universal auth / password / blah.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: ... rlm_ldap: performing search in c=uk, with filter (uid=raduser1) rlm_ldap: No default NMAS login sequence rlm_ldap: looking for check items in directory... That needs to be fixed. See Novell's documentation for how. rad_check_password: Found Auth-Type System Delete that entry from raddb/users. It's not necessary, and it's not in 2.0.x. It won't help solve this problem, but it may make a difference in the future. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Tue, Mar 04, 2008 at 10:35:29AM +, Phil Mayers wrote:
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap 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
The ldap module didn't find a password for the user, thus the PAP module
couldn't authenticate the user.
I don't know enough about eDirectory to help much more; I can say that a
normal LDAP server might contain entries of the form:
dn: cn=user,ou=
cn: user
objectClass: top
objectClass: person
userPassword: {CRYPT}
...or similar, and the ldap module is smart enough to figure it out.
As Ivan has pointed out, I suspect this line higher up is the issue:
rlm_ldap: No default NMAS login sequence
A quick read through the source code indicates the mysterious NMAS is
novell universal auth / password / blah.
How does the PAP module attempt to do the authentication? Does it do an
authenticated bind as the user or does it get the password variable and
compare it to something stored?
I've tried it against openldap with the same result but I've not spent much
time on the openldap config. I have to get this working with eDiretory
unfortunately...
I'll go back to the openldap config and see if I can get that set up in the
right way.
Thanks,
Mike
--
Mike Richardson
Networks
IT Services, University of Manchester
*Plain text only please - attachments stripped on arrival*
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Tue, Mar 04, 2008 at 11:48:41AM +0100, Alan DeKok wrote: Mike Richardson wrote: ... rlm_ldap: performing search in c=uk, with filter (uid=raduser1) rlm_ldap: No default NMAS login sequence rlm_ldap: looking for check items in directory... That needs to be fixed. See Novell's documentation for how. Any idea what it means? I get the same message when using openldap: rlm_ldap: performing search in ou=users,ou=radius,dc=mydomain,dc=com, with filter ((uid=example)(objectclass=radiusprofile)) rlm_ldap: No default NMAS login sequence rlm_ldap: looking for check items in directory... Does it need fixing for OpenLDAP too? rad_check_password: Found Auth-Type System Delete that entry from raddb/users. It's not necessary, and it's not in 2.0.x. It won't help solve this problem, but it may make a difference in the future. Ok, done. Thanks, Mike -- Mike Richardson Networks IT Services, University of Manchester *Plain text only please - attachments stripped on arrival* - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote:
On Tue, Mar 04, 2008 at 10:35:29AM +, Phil Mayers wrote:
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap 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
The ldap module didn't find a password for the user, thus the PAP module
couldn't authenticate the user.
I don't know enough about eDirectory to help much more; I can say that a
normal LDAP server might contain entries of the form:
dn: cn=user,ou=
cn: user
objectClass: top
objectClass: person
userPassword: {CRYPT}
...or similar, and the ldap module is smart enough to figure it out.
As Ivan has pointed out, I suspect this line higher up is the issue:
rlm_ldap: No default NMAS login sequence
A quick read through the source code indicates the mysterious NMAS is
novell universal auth / password / blah.
How does the PAP module attempt to do the authentication? Does it do an
authenticated bind as the user or does it get the password variable and
compare it to something stored?
The latter.
Basically rlm_pap takes the User-Password in the request, and compares
it against the correct password for the user.
The ldap module is expected to have extracted the password from LDAP
(see below).
There is another mode where PAP requests can be authenticated by
rlm_ldap, using simple bind against the LDAP server - that's the
authenticate {
Auth-Type LDAP {
ldap
}
}
...stuff, but you should avoid doing that if at all possible. In
particular it won't support PEAP/MS-CHAP, the only really useful EAP
type supported by the windows XP/vista 802.1x supplicants.
I've tried it against openldap with the same result but I've not spent much
time on the openldap config. I have to get this working with eDiretory
unfortunately...
I don't know specifically what the NMAS nonsense is, but a glance at the
rlm_ldap source code indicates it's a Novell-proprietary LDAP extension
which the LDAP client (in this case, FreeRadius) has to call to get at
the plaintext password for the user.
In all probability your Novell administrators need to grant some extra
permissions to the binddn so that it can do this - it's (obviously) a
privileged operation.
Moving to OpenLDAP won't help - it doesn't support NMAS at all (I
assume) so you'll just be trying to run operations against the LDAP
server it doesn't support, and if you need to eventually get it working
against Novell it's not time well spent anyway.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: Any idea what it means? I get the same message when using openldap: Ask Novell. Unfortunately, no one else knows... rlm_ldap: performing search in ou=users,ou=radius,dc=mydomain,dc=com, with filter ((uid=example)(objectclass=radiusprofile)) rlm_ldap: No default NMAS login sequence rlm_ldap: looking for check items in directory... Does it need fixing for OpenLDAP too? No. OpenLDAP doesn't implement Novell's proprietary extensions. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Tue, Mar 04, 2008 at 01:13:49PM +0100, Alan DeKok wrote: Mike Richardson wrote: Any idea what it means? I get the same message when using openldap: Ask Novell. Unfortunately, no one else knows... rlm_ldap: performing search in ou=users,ou=radius,dc=mydomain,dc=com, with filter ((uid=example)(objectclass=radiusprofile)) rlm_ldap: No default NMAS login sequence rlm_ldap: looking for check items in directory... Does it need fixing for OpenLDAP too? No. OpenLDAP doesn't implement Novell's proprietary extensions. How come this message appears for OpenLDAP? Mike -- Mike Richardson Networks IT Services, University of Manchester *Plain text only please - attachments stripped on arrival* - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Tue, Mar 04, 2008 at 11:18:49AM +, Phil Mayers wrote:
How does the PAP module attempt to do the authentication? Does it do an
authenticated bind as the user or does it get the password variable and
compare it to something stored?
The latter.
Basically rlm_pap takes the User-Password in the request, and compares
it against the correct password for the user.
The ldap module is expected to have extracted the password from LDAP
(see below).
There is another mode where PAP requests can be authenticated by
rlm_ldap, using simple bind against the LDAP server - that's the
authenticate {
Auth-Type LDAP {
ldap
}
}
...stuff, but you should avoid doing that if at all possible. In
particular it won't support PEAP/MS-CHAP, the only really useful EAP
type supported by the windows XP/vista 802.1x supplicants.
The suggestions made so far have been to uncomment this authenticate entry.
Once working should I be looking at commenting it out again and getting EAP
to work without the above bind?
I don't know specifically what the NMAS nonsense is, but a glance at the
rlm_ldap source code indicates it's a Novell-proprietary LDAP extension
which the LDAP client (in this case, FreeRadius) has to call to get at
the plaintext password for the user.
Ah, after another google search I've found another Novell article on
freeradius:
https://secure-support.novell.com/KanisaPlatform/Publishing/558/3009668_f.SAL_Public.html
which suggests using 'tls_mode=yes' and the port as 636. I've tried it and
it works - I can authenticate! However this option doesn't appear in the
radiusd.conf - is it deprecated or just not documented?
Seems that eDirectory needs an encrypted session before it'll present the
password in clear text. Makes sense.
I've also tried it with 'start_tls=yes' and port as 389, this also seems to
work. Which is the prefered method? Novell suggest the former but as it
isn't documented...
Thanks,
Mike
--
Mike Richardson
Networks
IT Services, University of Manchester
*Plain text only please - attachments stripped on arrival*
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: 802.1x, EAP and LDAP
The binddn configured in freeradius needs to have admin privileges to
extract a password. It then binds with the userdn and extracted
password. That gets an positive authentication. You also need radius
specific ldap attributes the pass the authorization phase.
We used the freeradius/eDirectory integration for over a year
successfully.
Download instructions from the document:
How to integrate freeradius and eDirectory
http://www.novell.com/coolsolutions/appnote/16745.html
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Phil Mayers
Sent: Tuesday, March 04, 2008 5:19 AM
To: freeradius-users@lists.freeradius.org
Subject: Re: 802.1x, EAP and LDAP
Mike Richardson wrote:
On Tue, Mar 04, 2008 at 10:35:29AM +, Phil Mayers wrote:
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap 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
The ldap module didn't find a password for the user, thus the PAP
module
couldn't authenticate the user.
I don't know enough about eDirectory to help much more; I can say
that a
normal LDAP server might contain entries of the form:
dn: cn=user,ou=
cn: user
objectClass: top
objectClass: person
userPassword: {CRYPT}
...or similar, and the ldap module is smart enough to figure it out.
As Ivan has pointed out, I suspect this line higher up is the issue:
rlm_ldap: No default NMAS login sequence
A quick read through the source code indicates the mysterious NMAS is
novell universal auth / password / blah.
How does the PAP module attempt to do the authentication? Does it do
an
authenticated bind as the user or does it get the password variable
and
compare it to something stored?
The latter.
Basically rlm_pap takes the User-Password in the request, and compares
it against the correct password for the user.
The ldap module is expected to have extracted the password from LDAP
(see below).
There is another mode where PAP requests can be authenticated by
rlm_ldap, using simple bind against the LDAP server - that's the
authenticate {
Auth-Type LDAP {
ldap
}
}
...stuff, but you should avoid doing that if at all possible. In
particular it won't support PEAP/MS-CHAP, the only really useful EAP
type supported by the windows XP/vista 802.1x supplicants.
I've tried it against openldap with the same result but I've not spent
much
time on the openldap config. I have to get this working with eDiretory
unfortunately...
I don't know specifically what the NMAS nonsense is, but a glance at the
rlm_ldap source code indicates it's a Novell-proprietary LDAP extension
which the LDAP client (in this case, FreeRadius) has to call to get at
the plaintext password for the user.
In all probability your Novell administrators need to grant some extra
permissions to the binddn so that it can do this - it's (obviously) a
privileged operation.
Moving to OpenLDAP won't help - it doesn't support NMAS at all (I
assume) so you'll just be trying to run operations against the LDAP
server it doesn't support, and if you need to eventually get it working
against Novell it's not time well spent anyway.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: The suggestions made so far have been to uncomment this authenticate entry. Once working should I be looking at commenting it out again and getting EAP to work without the above bind? No. If you're using TTLS + PAP, it's fine. For PEAP, it's impossible... Ah, after another google search I've found another Novell article on freeradius: https://secure-support.novell.com/KanisaPlatform/Publishing/558/3009668_f.SAL_Public.html which suggests using 'tls_mode=yes' and the port as 636. I've tried it and it works - I can authenticate! However this option doesn't appear in the radiusd.conf - is it deprecated or just not documented? It seems that Novell has updated their documentation without telling us. Nice. See why I say it's not the fault of FreeRADIUS? Seems that eDirectory needs an encrypted session before it'll present the password in clear text. Makes sense. I've also tried it with 'start_tls=yes' and port as 389, this also seems to work. Which is the prefered method? Novell suggest the former but as it isn't documented... If it works, ship it. Alan DeKok - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Hi,
The debug log says whens tarting up:
rlm_ldap: Over-riding set_auth_type, as we're not listed in the
authenticate section.
My first suggestion would be: check if the mentions of ldap are commented out
in the authenticate { } section - they are by default. Change that, and see
how far you get. Chances are that that was all and it works :-)
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: [EMAIL PROTECTED] Tel.: +352 424409-1
http://www.restena.lu Fax: +352 422473
signature.asc
Description: This is a digitally signed message part.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: My first post: I'm trying to do 802.1x between Xsupplicant (through a Cisco switch) to Freeradius 1.1.7 using Novell eDirectory LDAP. 1) Configure and test TTLS with a user in the users file. 2) Configure an test LDAP with radtest (clear-text password) for a *different* user 3) test TTLS with a user in LDAP. I can successfully authenticate as a local user in the 'users' file but the LDAP side is eluding me. Don't do 802.1x and LDAP until you have normal radtest working with LDAP. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Mon, Mar 03, 2008 at 03:38:32PM +0100, Stefan Winter wrote:
Hi,
The debug log says whens tarting up:
rlm_ldap: Over-riding set_auth_type, as we're not listed in the
authenticate section.
My first suggestion would be: check if the mentions of ldap are commented out
in the authenticate { } section - they are by default. Change that, and see
how far you get. Chances are that that was all and it works :-)
If it were only that easy... I've messed with that before. AFAICT that only
applies if you are doing plain text authentication. I'm using TTLS and PAP
because the password is going to be stored in an encryted format in LDAP.
Here's the output after uncommenting as suggested:
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/imported_clients.cfg
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 = no
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 CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = yes
mschap: require_strong = yes
mschap: with_ntdomain_hack = yes
mschap: passwd = (null)
mschap: ntlm_auth = (null)
Module: Instantiated mschap (mschap)
Module: Loaded LDAP
ldap: server = UK-AC-MAN-MTEST
ldap: port = 636
ldap: net_timeout = 1
ldap: timeout = 4
ldap: timelimit = 3
ldap: identity = cn=radiusadmin,ou=dir,o=ac,c=uk
ldap: tls_mode = no
ldap: start_tls = no
ldap: tls_cacertfile = /tmp/oak-test-publickeycert.pem
ldap: tls_cacertdir = (null)
ldap: tls_certfile = (null)
ldap: tls_keyfile = (null)
ldap: tls_randfile = (null)
ldap: tls_require_cert = demand
ldap: password = radius30
ldap: basedn = c=uk
ldap: filter = (uid=%{Stripped-User-Name:-%{User-Name}})
ldap: base_filter = (objectclass=radiusprofile)
ldap: default_profile = (null)
ldap: profile_attribute = (null)
ldap: password_header = (null)
ldap: password_attribute = nspmdistributionpassword
ldap: access_attr = (null)
ldap: groupname_attribute = cn
ldap: groupmembership_filter =
(|((objectClass=GroupOfNames)(member=%{Ldap-UserDn}))((objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
ldap: groupmembership_attribute = (null)
ldap: dictionary_mapping = /etc/freeradius/ldap.attrmap
ldap: ldap_debug = 0
ldap: ldap_connections_number = 5
ldap: compare_check_items = no
ldap: access_attr_used_for_allow = yes
ldap: do_xlat = yes
ldap: edir_account_policy_check = yes
ldap: set_auth_type = yes
rlm_ldap: Registering ldap_groupcmp for Ldap-Group
rlm_ldap: Creating new attribute uni_ldap-Ldap-Group
rlm_ldap: Registering ldap_groupcmp for uni_ldap-Ldap-Group
rlm_ldap: Registering ldap_xlat with xlat_name uni_ldap
rlm_ldap: Over-riding set_auth_type, as we're not listed in the authenticate
section.
rlm_ldap: reading ldap-radius mappings from file /etc/freeradius/ldap.attrmap
rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$
rlm_ldap: LDAP radiusReplyItem mapped to RADIUS
Re: 802.1x, EAP and LDAP
On Mon, Mar 03, 2008 at 03:44:29PM +0100, Alan DeKok wrote:
Mike Richardson wrote:
My first post: I'm trying to do 802.1x between Xsupplicant (through a Cisco
switch) to Freeradius 1.1.7 using Novell eDirectory LDAP.
1) Configure and test TTLS with a user in the users file.
Works.
2) Configure an test LDAP with radtest (clear-text password)
for a *different* user
Doesn't work. Similar sort of error though.
3) test TTLS with a user in LDAP.
I can successfully authenticate as a local user in the 'users' file but the
LDAP side is eluding me.
Don't do 802.1x and LDAP until you have normal radtest working with
LDAP.
AFAICT radtest doesn't do EAP so it didn't seem to be a particularly valid
test. The approach required appeared quite different but I'm open to
suggestions. I've spent a long time trying to get RADIUS/LDAP auth to work
in any format.
Anyway, the output from a test with 'radtest' and LDAP:
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/imported_clients.cfg
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 = no
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 CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = yes
mschap: require_strong = yes
mschap: with_ntdomain_hack = yes
mschap: passwd = (null)
mschap: ntlm_auth = (null)
Module: Instantiated mschap (mschap)
Module: Loaded LDAP
ldap: server = UK-AC-MAN-MTEST
ldap: port = 636
ldap: net_timeout = 1
ldap: timeout = 4
ldap: timelimit = 3
ldap: identity = cn=radiusadmin,ou=dir,o=ac,c=uk
ldap: tls_mode = no
ldap: start_tls = no
ldap: tls_cacertfile = /tmp/oak-test-publickeycert.pem
ldap: tls_cacertdir = (null)
ldap: tls_certfile = (null)
ldap: tls_keyfile = (null)
ldap: tls_randfile = (null)
ldap: tls_require_cert = demand
ldap: password = radius30
ldap: basedn = c=uk
ldap: filter = (uid=%{Stripped-User-Name:-%{User-Name}})
ldap: base_filter = (objectclass=radiusprofile)
ldap: default_profile = (null)
ldap: profile_attribute = (null)
ldap: password_header = (null)
ldap: password_attribute = nspmdistributionpassword
ldap: access_attr = (null)
ldap: groupname_attribute = cn
ldap: groupmembership_filter =
(|((objectClass=GroupOfNames)(member=%{Ldap-UserDn}))((objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
ldap: groupmembership_attribute = (null)
ldap: dictionary_mapping = /etc/freeradius/ldap.attrmap
ldap: ldap_debug = 0
ldap: ldap_connections_number = 5
ldap: compare_check_items = no
ldap: access_attr_used_for_allow = yes
ldap: do_xlat = yes
ldap: edir_account_policy_check = yes
ldap: set_auth_type = yes
rlm_ldap: Registering ldap_groupcmp for Ldap-Group
rlm_ldap: Creating new attribute uni_ldap-Ldap-Group
rlm_ldap: Registering ldap_groupcmp for uni_ldap-Ldap-Group
rlm_ldap: Registering ldap_xlat with xlat_name uni_ldap
rlm_ldap: Over-riding
Re: 802.1x, EAP and LDAP
On Mon, Mar 03, 2008 at 04:46:36PM +0100, Alan DeKok wrote: Mike Richardson wrote: 2) Configure an test LDAP with radtest (clear-text password) for a *different* user Doesn't work. Similar sort of error though. Then fix that before proceeding with EAP. Don't do 802.1x and LDAP until you have normal radtest working with LDAP. AFAICT radtest doesn't do EAP so it didn't seem to be a particularly valid test. To be blunt: it's rude to ask questions of experts, and then to tell them that their answers are invalid. If you know better, why are you asking questions on this list? I'm not trying to be rude I promise. I'm asking here because I don't know better. I'm sorry if it sounds differently, it's just that after a solid week on this I'm a little frustrated. Apologies if this came through. I'd read that radtest didn't do EAP so I installed Xsupplicant and was using that for tests. That seems to be a more realisic approach. If you think that I can fix the problem by not attempting EAP and using radtest then that is exactly what I shall do. The approach required appeared quite different but I'm open to suggestions. I've spent a long time trying to get RADIUS/LDAP auth to work in any format. I've spent over 10 years working with RADIUS, and almost 9 years with FreeRADIUS. The Active Directory with LDAP TTLS issue has come up more times than I can count. It has been *solved* more times than I can count, by FOLLOWING INSTRUCTIONS. I am doing everything that has been asked of me. Anyway, the output from a test with 'radtest' and LDAP: ... rlm_ldap: Over-riding set_auth_type, as we're not listed in the authenticate section. You were told to go fix this. Do it. Now I DID. I didn't think that posting the new radius config would be of use but the section in authenticate is DEFINTIELY there and uncommented. Why this message is appearing in the output is a mystery to me. rad_recv: Access-Request packet from host 130.88.200.85:1025, id=61, length=48 User-Name = raduser2 User-Password = raduser20 ... rlm_ldap: looking for check items in directory... Nothing. This isn't surprising for Active Directory. Novell eDirectory not active directory. auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user If you have configured ldap in the authenticate section, then this would work. The LDAP bind as user works with AD for PAP requests. I did. Hint: look in the configuration files for instances of the word ldap. Read the comments. Un-comment the sample configurations. I did. It's *not* hard. I know, that's why I did it. 1) install FreeRADIUS 2) configure LDAP (*all* references in radiusd.conf sites-available/default) 3) validate that radtest works. I'm reading everything and following all the instructions to the letter. Please don't take that sort of attitude. I've explained that I'm not so I'd appreciate it if you'd do the same. Thanks, Mike -- Mike Richardson Networks IT Services, University of Manchester *Plain text only please - attachments stripped on arrival* - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: I'd read that radtest didn't do EAP so I installed Xsupplicant and was using that for tests. That seems to be a more realisic approach. If you think that I can fix the problem by not attempting EAP and using radtest then that is exactly what I shall do. Yes. The problem has nothing to do with EAP. rlm_ldap: Over-riding set_auth_type, as we're not listed in the authenticate section. You were told to go fix this. Do it. Now I DID. I didn't think that posting the new radius config would be of use but the section in authenticate is DEFINTIELY there and uncommented. Why this message is appearing in the output is a mystery to me. How much of the default configuration file did you edit? Start with the *default* configuration, and make small changes from there. The default configuration *works*. If you've been trying to get this working for a long time, then either there's a major bug in the version you're using, *or*, you're not editing testing the configuration in a systematic way. I'm reading everything and following all the instructions to the letter. Please don't take that sort of attitude. I've explained that I'm not so I'd appreciate it if you'd do the same. My amazement is that it appears to be so hard to get this working. Honestly, the default configuration works in the widest possible set of circumstances. I can't tell you how many people just installed the server, un-commented the ldap config, pointed it to their local ldap server, tested with radtest, and saw that it worked. It really *is* that easy. Try it. If it doesn't work for you, then there's something major going wrong. *That's* why configurations are tested in pieces. If plain PAP doesn't work when going to LDAP, then it's a complete and total waste of your time to install and configure an 802.1x supplicant. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
On Mon, Mar 03, 2008 at 05:23:44PM +0100, Alan DeKok wrote: Mike Richardson wrote: I'd read that radtest didn't do EAP so I installed Xsupplicant and was using that for tests. That seems to be a more realisic approach. If you think that I can fix the problem by not attempting EAP and using radtest then that is exactly what I shall do. Yes. The problem has nothing to do with EAP. rlm_ldap: Over-riding set_auth_type, as we're not listed in the authenticate section. You were told to go fix this. Do it. Now I DID. I didn't think that posting the new radius config would be of use but the section in authenticate is DEFINTIELY there and uncommented. Why this message is appearing in the output is a mystery to me. How much of the default configuration file did you edit? Start with the *default* configuration, and make small changes from there. I've been making changes for 8 hours a day for over a week so it might differ from the original. However I been back to the defaults twice. As of tomorrow I'll reinstall and try it again. From what you're saying I believe I need to put in the LDAP config for our eDirectory and uncomment any LDAP authorisation/authentication entries. Anything else? Then I can use radtest to test the authentication? How does the config know to use PAP rather than CHAP/MSCHAP? The default configuration *works*. If you've been trying to get this working for a long time, then either there's a major bug in the version you're using, *or*, you're not editing testing the configuration in a systematic way. Freeradius 1.1.7 on debian etch. I've been through every config guide I can find on the net, several times. Admittedly at the start I'd only used Radiator so the Freeradius config was quite different. It's only today though that I found a site which explained the limitations of the PAP/CHAP/MSCHAP with respect to password encryptions. Most guides assume MSCHAP, for use with PEAP, and most use flat file user authentication. Not many touch on LDAP and only Novell have eDirectory based documentation. I'm reading everything and following all the instructions to the letter. Please don't take that sort of attitude. I've explained that I'm not so I'd appreciate it if you'd do the same. My amazement is that it appears to be so hard to get this working. Honestly, the default configuration works in the widest possible set of circumstances. I can't tell you how many people just installed the server, un-commented the ldap config, pointed it to their local ldap server, tested with radtest, and saw that it worked. That's what I keep reading and trying but so far nothing. I have set up an OpenLDAP server but so far I've got the same error messages as with eDirectory. It really *is* that easy. Try it. If it doesn't work for you, then there's something major going wrong. *That's* why configurations are tested in pieces. If plain PAP doesn't work when going to LDAP, then it's a complete and total waste of your time to install and configure an 802.1x supplicant. eDirectory was the only piece I have no control over (managed elsewhere) so started with Supplicant-RADIUS-files and got that working then attempted to add LDAP. It seemed to make sense at the time given the plethora of documentation to help with this and little for RADIUS-LDAP. In hindsight it was the wrong order but wisdom is not always learned linearly. I hope that it all works and I won't need to come back other than to thank you. Mike -- Mike Richardson Networks IT Services, University of Manchester *Plain text only please - attachments stripped on arrival* - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
From what you're saying I believe I need to put in the LDAP config for our eDirectory and uncomment any LDAP authorisation/authentication entries. Anything else? Then I can use radtest to test the authentication? Yes. First test with user file entry, then with entry in the directory. How does the config know to use PAP rather than CHAP/MSCHAP? Welcome to Freeradius. Server will figure it out on it's own (it can determine what type of a request it is) and apply the appropriate processing (ie. set Auth-Type itself). Once pap is working you can send a mschap request (radtest doesn't do it but something like JRadius Simulator can) to make sure that works (you haven't encrypted the password or such) before sending a PEAP request. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 802.1x, EAP and LDAP
Mike Richardson wrote: I've been making changes for 8 hours a day for over a week so it might differ from the original. Which is a bit of a problem in and of itself. However I been back to the defaults twice. As of tomorrow I'll reinstall and try it again. From what you're saying I believe I need to put in the LDAP config for our eDirectory and uncomment any LDAP authorisation/authentication entries. Anything else? Not for LDAP. Then I can use radtest to test the authentication? Yes. How does the config know to use PAP rather than CHAP/MSCHAP? Because all of the experience of the developers working for years with RADIUS is distilled into the configuration files. I've been through every config guide I can find on the net, several times. If it takes more than 10 minutes to get FreeRADIUS authenticating to LDAP, ask a question on the list. Honestly. It's *so* much better to get an answer on the list than to fight for a week... It's only today though that I found a site which explained the limitations of the PAP/CHAP/MSCHAP with respect to password encryptions. My deployingradius.com site? It has a number of resources. Most guides assume MSCHAP, for use with PEAP, and most use flat file user authentication. Not many touch on LDAP and only Novell have eDirectory based documentation. Of course. Only Novell understands how eDirectory works. For LDAP, buy the O'Reilly OpenLDAP book. It has a good section on getting OpenLDAP FreeRADIUS to talk to each other. It's very quick... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
