DOC-12750 Authentication improvements - Ability to enable/disable Couchbase User (#3853)

* manage users n groups n blocking user

* lock n unlock users n manage password page

* Updated manage users and roles page for cli n api

* Added auditing user activity and rewrote manage auditing

* Added Reference section contents

* Enterprise Edition note added

* whats new entries

* image fix

* Implemented technical review inputs

* Implemented editorial review comments

* Minor edit Enterprise to Enterprise Edition

Author: rao-shwe

modules/ROOT/nav.adoc

@@ -96,7 +96,6 @@ include::third-party:partial$nav.adoc[]
    **** xref:learn:security/using-multiple-cas.adoc[Using Multiple Root Certificates]
  ** xref:learn:security/authorization-overview.adoc[Authorization]
   *** xref:learn:security/roles.adoc[Roles]
-  *** xref:learn:security/upgrading-to-rbac.adoc[Upgrading to RBAC]
  ** xref:learn:security/on-the-wire-security.adoc[On-the-Wire Security]
  ** xref:learn:security/auditing.adoc[Auditing]
  ** xref:learn:security/encryption-overview.adoc[Encryption]
@@ -158,6 +157,7 @@ include::third-party:partial$nav.adoc[]
   *** xref:manage:manage-security/configure-saslauthd.adoc[Configure saslauthd]
   *** xref:manage:manage-security/configure-saml.adoc[Configure SAML]
   *** xref:manage:manage-security/configure-pam.adoc[Configure PAM]
+  *** xref:manage:manage-security/manage-passwords.adoc[Manage Passwords]
   *** xref:manage:manage-security/manage-certificates.adoc[Manage Certificates]
    **** xref:manage:manage-security/configure-server-certificates.adoc[Configure Server Certificates]
    **** xref:manage:manage-security/configure-client-certificates.adoc[Configure Client Certificates]

modules/introduction/partials/new-features-80.adoc

@@ -314,6 +314,40 @@ This mode enhances flexibility for clients while enforcing strict security for n
 +
 For more information, see xref:manage:manage-security/enable-client-certificate-handling.adoc[Enable Client Certificate Handling].
 
+https://jira.issues.couchbase.com/browse/MB-11575[MB-11575]::
+XDCR now supports the identification of Incoming Replications on a cluster.
+The Incoming Replications can be:
+
+* Viewed on the XDCR tab of the UI. See xref:manage:manage-xdcr/incoming-xdcr-replications.adoc#view-incoming-replications[View Incoming Replications] in xref:manage:manage-xdcr/incoming-xdcr-replications.adoc[Incoming Replications].
+* Retrieved by using the REST API command `GET /xdcr/sourceClusters`. See xref:rest-api:rest-xdcr-list-incoming-replications.adoc[Listing Incoming Replications].
+
+https://jira.issues.couchbase.com/browse/MB-30260[MB-30260]::
+You can lock user accounts to prevent them from authenticating with Couchbase Server.
++
+--
+* Locking an account terminates all active UI sessions and long-running connections such as Memcached or streaming connections.
+* This feature is useful for preventing users from connecting to the database during maintenance.
+* This feature is applicable to local domain user accounts only.
+* This is an Enterprise Edition feature, and only available after the entire cluster is upgraded to the Couchbase Server 8.0 or a later version.
+--
++
+For more information, xref:learn:security/authentication-overview.adoc#blocking-user-authentication[Blocking User Authentication].
+
+https://jira.issues.couchbase.com/browse/MB-31823[MB-31823]::
+As an administrator, you can force a local domain user account to change their password when they next authenticate with Couchbase Server.
+This feature is useful for assigning a temporary password to new user accounts by selecting the option to force the user to change their password when creating a new user.
++
+For more information, see xref:learn:security/usernames-and-passwords.adoc#force-password-change[Force Password Change].
+
+https://jira.issues.couchbase.com/browse/MB-63755[MB-63755]::
+You can track the user activity, such as the last time a user made a request to the Cluster Manager, through user auditing.
+It's useful in locating users whose accounts are no longer active.
+You select which roles or groups a user must belong to for their last activity time to be saved.
+This feature is only available for users in the local domain.
+The activity of externally authenticated users cannot be tracked using this feature.
++
+For more information, see xref:learn:security/auditing.adoc#audit-user-activity[Audit User Activity].
+
 [#section-new-feature-800-query-service]
 === Query Service
 

modules/learn/pages/security/auditing.adoc

@@ -14,19 +14,45 @@ The output is written to a log-file, which is periodically rotated.
 [#adit_event_types]
 == Audit Event-Types
 
-Events generated by Couchbase Server are of two kinds:
+The following types of events are generated by Couchbase Server:
 
-* _Admin_ events, which track administrative and configuration changes to the cluster.
+* Admin events and Data events:
 
-* _Data_ events, which track attempts to access and change data.
+** Admin events, which track administrative and configuration changes to the cluster.
 
-Note that event-auditing occurs on a _per node_ basis: each node captures its own events only.
-If a cluster-wide record is needed, the individual per node records must be manually consolidated by the administrator.
+** Data events, which track attempts to access and change data.
++
+[NOTE]  
+.Event auditing occurs on a per node basis  
+====  
+Each node captures its own events only.  
+If a cluster-wide record is needed, the individual per node records must be manually consolidated by the administrator.  
+====
+
+* User Activity, which records the date and time of the user’s last request to the server.
 
 This page explains frequently used audit fields, and gives examples of record-structures.
-For information on managing auditing, see xref:manage:manage-security/manage-auditing.adoc[Manage Auditing].
+For information about managing auditing, see xref:manage:manage-security/manage-auditing.adoc[Manage Auditing].
 See the reference page xref:audit-event-reference:audit-event-reference.adoc[Audit Event Reference], for a complete list of events that can be audited.
 
+[#audit-user-activity]
+== Audit User Activity
+
+IMPORTANT: This is a Couchbase Server Enterprise Edition feature.
+
+Auditing user activity allows administrators to track the last time a local user made a request to the Cluster Manager.
+This feature helps identify dormant accounts, improve security, and support compliance with organizational policies.
+The system does not record every action but instead stores the timestamp of the most recent request.
+This approach minimizes performance overhead while still providing useful insight into account usage.
+
+User activity auditing applies only to the local domain users.
+Externally authenticated users, such as those managed by LDAP or SAML, are not tracked.
+Administrators can configure which roles and groups are included in activity tracking.
+
+The last recorded connection time is visible on the UI in the xref:manage:manage-security:manage-security-settings.adoc[Security] section and can also be retrieved through the REST API.
+This makes it easier for administrators to monitor active and inactive accounts.
+To enable and configure user activity auditing, see xref:manage:manage-security/manage-auditing.adoc#auditing-user-activity[Auditing User Activity] in xref:manage:manage-security/manage-auditing.adoc[Manage Auditing].
+
 == Audit Fields
 
 The table below lists frequently used audit fields, with corresponding descriptions.

modules/learn/pages/security/authentication-overview.adoc

@@ -22,7 +22,7 @@ For more information about single sign-on, see xref:learn:security/authenticatio
 The recommended method for application-authentication when connecting to Couchbase Server is to use x.509 _certificate-based_ authentication.
 This ensures that only approved users, machines, or endpoints are authenticated, and provides what is known as _mutual authentication_.
 
-_Mutual-TLS_ (mTLS) certificate-based authentication relies on a _Certificate Authority_ (CA) to validate identities and issue certificates.
+Mutual-TLS (mTLS) certificate-based authentication relies on a _Certificate Authority_ (CA) to validate identities and issue certificates.
 When using this method, no sensitive credentials are shared over the network; and all communication between application and server is performed over an _encrypted channel_, to prevent eavesdropping and impersonation.
 
 For a complete overview of Couchbase Server’s certificate-handling mechanisms, see xref:learn:security/certificates.adoc[Certificates].
@@ -138,7 +138,40 @@ The _local_ domain contains users defined locally, on Couchbase Server.
 The _external_ domain contains users defined externally on an LDAP server, a SAML IdP provider, or Linux systems that are accessed by means of _PAM_.
 For a complete overview, see xref:learn:security/authentication-domains.adoc[Authentication Domains].
 
+In addition to a username and password requirement, 
+SAML can require _Two-Factor Authentication_ (TFA) such as a one-time code sent via text message or a code generated by an authentication module or app.
+SAML can also provide _Single Sign On_ (SSO), where a user that has already authenticated with another application is automatically authenticated to use.
 
+[#blocking-user-authentication]
+== Blocking User Authentication
 
+IMPORTANT: This is a Couchbase Server Enterprise Edition feature.
 
-In addition to a username and password requirement, SAML can require _Two-Factor Authentication_ (TFA) such as a one-time code sent via text message or a code generated by an authentication module or app. SAML can also provide _Single Sign On_ (SSO), where a user that has already authenticated with another application is automatically authenticated to use
+Administrators can lock user accounts by blocking their authentication.
+This is enforced through account locking.
+After an account is marked as locked, it prevents the user from logging in or from continuing the existing sessions.
+Locking an account terminates all active UI sessions and long-running connections such as Memcached or streaming connections.
+
+[IMPORTANT]
+====
+* This feature is only available after the entire cluster is upgraded to version 8.0 or later.
+
+* Only local domain user accounts can be locked or unlocked.
+External domain user accounts cannot be locked or unlocked.
+====
+
+This feature is useful for preventing users from connecting to the database during maintenance.
+
+Administrators can block authentication manually through the UI, REST API, or CLI,
+or automatically through inactivity-based locking after a defined idle period (using TTL).
+TTL based locking also allows accounts to be blocked temporarily, with automatic unlocking after the configured duration.
+By default, automatic blocking rules can exclude System Administrators and other critical roles, to maintain uninterrupted operations.
+
+From the authentication flow perspective, any login attempt against a blocked account is denied,
+and the login screen displays a clear error message indicating that the account has been locked.
+The server communicates this state consistently across interfaces; UI responses, CLI status, REST API outputs, and SDK error codes all reflect the locked status.
+
+For auditing and compliance, every lock event is logged with details of who performed the action and under what conditions.
+This ensures that blocking user authentication is both transparent and reversible while maintaining strong security boundaries.
+
+For more information about locking or unlocking user accounts from the UI, see xref:manage:manage-security/manage-users-and-roles.adoc#lock-and-unlock-user-accounts[Lock and Unlock User Accounts].

modules/learn/pages/security/upgrading-to-rbac.adoc

@@ -87,3 +87,35 @@ Therefore, once a user has authenticated, their role-assignment is examined, and
 See xref:learn:security/authorization-overview.adoc[Authorization], for details.
 
 Note that usernames and role-names are _case sensitive_.
+
+== Changing Passwords
+
+Administrators can configure and enforce security policies to make sure that users maintain secure and up-to-date passwords.
+Couchbase Server supports temporary passwords.
+These controls help prevent unauthorized access and reduce the risk of weak or repeated passwords.
+
+All local users can change their passwords through the UI, REST API, or CLI.
+
+When local users authenticate with the UI, the system prompts them to change their password at their next login.
+The CLI provides the `couchbase-cli user-change-password` command, and the REST API supports password updates through the `/controller/changePassword` endpoint.
+For more information, see xref:manage:manage-security/manage-passwords.adoc[Manage Passwords].
+
+Even users whose accounts do not have privileges to use the Couchbase Web Console can sign in using the UI login page to change their password.
+
+The users managed by external systems, such as LDAP or SAML, must use the tools provided by their external authentication provider to update their passwords.
+
+[#force-password-change]
+=== Force Password Change
+
+Administrators can enforce a password change on the user’s next login.
+This option is useful when issuing a temporary password or resetting a compromised account.
+
+Enforcing password change results in the following:
+
+* The user is prompted to set a new password before accessing the Couchbase Server.
+The user can set a new password using the UI, REST API, or CLI.
+* When authenticating from the UI, users are prompted to set a new password and cannot access any features until they have updated their password.
+
+This feature ensures that only the user knows their active password and that temporary or shared credentials cannot be reused indefinitely.
+
+For more information, see xref:manage:manage-security/manage-passwords.adoc#force-password-update[Force Password Update].