Skip to main content

#Security185 utenti parlano di questo argomento

Patrick Chinery ha fatto una domanda in #Tableau Server

Does anyone know the which files / folders need exemptions from the Anti Virus scans.  Deployments are on the D drive.. 

 

#Tableau Server  #Security

0/9000

Hi 

I have Connected Apps that I am updating with Client Credentials Flow for Server-to-Server Integration. 

 

The evidence seems to be that you can retain the Current Connected apps but all future apps will be External Client Apps 

 

My questions is are people migrating from Connected Apps to External Client Apps as a matter of course? 

or are they simply updating the Connected App to Client Credentials, accepting that any future apps are Client External Apps 

 

#Salesforce Admin  #Salesforce Developer  #Security  #Salesforce

2 risposte
  1. Oggi, alle 13:10

    Hi @Angela Mullen-Smith

    - You can keep connected apps AS IS. But External client apps offer more flexibility in terms of usage. Connected apps still work but its better to start migrating to external client app. 

    Migrating connected apps to external client app is not a direct way as you need to verify the auth mechanism (As you plan to revisit you can also try to move from basic authentication to Oauth and improve), auth provider, named credentials and how you authenticate (principal or per user). 

     

    Also external client apps requires access through permission set. That's also important to consider.

0/9000

Hi everyone,

I found the recent article about the upcoming changes to uninstalled connected apps to be a bit ambiguous, and I suspect others might share the same confusion. For example: 

  

"To minimize disruption to existing app usage, end users can continue to use uninstalled apps only if both of these criteria apply. The user has previously authorized the app. The app isn’t using the OAuth 2.0 device flow. Any new user trying to access these same uninstalled apps will be blocked. All uninstalled apps that use the OAuth 2.0 device flow will be blocked, even for specific users who have previously authorized the app. Connected apps installed before the change will continue to function without interruption.

 

This seems to contradict the guidance in the communication plan section:  

 

"Customer Admins or users responsible for managing connected apps should communicate this change to end-users to prevent issues if users can’t access connected apps. For example: 'Starting in early September, you may face issues accessing some connected apps since restrictions were put in place for accessing uninstalled apps. Please contact your Salesforce Org Admin, provide with the name of the application you are trying to access, and reason for the access request.' Establish a process for handling new end-user access requests for uninstalled apps following the least privileged principle. Review OAuth Usage for Connected Apps."  

 

This has left me unsure about the exact behavior. 

 

My questions are:

  1. For existing users who are already using an integration via a Connected App with the OAuth Username-Password flow, will they be impacted? Will their org admin need to install the app for them to keep using it?
  2. For new users, will the OAuth flow with username and password still work if the Connected App is not installed? Or will the authentication fail immediately, requiring the Connected App to be installed first?

Thanks in advance for any clarification! 

 

@* Salesforce Developers * 

3 risposte
0/9000

In our client on OKTA is enable so client don't want to use ' Require periodic step-up authentication when exporting or printing' feature because it required MFA for exporting reports, so please suggest me we can disable this feature or how we can bypass this feature other the IP restriction?

1 risposta
  1. Oggi, alle 12:05

    Hi @Indramani Tiwari If Require periodic step-up authentication when exporting or printing is enabled, Salesforce does not provide a supported way to bypass it. You can disable the feature only if your organization's security policy allows it. If your client uses Okta for MFA, review your identity and session security settings to determine whether the feature is required. Otherwise, the only supported options are to disable the setting or use trusted network/IP exceptions where appropriate.

0/9000

Hello All, 

We are currently facing an issue with the Salesforce Connector for Google Sheets. We have been unable to export Salesforce reports to Google Sheets using the connector. 

We are receiving the following error message: 

"In order to get all of the report data, disconnect and re-authorize the Add-on from Salesforce using Help > Connection Information > Disconnect Add-on. Once disconnected, log in to Salesforce again using the Add-on." 

Based on our initial findings, we suspect that this issue may have been caused by the recent MFA enforcement in the Production environment.  

Each time a user tries to export a report, a new verification window opens and asks for an MFA verification code.

We are using the Salesforce Connector and have followed the instructions provided in the error message. After reconnecting, the export works only up to 2,000 records, and then the connection fails again.

Is there any workaround or recommended solution to prevent repeated MFA prompts and allow users to export reports successfully?

 

 

 

#Salesforce Admin  #Security  #MFA  #Salesforce_connector

1 commento
  1. Oggi, alle 02:06

    Hi Sanjay, 

     

    I'm running into the exact same issue on our end. We've traced it back to the same root cause. 

    Could you share exactly what steps you've tried so far, and whether anything has actually resolved it on your end — even partially?  

     

    Thanks, 

    Nel

0/9000

⛰️ 🔐 New Hands-on Workshop for Premier & Signature Admins: Secure the Org: Find and Fix Vulnerabilities (ADX012)

 

 Misconfigured security settings are one of the leading causes of data breaches. In this 90-minute instructor-led workshop, you'll step into the role of an internal security auditor to identify and fix real Salesforce vulnerabilities across the most common misconfiguration areas. 

 

This workshop was adapted from a fan-favorite capture-the-flag game that has been a hit at live Salesforce events — now available virtually so more admins can play! This practical workshop is for:

  • Newer admins — you'll find the challenges approachable and manageable. The hands-on format makes security feel less daunting and more actionable
  • Seasoned practitioners — you'll likely discover security settings you haven't previously been aware of
  • All learners — challenges are independent of each other, so you can move at your own pace, skip ahead, and circle back with no pressure

