Authentication type (ldap, users, etc) per client or user?
Hello, I have a FreeRADIUS server working properly with an LDAP backend. I've brought some user config into the 'users' file for a legacy system we're migrating to this server. However, I cannot seem to find the appropriate way to have FreeRADIUS map clients to a specific authentication type. In my example I want everything to use LDAP, except one client to use the legacy 'users' file syntax. The closest example to this that I can find is here: https://lists.freeradius.org/pipermail/freeradius-users/2005-April/043218.ht... However, this deals with multple LDAP instances, and it does not like syntax of my chaning: files { } to: files foo {} and the other steps that seem logical when looking at the above. Is there any way to do this off of a single FreeRADIUS install? Any suggestions appreciated! Thanks, --falz
falz wrote:
I have a FreeRADIUS server working properly with an LDAP backend. I've brought some user config into the 'users' file for a legacy system we're migrating to this server. However, I cannot seem to find the appropriate way to have FreeRADIUS map clients to a specific authentication type.
What does that mean? Alan DeKok.
On Jan 3, 2008 10:18 AM, Alan DeKok <aland@deployingradius.com> wrote:
falz wrote:
I have a FreeRADIUS server working properly with an LDAP backend. I've brought some user config into the 'users' file for a legacy system we're migrating to this server. However, I cannot seem to find the appropriate way to have FreeRADIUS map clients to a specific authentication type.
What does that mean?
Radius Client A uses rlm_ldap, Radius Client B uses 'files' for the livingston-style 'users' file. What I have now is Client A works fine with LDAP, but it seems to be a default across the system. Client B always talks to LDAP, it doesn't seem to read from the user's file. Here's some debug stuff. When I start radiusd -X, it does show that it reads the files module: Module: Loaded files files: usersfile = "/usr/local/etc/raddb/users" files: acctusersfile = "/usr/local/etc/raddb/acct_users" files: preproxy_usersfile = "/usr/local/etc/raddb/preproxy_users" files: compat = "no" As well as ldap: Module: Loaded LDAP <snipped because it all works> But when one authenticate, it chooses ldap only: rad_recv: Access-Request packet from host 192.168.0.130:1028, id=18, length=119 User-Name = "falz" User-Password = "abc123" NAS-IP-Address = 192.168.0.130 NAS-Port = 4 NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP Connect-Info = "52000 LAPM/V42BIS" Called-Station-Id = "5552271012" Calling-Station-Id = "5552291017" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request 2 modcall[authorize]: module "chap" returns noop for request 2 modcall[authorize]: module "mschap" returns noop for request 2 rlm_realm: No '@' in User-Name = "falz", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 2 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 2 rlm_ldap: - authorize rlm_ldap: performing user authorization for falz radius_xlat: '(uid=falz)' radius_xlat: 'ou=staff,dc=domain,dc=net' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=staff,dc=domain,dc=net, with filter (uid=falz) request done: ld 0x8068e00 msgid 3 rlm_ldap: checking if remote access for falz is allowed by radiusReplyItem rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: extracted attribute Cisco-AVPair from generic item Cisco-AVPair := "shell:priv-lvl=15" rlm_ldap: extracted attribute Fall-Through from generic item Fall-Through = 1 rlm_ldap: extracted attribute Extreme-CLI-Authorization from generic item Extreme-CLI-Authorization = Enabled rlm_ldap: extracted attribute Service-Type from generic item Service-Type = NAS-Prompt-User rlm_ldap: extracted attribute Service-Type from generic item Service-Type := Administrative-User rlm_ldap: Setting Auth-Type = ldap rlm_ldap: user falz authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 2 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 2 modcall: leaving group authorize (returns ok) for request 2 rad_check_password: Found Auth-Type ldap auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 2 rlm_ldap: - authenticate rlm_ldap: login attempt by "falz" with password "abc123" rlm_ldap: user DN: uid=falz,ou=users,ou=staff,dc=domain,dc=net rlm_ldap: (re)connect to localhost:389, authentication 1 rlm_ldap: bind as uid=falz,ou=users,ou=staff,dc=domain,dc=net/abc123 to localhost:389 rlm_ldap: waiting for bind result ... request done: ld 0x8068f00 msgid 1 rlm_ldap: Bind failed with invalid credentials modcall[authenticate]: module "ldap" returns reject for request 2 modcall: leaving group LDAP (returns reject) for request 2 auth: Failed to validate the user. Login incorrect (rlm_ldap: Bind as user failed): [falz] (from client portmaster3 port 4 cli 6082291017) Delaying request 2 for 1 seconds Finished request 2 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 18 to 192.168.0.130 port 1028 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 2 ID 18 with timestamp 477d0e80 Nothing to do. Sleeping until we see a request. It is logical that it does this, as I have nothing in my config about this client using 'files'/'users', because I do not know what to put in. I posted the original link, and also found this, which is related: http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg40372.h... However, in all cases that I find, users are trying to authenticate with multiple same-type backends. Original link user is authenticating off of different LDAP servers, this case they're authenticating off of multiple SQL servers. I want 1 LDAP and one 'files'. --falz
falz wrote:
Radius Client A uses rlm_ldap, Radius Client B uses 'files' for the livingston-style 'users' file. What I have now is Client A works fine with LDAP, but it seems to be a default across the system. Client B always talks to LDAP, it doesn't seem to read from the user's file.
If you want to use one OR the other, try the following: authorize { ... group { files { ok = return } ldap } ... } i.e. if an entry is found in the "users" file, then don't do LDAP. If no entry is found in the "users" file, do LDAP. Of course, in 2.0, you could just have a virtual server for client A, and a different virtual server for client B.
But when one authenticate, it chooses ldap only:
Because that's what you've configured it to do. In this case, the debug output shows that it's not calling the "files" module. So you've edited the default configuration so that the "files" module isn't called... and yet you say you want it to call the "files" module.
It is logical that it does this, as I have nothing in my config about this client using 'files'/'users', because I do not know what to put in.
What's wrong with the default configuration file that ships with the server?
I posted the original link, and also found this, which is related:
http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg40372.h...
However, in all cases that I find, users are trying to authenticate with multiple same-type backends. Original link user is authenticating off of different LDAP servers, this case they're authenticating off of multiple SQL servers. I want 1 LDAP and one 'files'.
You can copy & paste an example that doesn't apply to what you want to do, or you can understand how the server works. In this case, reading the files in the "doc" directory would help. They explain *how* those examples are configured, and *why* they work. Alan DeKok.
On Jan 3, 2008 3:45 PM, Alan DeKok <aland@deployingradius.com> wrote:
If you want to use one OR the other, try the following:
authorize { ... group { files { ok = return } ldap } ... }
i.e. if an entry is found in the "users" file, then don't do LDAP. If no entry is found in the "users" file, do LDAP.
This would technically get things working, but poses a security issue. I want to have clients associated with backends. The above example appears that it will simply give priority of one authentication source over the other, which isn't what I'm trying to do.
Of course, in 2.0, you could just have a virtual server for client A, and a different virtual server for client B.
I'll look into 2.0 if this is the only way to get this functionality.
Because that's what you've configured it to do. In this case, the debug output shows that it's not calling the "files" module. So you've edited the default configuration so that the "files" module isn't called... and yet you say you want it to call the "files" module.
No, I did not remove the files section. It is called, and loaded per my output in the previous email. Both are listed, but nothing in the config points a client to an auth method, because I don't know the syntax for this, or it's not possible.
What's wrong with the default configuration file that ships with the server?
I don't believe I said anything is. I simply don't know its syntax well enough to know what to put in, or it's not possible.
You can copy & paste an example that doesn't apply to what you want to do, or you can understand how the server works. In this case, reading the files in the "doc" directory would help. They explain *how* those examples are configured, and *why* they work.
Looking through the docs, it appears that Autz-Type gives indications of what I am trying to do: http://www.freeradius.org/radiusd/doc/Autz-Type I will experiment with it and some syntax, and chime back in when I get things working for future reference for other users (and for me, if I neglect to document it myself :) --falz
falz wrote:
This would technically get things working, but poses a security issue. I want to have clients associated with backends. The above example appears that it will simply give priority of one authentication source over the other, which isn't what I'm trying to do.
You can use Autz-Type to get what you want, but it's more complicated.
I'll look into 2.0 if this is the only way to get this functionality.
It's not the only way, but it's *much* easier in 2.0. You just put an entry in the "client" configuration saying "virtual_server = foo", and all requests get processed through "foo".
No, I did not remove the files section. It is called, and loaded per my output in the previous email.
It's not listed in the debug output you posted. So it's not being called.
Looking through the docs, it appears that Autz-Type gives indications of what I am trying to do:
Yes. It may require running two copies of the "files" module, which is more complicated.
I will experiment with it and some syntax, and chime back in when I get things working for future reference for other users (and for me, if I neglect to document it myself :)
In 2.0: client a { ipaddr = 1.2.3.4 ... virtual_server = foo } client b { ipaddr = 5.6.7.8 ... virtual_server = bar } server foo { authorize { users ... } ... } server bar { authorize { ldap ... } ... } It's more typing to set up, but it's significantly easier to understand and to maintain. It means that there are fewer possibilities for something to go wrong, too. Alan DeKok.
participants (3)
-
Alan DeKok -
falz -
falz