On 04/05/16 13:15, A.L.M.Buxey@lboro.ac.uk wrote:

Hi,

...

Don't worry folks - this isn't a repeat of the same question about multiple LDAP servers. I've read the docs and I know how it's *supposed* to work, but I think I've found a discrepancy in the messages printed by the server. I'm running FreeRADIUS 3.0.11.

you ge the same with 3.1.x - if defined in one line you get that same warning message. havent had time to look at the 'correct' way that the server suggests yet...which is multiple 'server' lines - which as you say seems to not work at all as expected - as I havent looked into it, I havent submitted a bug on github.

alan -

Looks like Arran was talking about the new syntax at least in April 2015: http://stackoverflow.com/questions/18060771/how-to-configure-freeradius-with... Arran, what counts as "later versions of FreeRADIUS 3"? Thanks, Jonathan

On 4 May 2016, at 08:05, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

...

On 4 May 2016, at 05:19, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:

On 04/05/16 13:15, A.L.M.Buxey@lboro.ac.uk wrote:

...

Hi,

...

Don't worry folks - this isn't a repeat of the same question about multiple LDAP servers. I've read the docs and I know how it's *supposed* to work, but I think I've found a discrepancy in the messages printed by the server. I'm running FreeRADIUS 3.0.11.

you ge the same with 3.1.x - if defined in one line you get that same warning message. havent had time to look at the 'correct' way that the server suggests yet...which is multiple 'server' lines - which as you say seems to not work at all as expected - as I havent looked into it, I havent submitted a bug on github.

alan -

Looks like Arran was talking about the new syntax at least in April 2015:

http://stackoverflow.com/questions/18060771/how-to-configure-freeradius-with... Arran, what counts as "later versions of FreeRADIUS 3"?

If you want visibility into what's going on, it's better to use a template section to configure rlm_ldap, and have one instance per server, referencing them in a redundant-load-balance block. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On 4 May 2016, at 09:25, A.L.M.Buxey@lboro.ac.uk wrote:

Hi,

...

If you want visibility into what's going on, it's better to use a template section to configure rlm_ldap, and have one instance per server, referencing them in a redundant-load-balance block.

ldap ldap1 {} ldap ldap2 {}

etc - could all be in one file....

and then use the redundancy load balance block to use them:

redundant-load-balance { ldap1 ldap2 ldap3 }

instead of just calling ldap ?

It's the better way. I've been really tempted to remove support for multiple servers because of how they would mess up the connection pool stats. But... The final design for rlm_ldap involves multiple connection pools, so that we can deal with referrals better. When used with referrals, it would be useful to be able to pre-establish connections to the hosts that may be referred to, so allowing multiple server config items would be better. We'd also then have different pools for each server, so the stats would work ok...

interesting....might give that a go (our current problem is that we set the lifetime/timeout to 0 and it appears that after *seme time* (to be found out) and/or *some event* the server will not connect to the LDAP anymore... it shouldnt have closed connections....)

1) maybe need some kind of keepalive thing going on in the server (to ensure firewalls or linux kernel TCP stuff doesnt play in this?)

Yeah, that'd be my guess, but libldap does allow the TCP keepalive stuff to be tweaked. #ifdef LDAP_OPT_X_KEEPALIVE_IDLE { FR_CONF_OFFSET("idle", PW_TYPE_INTEGER, rlm_ldap_t, keepalive_idle), .dflt = "60" }, #endif #ifdef LDAP_OPT_X_KEEPALIVE_PROBES { FR_CONF_OFFSET("probes", PW_TYPE_INTEGER, rlm_ldap_t, keepalive_probes), .dflt = "3" }, #endif #ifdef LDAP_OPT_X_KEEPALIVE_INTERVAL { FR_CONF_OFFSET("interval", PW_TYPE_INTEGER, rlm_ldap_t, keepalive_interval), .dflt = "30" }, #endif Consult libldap docs for what each of those options actually do.

2) more connection info with eg radmin ?

Yes, in v3.1.x I added per connection pool statistics with high/low triggers. Need to finish plumbing that in, but we now have stats internally on how long a connection was reserved for. It's not necessarily how long an operation took, there may be multiple operations per connection reservation, but it does let you identify when things are moving towards some sort of nasty meltdown.

by the way, we are using OpenLDAP compiled against OpenSSL rather than NSS - which was the default stuff....

Yeah, known problem with NSS/libldap/FreeRADIUS. We always have to build our own for RHEL, it's a bit of a pain.

when we did that (use our own LDAP compiled against OpenSSL) the reconnection after deliberately breaking connectivity worked a treat! :)

Great :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On 4 May 2016, at 14:55, A.L.M.Buxey@lboro.ac.uk wrote:

Hi,

...

It's the better way.

if you go this route, whats the way to do eg

if ( "%{ldap:ldaps:///dc=foo,dc=bar?department?sub?(&(sAMAccountName=%{User-Name})(memberOf=CN=leet staff,OU=p45,OU=possible,DC=foo,DC=bar))}" ) { stuff here }

Redundant blocks register their own expansions, even in v3.0.x. You just need to declare the redundant block in the instantiate section and give it a name. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On 4 May 2016, at 15:50, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:

Ah!

Of course, now I'm using multiple ldap configs I've now hit the too many files open issue.

You hit a file descriptor limit? How many connections are you opening? How many servers are you talking to? Unfortunately from a long term architecture point of view, having one connection per working thread is desirable, so there's not much we can do to fix that.

Which causes all sorts of interesting failure modes. Obvious when sql connection can't work - the cause is printed out. ... but it was failing in reading the root cert used for ldap instance 5 and claimed it couldn't read the file, x509 issue.

Heh. Yeah that's far outside of our control, deep inside whatever libldap happens to be using for TLS.

Given that using ulimit fixed this. ...... i guess if the failure is when spawning some Ssl stuff you can't do anything about it?

It failed when instantiating the module, right? Not when opening a connection? That'll be when it creates the new SSL_CTX.

I've updated /etc/security/limits.conf - giving radius user more soft/hard files... but that didn't work .. even though the server is using radius/radius the limits seem to require root limits to be modified . Looking at adjusting the systemd script right now but it'll catch out any local admins trying to do eg radiusd -X ;)

If you do sudo radiusd -X it'll change to the correct user IIRC. Only when you run it with usual user privs, will it stick to that user. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2