Unknown Auth-Type "LDAP" in authenticate sub-section
Hi: Trying to set up a new RADIUS 2.1.12 server with LDAP. It configured and built all the modules I need, including rlm_ldap, once I installed the dependencies. I took all of the same config files that I have working on servers running 2.1.9 and 2.1.10, but 2.1.12 rlm_ldap doesn't seem to finish instantiating. Here's most of the debug: FreeRADIUS Version 2.1.12, for host x86_64-unknown-linux-gnu, built on Mar 8 2012 at 21:44:43 Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. Starting - reading configuration files ... including configuration file /usr/etc/raddb/radiusd.conf including configuration file /usr/etc/raddb/clients.conf including configuration file /usr/etc/raddb/eap.conf including configuration file /usr/etc/raddb/policy.conf including files in directory /usr/etc/raddb/sites-enabled/ including configuration file /usr/etc/raddb/sites-enabled/inner-tunnel including configuration file /usr/etc/raddb/sites-enabled/default main { user = "root" group = "wheel" allow_core_dumps = no } including dictionary file /usr/etc/raddb/dictionary main { name = "radiusd" prefix = "/usr" localstatedir = "/usr/var" sbindir = "/usr/sbin" logdir = "/var/log/radius" run_dir = "/usr/var/run/radiusd" libdir = "/usr/lib" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 pidfile = "/usr/var/run/radiusd/radiusd.pid" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = no log { stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } security { max_attributes = 200 reject_delay = 5 status_server = yes } } radiusd: #### Loading Realms and Home Servers #### radiusd: #### Loading Clients #### client localhost { <SNIP CLIENTS> radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating module "exec" from file /usr/etc/raddb/radiusd.conf exec { wait = yes input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating module "expr" from file /usr/etc/raddb/radiusd.conf Module: Linked to module rlm_expiration Module: Instantiating module "expiration" from file /usr/etc/raddb/radiusd.conf expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating module "logintime" from file /usr/etc/raddb/radiusd.conf logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server { # from file /usr/etc/raddb/radiusd.conf modules { Module: Creating Post-Auth-Type = REJECT Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating module "pap" from file /usr/etc/raddb/radiusd.conf pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating module "chap" from file /usr/etc/raddb/radiusd.conf Module: Linked to module rlm_mschap Module: Instantiating module "mschap" from file /usr/etc/raddb/radiusd.conf mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no allow_retry = yes } Module: Linked to module rlm_pam Module: Instantiating module "pam" from file /usr/etc/raddb/radiusd.conf pam { pam_auth = "radiusd-auth" } Module: Linked to module rlm_unix Module: Instantiating module "unix" from file /usr/etc/raddb/radiusd.conf unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_ldap Module: Instantiating module "ldap1" from file /usr/etc/raddb/radiusd.conf ldap ldap1 { server = "ldap1.domain.com" port = 389 password = "" identity = "" net_timeout = 1 timeout = 4 timelimit = 3 tls_mode = no start_tls = no tls_require_cert = "allow" tls { start_tls = no require_cert = "allow" } basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" auto_header = no access_attr_used_for_allow = yes groupname_attribute = "cn" groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" dictionary_mapping = "/usr/etc/raddb/ldap.attrmap" ldap_debug = 0 ldap_connections_number = 5 compare_check_items = no do_xlat = yes set_auth_type = no } rlm_ldap: Registering ldap_groupcmp for Ldap-Group rlm_ldap: Creating new attribute ldap1-Ldap-Group rlm_ldap: Registering ldap_groupcmp for ldap1-Ldap-Group rlm_ldap: Registering ldap_xlat with xlat_name ldap1 rlm_ldap: reading ldap<->radius mappings from file /usr/etc/raddb/ldap.attrmap rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS Calling-Station-Id rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP ntPassword mapped to RADIUS NT-Password rlm_ldap: LDAP sambaLmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP sambaNtPassword mapped to RADIUS NT-Password rlm_ldap: LDAP acctFlags mapped to RADIUS SMB-Account-CTRL-TEXT rlm_ldap: LDAP shadowMax mapped to RADIUS Shadow-Max-Age rlm_ldap: LDAP shadowLastChange mapped to RADIUS Shadow-Last-Change rlm_ldap: LDAP radiusNASIpAddress mapped to RADIUS NAS-IP-Address rlm_ldap: LDAP radiusServiceType mapped to RADIUS Service-Type rlm_ldap: LDAP radiusFramedProtocol mapped to RADIUS Framed-Protocol rlm_ldap: LDAP radiusFramedIPAddress mapped to RADIUS Framed-IP-Address rlm_ldap: LDAP radiusFramedIPNetmask mapped to RADIUS Framed-IP-Netmask rlm_ldap: LDAP radiusFramedRoute mapped to RADIUS Framed-Route rlm_ldap: LDAP radiusFramedRouting mapped to RADIUS Framed-Routing rlm_ldap: LDAP radiusFilterId mapped to RADIUS Filter-Id rlm_ldap: LDAP radiusFramedMTU mapped to RADIUS Framed-MTU rlm_ldap: LDAP radiusFramedCompression mapped to RADIUS Framed-Compression rlm_ldap: LDAP radiusLoginIPHost mapped to RADIUS Login-IP-Host rlm_ldap: LDAP radiusLoginService mapped to RADIUS Login-Service rlm_ldap: LDAP radiusLoginTCPPort mapped to RADIUS Login-TCP-Port rlm_ldap: LDAP radiusCallbackNumber mapped to RADIUS Callback-Number rlm_ldap: LDAP radiusCallbackId mapped to RADIUS Callback-Id rlm_ldap: LDAP radiusFramedIPXNetwork mapped to RADIUS Framed-IPX-Network rlm_ldap: LDAP radiusClass mapped to RADIUS Class rlm_ldap: LDAP radiusSessionTimeout mapped to RADIUS Session-Timeout rlm_ldap: LDAP radiusIdleTimeout mapped to RADIUS Idle-Timeout rlm_ldap: LDAP radiusTerminationAction mapped to RADIUS Termination-Action rlm_ldap: LDAP radiusLoginLATService mapped to RADIUS Login-LAT-Service rlm_ldap: LDAP radiusLoginLATNode mapped to RADIUS Login-LAT-Node rlm_ldap: LDAP radiusLoginLATGroup mapped to RADIUS Login-LAT-Group rlm_ldap: LDAP radiusFramedAppleTalkLink mapped to RADIUS Framed-AppleTalk-Link rlm_ldap: LDAP radiusFramedAppleTalkNetwork mapped to RADIUS Framed-AppleTalk-Network rlm_ldap: LDAP radiusFramedAppleTalkZone mapped to RADIUS Framed-AppleTalk-Zone rlm_ldap: LDAP radiusPortLimit mapped to RADIUS Port-Limit rlm_ldap: LDAP radiusLoginLATPort mapped to RADIUS Login-LAT-Port rlm_ldap: LDAP radiusReplyMessage mapped to RADIUS Reply-Message conns: 0x958cf20 Module: Instantiating module "ldap2" from file /usr/etc/raddb/radiusd.conf ldap ldap2 { server = "ldap2.domain.com" port = 389 password = "" identity = "" net_timeout = 1 timeout = 4 timelimit = 3 tls_mode = no start_tls = no tls_require_cert = "allow" tls { start_tls = no require_cert = "allow" } basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" auto_header = no access_attr_used_for_allow = yes groupname_attribute = "cn" groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" dictionary_mapping = "/usr/etc/raddb/ldap.attrmap" ldap_debug = 0 ldap_connections_number = 5 compare_check_items = no do_xlat = yes set_auth_type = no } rlm_ldap: Registering ldap_groupcmp for Ldap-Group rlm_ldap: Creating new attribute ldap2-Ldap-Group rlm_ldap: Registering ldap_groupcmp for ldap2-Ldap-Group rlm_ldap: Registering ldap_xlat with xlat_name ldap2 rlm_ldap: reading ldap<->radius mappings from file /usr/etc/raddb/ldap.attrmap rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS Calling-Station-Id rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password <SNIP most attr maps> rlm_ldap: LDAP radiusFramedAppleTalkZone mapped to RADIUS Framed-AppleTalk-Zone rlm_ldap: LDAP radiusPortLimit mapped to RADIUS Port-Limit rlm_ldap: LDAP radiusLoginLATPort mapped to RADIUS Login-LAT-Port rlm_ldap: LDAP radiusReplyMessage mapped to RADIUS Reply-Message conns: 0x958f390 /usr/etc/raddb/sites-enabled/default[241]: Unknown Auth-Type "LDAP" in authenticate sub-section.
up@3.am wrote:
Trying to set up a new RADIUS 2.1.12 server with LDAP. It configured and built all the modules I need, including rlm_ldap, once I installed the dependencies. I took all of the same config files that I have working on servers running 2.1.9 and 2.1.10, but 2.1.12 rlm_ldap doesn't seem to finish instantiating. Here's most of the debug:
You edited the default configuration and broke it. You deleted the default "ldap" module. You added "ldap1" and "ldap2". Then, the "authenticate" section refers to "ldap", which doesn't exist. Make sure that you refer to modules which exist. Alan DeKok.
up@3.am wrote:
Trying to set up a new RADIUS 2.1.12 server with LDAP. It configured and built all the modules I need, including rlm_ldap, once I installed the dependencies. I took all of the same config files that I have working on servers running 2.1.9 and 2.1.10, but 2.1.12 rlm_ldap doesn't seem to finish instantiating. Here's most of the debug:
You edited the default configuration and broke it.
You deleted the default "ldap" module. You added "ldap1" and "ldap2".
Then, the "authenticate" section refers to "ldap", which doesn't exist.
Make sure that you refer to modules which exist.
That's the first thing I checked in raddb/sites-available/default but "ldap" is commented out in the auth (and accounting) section. Here is what I have, which is at this point is the entire raddb directory lifted out of two older versions that are running fine: authorize { preprocess redundant LDAP{ ldap1 ldap2 } # The ldap module will set Auth-Type to LDAP if it has not # already been set # ldap authenticate { #Auth-Type LDAP { redundant LDAP{ ldap1 ldap2 } accounting { # Un-comment the following if you have set # 'edir_account_policy_check = yes' in the ldap module sub-section of # the 'modules' section. # # ldap HOWEVER, I do refer to the ldap module in the radiusd.conf, but this is how I got it working with redundant LDAP servers in the first place. ldap ldap1{ server = "ldap1.domain.com" basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 ldap ldap2{ server ="ldap2.domain.com" basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 This is how I understood to define more than one ldap source and it does work on 2 older servers, as I noted. Is there something outside of raddb that I missed? Thanks again!
up@3.am wrote:
Trying to set up a new RADIUS 2.1.12 server with LDAP. It configured and built all the modules I need, including rlm_ldap, once I installed the dependencies. I took all of the same config files that I have working on servers running 2.1.9 and 2.1.10, but 2.1.12 rlm_ldap doesn't seem to finish instantiating. Here's most of the debug:
You edited the default configuration and broke it.
You deleted the default "ldap" module. You added "ldap1" and "ldap2".
Then, the "authenticate" section refers to "ldap", which doesn't exist.
Make sure that you refer to modules which exist.
That's the first thing I checked in raddb/sites-available/default but "ldap" is commented out in the auth (and accounting) section. Here is what I have, which is at this point is the entire raddb directory lifted out of two older versions that are running fine:
authorize {
preprocess redundant LDAP{ ldap1 ldap2 }
# The ldap module will set Auth-Type to LDAP if it has not # already been set # ldap
authenticate {
#Auth-Type LDAP { redundant LDAP{ ldap1 ldap2
}
accounting {
# Un-comment the following if you have set # 'edir_account_policy_check = yes' in the ldap module sub-section of # the 'modules' section. # # ldap
HOWEVER, I do refer to the ldap module in the radiusd.conf, but this is how I got it working with redundant LDAP servers in the first place. net_timeout = 1
Sorry, I inadvertently gave incomplete ldap module configs for ldap1 and 2..here is a complete one: ldap ldap2{ server ="ldap2.domain.com" basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 tls { start_tls = no } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = no set_auth_type = no } ________ I did try set_auth_type = yes for gags, but no go.
On Fri, Mar 09, 2012 at 10:59:46AM -0500, up@3.am wrote:
authorize {
preprocess redundant LDAP{ ldap1 ldap2 }
# The ldap module will set Auth-Type to LDAP if it has not # already been set # ldap
authenticate {
#Auth-Type LDAP { redundant LDAP{ ldap1 ldap2
}
I think that's (very) wrong. I would need to check this, but I *think* you want something like this: authorize { ... redundant { ldap1 ldap2 } ... } authenticate { Auth-Type ldap1 { ldap1 } Auth-Type ldap2 { ldap2 } } ..and: ldap ldap1 { ... set_auth_type = yes } ldap ldap2 { ... set_auth_type = yes } Did you read a doc telling you to do it the way you did? Using "ldap" in the authenticate section is a bit tricky, and you'd be wise to avoid it if you can - if the LDAP server will "give" you the password (plaintext or crypted) you're better of doing that in "authorize" and letting FreeRADIUS perform the auth using rlm_pap or whatever. Very briefly, here's how it works: IF "set_auth_type = yes" on the module AND there is an "Auth-Type modname" in the "authenticate" section AND Auth-Type is not already set AND the request is PAP i.e. has User-Password AND the ldap module did NOT put a password hash into the control items THEN the ldap module will set Auth-Type==modname and authentication will come "back to itself" in authenticate {} The reasons it works that way are complex, and in an ideal world the ldap module would be a lot simpler, but it's got a lot of backwards compatibility code in it, and LDAP and RADIUS have a pretty bad impedance mistmatch when used this way (LDAP as an oracle).
On Sat, Mar 10, 2012 at 3:23 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On Fri, Mar 09, 2012 at 10:59:46AM -0500, up@3.am wrote:
authenticate {
#Auth-Type LDAP { redundant LDAP{ ldap1 ldap2
}
Using "ldap" in the authenticate section is a bit tricky, and you'd be wise to avoid it if you can - if the LDAP server will "give" you the password (plaintext or crypted) you're better of doing that in "authorize" and letting FreeRADIUS perform the auth using rlm_pap or whatever.
Yes. So to save lots of time and configuration problem: does your LDAP store user passwords in clear text or any "common" hash (e.g. md5, unix)? If yes, AND you know what the LDAP attribute is, you don't even need an LDAP section in authenticate. -- Fajar
On Sat, Mar 10, 2012 at 3:23 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On Fri, Mar 09, 2012 at 10:59:46AM -0500, up@3.am wrote:
authenticate {
#Auth-Type LDAP { redundant LDAP{ ldap1 ldap2
}
Using "ldap" in the authenticate section is a bit tricky, and you'd be wise to avoid it if you can - if the LDAP server will "give" you the password (plaintext or crypted) you're better of doing that in "authorize" and letting FreeRADIUS perform the auth using rlm_pap or whatever.
Yes.
So to save lots of time and configuration problem: does your LDAP store user passwords in clear text or any "common" hash (e.g. md5, unix)? If yes, AND you know what the LDAP attribute is, you don't even need an LDAP section in authenticate.
Mostly crypt, but I've seen a few SSHA hashes. I know the ldap attribute as well. Assuming those hashes are "common" enough, what do I need to do? I should point out that I had been using: DEFAULT Auth-Type = Ldap In the users file as well on the two older servers, despite docs that say that it is "almost always wrong", but it was the only way we got it working. I switched the conf files to the way Phil suggested and it complained about what I was doing in the users file, so I just used the sample users file and it started ok. I've not been able to test authenticating against it yet.
On Sat, Mar 10, 2012 at 5:29 AM, <up@3.am> wrote:
So to save lots of time and configuration problem: does your LDAP store user passwords in clear text or any "common" hash (e.g. md5, unix)? If yes, AND you know what the LDAP attribute is, you don't even need an LDAP section in authenticate.
Mostly crypt, but I've seen a few SSHA hashes. I know the ldap attribute as well. Assuming those hashes are "common" enough, what do I need to do?
If the hash is supported (see http://wiki.freeradius.org/Protocol%20Compatibility) , you only need to make sure FR sees it in the right place. See ldap.atrmap.
I should point out that I had been using:
DEFAULT Auth-Type = Ldap
In the users file as well on the two older servers, despite docs that say that it is "almost always wrong", but it was the only way we got it working.
If you have the attribute, and the hash is supported, you shouldn't need that. -- Fajar
On Sat, Mar 10, 2012 at 5:29 AM, <up@3.am> wrote:
So to save lots of time and configuration problem: does your LDAP store user passwords in clear text or any "common" hash (e.g. md5, unix)? If yes, AND you know what the LDAP attribute is, you don't even need an LDAP section in authenticate.
Mostly crypt, but I've seen a few SSHA hashes. I know the ldap attribute as well. Assuming those hashes are "common" enough, what do I need to do?
If the hash is supported (see http://wiki.freeradius.org/Protocol%20Compatibility) , you only need to make sure FR sees it in the right place. See ldap.atrmap.
Both hashes are supported, thanks for the link. I assume I need to define something to map to, as well? Like this: raddb/dictionary: ATTRIBUTE userPassword 3004 string raddb/ldap.attrmap: checkItem User-Password userPassword Then I just noticed this in the ldap module (which we have in the radiusd.conf): # password_attribute = userPassword Do I understand correctly that I can just uncomment that and not define anything in the dictionary or ldap.attrmap? Again, thanks!
On Sat, Mar 10, 2012 at 10:47 AM, <up@3.am> wrote:
Both hashes are supported, thanks for the link. I assume I need to define something to map to, as well? Like this:
raddb/dictionary: ATTRIBUTE userPassword 3004 string
err... no.
raddb/ldap.attrmap: checkItem User-Password userPassword
Is your LDAP attribute storing the password called userPassword? If yes, you shouldn't need to do anything as it's already mapped to the correct attribute on ldap.attrmap checkitem Password-With-Header userPassword
Then I just noticed this in the ldap module (which we have in the radiusd.conf):
# password_attribute = userPassword
Not sure about that one. Just leave whatever the default is. -- Fajar
On Sat, Mar 10, 2012 at 10:47 AM, <up@3.am> wrote:
Both hashes are supported, thanks for the link. I assume I need to define something to map to, as well? Like this:
raddb/dictionary: ATTRIBUTE userPassword 3004 string
err... no.
raddb/ldap.attrmap: checkItem User-Password userPassword
Is your LDAP attribute storing the password called userPassword? If yes, you shouldn't need to do anything as it's already mapped to the correct attribute on ldap.attrmap
checkitem Password-With-Header userPassword
Ah...it seems that my ldap.attrmap is from an older version of FreeRadius that didn't have it. I had copied it over to the new raddb/ because I now have those custom POSIX expiry attributes that you and others helped me with. We generally try to use the entire existing raddb/ dir when we upgrade FR, because our configuration has gotten pretty complex (to us, anyway), but I guess this isn't always a good idea. Thanks again for your help!
On Sat, Mar 10, 2012 at 5:29 AM, <up@3.am> wrote:
So to save lots of time and configuration problem: does your LDAP store user passwords in clear text or any "common" hash (e.g. md5, unix)? If yes, AND you know what the LDAP attribute is, you don't even need an LDAP section in authenticate.
Mostly crypt, but I've seen a few SSHA hashes. I know the ldap attribute as well. Assuming those hashes are "common" enough, what do I need to do?
If the hash is supported (see http://wiki.freeradius.org/Protocol%20Compatibility) , you only need to make sure FR sees it in the right place. See ldap.atrmap.
I should point out that I had been using:
DEFAULT Auth-Type = Ldap
In the users file as well on the two older servers, despite docs that say that it is "almost always wrong", but it was the only way we got it working.
If you have the attribute, and the hash is supported, you shouldn't need that.
I've taken that out on the new, 2.1.12 install and now a typical DEFAULT entry looks like this: DEFAULT Group == "FOO", Pool-Name :="FOO_pool" It seems to instantiate the module ok: Module: Linked to module rlm_ippool Module: Instantiating module "FOO_pool" from file /usr/etc/raddb/radiusd.conf ippool FOO_pool { session-db = "/usr/etc/raddb/db.FOO_ippool" ip-index = "/usr/etc/raddb/db.FOO_ipindex" key = "%{NAS-IP-Address} %{NAS-Port}" range-start = 172.17.0.101 range-stop = 172.17.0.253 netmask = 255.255.255.0 cache-size = 251 override = yes maximum-timeout = 0 The Access-Request packet looks ok: Framed-Protocol = PPP User-Name = "someuser" User-Password = "somepassword" NAS-Port-Type = Virtual NAS-Port = 2 NAS-Port-Id = "Uniq-Sess-ID2" Service-Type = Framed-User NAS-IP-Address = some pptp cisco device LDAP authentication then succeeds as it should. [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = ldap1 LDAP bind is then successful as it should be, but then: # Executing section post-auth from file /usr/etc/raddb/sites-enabled/default [FOO_pool] Could not find Pool-Name attribute. ++[FOO_pool] returns noop I assume I must be doing something wrong now with the users file entry. The old, working one was this: DEFAULT Group == FOO, Pool-Name :="FOO_pool", Auth-Type = Ldap Framed-Protocol == PPP, Framed-Compression = Van-Jacobson-TCP-IP The new one is currently: DEFAULT Group == "FOO", Pool-Name :="FOO_pool" I have tried the Framed-Protocol=PPP (is this still desired for PPTP, BTW?), I have tried setting: Service-Type = Framed-User At the beginning and end of the line, same for "Login-User", but the "Could not find Pool-Name attribute" persists. The config files are all the same as the older versions (2.1.09-.10). The pool name is listed in the accounting and post-auth sections of sites-enabled/default. Appreciate any clues as to what I missed.
On 12/03/12 15:44, up@3.am wrote:
DEFAULT Group == "FOO", Pool-Name :="FOO_pool"
"Group" is probably empty. I can't remember what module, if any, fills it out. What do you *think* "Group" will contain? It won't contain LDAP groups.
On 12/03/12 15:44, up@3.am wrote:
DEFAULT Group == "FOO", Pool-Name :="FOO_pool"
"Group" is probably empty. I can't remember what module, if any, fills it out.
What do you *think* "Group" will contain? It won't contain LDAP groups.
I was about to post about this..I just did a test with this entry: someuser Pool-Name :="FOO_pool" And it got an IP from the pool just fine, so you're right, the problem lies with "Group". It is a legacy entry, left over from before we switched from PAM/unix to LDAP. Since it continued to work even after removing all of the unix group entries and still continues to work when we add new LDAP groups and LDAP users to that group. How it gets that is something I don't know...there's no ldap.attrmap entry for it on the older, working servers. I take it I will need to define map the LDAP attribute PosixGroup to something?
Hi,
DEFAULT Group == "FOO", Pool-Name :="FOO_pool"
"Group" is probably empty. I can't remember what module, if any, fills it out.
# The Group and Group-Name attributes are automatically created by # the Unix module, and do checking against /etc/group automatically. # This means that you CANNOT use Group or Group-Name to do any other # kind of grouping in the server. You MUST define a new group # attribute. ...thats probably the one :-) alan
Hi,
DEFAULT Group == "FOO", Pool-Name :="FOO_pool"
"Group" is probably empty. I can't remember what module, if any, fills it out.
# The Group and Group-Name attributes are automatically created by # the Unix module, and do checking against /etc/group automatically. # This means that you CANNOT use Group or Group-Name to do any other # kind of grouping in the server. You MUST define a new group # attribute.
...thats probably the one :-)
...and you just hit on something that solved the problem. It seems that FR was getting the group info from LDAP indirectly, through the PAM module, which was configured using authconfig. Running authconfig pointing to the local LDAP server solved the problem. /etc/pam.d/system-auth auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so Dovecot, sshd and other apps transparently use LDAP this way. I didn't think FR did (and maybe it doesn't completely), because I seem to recall trying to get it to work on an older version (using Auth-type=PAM) that way with no luck...but that was a while ago.
On 12/03/12 18:23, up@3.am wrote:
...and you just hit on something that solved the problem. It seems that FR was getting the group info from LDAP indirectly, through the PAM module, which was
Actually, probably not. It probably gets the groups via nss_ldap, through nssswitch.
participants (5)
-
Alan Buxey -
Alan DeKok -
Fajar A. Nugraha -
Phil Mayers -
up＠3.am