Error: Ignoring duplicate packet, LDAP performance

[uj2.hahn at posteo.de]

Hi, Alan!

On 28.02.2020 13:23, Alan DeKok wrote:
>> On Feb 28, 2020, at 4:53 AM, uj2.hahn at posteo.de wrote:
>>
>> Hi, freeradius team!
>> I know, this "Ignoring duplicate packet" topic has been discussed for a long time again and again.
>    It's almost always a slow database.
>
>> Everything works fine, there are no user complaints so far.
>> BUT: The central Meraki dashboard has a built-in test function to check all managed NAS if they are able to communicate
>> with radius server. So I have to provide an existing user/password and the dashboard triggers each NAS to check for
>> freeradius authentication with same credentials.
>> In this scenario I run into the "Ignoring duplicate packet" issue (see freeradius log part below)
>    Why is that user special?  i.e. what is different about that user account, versus the normal user accounts?

Nothing! It is a normal user account I provide manually, e.g. my own.

>
>> which let the Meraki dashboard reports some NAS as failing. The count of failing NASs and the failing NASs are varying .
>> However when I disable the LDAP post-auth section everything is fine.
>    Then something in LDAP is blocking FreeRADIUS.
>
>    And what are you doing with LDAP in the post-auth section?
Group checking to start some authorizing, e.g. students have login time 
limitations but teachers don't have limitations.
>
>> Wed Feb 26 14:21:05 2020 : Info: rlm_ldap (ldap): Opening additional connection (17641), 1 of 30 pending slots used
>> Wed Feb 26 14:21:05 2020 : Info: rlm_ldap (ldap): Deleting connection (17640) - Was referred to a different LDAP server
>    That's useful information.
>
>> I'm pretty sure the root cause is related to general network and/or LDAP performance.
>    Yes.
>
>> Actions I will take are:
>> - let network admin check the network and DC/AD server performance
>> - review my freeradius LDAP queries if they are specific enough (reducing the amount of data they generate)
>    What are you doing with LDAP in the post-auth section?  That's good to know.
See above.
>
>> But I have some questions to freeradius team related to that:
>> I have a single freeradius server and a single DC/AD server.
>    Your LDAP server doesn't think so.
>
>> 1) Why does freeradius open and close LDAP connections pretty often? Isn't one permanently open connection good enough?
>    See the logs above.  The LDAP server is telling FreeRADIUS to look up the information in a different LDAP server / domain.
>
>    The same machine might serve both domains, but the LDAP APIs require us to completely rebind / tear down the connections.

O.k, understood!

>
>> 2)  What does this message mean: Info: rlm_ldap (ldap): Deleting connection (17640) - Was referred to a different LDAP server
>>       There is just one LDAP server!
>    Then configure it to *not* send referrals.
>
>    Or, read mods-available/ldap, and look for "referrals".  You can configure FreeRADIUS to ignore the referral request.
>
>    But, ignoring referrals will likely just make the LDAP query fail.

Will try out.

>
>>       I started  a debug session and found this matching part in debug log:
>>
>>      (25) ldap: User object found at DN "CN=jasmin hahn,OU=Schueler,DC=moritz,DC=local"
>>      (25) ldap: EXPAND (samaccountname=%{mschap:User-Name})
>>      (25) ldap:    --> (samaccountname=jasmin-hahn)
>>      (25) ldap: Waiting for bind result...
>>      (25) ldap: Bind successful
>>      (25) ldap: Performing search in "DC=moritz,DC=local" with filter "(samaccountname=jasmin-hahn)", scope "sub"
>>      (25) ldap: Waiting for search result...
>>      rlm_ldap (ldap): Rebinding to URL ldap://ForestDnsZones.moritz.local/DC=ForestDnsZones,DC=moritz,DC=local
>>      rlm_ldap (ldap): Waiting for bind result...
>>      rlm_ldap (ldap): Rebinding to URL ldap://DomainDnsZones.moritz.local/DC=DomainDnsZones,DC=moritz,DC=local
>>      rlm_ldap (ldap): Waiting for bind result...
>>      rlm_ldap (ldap): Rebinding to URL ldap://moritz.local/CN=Configuration,DC=moritz,DC=local
>    Your LDAP server is referring the query to a different AD domain.  That's pretty clear.

I guess this is a LDAP server configuration issue, I need 
ldap://moritz.local only. Or can I tweak the LDAP query
to focus on this domain only?

>
>> 3) In my special case (self test by Meraki dashboard) I check same user from all NASs within a short timeframe.
>>      So freeradius should provide always same feedback. Could the freeradius flow be shortened by a cache mechanism?
>    There's a "cache" module which can be configured to cache information.  See mods-available/cache

Hah! I hoped you will say that!! :-)
I will try that out.
Thanks a lot!
>
>    Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html