On Feb 1, 2022, at 1:16 PM, Toupin, Nick via Freeradius-Users <freeradius-users@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-...
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.