Post-auth (ldap) update if statement works w/ radtest, doesn't work with actual authentication

Tue Feb 1 18:31:11 UTC 2022

On Feb 1, 2022, at 1:16 PM, Toupin, Nick via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> 
> Fairly new to Freeradius - been using Microsoft/NPS for years and now
> trying to migrate to Freeradius.

  That's good.  :)  I'm sure NPS is a good product for what it does, but FreeRADIUS does more and better!

>  I'm like 99% of the way to having what we
> want configured, just stuck on this last part.  Seeing as it works with
> radtest but doesn't work with an actual authentication, I'm assuming
> there's something missing/different in my config that's specific to the
> authentication type (PAP -> ldap) that radtest doesn't hit so the radtest
> works.. more below including the debug.

  Yes.  Google doesn't provide passwords to FreeRADIUS.  So FreeRADIUS has to get the plain-text password from the user. This happens *only* with PAP.

  i.e. if the debug output doesn't contain any reference to User-Password, then Google LDAP authentication won't work.

> *Some background info:*
> 
>   - Using Google LDAP to authenticate the radius using Google accounts
> 
>   - Built the setup using this guide/info:
>   https://www.nasirhafeez.com/freeradius-with-google-g-suite-workspace-secure-ldap-for-wpa2-enterprise-wifi/

  That's not too bad.  What he doesn't say is that the end user systems have to send TTLS + PAP for authentication.  If they don't use that, then Google LDAP authentication is impossible.

>   - Added in a if statemenet under the /sites-enabled/default -> ldap ->
>   update to check the user's DN in Google to grab their OU, if they match an
>   OU within the statement they are given an update reply of '
>   Tunnel-Private-Group-Id = "160"   '  with an else of
>   '  Tunnel-Private-Group-Id = "180"   ' so X OU members get VLAN 160 and
>   everyone else gets VLAN 180.

  That's fine.  It won't affect authentication.

>   - This is all fully working with radtest:
> 
>   radtest teststaff '******' xx.xxx.xx.xxx 0 '**************'
>   Sent Access-Request Id 87 from 0.0.0.0:37520 to xx.xxx.xx.xxx:1812
>   length 79
>           User-Name = "teststaff"
>           User-Password = "******"

  Yup.  "User-Password".

>   - When trying with an actual Radius authentication the authentication
>   goes through however the if statement fails so the user gets
>    Tunnel-Private-Group-Id 180 no matter what -- freeradius debug notes
>   'ERROR: Failed retrieving values required to evaluate condition'

  See the debug output for why.  The message isn't perfect, but what it means is this:

* the "if" condition refers to a particular attribute
* that attribute doesn't exist in the packet (or anywhere else referenced by the "if" statement)

> (5) eap: Peer sent packet with method EAP TTLS (21)

  TTLS is good.

> (5) eap: Calling submodule eap_ttls to process data
> (5) eap_ttls: Authenticate
> (5) eap_ttls: Continuing EAP-TLS
> (5) eap_ttls: [eaptls verify] = ok
> (5) eap_ttls: Done initial handshake
> (5) eap_ttls: [eaptls process] = ok
> (5) eap_ttls: Session established.  Proceeding to decode tunneled attributes
> (5) eap_ttls: Got tunneled request
> (5) eap_ttls:   User-Name = "teststaff"
> (5) eap_ttls:   User-Password = "******"
> (5) eap_ttls:   FreeRADIUS-Proxied-To = 127.0.0.1
> (5) eap_ttls: Sending tunneled request
> (5) Virtual server inner-tunnel received request
> (5)   User-Name = "teststaff"
> (5)   User-Password = "******"

  User-Password is good.

> ...
> (5) server inner-tunnel {
> (5)   # Executing section authorize from file
> /etc/freeradius/3.0/sites-enabled/inner-tunnel
> (5)     authorize {
> ...
> rlm_ldap (ldap): Reserved connection (2)
> (5) ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
> (5) ldap:    --> (uid=teststaff)
> (5) ldap: Performing search in "dc=DOMAIN,dc=org" with filter
> "(uid=teststaff)", scope "sub"
> (5) ldap: Waiting for search result...
> (5) ldap: User object found at DN "uid=teststaff,ou=Testing,ou=Elementary
> Staff,ou=Elementary School,ou=Users,dc=DOMAIN,dc=org"
> (5) ldap: Processing user attributes
> (5) ldap: WARNING: No "known good" password added. Ensure the admin user
> has permission to read the password attribute

  That's fine.  Google doesn't supply passwords to FreeRADIUS.

> ...
> (5)       if (User-Password)  -> TRUE
> (5)       if (User-Password)  {
> (5)         update control {
> (5)           Auth-Type := ldap

  OK.

> (5)   Found Auth-Type = ldap
> (5)   # Executing group from file
> /etc/freeradius/3.0/sites-enabled/inner-tunnel
> (5)     authenticate {
> rlm_ldap (ldap): Reserved connection (3)
> (5) ldap: Login attempt by "teststaff"
> (5) ldap: Using user DN from request
> "uid=teststaff,ou=Testing,ou=Elementary Staff,ou=Elementary
> School,ou=Users,dc=DOMAIN,dc=org"
> (5) ldap: Waiting for bind result...
> (5) ldap: Bind successful
> (5) ldap: Bind as user "uid=teststaff,ou=Testing,ou=Elementary
> Staff,ou=Elementary School,ou=Users,dc=DOMAIN,dc=org" was successful
> rlm_ldap (ldap): Released connection (3)
> Need 2 more connections to reach 10 spares
> rlm_ldap (ldap): Opening additional connection (8), 1 of 24 pending slots
> used
> rlm_ldap (ldap): Connecting to ldaps://ldap.google.com:636
> rlm_ldap (ldap): Waiting for bind result...
> ber_get_next failed.
> rlm_ldap (ldap): Bind successful

  That's good.  So the user has been successfully authenticated.

> (5)     } # update = noop
> (5)     if (&control:LDAP-UserDN =~ /,ou=District Staff/) ||
> (&control:LDAP-UserDN =~ /,ou=High School Staff/) || (&control:LDAP-UserDN
=~ /,ou=Elementary Staff/) {
> (5)     ERROR: Failed retrieving values required to evaluate condition

  i.e. there's no control:LDAP-UserDN in the "outer" session, because it's only been set in the inner one.

> ...
> (5) Sent Access-Accept Id 147 from xx.xxx.xx.xxx:1812 to
> xxx.xx.xxx.xxx:56820 length 0
> (5)   MS-MPPE-Recv-Key =
> 0xa107a762471fee4871d11ab936184c5cb8a0af457be8f91698ada4e266007a0d
> (5)   MS-MPPE-Send-Key =
> 0xbfc140a4da9bf14e67cebb2db4d1bd9115b9b2f6831acec281f610a0636c8f33
> (5)   EAP-Message = 0x03850004
> (5)   Message-Authenticator = 0x00000000000000000000000000000000
> (5)   User-Name = "teststaff"
> (5)   Tunnel-Private-Group-Id = "180"

  And the user is put into VLAN 180. :(

  The solution here is to copy the LDAP-UserDn from the "inner-tunnel" to the "outer" one.

  Edit sites-enabled/inner-tunnel, and look for "post-auth { ... }

  Then near the end, add:

	update outer.control {
		LDAP-UserDn := &control:LDAP-UserDn
	}

  which copies the attribute to where it can be used.  That should work.

  As with everything FreeRADIUS, it's big, complex, but all of the pieces are there (somewhere) in the debug log. :)

  Alan DeKok.