Re: FreeRADIUS 3.0.12 + openLDAP + Apple access point?
It seems like the problem is with my huntgroup. In users: This will allow me to log in from the access point: DEFAULT Ldap-Group == "wifi-cph" With this definition I am rejected: DEFAULT Ldap-Group == "wifi-cph", Huntgroup-Name == "accesspoints-lan" The huntgroup from the huntgroups file # Group of accesspoint. Login from those, and you needi # to be a member of the wifi-copenhagen group (LDAP) accesspoints-lan NAS-IP-Address == 172.22.33.11 accesspoints-lan NAS-IP-Address == 172.22.33.22 accesspoints-lan NAS-IP-Address == 172.22.33.30 accesspoints-lan NAS-IP-Address == 172.22.33.33 accesspoints-lan NAS-IP-Address == 172.22.33.34 This is what I get when the access point connects: Thu Dec 7 09:28:15 2017 : Debug: (11) User-Name = "***" Thu Dec 7 09:28:15 2017 : Debug: (11) NAS-IP-Address = 172.22.33.33 Maybe the NAS-IP-Address is not available in the inner tunnel?
On Thu, 2017-12-07 at 08:47 +0000, Tobias Balle-Petersen wrote:
It seems like the problem is with my huntgroup.
Yes
In users:
This will allow me to log in from the access point: DEFAULT Ldap-Group == "wifi-cph"
With this definition I am rejected: DEFAULT Ldap-Group == "wifi-cph", Huntgroup-Name == "accesspoints- lan"
You can see in the debug output that the user was found in one of the LDAP searches, so the only logical conclusion here is that any other checks with it are failing.
The huntgroup from the huntgroups file # Group of accesspoint. Login from those, and you needi # to be a member of the wifi-copenhagen group (LDAP) accesspoints-lan NAS-IP-Address == 172.22.33.11 accesspoints-lan NAS-IP-Address == 172.22.33.22 accesspoints-lan NAS-IP-Address == 172.22.33.30 accesspoints-lan NAS-IP-Address == 172.22.33.33 accesspoints-lan NAS-IP-Address == 172.22.33.34
This is what I get when the access point connects: Thu Dec 7 09:28:15 2017 : Debug: (11) User-Name = "***" Thu Dec 7 09:28:15 2017 : Debug: (11) NAS-IP-Address = 172.22.33.33
Maybe the NAS-IP-Address is not available in the inner tunnel?
The debug output shows you what attributes are available in the inner tunnel... You need to copy the attribute from the outer to the inner so that you can use it. Either use the old (deprecated) method of setting 'copy_request_to_tunnel' in the eap configuration, or the current way of just copying the attribute you need, so update request { Huntgroup-Name := &outer.Huntgroup-Name } before calling 'files' in the inner tunnel should do it. -- Matthew
The debug output shows you what attributes are available in the inner tunnel...
I'm looking here, but I can't see it. Thu Dec 7 12:37:39 2017 : Debug: (10) Virtual server inner-tunnel received request Thu Dec 7 12:37:39 2017 : Debug: (10) EAP-Message = 0x023000061a03 Thu Dec 7 12:37:39 2017 : Debug: (10) FreeRADIUS-Proxied-To = 127.0.0.1 Thu Dec 7 12:37:39 2017 : Debug: (10) User-Name = "bj" Thu Dec 7 12:37:39 2017 : Debug: (10) State = 0x9aa53a9f9b95204846eab62797564f73 Thu Dec 7 12:37:39 2017 : WARNING: (10) Outer and inner identities are the same. User privacy is compromised. Thu Dec 7 12:37:39 2017 : Debug: (10) server inner-tunnel { Thu Dec 7 12:37:39 2017 : Debug: (10) session-state: No cached attributes Thu Dec 7 12:37:39 2017 : Debug: (10) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/inner-tunnel Thu Dec 7 12:37:39 2017 : Debug: (10) authorize { Thu Dec 7 12:37:39 2017 : Debug: (10) policy filter_username { Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name) { Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name) -> TRUE Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name) { Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name =~ / /) { Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name =~ / /) -> FALSE Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name =~ /@[^@]*@/ ) { Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name =~ /@[^@]*@/ ) -> FALSE Thu Dec 7 12:37:39 2017 : Debug: (10) if (&User-Name =~ /\.\./ ) { Or, maybe it's here, and only two attributes exist in the tunnel? Thu Dec 7 12:37:39 2017 : Debug: (1) ldap: Waiting for search result... Thu Dec 7 12:37:39 2017 : Debug: (1) ldap: User object found at DN "uid=bj,ou=people,l=copenhagen,c=dk,o=kontrapunkt,dc=examplet,dc=com" Thu Dec 7 12:37:39 2017 : Debug: (1) ldap: Processing user attributes Thu Dec 7 12:37:39 2017 : Debug: (1) ldap: control:Password-With-Header += '{CRYPT}****' Thu Dec 7 12:37:39 2017 : Debug: (1) ldap: control:NT-Password := 0x**** You need to copy the attribute from the outer to the inner so that you
can use it. Either use the old (deprecated) method of setting 'copy_request_to_tunnel' in the eap configuration, or the current way of just copying the attribute you need
copy_request_to_tunnel = yes in the eap file, did not solve the problem. I had gotten that far by myself.
update request { Huntgroup-Name := &outer.Huntgroup-Name }
before calling 'files' in the inner tunnel should do it.
That worked. Thank you for taking the time to help me out! I wonder why "copy_request_to_tunnel = yes" did not work? Is Huntgroup-Name actually a part of the request, as It's not sent by the client? Regards, Tobias
On Thu, 2017-12-07 at 11:47 +0000, Tobias Balle-Petersen wrote:
The debug output shows you what attributes are available in the inner tunnel...
I'm looking here, but I can't see it.
Thu Dec 7 12:37:39 2017 : Debug: (10) Virtual server inner-tunnel received request Thu Dec 7 12:37:39 2017 : Debug: (10) EAP-Message = 0x023000061a03 Thu Dec 7 12:37:39 2017 : Debug: (10) FreeRADIUS-Proxied-To = 127.0.0.1 Thu Dec 7 12:37:39 2017 : Debug: (10) User-Name = "bj" Thu Dec 7 12:37:39 2017 : Debug: (10) State = 0x9aa53a9f9b95204846eab62797564f73
Exactly - it's not there, so anything depending on it won't behave as expected.
You need to copy the attribute from the outer to the inner so that you
can use it. Either use the old (deprecated) method of setting 'copy_request_to_tunnel' in the eap configuration, or the current way of just copying the attribute you need
copy_request_to_tunnel = yes in the eap file, did not solve the problem. I had gotten that far by myself.
It's not set. If it was then there would be a lot more attributes in the inner tunnel than there are. Maybe you set the ttls setting, but not the peap one?
That worked. Thank you for taking the time to help me out!
OK, that's good. That's the better way to do it now anyway.
I wonder why "copy_request_to_tunnel = yes" did not work? Is Huntgroup-Name actually a part of the request, as It's not sent by the client?
It's added by 'preprocess'. -- Matthew
I'm looking here, but I can't see it.
Thu Dec 7 12:37:39 2017 : Debug: (10) Virtual server inner-tunnel received request Thu Dec 7 12:37:39 2017 : Debug: (10) EAP-Message = 0x023000061a03 Thu Dec 7 12:37:39 2017 : Debug: (10) FreeRADIUS-Proxied-To = 127.0.0.1 Thu Dec 7 12:37:39 2017 : Debug: (10) User-Name = "bj" Thu Dec 7 12:37:39 2017 : Debug: (10) State = 0x9aa53a9f9b95204846eab62797564f73
Exactly - it's not there, so anything depending on it won't behave as expected.
Doh.. Could not see the forest for the trees. Maybe you set the ttls setting, but not the peap one?
Yes, I actually tried setting both.. It's added by 'preprocess'.
Got it. Thanks. Tobias
participants (2)
-
Matthew Newton -
Tobias Balle-Petersen