Password Depot Enterprise Server (version 19) controls access on three levels: globally via the server policies, per database via the General tab, and at a fine-grained level via the Entries and folders tab. If a user cannot see a database or its entries, one of the two pitfalls described below is almost always the cause – not a defect.
The permission model in brief
Server policies (Manage → Server Policies) apply to the entire server. Each permission has three states: Enabled, Undefined, Disabled. A permission disabled here applies to all users, groups, and databases and cannot be re-enabled at the lower levels. Therefore, leave the server policies in their default state and only disable permissions here if it is mandatory company-wide (e.g. Print entries).
Database level: In the Databases area, right-click the database and select Permissions. Use New to add users or groups; double-click (or click Properties) to open the rights management dialog with the tabs General, Entries and folders, and Sealed access. Permissions in General apply to the entire database: anyone granted Read entries here, for example, sees all entries by default – including entries added later.
Entries and folders: Here you assign permissions specifically for individual folders and entries; permissions set on a folder also apply to its content and subfolders. Green = allowed, red = denied; use View effective rights to check the result.
Best practice: only access at database level, specific rights in the object tree
At database level, allow only Access to database.
Remove the Allow ticks for Read/Modify/Add/Delete entries – do not set a "deny" there.
In the Entries and folders tab, share exactly those folders the user or group is supposed to see (e.g. one private folder plus one shared folder within the same database).
Folders and entries created later in the root directory are then initially visible to no one and are shared individually as needed.
The four permissions Read/Modify/Add/Delete entries depend on each other and should, per object, be allowed together or left unset together where possible.
Pitfall 1: "Deny" always takes precedence
A set deny overrides every "allow" and cannot be overridden itself. Anyone who grants full access at database level and then tries to hide individual areas via deny quickly locks users out completely (database visible, but empty). Therefore, do not use deny for routine rights management – removing the tick is the correct way – but only for targeted exceptions, such as a single entry in an otherwise shared folder.
Pitfall 2 (version 19): assign permissions with the super administrator
In version 19, assign permissions in the Server Manager using the predefined super administrator account admin. If permissions are set with a different administrator account, they may not take effect; affected users then receive, for example, a "database expired" message.
Note: Where possible, work with groups instead of individual users – the logic is identical, but maintenance is considerably easier.
Related topics: