I don’t think you need braces and such,
this is not as much an auth type as a method
Try just a single line that reads: ntlm_auth
Also, I actually had to set my default
auth-type to ntlm_auth. You know the part where it says “…for testing only..”.
in the users file? But, I had to leave it in or it would never call ntlm_auth
and hence to logins would work.
G
From:
freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org
[mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Edge
Sent: Thursday, July 14, 2011
10:05 AM
To:
freeradius-users@lists.freeradius.org
Subject: Error with AD/freeradius
config
Im following the AD config guide over at
deployingradius.com and think I have an error in one of the config files, I
suspect Im not using the right syntax, or another really simple error .
Fresh install of the latest freeradius version on
ubuntu – not the packaged version, built from source
PAP is working
I have configured and tested samba and ntlm_auth -
both working fine
The deployingradius guide then states
<You will also have to list ntlm_auth in the
authenticate sections of each the raddb/sites-enabled/default file, and of the
raddb/sites-enabled/inner-tunnel file:>
This is where I have hit problems.....
ERROR: No authenticate method (Auth-Type) found for
the request:
The above error makes me think I have amended the
config files incorrectly. I have copied the
/usr/local/etc/raddb/sites-enabled/default and
/usr/local/etc/raddb/sites-enabled/inner-tunnel files below and at the end the
radius debug information Can someone have a look at them and tell me where I
have gone wrong? I just didn’t understand what format the entry had to take, so
copied the existing entries in both files. If you search for ntlm_auth it will
take you straight to the areas I have changed..
Many thanks
My /sites-enabled/default file - I have just copied
the authentication section as everything else in the file is at default
settings
# Authentication.
#
#
# This section lists which modules are available
for authentication.
# Note that it does NOT mean 'try each module in
order'. It means
# that a module from the 'authorize' section
adds a configuration
# attribute 'Auth-Type := FOO'. That
authentication type is then
# used to pick the apropriate module from the
list below.
#
# In general, you SHOULD NOT set the Auth-Type
attribute. The server
# will figure it out on its own, and will do the
right thing. The
# most common side effect of erroneously setting
the Auth-Type
# attribute is that one authentication method
will work, but the
# others will not.
#
# The common reasons to set the Auth-Type
attribute by hand
# is to either forcibly reject the user
(Auth-Type := Reject),
# or to or forcibly accept the user (Auth-Type
:= Accept).
#
# Note that Auth-Type := Accept will NOT work
with EAP.
#
# Please do not put "unlang"
configurations into the "authenticate"
# section. Put them in the
"post-auth" section instead. That's what
# the post-auth section is for.
#
authenticate {
#
# PAP
authentication, when a back-end database listed
# in
the 'authorize' section supplies a password. The
#
password can be clear-text, or encrypted.
Auth-Type
PAP {
pap
}
#
#
Most people want CHAP authentication
# A
back-end database listed in the 'authorize' section
#
MUST supply a CLEAR TEXT password. Encrypted passwords
#
won't work.
Auth-Type
CHAP {
chap
}
#
#
MSCHAP authentication.
Auth-Type
MS-CHAP {
mschap
}
#
ntlm authentication.
Auth-Type
ntlm_auth {
ntlm_auth
}
# If
you have a Cisco SIP server authenticating against
#
FreeRADIUS, uncomment the following line, and the 'digest'
#
line in the 'authorize' section.
digest
#
#
Pluggable Authentication Modules.
# pam
#
# See
'man getpwent' for information on how the 'unix'
#
module checks the users password. Note that packets
#
containing CHAP-Password attributes CANNOT be authenticated
#
against /etc/passwd! See the FAQ for details.
#
# For
normal "crypt" authentication, the "pap" module should
# be
used instead of the "unix" module. The "unix" module
should
# be
used for authentication ONLY for compatibility with legacy
#
FreeRADIUS configurations.
#
unix
# Uncomment
it if you want to use ldap for authentication
#
# Note that
this means "check plain-text password against
# the ldap
database", which means that EAP won't work,
# as it
does not supply a plain-text password.
# Auth-Type LDAP {
#
ldap
# }
#
#
Allow EAP authentication.
eap
#
# The
older configurations sent a number of attributes in
#
Access-Challenge packets, which wasn't strictly correct.
# If
you want to filter out these attributes, uncomment
# the
following lines.
#
# Auth-Type eap {
#
eap {
#
handled = 1
#
}
#
if (handled && (Response-Packet-Type == Access-Challenge)) {
#
attr_filter.access_challenge.post-auth
#
handled # override the "updated" code from attr_filter
#
}
# }
}
My / sites-enabled/inner-tunnel file - again, I have
just copied the section I have added to...
# Authentication.
#
#
# This section lists which modules are available
for authentication.
# Note that it does NOT mean 'try each module in
order'. It means
# that a module from the 'authorize' section
adds a configuration
# attribute 'Auth-Type := FOO'. That
authentication type is then
# used to pick the apropriate module from the
list below.
#
# In general, you SHOULD NOT set the Auth-Type
attribute. The server
# will figure it out on its own, and will do the
right thing. The
# most common side effect of erroneously setting
the Auth-Type
# attribute is that one authentication method
will work, but the
# others will not.
#
# The common reasons to set the Auth-Type
attribute by hand
# is to either forcibly reject the user, or
forcibly accept him.
#
authenticate {
#
# PAP
authentication, when a back-end database listed
# in
the 'authorize' section supplies a password. The
#
password can be clear-text, or encrypted.
Auth-Type
PAP {
pap
}
#
#
Most people want CHAP authentication
# A
back-end database listed in the 'authorize' section
#
MUST supply a CLEAR TEXT password. Encrypted passwords
#
won't work.
Auth-Type
CHAP {
chap
}
#
MSCHAP authentication.
Auth-Type
MS-CHAP {
mschap
}
#
#
NTLM authentication.
Auth-Type
ntlm_auth {
ntlm_auth
}
#
Pluggable Authentication Modules.
# pam
#
# See
'man getpwent' for information on how the 'unix'
#
module checks the users password. Note that packets
#
containing CHAP-Password attributes CANNOT be authenticated
#
against /etc/passwd! See the FAQ for details.
#
unix
# Uncomment
it if you want to use ldap for authentication
#
# Note that
this means "check plain-text password against
# the ldap
database", which means that EAP won't work,
# as it
does not supply a plain-text password.
# Auth-Type LDAP {
#
ldap
# }
#
#
Allow EAP authentication.
eap
}
My debug output is as follows
rad_recv: Access-Request packet from host 127.0.0.1
port 44992, id=218, length=60
User-Name =
"xxxxxxxx"
User-Password = "xxxxxxxxx"
NAS-IP-Address = xxx.xxx.xxx.xxx
NAS-Port =
0
# Executing section authorize from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "xxxxxxxx",
looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password
found for the user. Authentication may fail because of this.
++[pap] returns noop
ERROR: No authenticate method (Auth-Type) found for
the request: Rejecting the user
Failed to authenticate the user.
Using Post-Auth-Type Reject
# Executing group from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject]
expand: %{User-Name} -> xxxxxxxxxx
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 16 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 16
Sending Access-Reject of id 218 to 127.0.0.1 port
44992
Waking up in 4.9 seconds.
Cleaning up request 16 ID 218 with timestamp +84526
Ready to process requests.
Many thanks