Sessions are live and available!

  • Fri Jul 31 — 9:00am ET [AMER]
  • Mon Aug 3 — 3:30pm ET [AMER]
  • Tue Aug 11 — 10:00am CET [EMEA]
  • Check the session listings for more workshops across regions 

➡️ Premier and Signature customersRegister today on Trailhead Academy — Course code: ADX012

 

#Security

11 commenti
0/9000

Hi everyone, 

I'm experiencing an issue in a Salesforce Sandbox when trying to access: 

Setup → App Manager → View App → Manage Consumer Details 

 

When I click Manage Consumer Details, Salesforce opens the Verify Your Identity dialog, but the authentication immediately fails with the following error: 

There are no built-in authenticators available to this browser. 

Verify Your Identity fails with 'There are no built-in authenticators available to this browser' when opening Manage Consumer Details

 

Environment:

  • Salesforce Sandbox
  • Google Chrome

 

What I've already verified:

  • Touch ID is correctly registered as my authentication method.
  • Touch ID works correctly for other authentication requests.

 

From what I've investigated, it appears that the Verify Your Identity dialog may be rendered inside an internal iframe, and the browser is therefore unable to access the registered authenticator. 

 

Has anyone encountered this issue before? Is this a known Salesforce or Chrome limitation, or is there a configuration or workaround that resolves it? 

 

Any help or suggestions would be greatly appreciated. 

 

Thank you! 

 

 

 

#Security

8 risposte
  1. 22 lug, 18:11

    Im having this same issue as well, switching to Classic as a work around worked. For anyone else who can't remember where it is in classic Setup > Build > Create > Apps > clicks on the connected app name

0/9000

I have some issues with some employees, they request approval, but where do I find that approval I'm not seeing any place as the admin to approve so he can continue using inbox    

2 risposte
  1. 29 lug, 19:21

    Another question relating to this update, I have one person who does get the regualar setup for inbox ,but one person only had this   

     

    Another question relating to this update, I have one person who does get the regualar setup for inbox ,but one person only had this Any help would be great

     

     

    inbox not working Screenshot 2026-07-29 094314.png

     

    Any help would be great

0/9000

Hi all - coming to you with what is (hopefully) an easy fix. One of my users is having to manually log out of SFDC, login, use her authenticator, and finally be back in. Right now she's the only person who has to manually do this each day, otherwise nothing will work properly.     Details:

  • We have the same profile/role but I'm the active admin for the org at this point
  • I've checked our User accounts and the only real difference is I use external websites like Dataloader where I have to separately authenticate, everything else is the same
  • She's cleared her cache/restarted her computer
  • I believe she's using a Microsoft Authenticator (as am I)
  • She's logging in through the website (not via our SSO)
  • This started on or after July 1, 2026

Any idea what she might need to do? She originally had two authenticators linked, so I removed the inactive one. My thought process would be for her to reset the authenticator and see how that lands, but if folks have other recommendations, I'd greatly appreciate it.

1 risposta
  1. 29 lug, 16:46

    Hi Jozette, 

     

    Since this is affecting only one user

    , it's unlikely to be an org-wide Session Settings or MFA configuration issue. I'd focus on the user's browser, session, or authentication state. 

     

    Here are a few things to check: 

     

    • Login History (Setup → Login History) for that user. Look for repeated session expirations, identity verification events, or login errors that might explain why they're being forced to reauthenticate.
    • Compare the user's Profile Session Settings (especially Session Times Out After and Session Security Level Required at Login) with yours to ensure there isn't a profile-specific difference. Salesforce documents these settings here: https://help.salesforce.com/s/articleView?id=platform.users_profiles_session.htm&type=5
    • Review your org's Session Settings (Setup → Session Settings) to verify the session timeout and identity verification policies. If these were the cause, however, you'd expect multiple users to be affected. https://help.salesforce.com/s/articleView?id=sf.admin_sessions.htm&type=5
    • Have the user remove and re-register Microsoft Authenticator as the MFA method. Since you mentioned they previously had two authenticators configured, re-enrolling the active authenticator is a reasonable next step.
    • Try signing in from a different browser or another machine. If the issue disappears, it's likely related to the browser profile, cookies, or local security software rather than Salesforce.
    • Check whether the user's browser is clearing cookies on exit or has privacy settings/extensions that delete Salesforce session cookies each time the browser is closed. This can force a full login every day.

    You mentioned this started on or after July 1, 2026. Salesforce has been rolling out additional login security and phishing-resistant authentication changes during this period, but since only one user is affected, this doesn't appear to be the expected behavior of the rollout. If the above checks don't identify the cause, I'd recommend opening a Salesforce Support case and including the affected user's Login History

    and timestamped examples. 

     

    Official references: 

     

0/9000

i was prompted this morning to create a passkey - am I system administrator - how do I ensure its been turned off for all other users?  Can I disable this feature we already have MFA and the firm determined that passkeys are not important 

 

 

#Salesforce Admin  #Sales Cloud  #Security

2 risposte
  1. Coby Press (Black Cloud) Forum Ambassador
    28 lug, 14:58

    Salesforce has recently updated their security requirements so that Privileged users are now required to have a passkey, non privileged users still have other MFA options. E.g. If you are an admin - you will need to have one 

     

    https://help.salesforce.com/s/articleView?id=005388907&type=1

0/9000