> Source: [sk185126](https://support.checkpoint.com/results/sk/sk185126)

# sk185126 - Users are unable to access non-SMO members after a Gaia password policy change or password reset

| Property | Value |
|----------|-------|
| Solution ID | sk185126 |
| Date Created | 2026-07-16 |
| Last Modified | 2026-08-04 |
| Technical Level | Advanced |
| Products | Scalable Platforms |
| Versions | R82.10, R82, R81.20 |
| OS | Gaia |

## Symptoms

- * After a Gaia password policy change or a password reset, existing users cannot switch from the SMO Security Group Member to a non-SMO Security Group Member using the *member* command - for example: *m 1_02*   

* When connecting to the non-SMO Security Group Member, the user is prompted for a password, but authentication consistently fails and the session ends with messages similar to `Permission denied` and `Connection closed`.  

  **Example lock-out log** in `/var/log/secure` for too many Failed Login Attempts:  

  `Disconnecting authenticating user <username> <client ip> port <source port>: Too many authentication failures [preauth]`  

  **Example lock-out log** in `/var/log/messages` for Unused Account Login:  

  `User <username> has not logged in in over X days; not allowing.`  

* The password reset completes successfully and the password hash is synchronized correctly between the SMO member and the non-SMO member, but authentication to the non-SMO member still fails.  

* Account-lockout events are recorded in the Gaia system messages log (*/var/log/messages* ) on each Security Group Member. To review them, connect over SSH to the Security Group management IP address, and then either run *show smo log messages filter \<USERNAME\>* in Gaia gClish or *g_all 'grep \<USERNAME\> /var/log/messages'* in Expert mode. In the output, look for entries such as *pam_dof_tally* and *failed password* for the affected user.

## Cause

Gaia account-lockout state is stored and enforced *locally and independently* on each Security Group Member. It is not part of the data that synchronizes from the SMO member, so each member maintains its own per-user lockout state in two files:

* */etc/loginhist/\<USERNAME\>* - used by the "Deny Access After Failed Login Attempts" mechanism.
* */etc/loginhist2/\<USERNAME\>* - used by the "Deny Access to Unused Accounts" mechanism.

The "Deny Access to Unused Accounts" mechanism (*/etc/loginhist2/\<USERNAME\>*) locks any account that has not recorded a successful login on that specific member within the configured unused-account period. Because a pre-existing user connects only through the SMO member and never logs in directly to the other members, those members never record a successful login for that user and therefore hold the account in a locked state.

Authentication in Gaia is evaluated in two separate phases: the credential (password) phase and the account-authorization phase. The password hash is synchronized to every member, so the credential phase succeeds - but the account-authorization phase on the non-SMO member then rejects the login based on that member's local unused-account lockout state.

**Important** - The lockout state is independent of the password. Changing or resetting the password does not create a successful-login record on the non-SMO members and does not clear the local lockout files, so the block persists until the files are removed.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content