Separate a person from a phone account
A SIP extension, a person’s User Management account and permission to administer the PBX are different responsibilities. Start with the user’s job: retrieve their voicemail, manage an approved shared mailbox, use a phone application or administer a defined set of modules. Grant only the access needed for that job.
Sangoma documents users, groups and authentication directories in User Management. Some examples retain FreePBX 13 screenshots; verify the installed FreePBX 17 module and enabled authentication method before following screen-level instructions.
Identify the source of the account
Determine whether the user is local to the PBX or comes from an external directory. Record the stable username, the intended linked extension and who owns changes in the source directory. Editing a synchronized attribute only on the PBX may be ineffective when the next synchronization runs.
For a failed login, first distinguish an absent account, an authentication failure and a successfully authenticated user who lacks access to an application. These failures need different evidence and should not all be treated by resetting a SIP password.
Inspect effective permissions
Review group membership and per-user overrides together. Where a feature is set to Inherit, inspect the group that supplies the value. The documentation describes this distinction for Phone Apps. Test the actual application and allowed extension or mailbox scope; a successful portal login alone does not prove the scope is correct.
Create a narrow role for a representative test user before assigning a department. Check both an allowed action and a deliberately disallowed action, such as opening another employee’s mailbox or an unrelated administration module.
Keep administration recoverable
The older Administrators module is deprecated; the official documentation directs its functionality toward User Management and explains that the configured authorization type affects behavior. Inventory the currently working administrative access before changing authentication settings.
Keep a documented, controlled recovery path and verify it during a planned maintenance window. Avoid changing directory connectivity, account membership and the only administrator’s permissions in one step. Record the authentication source and module versions with the change so another administrator can reproduce the decision.
Offboard across all access paths
For a departing user, revoke the person’s portal and application access in the authoritative directory, then address the extension and its credentials separately. Review voicemail access, forwarding destinations, shared roles, phone provisioning and any retained device. Disabling a web login does not establish that a desk phone can no longer place calls.
Retest denied access and preserve business-owned routing to an approved successor or mailbox. Keep the disposition of recordings and messages under the organization’s retention policy. Finally, remove obsolete group membership and update the staff access register.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma: User Management guide ↗
- Sangoma: Phone Apps user permissions ↗
- Sangoma: deprecated Administrators module ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.