authenticating against local LDAP and Jumpcloud LDAP

[Alan DeKok]

On Feb 15, 2016, at 8:20 PM, Michael Martinez <mwtzzz at gmail.com> wrote:
> The situation is this: I've got a Freeradius server that successfully
> authenticates Wifi devices with EAP-TTLS with PAP for the inner tunnel. The
> system also works for ssh clients with PAM authentication. I set up it
> myself following different instructions, half-knowing but not really
> knowing what I was doing. But it works.

  If it works, that's good.

> Recently I set up an LDAP directory in Jumpcloud. Their instructions for
> integrating with Freeradius also are for PAP within TTLS, and involve
> making one change in the sites-available/inner-tunnel file:
> 
> within the authorize{} block, move the following to the bottom of the block
> update control {
>    Proxy-To-Realm := LOCAL
> }

  That move doesn't do anything useful in your configuration.

  I'd suggest using the default configuration.  Not because your changes are wrong, but because they are pointlessly different.


> and insert Auth-Type := `/bin/bash /opt/RadiusCheck/CheckUser.sh
> '%{User-Name}' '%{User-Password}'` immediately after the Proxy-to-Realm
> line.

  That's... weird.

> The CheckUser.sh script is just a simple shell script that makes an LDAP
> query to Jumpcloud and returns a success or fail.

  Why not just configure LDAP directly in FreeRADIUS?  The server has done LDAP for oh, 15 years now.

 That's just weird.  But I'm not surprised, because most third-party documentation is incredibly wrong.

> Okay, I don't know what "update control" is for.

$ man unlang

  This *is* documented.

> I don't know how the
> authorize section works, but I made the changes and tested it out and it
> works fine for my Jumpcloud user. But it doesn't work anymore for my local
> LDAP users because irying to authenticate all users against jump cloud.

  Exactly.

> What I'd like is for the local ldap database to be queried first. And if
> that fails, then to check the Jumpcloud directory.

  That's a bad design.

  Instead, figure out why the users are different.  Read the debug output.  Look at User-Names for local users, and for jump cloud users.  Are they consistently different?  How are they different?

 Then, write a rule:

	if (local user)  {
		ldap
	}
	else {
		do jump cloud stuff
	}

> Looking through the
> inner-tunnel file I see a few references to ldap, but these are all
> commented out, so I'm not clear how/where the local ldap database is being
> queried.

  If the LDAP calls are commented out, then the local LDAP database isn't being queried.

  Alan DeKok.