On Thu, 3 Apr 2008, Alan DeKok wrote:
You have to change the reference to "ldap" in sites-available/default.
to the instance name. e.g. "ldap_wireless".
...
In 2.0, you don't really need Autz-Type. I would suggest pretending
that it doesn't exist. Instead, use "unlang".
...
The sections are processed top to bottom, as a linear list. If you
want to make the server do your bidding, write "if/else" statements
using "unlang".
i.e. write the conditions you want to match in plain english, and what
you want it to do. Then, translate that pretty much directly into
"unlang".
and in a response to a different message:
What is the proper way to call a specific LDAP module based on
NAS-IP-Address (or huntgroup, probably)?
authorize {
...
if (NAS-IP-Address == 1.2.3.4) {
ldap_1
}
elsif (NAS-IP-Address == 3.4.5.6) {
ldap_2
}
...
}
Or, use "switch". See "man unlang".
...
Don't use the "users" file for things like this. It doesn't know
about modules, or module order. The "unlang" parser does know.
On the one hand, "OH!!!" I think I'm starting to understand, but on the
other hand, I appear to still not be doing it quite right. I put into
the "authorize" section of sites-available/default:
...
#
# The ldap module will set Auth-Type to LDAP if it has not
# already been set
#ldap
# wireless
if (NAS-Port-Type == Wireless-802.11) {
ldap_wireless
}
...
I also tried NAS-IP-Address with the same result so far, but I can
clearly see from the debug output that this part is now functioning as
expected. If the user does not match the search filter configured in my
ldap_wireless instance of the ldap module, this section returns
"notfound", otherwise it returns "ok".
However, then the request carries on to the inner-tunnel of the TTLS
transaction (whether or not the outer authorization succeeded or returned
not found; is it possible to equate "notfound" to "fail" or "reject"?).
If I configure sites-available/inner-tunnel's authorization section as
above, when it gets to that point, debug output says:
++? if (NAS-Port-Type == Wireless-802.11)
(Attribute NAS-Port-Type was not found)
The user is rejected shortly after, even when the ldap search is
expected to succeed, with the following in debug output:
auth: No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user
auth: Failed to validate the user.
In other words, despite having found the user in the ldap_wireless
search in sites-available/default, the inner-tunnel seems to not receive
sufficient information about the request to decide to use the
ldap_wireless module, leaving the RADIUS server with no way to
authenticate the user. This is despite ldap_wireless in
sites-available/default having produced:
rlm_ldap: checking if remote access for j_doe is allowed by cn
rlm_ldap: Added User-Password = {SSHA}*SANITIZED*QDmffXBQkU42Wt9x*SANITIZED*==
in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user j_doe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
+++[ldap_wireless] returns ok
++- if (NAS-Port-Type == Wireless-802.11) returns ok
ie. we have a password and have already determined authorization for
this user.
And also despite the debug output of the request arriving at inner-tunnel
*appearing* to contain items sufficient for me to select on:
User-Name = "j_doe"
NAS-IP-Address = 127.0.0.1
Calling-Station-Id = "02-00-00-00-00-01"
Framed-MTU = 1400
NAS-Port-Type = Wireless-802.11
Connect-Info = "CONNECT 11Mbps 802.11b"
EAP-Message =
0x02050070150017030100207ec2e216f79ef34a114bb34054277beb1a45fd25505d975be42b62d449e1be8c1703010040ca0cbb9c6b5abfef1e656ccc100c8350cae810edc08d9b6c3135dabbcac32a2ef26c2a3824cb7eaf7423d00c83432cfaceb08721d92faa5c3579908e3be88ba3
State = 0x6f66f2676b63e70a05f25e914c848f96
Message-Authenticator = 0x314bc723b23efd033689667de8c0ca7a
If I put in inner-tunnel:
authorize {
...
ldap
...
}
Then it seems to authorize access for users that "ldap_wireless" in
"default" didn't find. I can get the intended result for *this* service
with inner-tunnel containing instead:
authorize {
...
ldap_wireless
...
}
but that doesn't help me for other services for which I want to use
RADIUS.
Help?
--
----------------------------------------------------------------------
Sylvain Robitaille [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
