F5 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.F5OS 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.
R-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. Dave
F5 & 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, PradeepYubikey Authentication Modes and Azure AD integration via the APM
Introduction The Yubikey ( https://www.yubico.com/) supports three major functions, authentication, signing and encryption. As far as authentication goes, it supports a list of the following mechanisms. OTP (one-time password) Yubikey OTP (Time based OTP) OATH HOTP (HMAC based OTP) FIDO U2F (Universal 2 nd Factor) FIDO2 PIV (Smartcard) Each of the above-mentioned protocols has its own set of requirements and is therefore not universally supported everywhere. OTP OTP is probably the simplest, with a one-time password being used, typically as the 2 nd factor. However, it is also the weakest, as it does not mitigate against MITM attacks. E.g., A fake site impersonating a legitimate site can trick the user into entering the OTP and subsequently forwards it to the real site. All Yubikey’s by default have manufacture assigned secrets registered with Yubico’s own validation servers. Yubico provides a tool that allows you to re-program the key, giving it a different secret. However, the new secret has to be uploaded to Yubico’s validation servers ( https://upload.yubico.com/ ) otherwise OTP will stop working. Yubikey OTP integrates with a large number of services (e.g., Gmail, LastPass). When a service receives an OTP, it reaches out to Yubico for validation. In the case of Okta, the secrets can be uploaded directly into Okta and validation happens within Okta. FIDO U2F FIDO U2F or U2F for short, mitigates MITM. This method requires the user to register the authenticator (e.g., Yubikey) with the application (e.g., Gmail) first, during which a key pair is generated by the authenticator, and the public key is sent and stored on the application. Once the registration is complete, the user can then use the authenticator as the 2 nd factor. In the case of Gmail, once the user’s credentials are verified, the user touches the Yubikey for 2 nd factor. No code is entered by the user. FIDO2 FIDO2 enables passwordless authentication. Once the Yubikey is registered with an application (e.g., Azure Portal) for FIDO2 authentication, the user touches the Yubikey, optionally provides a PIN code for the key, logs straight in. – no username is entered FIDO2 is an evolution of U2F and is dependent upon WebAuthn (client API implemented within the browser) and CTAP2 (authenticator API that enables FIDO2-capable devices to interface to external/roaming authenticators over Bluetooth, USB or Near field communication (NFC)). Per FIDO Alliance ( https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/#:~:text=WebAuthn%20is%20currently%20supported%20in,Windows%2010%20and%20Android%20platforms ), browser support for U2F and WebAuthn are shown below. PIV YubiKey can also present itself as a PIV smartcard that contains a client certificate. APM Integration There are a number of articles on DevCentral that cover programming the APM to receive the Yubikey OTP and then send it over to Yubico’s validation servers via a side band connection for OTP verification. My particular use case is to leverage an IDaaS (e.g., Azure AD) as an IDP and use the APM as the SP. My choice of integration is via OIDC, but SAML is an equally valid option. Since authentication is offloaded to Azure AD, both the OTP and FIDO2 passwordless authentication methods are now available. Azure AD does not support U2F. Azure AD and User Configuration OTP If Yubikey is used for OTP, Azure AD needs to have MFA enabled, a ‘Conditional Access’ policy is created to ‘Require multi-factor authentication’ for your selected apps. This process is documented by Microsoft ( https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa ). The user must also add an authenticator app via self-registration ( https://mysignins.microsoft.com/ ), be sure to click on the highlighted, this allows you to enrol the ‘Yubico Authenticator’ ( https://www.yubico.com/products/services-software/download/yubico-authenticator/ ). The Yubico Authenticator works with the Yubikey to generate the OTP. Yubico argues that it is more secure as unlike a soft authenticator, the secrets are not saved within the authenticator itself, but rather in a secure element within the Yubikey. Note ‘Touch your Yubikey’, which is needed before an OTP is generated. The OTP method does not impose special requirements on the browsers, which means it works on any browsers, as well as on the APM Edge client, which leverages certain browser functions FIDO2 With FIDO2 based passwordless authentication, the ‘FIDO2 Security Key’ option within the Azure AD (e.g., under Security) has to be enabled first. Again, the user goes through self-registration ( https://mysignins.microsoft.com/ ) prior to the Yubikey becoming available. I have tried different browsers on the Mac, the only browsers that work are Chrome and Edge. Milage may vary in Windows. If FIDO2 works, the highlighted option will appear. In the case of Azure AD, a PIN is required (configured over the self-registration process). Once it’s entered, the user logs in after touching the Yubikey. At this time, the latest (v7210) APM Edge client’s embedded browser for login does not work with FIDO2, likely due to WebAuthn not being supported. If the user uses a supported browser, passwordless authentication should work, after which a webtop is presented.
Problems 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 RegardsHA 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?BigIP 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 failed
