2.3 Login Security, Session Settings, and Identity Basics

Login security is layered control

Authentication answers who is trying to enter Salesforce. Authorization answers what the authenticated user can do. Session control answers how long and under what assurance level the authenticated session remains valid. Setup scenarios often mix these ideas, and the wrong answer usually comes from treating all access failures as profile problems.

Start with evidence. Setup > Users > Login History shows login attempts, status, source IP, login type, and failure reasons. Setup > Security > Session Settings controls timeout behavior, session security levels, clickjack and content protections, and related session policies. Setup > Security > Network Access stores trusted IP ranges. Profiles can also include login hours and login IP ranges. Connected Apps add another layer for OAuth and external client access.

Passwords are only one part of the login story. Password Policies let admins define expiration, history, complexity, lockout behavior, and related controls. Multi-factor authentication adds a second verification factor and is a major expectation for modern Salesforce access. Admins should not solve repeated login challenges by weakening password or verification settings for everyone. First find whether the friction is caused by a location, device, SSO policy, session timeout, or user education issue.

Security control comparison

Trusted IP ranges and profile login IP ranges are a classic exam trap. A trusted range can reduce additional verification challenges for logins from known networks. A profile login IP range can prevent users with that profile from logging in outside approved ranges. If a question says users are blocked when they travel, inspect profile login IP ranges. If it says users are prompted for extra verification from a new office, inspect trusted ranges and identity verification behavior.

Session timeout is another place where admins need judgment. A short timeout can protect sensitive data on shared or mobile devices, but it can frustrate users who work from long forms or dashboards. A long timeout improves convenience but increases risk if devices are unattended. The right answer depends on data sensitivity, device posture, compliance requirements, and user workflow. For sensitive permissions, high assurance session requirements may be more precise than making every session extremely short.

My Domain is foundational for modern identity features because it gives the org a branded, unique login domain and supports several authentication and security capabilities. Single sign-on can centralize authentication through an identity provider. That does not mean Salesforce permissions disappear. A user authenticated through SSO still needs the correct license, profile, permission sets, role, and sharing access inside Salesforce.

Connected apps deserve attention because many login problems are not browser login problems. A user may access Salesforce through the mobile app, an integration, a data tool, or an external application using OAuth. Connected app policies can restrict users, require approval, set refresh token behavior, or enforce session policies. Before changing global session settings, ask whether the issue affects all login methods or only one connected app.

Agentforce and AI-related access should be treated as a governed identity surface. Admins may need to know which users can configure agents, test actions, access grounding data, or monitor usage. Do not use an AI feature to bypass the security model. If an agent or assistant can surface data, the admin must understand whose access is being used, which permissions apply, what audit data exists, and whether the use case is appropriate for automation or should remain a human review path.

Login troubleshooting workflow

1. Confirm the exact error, login method, time, user, browser or app, and network location.
2. Review Login History for status, source IP, and failure reason.
3. Check whether the user is active, frozen, locked out, assigned the correct license, and inside allowed login hours.
4. Compare the source IP with profile login IP ranges and trusted network ranges.
5. Review SSO, My Domain, connected app, and multi-factor requirements if the login uses identity integrations.
6. If login succeeds but work fails, move to authorization: profile, permission sets, role, sharing, field security, and app access.

Hands-on practice should include deliberately creating a safe, limited login policy in a sandbox or Developer Edition org. For example, set login hours on a test profile, observe the effect with a test user, and then remove the restriction. Review Login History after both attempts. This is better than memorizing labels because it shows how Salesforce records the event and how a real admin would troubleshoot.

The exam angle is to preserve security while restoring legitimate access. If only one user is locked out, resetting the password or unlocking the user may be enough. If all users on one profile fail from home, profile IP ranges may be the cause. If mobile access fails but browser access works, inspect connected app policy. If users can log in but cannot view account records, stop looking at authentication and troubleshoot authorization.