authentication
62 TopicsAPI Pre-Authentication
Some time ago I was dealing with legacy web applications being retrofitted with modern authentication. As you can imagine this opens up a world of pain when the developers of said applications have long since left. In this particular case we had an application migrating to a new API which was secured behind a non-f5 reverse proxy. The difficulty was API authentication. First the user would SSO to access the application but this was only for web application access. The API used by the application was hosted in a secure environment behind the proxy and there is no support by the standards for any authentication flows under the hood. I refer to fetch() and XHTMLRequest() calls by the application. Key: Redirect = > Issue Flow User requests web application > Federated auth > Web application loads in user browser context and starts making API calls which fail. I did not have LTM handy to whip up some awesome solution to resolve this which would have been ideal case so had to figure out how to solve this another way. The Non-F5 Solution All authentication requests have to occur at the user level so the only way in this scenario, was to redirect them. They were redirected to a dedicated endpoint on the proxy which automatically triggered an auth redirect for federated authentication. This would see the user has already logged in and issue the relevant proxy credentials (as a cookie) to the client who would then return to the proxy with these credentials. The only issue with this flow is everything about the original redirect from the client is lost during the authentication process. The only thing that remains is the original URL the user requested. Prototype Solution User requests web application > Federated auth > Web application Loads - API Access? No > Proxy > Federated auth > Proxy > ? Javascript handling Developers add javascript calls to API endpoint and if the return code is XXX redirects the user to proxy with parameter ?return=current url Final Solution User requests web application > Federated auth > Web application loads - API Access? No > Proxy with return URL > (No Authentication) Federated auth > (Adds Proxy Authentication Cookie into Users Browser) Proxy with return URL > (Redirect user to return URL) Web application loads - API Access (Using Proxy Authentication Cookie) ? Yes, proceed as normal. Since that time there may have been new standards that make this challenge simpler to navigate. Are you aware of any? Moreover which of the various F5 offerings would have been able to assist us with this issue?Solved120Views1like8CommentsOCSP AUTH AGENT
Hello everyone, I'm facing a situation and I need your input to figure it out what's wrong. I have a VIP where mtls is configured in the client SSL profile with the issuer's certificate as CA (we call it CA_1), and it works well. (Per info, the client cert is issued by CA_1, which is also issued and signed by a higher authority CA_2.) I wanted to make OCSP checks for client certificates so I created a simple APM policy as follows : Client --- > on-demand cert agent ---> OCSP Auth Agent ---> Allow or deny The OCSP responder is configured with the same CA_1 that's configured in the in the Client authentication in the ssl profile, and a responder (ocsp.example.com). The error I'm facing is OCSP Auth agent: Failure status 'Error querying OCSP responder host ocsp.example.com. To troubleshoot, I did few tests and we can eliminate the following possibilities: Connectivity and DNS: I can reach the responder in the http port using the FQDN. Blocked traffic : no Firewall inspection between the BIG IP and the responder. The responder is not treating the request as it should: openssl ocsp verification works fine and gets me the wanted result from the ocsp responder. The famous "missing host header" : the header is well included in the request sent by the big ip to the responder; moreover, i compared this request to the one sent when using openssl ocsp and the one sent when i test from my own computer using openssl, and they are identical when it comes to the OCSP date in the request and response frames. What's more interesting is when I capture the response sent by the responder when the apm sends the ocsp verification request, i can clearly see that's stating the status of the certificate (which is revoked in my case), but the APM logs doesn't show that; instead, when debugging, it says that the on-demand cert agent is executed (i can see the client cert and the issuer cert CA_1 as well) and then it moves successfully to the OCSP auth agent and then directly it says the querying error. Could you please tell me if you see anything i could do to troubleshoot more ? Any ideas ? PS 1 : I tried also using the CA_2, a bundle of CA_1 and CA_2, a cert chain of both, but no luck ! PS 2 : when i use the CRLDP agent, i can see the status (revoked) in the APM logs. Thank you in advance !31Views0likes0CommentsKerberos Authentication Failing for Exchange 2016 Behind F5 Cloud WAF
Hi Team, We’re running Microsoft Exchange Server 2016 CU24 on Windows Server 2019, and have enabled Kerberos (Negotiate) authentication due to NTLM being deprecated in F5 Cloud WAF. Environment summary: Exchange DAG setup: 4 servers in Primary Site, 2 in DR Site Active Directory: Windows Server 2019 F5 Component: Cloud WAF (BIG-IP F5 Cloud Edition) handling inbound HTTPS traffic Namespaces: mail.domain.lk, webmail.domain.lk, autodiscover.domain.lk Authentication configuration: Negotiate (Kerberos) with NTLM, Basic, and OAuth as fallback SPNs: Correctly registered under the ASA (Alternate Service Account) computer account Certificate: SAN includes mail, webmail, and autodiscover Current status: Internal domain-joined Outlook 2019 clients work without issue. Outlook 2016, Office 2021, and Microsoft 365 desktop apps continue to prompt for passwords. Internal OWA and external OWA through F5 Cloud WAF both work correctly. Observation: Autodiscover XML shows <AuthPackage>Negotiate</AuthPackage> for all URLs. Kerberos authentication works internally, so SPNs and ASA setup are confirmed healthy. Password prompts appear only when traffic passes through F5 Cloud WAF, which terminates TLS before reaching Exchange. Suspected cause: F5 Cloud WAF may not support Kerberos Constrained Delegation (KCD) in the current configuration. TLS termination on F5 breaks the Kerberos authentication chain. NTLM/Basic fallback might not be fully passed through from WAF to backend. We would appreciate clarification on: Does F5 Cloud WAF support Kerberos Constrained Delegation (KCD) for backend Exchange 2016 authentication? If not, can Kerberos pass-through or secure fallback methods (NTLM/Basic) be enabled? Recommended configuration for supporting Outlook 2016 and Microsoft 365 clients when Exchange advertises Kerberos (Negotiate)? Is there an F5 reference configuration or iRule template for this scenario (Exchange 2016 + Kerberos)? Thank you for your guidance.Solved418Views0likes7CommentsF5 with TACACS+ Cisco ISE for users authentication
Hi Guys, I'm trying to setup F5 TACACS+ authentication against Cisco ISE, however I notice my F5 is using external interface's IP to communicate with Cisco ISE, is there a way to tell F5 to use mgmt or internal interface's IP to communicate with Cisco ISE instead of external? Thanks.232Views0likes2CommentsF5OS Radius failures with Clearpass
Hello, First post ever on devcentral so I ask that you take it easy on me haha. Anyways, recently stood up some new R-series F5s and F5OS is a new world for me. Currently running iSeries appliances. Going through some of the basic configurations and I've made my way to authentication. I've added radius as one of my accepted authentication options and created my server group with the clearpass server attached in that group. Selected radius, put in the correct IP, radius secret, etc. Per the documentation it looks good. Going into clearpass for those familiar - Created my new F5 device, put in the shared secret, added new device to my existing F5 device group. Essentially all I've ever had to do when working with other vendors. Attempting logins with my user account I get hit with "Permission Denied" at the login screen. This is where I am lost. I check clearpass, my access tracker says I successfully authenticated. Clearpass shows no obvious issues. I log back into F5OS with my local admin and I check the login activity. Shows my user account and a big ole "Success" for the login attempt. I apologize for the word salad. I was trying to put my process out there including that both F5OS and Clearpass seem happy with my attempt but the F5OS login page says denied. Anyone have any R-series appliances using clearpass for radius and authentication? I'm curious what I'm missing.451Views1like2CommentsR-Series after upgrading to 1.8 - RADIUS Auth stopped working
Radius user authentication was working just fine while running v1.40. After upgrading to 1.80 any attempt is "Failed authentication." Running tcpdump does not show any traffic going to the RADIUS server and the RADIUS server has not entry of the failures in it's log. I have deleted and recreated the radius server group - that did not help. I have deleted and recreated users - that did not help. Any guidance for what to try next is appreciated. Dave208Views0likes1CommentF5 & TACACS communication
Hello Community, I am currently working to find RCA for an issue in which during Datacentre fail-over testing, we unable to to login to F5 and assuming their is communication issue between F5 and TACACS Server, and I have a few questions regarding how the authentication process works and how failover occurs when the primary TACACS server is unavailable. Here are my questions: Packet Exchange: How does TACACS function at the packet level when F5 sends authentication requests? What types of packets are exchanged between F5 and the TACACS server during authentication? Failover to Secondary TACACS Server: When the primary TACACS server is down or unreachable, how does F5 detect this and automatically send authentication requests to the secondary TACACS server? What type of packets and log entries should we see on the F5 side when this occurs? Timeout and Retry Behavior: How many retry attempts does F5 make before switching to the secondary TACACS server? How long does F5 wait before retrying, and is this configurable? I would appreciate any insights, best practices, or references to relevant documentation that can help clarify these points. Even packet capture also helps as this is not feasible for me to reproduce issue. Thanks in advance for your help! Best regards, Pradeep264Views0likes1CommentProblems with F5 Rseries and LDAPs for remote authentication
Good afternoon I'm having some problems getting remote authentication to work on my Rseries computer over LDAPS, when debugging I get the following error: Can't contact LDAP server: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate) I have followed several guides and consulted different articles, but I can't find any of them which fields are mandatory and which aren't. My question is regarding the fields: Cipher String, TLS CA Certificate and TLS Key. Is it mandatory to fill in these fields? What happens if they are left empty? Best Regards218Views0likes1CommentHA Active Directory for F5 authentication
I have two f5 Big-IP wit LTM module in HA. I have configured Admin authentication in BIG-IP through Remote Active Directory and It works properly. The challenge is I have several synchronized AD servers and I would like to achieve HA in Big-IP authentication. I have created a pool with my AD servers with a custom LDAP monitor and It seems that works because all members look up in the pool. I also created a virtual server that listen in port 389 and use the AD server pool as default pool. However, when I set the host value to virtual server IP in system-->users-->authentication, all authentication attempts fail. Is required an special configuration in virtual server to make it work?158Views0likes2CommentsBigIP APM Oauth - set to 'Failed to perform curl: Failure when receiving data from the peer'
We've been dealing with a issue when an Oath token is sent to Azure for authentication using XXX.session.oauth.client.last.auth_redirect: login.windows.net/XXXXX/XXXX session.oauth.client.last.auth_resule 0 We are constantly seeing the error and causing out Oath Client to be denied. We are able to perform a "discover" in the Provider and able to "dig" to the Azure Enterprise. Our DNS Resolver is able to resolve DNS as per guide. Has anybody come across this and can point us in the right direction? The only way we can make is work is to change the APM policy to "fallback" Allow OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/Azure_Oauth_Server' using 'authorization_code' grant type (client_id=XXXXXXXXXXXXXXXX), error: Failed to perform curl: Failure when receiving data from the peer Session variable 'session.oauth.client./DC-TEST/OAuthClientToAzureAD_act_oauth_client_ag.authresult' set to '0' Session variable 'session.oauth.client./DC-TEST/OAuthClientToAzureAD_act_oauth_client_ag.errMsg' set to 'Failed to perform curl: Failure when receiving data from the peer Session variable 'session.oauth.client.last.authresult' set to '0' OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'client_secret=********'OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'grant_type=authorization_code' OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'redirect_uri=https://our.test.website.com/oauth/client/redirect OAuthClientToAzureAD_act_oauth_client_ag: OAuth: Request parameter 'code=********' OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/Azure_Oauth_Server' using 'authorization_code' grant type (client_id=XXXXXXXXXXXXXXX), error: Failed to perform curl: Failure when receiving data from the peer If we change the Access Policy "fallback" to "Allow" the user is then allowed to reach the backend application but would have otherwise been denied. It seem during the Oauth Client process the token request is rejected Previously we were seeing the error below which we resolved by making sure the DNS resolver could resolve DNS correctly. OAuthClientToAzureAD_act_oauth_client_ag: OAuth Client: failed for server '/DC-TEST/AzureAD_Server' using 'authorization_code' grant type (client_id=d7b3f856-6053-462b-a8f3-c2820e2a4c6c), error: HTTP error 503, DNS lookup failed1.4KViews0likes5Comments