FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap
Hello, I have an issue which I am sure is easy to fix but I cannot find the correct file/setting. Let me explain: Environment: Active Directory - backend authentication. The AD environment is setup as a hub & spoke design. This means not all domain controllers (GC) are accessible from everywhere (by design & security) Freeradius - CentOS7 server FreeRadius-3.0.13 Source Setup: It is basically a setup following this site: https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-factor-... Validations: SSSD = Server joined to the domain fine. Can login to the local server with a domain account. ident tests resolve fine DNS = hostname and any GC server resolves correctly AD search results = **while in subnet80, works correctly** Google Authenticator PAM = **while in subnet80, works correctly** Issue: When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine. So I know the basic configurations are working as designed. When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers. There is a firewall between these subnets. I have configured the following files to specify which GC servers FreeRadius should use: /etc/raddb/mods-available/ldap ldap { server = 'dc01.domain.local' server = 'dc02.domain.local' start_tls = no port = 389 identity = 'CN=ad-read-account,DC=domain,DC=local' password = 'xxxxxxx' base_dn = 'DC=domain,DC=local' /etc/sssd/sssd.conf [sssd] domains = domain.local services = nss, pam [domain/domain.local] id_provider = ad access_provider = ad ad_server = dc01.domain.local ad_backup_server = dc02.domain.local krb5_realm = DOMAIN.LOCAL krb5_server = dc01.domain.local kerb5_backup_server = dc02.domain.local ldap_uri = ldap://dc01.domain.local /etc/krb5.conf [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false [realms] DOMAIN.LOCAL = { kdc = dc01.domain.local kdc = dc02.domain.local [domain_realm} domain.local = DOMAIN.LOCAL .domain.local = DOMAIN.LOCAL When I run "radiusd -CX". I get an ready to process requests for configuration check. When I run "radiusd -X", this is the where the process fails/hangs: rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Reserved connection (5) (0) EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}) (0) --> (userPrincipalName=user1@domain.local) (0) Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1@domain.local)", scope "sub" (0) Waiting for search result... This will sit there until the LDAP search times out. When I perform a packet capture during this time, what I see: 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local 2 dns server responds with records of ALL GC servers 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions) Resolution: It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP. Of course DNS responds with all LDAP SRV records. What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use. This seems very similar to SSSD Service Discovery. Any assistance on this one would be appreciated. btw... I cannot post full debug logs due to security but will provide any additional info that might assist with this Thanks
On Aug 10, 2020, at 12:04 PM, Brandt Winchell <brandt.winchell@thinkon.com> wrote:
I have an issue which I am sure is easy to fix but I cannot find the correct file/setting. Let me explain:
Environment: Active Directory - backend authentication. The AD environment is setup as a hub & spoke design. This means not all domain controllers (GC) are accessible from everywhere (by design & security) Freeradius - CentOS7 server FreeRadius-3.0.13
Updated packages are available from http://packages.networkradius.co,
Source Setup: It is basically a setup following this site: https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-factor-...
OK..
Issue: When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine. So I know the basic configurations are working as designed. When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers. There is a firewall between these subnets.
So... you put a firewall between FreeRADIUS and LDAP, which prevents them from communicating. The short answer is "don't do that".
I have configured the following files to specify which GC servers FreeRadius should use: /etc/raddb/mods-available/ldap ldap { server = 'dc01.domain.local' server = 'dc02.domain.local'
That's nice, except that the LDAP servers don't know which ones are reachable from where. So they might give FreeRADIUS an LDAP redirect, to an LDAP server it can't reach.
When I run "radiusd -CX". I get an ready to process requests for configuration check.
Because it doesn't try to open connections to the LDAP server.
When I run "radiusd -X", this is the where the process fails/hangs: rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful
Which means that FreeRADIUS can talk to dc02.domain.local.
rlm_ldap (ldap): Reserved connection (5) (0) EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}) (0) --> (userPrincipalName=user1@domain.local) (0) Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1@domain.local)", scope "sub" (0) Waiting for search result...
This will sit there until the LDAP search times out.
Because the LDAP server it's trying to talk to is unreachable.
When I perform a packet capture during this time, what I see: 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local
Because dc02.domain.local is giving an LDAP redirect to forestdnszones.domain.local. And forestdnszones.domain.local isn't reachable.
2 dns server responds with records of ALL GC servers 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions)
Exactly.
Resolution: It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP. Of course DNS responds with all LDAP SRV records. What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use. This seems very similar to SSSD Service Discovery.
The short answer here is "don't break your network". Either make sure that all GC servers are reachable from FreeRADIUS, *or* make sure that the GC servers know about the network topology. i.e. the GC servers don't give redirects to ones which are unreachable. The longer answer is that FreeRADIUS doesn't implement LDAP itself. It uses the OpenLDAP client library to implement LDAP. And it's not trivial to "filter" those redirects. And even if it could filter those redirects, what would it do? If the GC returns "talk to forestdnszones.domain.local", what should FreeRADIUS do? Ignore it? Connect instead to some random other LDAP server? The solution here isn't poking FreeRADIUS, unfortunately. The solution is fixing your network so that it isn't broken. Alan DeKok.
Hello, I have spent the last few days trying to figure out what can be done. (in reference to fix the network) The network is perfectly fine. The AD replication topology is deliberately designed to be a hub-spoke. 172.16.80.0/24 hub site happens it can talk to all the other GCs by design. 172.16.99.0/24 is only designed to talk to 172.16.80.0/24 by design and security reasons. So FreeRadius should not have or should have to talk any other GCs as there are 2 perfectly good GCs it is allowed to talk to. (What I was able to find - Joe's comment about ldap query too broad) I performed some ldapsearch tests with the same bind account FreeRadius is using (to verify creds). When I run the search command to the base "dc=domain,dc=local", The results come back right away but I do reach a size limit an the end of the output. When I run the same command but base "ou=users,dc=domain,dc=local", I get all the results of the OU and no size limit error/warning. . I played around with the ldap.conf file. No matter what I set there seemed to make no difference. . When I played with the LDAP {} section of /etc/raddb/mods-available/ldap, I was able to get some results. When I set the base_dn = 'DC=domain,DC=local' -> base_dn = 'OU=users,DC=domain,DC=local' I get the search results back right away. . Now I cannot leave this setting as not all my users exists under that one OU. That is just where the test account resides. . I have a feeling the rlm_ldap is reaching a limit with the size of the search but no matter what is set in ldap.conf makes no difference. I see no option within the ldap{} module to set a size/time limit Are there any more debug logs I can view during this process to validate it is a size limit? Thanks B -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+brandt.winchell=thinkon.com@lists.freeradius.org> On Behalf Of Alan DeKok Sent: August 10, 2020 1:45 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap On Aug 10, 2020, at 12:04 PM, Brandt Winchell <brandt.winchell@thinkon.com> wrote:
I have an issue which I am sure is easy to fix but I cannot find the correct file/setting. Let me explain:
Environment: Active Directory - backend authentication. The AD environment is setup as a hub & spoke design. This means not all domain controllers (GC) are accessible from everywhere (by design & security) Freeradius - CentOS7 server FreeRadius-3.0.13
Updated packages are available from http://packages.networkradius.co,
Source Setup: It is basically a setup following this site: https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-f actor-Authentication-with-Google-Authenticator.pdf
OK..
Issue: When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine. So I know the basic configurations are working as designed. When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers. There is a firewall between these subnets.
So... you put a firewall between FreeRADIUS and LDAP, which prevents them from communicating. The short answer is "don't do that".
I have configured the following files to specify which GC servers FreeRadius should use: /etc/raddb/mods-available/ldap ldap { server = 'dc01.domain.local' server = 'dc02.domain.local'
That's nice, except that the LDAP servers don't know which ones are reachable from where. So they might give FreeRADIUS an LDAP redirect, to an LDAP server it can't reach.
When I run "radiusd -CX". I get an ready to process requests for configuration check.
Because it doesn't try to open connections to the LDAP server.
When I run "radiusd -X", this is the where the process fails/hangs: rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful
Which means that FreeRADIUS can talk to dc02.domain.local.
rlm_ldap (ldap): Reserved connection (5) (0) EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}) (0) --> (userPrincipalName=user1@domain.local) (0) Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1@domain.local)", scope "sub" (0) Waiting for search result...
This will sit there until the LDAP search times out.
Because the LDAP server it's trying to talk to is unreachable.
When I perform a packet capture during this time, what I see: 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local
Because dc02.domain.local is giving an LDAP redirect to forestdnszones.domain.local. And forestdnszones.domain.local isn't reachable.
2 dns server responds with records of ALL GC servers 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions)
Exactly.
Resolution: It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP. Of course DNS responds with all LDAP SRV records. What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use. This seems very similar to SSSD Service Discovery.
The short answer here is "don't break your network". Either make sure that all GC servers are reachable from FreeRADIUS, *or* make sure that the GC servers know about the network topology. i.e. the GC servers don't give redirects to ones which are unreachable. The longer answer is that FreeRADIUS doesn't implement LDAP itself. It uses the OpenLDAP client library to implement LDAP. And it's not trivial to "filter" those redirects. And even if it could filter those redirects, what would it do? If the GC returns "talk to forestdnszones.domain.local", what should FreeRADIUS do? Ignore it? Connect instead to some random other LDAP server? The solution here isn't poking FreeRADIUS, unfortunately. The solution is fixing your network so that it isn't broken. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Aug 14, 2020, at 2:39 PM, Brandt Winchell <brandt.winchell@thinkon.com> wrote:
(in reference to fix the network) The network is perfectly fine.
So... everything works, and you're not asking for any more help? Realistically, the network is not fine. If it was fine, then FreeRADIUS would be able to talk to all GC servers. And I've never understood the reasoning behind people who ask questions and then argue with the answers. If you know better than us, you don't need to ask questions. And if you don't know better than us, it would be polite to learn from others. As it stands now, you're just arguing for the sake of arguing.
The AD replication topology is deliberately designed to be a hub-spoke. 172.16.80.0/24 hub site happens it can talk to all the other GCs by design. 172.16.99.0/24 is only designed to talk to 172.16.80.0/24 by design and security reasons.
That's nice. Have you told AD about these restrictions? i.e. does AD check the source network, and refer clients to *only* those GC servers which are reachable from that source network? Hint: No.
So FreeRadius should not have or should have to talk any other GCs as there are 2 perfectly good GCs it is allowed to talk to.
As I tried to explain, this isn't about FreeRADIUS. The AD server is returning a referral to FreeRADIUS. That referral is the DNS name of a GC server. That DNS name resolves to an IP address which is unreachable from FreeRADIUS. You've split your network into multiple segments which can't talk to each other. Then, you've made sure that AD doesn't know about this split. That's the problem. It isn't difficult. Your options for a solution are: a) un-break your network so that each segment can talk to any GC server b) fix AD so that it returns only reachable GC servers when queried from a segment. No amount of poking FreeRADIUS will fix this issue. It isn't a FreeRADIUS problem.
I have a feeling the rlm_ldap is reaching a limit with the size of the search
Which is why it's getting a referral to a GC server which is unreachable. Hmm... yes, that's it.
but no matter what is set in ldap.conf makes no difference. I see no option within the ldap{} module to set a size/time limit Are there any more debug logs I can view during this process to validate it is a size limit?
Why ask questions if you're going to argue with the answers? Why would we answer questions if you're doing to tell us that we're wrong? Alan DeKok.
Typically a ldap query goes to the gc when your search parameters are too broad and or not configured properly. What configuration do you have setup for the group portion of ldap.conf? Thanks! —joe
On Aug 10, 2020, at 12:05 PM, Brandt Winchell <brandt.winchell@thinkon.com> wrote:
Hello, I have an issue which I am sure is easy to fix but I cannot find the correct file/setting. Let me explain:
Environment: Active Directory - backend authentication. The AD environment is setup as a hub & spoke design. This means not all domain controllers (GC) are accessible from everywhere (by design & security) Freeradius - CentOS7 server FreeRadius-3.0.13
Source Setup: It is basically a setup following this site: https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-factor-...
Validations: SSSD = Server joined to the domain fine. Can login to the local server with a domain account. ident tests resolve fine DNS = hostname and any GC server resolves correctly AD search results = **while in subnet80, works correctly** Google Authenticator PAM = **while in subnet80, works correctly**
Issue: When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine. So I know the basic configurations are working as designed. When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers. There is a firewall between these subnets. I have configured the following files to specify which GC servers FreeRadius should use: /etc/raddb/mods-available/ldap ldap { server = 'dc01.domain.local' server = 'dc02.domain.local' start_tls = no port = 389 identity = 'CN=ad-read-account,DC=domain,DC=local' password = 'xxxxxxx' base_dn = 'DC=domain,DC=local'
/etc/sssd/sssd.conf [sssd] domains = domain.local services = nss, pam [domain/domain.local] id_provider = ad access_provider = ad ad_server = dc01.domain.local ad_backup_server = dc02.domain.local krb5_realm = DOMAIN.LOCAL krb5_server = dc01.domain.local kerb5_backup_server = dc02.domain.local ldap_uri = ldap://dc01.domain.local
/etc/krb5.conf [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false [realms] DOMAIN.LOCAL = { kdc = dc01.domain.local kdc = dc02.domain.local [domain_realm} domain.local = DOMAIN.LOCAL .domain.local = DOMAIN.LOCAL
When I run "radiusd -CX". I get an ready to process requests for configuration check. When I run "radiusd -X", this is the where the process fails/hangs: rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Reserved connection (5) (0) EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}) (0) --> (userPrincipalName=user1@domain.local) (0) Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1@domain.local)", scope "sub" (0) Waiting for search result...
This will sit there until the LDAP search times out.
When I perform a packet capture during this time, what I see: 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local 2 dns server responds with records of ALL GC servers 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions)
Resolution: It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP. Of course DNS responds with all LDAP SRV records. What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use. This seems very similar to SSSD Service Discovery.
Any assistance on this one would be appreciated. btw... I cannot post full debug logs due to security but will provide any additional info that might assist with this
Thanks
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Brandt Winchell -
Joe Nordone