On Mar 10, 2016, at 5:43 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks@sath.nhs.uk> wrote:
Thanks Arran, So it seems that disabling "chase referals" might fix things, it's certainly a huge amount quicker and doesn't sit there binding until timeout. If, as part of the redundant-load-balance module handling, the "downed" server gets called, it waits for a search result from the dead server for the res_timeout figure, and then tries to get back it's required pool amount since it deleted the inviable connection, but it tries the same server.
The problem here is interaction between the FreeRADIUS fail-over and the LDAP referrals. FreeRADIUS assumes that an LDAP server is just an LDAP server. When AD sends a referral... many things can happen.
This is the bit I'd like to understand - it then waits "Connecting to..." for about 75-80 seconds before it idles out all the pooled connections, even if the idle option in mods-enabled/ldap is set to something quite a bit lower like 20 seconds. Is this expected?
idle_timeout means "used successfully, and then not used for a while". If it sits in "connecting to" for 75-80 seconds, you want just a connection timeout. There should be one in the LDAP module configuration.
It's not a huge problem as stuff eventually catches up and when new connections are tried, the fail response is quite quick and will try the next server in the redundant... bit. Two questions : - Is the 75-80 seconds expected (not a huge deal)
Blame AD. And see the timeout configurations in the LDAP module.
- Is it worth me debugging to find out why AD is giving out referals that presumably can't be connected to, and if so how?
Uh... ask AD why it's referring you to servers that are down.
I tried adding debug options "debug 255" and "logdir /var/log" to ldap.conf, and turning on the 0x0028 option in mods-enabled/ldap but I can't see any debugging information - any clues?
You need to run the server in debug mode to see the LDAP debugging. Alan DeKok.