Re: Mac Auth against LDAP
On 24/8/2013 12:00 μμ, Nikolaos Milas wrote:
...and then I could simply use my *exact current configuration* by
simply changing the ldap filter to:
filter =
((macAddress=%{Calling-Station-Id})(radiusNASIpAddress=%{NAS-IP-Address})(radiusHint=%{NAS-Port}))
I tested this and it works. (Yet, please respond to the questions on my
earlier mails.)
Now, I am thinking of an extended (MAC-Auth) policy (rule set) like:
Rule 1: If in the LDAP host entry we have included a radiusNASIpAddress
value AND a radiusHint value, then authorize based on all, otherwise
reject. (No mobility allowed)
Rule 2: If in the LDAP host entry we have included only a
radiusNASIpAddress value, then authorize based only on it, otherwise
reject. (NAS-mobility)
Rule 3: If in the LDAP host entry we have included NEITHER a
radiusNASIpAddress value NOR a radiusHint value, then authorize based
only on the MAC Address. (Full Mobility)
QUESTION 1: Is it legitimate to set up the above policy as follows?
server macauth {
authorize {
preprocess
rewrite_calling_station_id
if
(%{ldap_macauth:ldap:///ou=Nodes,dc=example,dc=com?radiusHint?sub?radiusHint=*}
and
%{ldap_macauth:ldap:///ou=Nodes,dc=example,dc=com?radiusNASIpAddress?sub?radiusNASIpAddress=*})
{
ldap_macauth
if (ok) {
update control {
Auth-Type := Accept
}
}
}
else if
(%{ldap_macauth_NAS_only:ldap:///ou=Nodes,dc=example,dc=com?radiusNASIpAddress?sub?radiusNASIpAddress=*})
{
ldap_macauth_NAS_only
if (ok) {
update control {
Auth-Type := Accept
}
}
}
else {
ldap_macauth_mobility
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
}
authenticate {
Auth-Type LDAP_MACAUTH {
ldap_macauth
}
}
preacct {
preprocess
acct_unique
}
accounting {
detail
exec
attr_filter.accounting_response
}
}
...where the three ldap instances above are identical except the filter
which is:
ldap_macauth:
filter =
((macAddress=%{Calling-Station-Id})(radiusNASIpAddress=%{NAS-IP-Address})(radiusHint=%{NAS-Port}))
ldap_macauth_NAS_only:
filter =
((macAddress=%{Calling-Station-Id})(radiusNASIpAddress=%{NAS-IP-Address}))
ldap_macauth_mobility:
filter = (macAddress=%{Calling-Station-Id})
If the above configuration is legitimate, what should we place in the
authenticate {} section ? All ldap_machauth* instances used in authorize
{} section should be included? I am confused.
Thanks and regards,
Nick
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Groups in active directory and checks in MySQL
Hello,
sorry for the top quoting but i'm using a webmail for replying
nbsp;which is really crap.
nbsp;
accordingly i'm posting here the debug log of a radtest.
the authentication gets rejected because the group matches in the
raddb/users with the following expression:
nbsp;
DEFAULT Ldap-Group == fax, Auth-Type := Reject
nbsp;
i've tried commenting it out and adding this to mysql in the table
radgroupcheck:
nbsp;
table: radgroupcheck
Groupname: fax
Attribute: Auth-Type
op: :=
Value: Reject
nbsp;
but it's not giving the same result, the check against sql is ignored and
the user is authed successfully.
nbsp;
here is the debug log:
nbsp;
rad_recv: Access-Request packet from host 127.0.0.1 port 45195, id=232,
length=57
User-Name = sogo1
User-Password = userpassword
NAS-IP-Address = 192.168.4.82
NAS-Port = 80
# Executing section authorize from file
/etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
[auth_log] expand:
/var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -gt;
/var/log/freeradius/radacct/127.0.0.1/auth-detail-20130826
[auth_log]
/var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands
to /var/log/freeradius/radacct/127.0.0.1/auth-detail-20130826
[auth_log] expand: %t -gt; Mon Aug 26 07:56:19 2013
++[auth_log] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = sogo1, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
nbsp; [ldap] Entering ldap_groupcmp()
[files] expand: dc=plutone,dc=local -gt; dc=plutone,dc=local
[files] WARNING: Deprecated conditional expansion :-. nbsp;See man
unlang for details
[files] ... expanding second conditional
[files] expand: %{User-Name} -gt; sogo1
[files] expand: (sAMAccountName=%{Stripped-User-Name:-%{User-Name}}) -gt;
(sAMAccountName=sogo1)
nbsp; [ldap] ldap_get_conn: Checking Id: 0
nbsp; [ldap] ldap_get_conn: Got Id: 0
nbsp; [ldap] performing search in dc=plutone,dc=local, with filter
(sAMAccountName=sogo1)
nbsp; [ldap] ldap_release_conn: Release Id: 0
[files] expand:
(|(amp;(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(amp;(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
-gt;
(|(amp;(objectClass=GroupOfNames)(member=))(amp;(objectClass=GroupOfUniqueNames)(uniquemember=)))
nbsp; [ldap] ldap_get_conn: Checking Id: 0
nbsp; [ldap] ldap_get_conn: Got Id: 0
nbsp; [ldap] performing search in dc=plutone,dc=local, with filter
(amp;(cn=fax)(|(amp;(objectClass=GroupOfNames)(member=))(amp;(objectClass=GroupOfUniqueNames)(uniquemember=
nbsp; [ldap] object not found
nbsp; [ldap] ldap_release_conn: Release Id: 0
nbsp; [ldap] ldap_get_conn: Checking Id: 0
nbsp; [ldap] ldap_get_conn: Got Id: 0
nbsp; [ldap] performing search in CN=sogo1,CN=Users,DC=plutone,DC=local,
with filter (objectclass=*)
nbsp; [ldap] performing search in CN=Fax,CN=Users,DC=plutone,DC=local, with
filter (cn=fax)
rlm_ldap::ldap_groupcmp: User found in group fax
nbsp; [ldap] ldap_release_conn: Release Id: 0
[files] users: Matched entry DEFAULT at line 205
++[files] returns ok
[ldap] performing user authorization for sogo1
[ldap] WARNING: Deprecated conditional expansion :-. nbsp;See man
unlang for details
[ldap] ... expanding second conditional
[ldap] expand: %{User-Name} -gt; sogo1
[ldap] expand: (sAMAccountName=%{Stripped-User-Name:-%{User-Name}}) -gt;
(sAMAccountName=sogo1)
[ldap] expand: dc=plutone,dc=local -gt; dc=plutone,dc=local
nbsp; [ldap] ldap_get_conn: Checking Id: 0
nbsp; [ldap] ldap_get_conn: Got Id: 0
nbsp; [ldap] performing search in dc=plutone,dc=local, with filter
(sAMAccountName=sogo1)
[ldap] No default NMAS login sequence
[ldap] looking for check items in directory...
[ldap] looking for reply items in directory...
WARNING: No known good password was found in LDAP. nbsp;Are you sure that
the user is configured correctly?
[ldap] user sogo1 authorized to use remote access
nbsp; [ldap] ldap_release_conn: Release Id: 0
++[ldap] returns ok
[sql] expand: %{User-Name} -gt; sogo1
[sql] sql_set_user escaped user --gt; 'sogo1'
rlm_sql (sql): Reserving sql socket id: 1
[sql] expand: SELECT id, username, attribute, value, op nbsp; nbsp; nbsp;
nbsp; nbsp; FROM radcheck nbsp; nbsp; nbsp; nbsp; nbsp; WHERE
username = '%{SQL-User-Name}' nbsp; nbsp; nbsp; nbsp; nbsp; ORDER BY id
-gt; SELECT id, username, attribute, value, op nbsp; nbsp; nbsp; nbsp;
nbsp; FROM radcheck nbsp; nbsp; nbsp; nbsp; nbsp; WHERE username =
'sogo1' nbsp; nbsp; nbsp; nbsp; nbsp; ORDER BY id
[sql] expand: SELECT groupname nbsp; nbsp; nbsp; nbsp; nbsp; FROM
radusergroup nbsp; nbsp; nbsp; nbsp; nbsp; WHERE username =
'%{SQL-User-Name}' nbsp; nbsp; nbsp; nbsp; nbsp; ORDER BY priority
-gt; SELECT groupname nbsp; nbsp; nbsp; nbsp; nbsp
Re: Intermediate SSL certificate
Hi Matthew 2013/8/22 Matthew Ceroni matthewcer...@gmail.com I read that for FreeRadius just combine the cert with the intermediate cert into one file and then reference that in eap.conf:certificate_file. I have done that but clients are still failing certificate validation. Honestly I also had some hassles with the certificate chain, now we can configure clients to check both CA as well as certificate CN. My experience was that I had to honor the certificate order and make sure to not include unused intermediate certificates. That is: Don't include a full CA bundle from your CA stay way below the 64k limit ( http://wiki.freeradius.org/guide/Certificate%20Compatibility) I used OpenSSL to show both subject and issuer go through the chain of trust starting with the server certificate, which in my case was StartCom. You'll need to know where you can download all root and intermediate roots from your issuing CA. openssl x509 -noout -in mysignedservercert.pem -subject -issuer subject= removed issuer= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA After getting the Class 2 Primary Intermediate Server CA: $ openssl x509 -noout -in sub.class2.server.ca.pem -subject -issuer subject= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA issuer= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority And finally we're up in the chain: $ openssl x509 -noout -in ca.pem -subject -issuer subject= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority issuer= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority # Build the cert bundle for freeradius cat mysignedservercert.pem myservercert-roots-bundled.pem cat sub.class2.server.ca.pem myservercert-roots-bundled.pem cat ca.pem myservercert-roots-bundled.pem This resulted in an 8k file while StartSSL's CA bundle is 124k. -- Mathieu - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mac Auth against LDAP
On 24 Aug 2013, at 10:00, Nikolaos Milas nmi...@noa.gr wrote: On 23/8/2013 9:19 μμ, Arran Cudbard-Bell wrote: It'll either be in NAS-Port or NAS-Port-ID if the NAS is providing that information. Thanks Arran, It was NAS-Port indeed. Strangely enough, this is not included either in ldap.attrmap or the freeradius schema. Shouldn't it (and other attributes missing from ldap.attrmap and freeradius schema but defined in RFC 2865, like NAS-Port-Type) be included at least in future FreeRadius releases? Or there is a particular reason for which they were not included? No, they should not be included in future releases. It is inefficient to check for the presence of hundreds of attributes in the retrieved object. The generic attribute format supported in both 2.0.0 and 3.0.0 allows you to map any attribute present in the FreeRADIUS dictionary, and even specify the operator used to add them to the various lists. You can of course, also use generic attributes as part of filters. In any case, could I include the (desired) NAS-Port value in another (seemingly unused) attribute of the FreeRadius Schema, like radiusHint (which -if I understand right- has a suitable syntax: IA5 String), for which I guess I should also add an entry in ldap.attrmap (because there is no radiusHint attribute mapping therein), like: checkItem NAS-Port radiusHint Either update the schema for your installation, or use the generic attribute mapping and do the comparisons server side. Arran Cudbard-Bell a.cudba...@freeradius.org FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mac Auth against LDAP
...where the three ldap instances above are identical except the filter which
is:
ldap_macauth:
filter =
((macAddress=%{Calling-Station-Id})(radiusNASIpAddress=%{NAS-IP-Address})(radiusHint=%{NAS-Port}))
ldap_macauth_NAS_only:
filter =
((macAddress=%{Calling-Station-Id})(radiusNASIpAddress=%{NAS-IP-Address}))
ldap_macauth_mobility:
filter = (macAddress=%{Calling-Station-Id})
No. It's a really inefficient way of doing this.
Use generic attribute maps or an update ldap schema to pull the necessary
values into control attributes,
and then do the comparison in policy language. Otherwise you end up doing
multiple LDAP queries which are
comparatively extremely slow to anything else you're doing in the policy.
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mac Auth against LDAP
On 26/8/2013 12:15 μμ, Arran Cudbard-Bell wrote:
No. It's a really inefficient way of doing this.
Thanks Arran,
Yet, would it be logically/technically correct?
Use generic attribute maps or an update ldap schema to pull the necessary
values into control attributes,
and then do the comparison in policy language.
Hmm, if I understand right, I could query once a custom attribute with
e.g. the value of 0/1/2 depending on the type of mac-auth we would like
to do.
Thus, two LDAP queries would suffice to check correctly the client in
all cases, where in my initial script we would need 3 at best or 4 at
worst.
The example would be to use a policy like:
set_mac_auth_type {
update request {
auth_type :=
%{ldap_macauth:ldap:///ou=Nodes,dc=example,dc=com?macauthtype?sub?macAddress=%{Calling-Station-Id}})
}
}
And finally:
server macauth {
authorize {
preprocess
rewrite_calling_station_id
set_mac_auth_type
if (%{auth_type} = 0) {
ldap_macauth
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
else if (%{auth_type} = 1) {
ldap_macauth_NAS_only
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
else if (%{auth_type} = 2) {
ldap_macauth_mobility
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
else {
reject
}
}
...
}
Is the above syntax/logic correct? That is what you are suggesting?
Otherwise you end up doing multiple LDAP queries which are
comparatively extremely slow to anything else you're doing in the policy.
OK, although we are mirroring the LDAP DIT locally (OpenLDAP Consumer)
so LDAP queries are VERY fast, and our FreeRadius load is expected to be
low (hosts on campus are less than 1000).
Thanks,
Nick
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Troubleshooting PostgreSQL Integration
On 08/26/2013 12:10 AM, mdeche...@comcast.net wrote:
Dear Users --
This is my first posting to the FreeRADIUS users list, so please be patient :)
You're already doing pretty well - you actually posted a full debug,
which hardly anyone does first time!
Ok, so for the SQL case the server startup shows:
authorize_check_query =
authorize_group_check_query =
authorize_group_reply_query =
...which then causes this:
rlm_sql (sql): Reserving sql socket id: 4
[sql] expand: -
[sql] Error generating query; rejecting user
rlm_sql (sql): Released sql socket id: 4
++[sql] returns fail
i.e. because authorize_check_query is blank, the SQL module fails.
I can see from the debug output that it's complaining about the user being
invalid.
Sort of; that's the server core talking, based in the SQL module
returning. The actual error is a few lines higher up (see above).
authorize_check_query = SELECT id, UserName, Attribute, Value, Op \
FROM ${authcheck_table} \
WHERE Username = '%{SQL-User-Name}' \
ORDER BY id
[info on case ordering of fields]
This isn't actually significant in SQL; it's case-insensitive to
table/column names unless you double-quote them, and ordering is as-per
the query, not table def. But it's not the cause of your issue.
What else is left to provide as far as details?
Nothing, you've been very comprehensive. The actual problem seems to be
that sql/postgres/dialup.conf isn't being read. The 2.x series
sql.conf basically looks like this:
sql {
database = blah
driver = rlm_sql_${blah}
...
$INCLUDE sql/${database}/dialup.conf
}
Check that this INCLUDE hasn't vanished or gotten lost; if you look
right at the top of the server startup, it reads all the config,
including all including lines, and you can see it loads sql.conf, then
policy.conf - there's no message saying it's including dialup.conf.
So, in short, the SQL queries aren't being read from your config file -
check the raddb/sql.conf file, and compare it to the original, or the
one for reference here:
https://github.com/FreeRADIUS/freeradius-server/blob/release_2_1_12/raddb/sql.conf
Finally, and not related to your issue - consider upgrading to 2.2.0 as
2.1.12 has security issues and bugs which are fixed.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Groups in active directory and checks in MySQL
On 08/26/2013 09:04 AM, Atomikramp wrote: but it's not giving the same result, the check against sql is ignored and the user is authed successfully. Because: [sql] User sogo1 not found ++[sql] returns notfound - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-SIM Module Failed to Load
On 25.08.2013 15:03, ken.farrington wrote: Module: Linked to sub-module rlm_eap_sim Module: Instantiating eap-sim rlm_eap_sim is compiled in. /usr/local/etc/raddb/modules/sim_files[1]: Failed to link to module 'rlm_sim_files': rlm_sim_files.so: cannot open shared object file: No such file or directory rlm_sim_files is not compiled in. In fact you do not need rlm_eap_files. All can be done using rlm_files module. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mac Auth against LDAP
On 26 Aug 2013, at 11:39, Nikolaos Milas nmi...@noa.gr wrote:
On 26/8/2013 12:15 μμ, Arran Cudbard-Bell wrote:
No. It's a really inefficient way of doing this.
Thanks Arran,
Yet, would it be logically/technically correct?
Sure.
Use generic attribute maps or an update ldap schema to pull the necessary
values into control attributes,
and then do the comparison in policy language.
Hmm, if I understand right, I could query once a custom attribute with e.g.
the value of 0/1/2 depending on the type of mac-auth we would like to do.
Thus, two LDAP queries would suffice to check correctly the client in all
cases, where in my initial script we would need 3 at best or 4 at worst.
Unless you are querying different DNs for the different Mac-Auth types then
doing this is the wrong way to approach this.
the presence of the attributes in the LDAP object to dictate what type of
authorisation you're doing.
Map the check items:
radiusNASIPAddress
radiusNASPort (add it to the default schema or use radiusHint instead)
to the check items NAS-IP-Address and NAS-Port
authorize {
preprocess
rewrite_calling_station_id
ldap
if (!ok !updated) {
reject
}
if (control:NAS-IP-Address) {
if (control:NAS-IP-Address !=
%{%{NAS-IP-Address}:-%{Packet-Src-IP-Address}}) {
reject
}
if (control:NAS-Port (control:NAS-Port !=
%{%{NAS-Port}:-%{NAS-Port-ID}})) {
reject
}
}
update control {
Auth-Type := Accept
}
}
Reject has the same effect as a return statement in the above.
The example would be to use a policy like:
set_mac_auth_type {
update request {
auth_type :=
%{ldap_macauth:ldap:///ou=Nodes,dc=example,dc=com?macauthtype?sub?macAddress=%{Calling-Station-Id}})
}
}
You may as well use Autz-Type.
i.e. map an attribute macautztype to the checkItem autz-type
authorize {
preprocess
rewrite_calling_station_id
ldap
if (!ok !updated) {
reject
}
Autz-Type nas {
# do stuff
}
Autz-Type nas_and_port {
# do stuff
}
}
You can then check the states of the various other control attributes inside
one of those Autz-Type sections.
Policy execution will effectively ignore Autz-Type sections the first pass
through authorize, and then loop back round
and enter one of them.
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-SIM Module Failed to Load
On 08/26/2013 12:11 PM, Iliya Peregoudov wrote: On 25.08.2013 15:03, ken.farrington wrote: Module: Linked to sub-module rlm_eap_sim Module: Instantiating eap-sim rlm_eap_sim is compiled in. /usr/local/etc/raddb/modules/sim_files[1]: Failed to link to module 'rlm_sim_files': rlm_sim_files.so: cannot open shared object file: No such file or directory rlm_sim_files is not compiled in. Oops yes sorry. rlm_sim_files, not rlm_eap_sim In fact you do not need rlm_eap_files. All can be done using rlm_files module. I'll defer to you on that ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Groups in active directory and checks in MySQL
So, basically if i didn't understand incorrectly, the user must also exist in the sql database for it to be checked against the radgroupcheck table and for attributes in the radreply table to be sent back to the NAS. nbsp; an hybrid configuration cannot be done? as my schema, being an active directory, is pretty strict and i cant modify it without the risk of screwing it up, and even if i could mess with the schema, groupcheck when LDAP is nbsp;involved, in all examples i've seen, has always been done using file backend (raddb/users). nbsp; it would be really useful for me to be able to populate the groupcheck and radgroupreply tables with the parameters i need, and keep the user authentication in LDAP. nbsp; - Original Message Da: FreeRadius users mailing list lt;freeradius-users@lists.freeradius.orggt; To: freeradius-users@lists.freeradius.org lt;freeradius-users@lists.freeradius.orggt; Oggetto: Re: Groups in active directory and checks in MySQL Data: 26/08/13 13:22 On 08/26/2013 09:04 AM, Atomikramp wrote: gt; but it's not giving the same result, the check against sql is ignored gt; and the user is authed successfully. Because: gt; [sql] User sogo1 not found gt; ++[sql] returns notfound -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: SUPERMARIO: Acquista Peluche e T-shirt Originali su mistercupido.com Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12899d=20130826 -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: BARBAPAPA': Acquista i Peluche Originali su mistercupido.com Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12898d=26-8 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mac Auth against LDAP
On 26/8/2013 2:15 μμ, Arran Cudbard-Bell wrote:
Unless you are querying different DNs for the different Mac-Auth types then
doing this is the wrong way to approach this.
the presence of the attributes in the LDAP object to dictate what type of
authorisation you're doing.
Thanks Arran,
I tried and tested all scenarios with your (former) suggestion and it
worked flawlessly as:
ldap_macauth
if (!ok !updated) {
reject
}
if (control:NAS-IP-Address) {
if (control:NAS-IP-Address != %{NAS-IP-Address}) {
reject
}
if (control:NAS-Port (control:NAS-Port != %{NAS-Port})) {
reject
}
}
update control {
Auth-Type := Accept
}
Thanks so much. Correctly using the policy language is not so obvious
and it would take me long to figure out.
Finally, one finishing touch:
Can we use the new DHCP functionality to assign an IP address (stored in
the host's LDAP entry) to a correctly authenticated host?
-OR-
Can we check the IP address being used by the authenticated host,
compare it against a stored IP Address in the host's LDAP entry, and
deny access if there is a mismatch?
Best regards,
Nick
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
how to limit the repeating ldap lookups
Hi. Is it possible to limit the repeating ldap lookups that happen during mschap and tls negotiations? Like having an attribute that I could test for which would tell me that the negotiation is completed? thanks martin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: how to limit the repeating ldap lookups
On 26 Aug 2013, at 14:33, Martin Kraus lists...@wujiman.net wrote: Hi. Is it possible to limit the repeating ldap lookups that happen during mschap and tls negotiations? Like having an attribute that I could test for which would tell me that the negotiation is completed? If you list the ldap module after the eap module in the default configuration then the default config already does this. You may also want to consider using the rlm_cache module. Arran Cudbard-Bell a.cudba...@freeradius.org FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: how to limit the repeating ldap lookups
On Mon, Aug 26, 2013 at 02:45:29PM +0100, Arran Cudbard-Bell wrote:
Is it possible to limit the repeating ldap lookups that happen during mschap
and tls negotiations? Like having an attribute that I could test for which
would tell me that the negotiation is completed?
If you list the ldap module after the eap module in the default configuration
then the default config already does this.
You may also want to consider using the rlm_cache module.
I'm using TTLS+TLS.
I can see that the eap { ok = return } automagically skips to the
authentication section but the first two access-requests in the session cause
it to return updated status so the ldap lookups are executed.
I assume there isn't much I can do about that, right?
I then have a separate problem with the inner-tunnel where the inner-eap never
returns ok in the authorization section so it keeps on doing the ldap lookups.
in the session I have it did 9 separate passes which together with the outer
tunnel is 11 ldap passes which in my case is more then 30 ldap lookups for a
single user login.
There are also these warnings in inner-tunnel
WARNING: !!
WARNING: !! EAP session for state 0xfa098d01f80a8033 did not finish!
WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility
WARNING: !!
but the inner tls session seems to be still progressing fine since the last
warning is right before the last access-request which results in the
access-accept for the user.
Is there something I can do about the 9 lookups in the inner-tunnel server?
I'll have a look at the rlm_cache as well but I'm just curious as to why is it
happening.
thanks
Martin
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
