Account Policies
An account policy decides how GrantFlow handles the password of a managed account. It sets how new passwords are generated, how old a password may get, when GrantFlow rotates it automatically, what happens once it expires, and how long a single checkout may last. You assign one policy to each managed account on the Managed Accounts page. An account without a policy is never rotated, automatically or manually.
You manage policies under Account Management > Account Policies.
Policy cards
Each policy appears as a card. The dot in the corner is green when Auto Rollover is on and gray when it is off. The card shows the password type (Random or Passphrase), the length or word count, the required character classes, Max Age, Auto Rollover, and Max Request.
When Auto Rollover is on, its badge shows the rotation window together with its time zone, for example 21:00–04:00 Europe/Vienna. A policy without a time zone shows UTC. When Auto Rollover is off, the badge reads Disabled. A Max Request of 0 shows as Unlimited.
You can search policies by name or description and filter them by rollover type (Auto Rollover or Manual Only) and by request limit (Limited Time or Unlimited). Select New Policy to create a policy, or select a card or its Edit button to change one.
Policy fields
The editor groups the fields into Password Settings, Account Settings, and Auto Rollover. This section covers every field in the order the editor shows it.
General
Name is a short name that identifies the policy when you assign it to an account. It can be up to 200 characters long. Description is optional, holds up to 2,000 characters, and appears on the card and in the assignment dialog.
Password settings
Password Type selects how GrantFlow generates new passwords. Random Password builds a password from character sets. Passphrase joins random words into a phrase such as Correct-Horse-Battery-Staple-42.
For a random password, you set the following:
- Password Length: 8 to 128 characters. New policies default to 16.
- Complexity: Require Uppercase, Require Lowercase, Require Digit, and Require Symbol.
- Allowed Symbols: the symbols GrantFlow may use, up to 50 characters. The default is
!@#$%^&*()-_=+[]{}. - Options: Avoid ambiguous characters (0, O, l, I) and Allow repeated characters.
For a passphrase, you set the Word Count (3 to 8 words), the Word Separator (hyphen, underscore, period, space, or none), and two options: Capitalize first letter of each word and Append random number. The Example field previews the format.
Password Strength estimates the entropy of the settings you chose. It is a guide only. GrantFlow does not refuse a weak setting.
Max Password Age is the number of days a password stays valid after its last rotation. New policies default to 90 days. This value drives both automatic rotation and the expiry check at checkout, which the next sections describe. A value of 0 turns off the expiry check at checkout. Always use a positive value when Auto Rollover is on, because with 0 every password counts as due for rotation whenever the window is open.
WARNING
The password must also satisfy the password policy of the target directory. If Active Directory or Entra ID rejects a generated password, the rotation fails and GrantFlow retries it later.
Account settings
Max Request caps how long a single checkout of the account may last. You set it in 15-minute steps from 0 to 1,440 minutes. A value of 0 means the policy sets no cap of its own. Checkouts are still limited to 24 hours in that case, because no checkout can be longer than 1,440 minutes. When a user requests a longer checkout than the policy allows, GrantFlow refuses the request and names the permitted maximum. A checkout that names no duration lasts 60 minutes, so under a cap below 60 minutes the user must pick a shorter duration.
Password delivery controls how the password reaches the user who holds the checkout:
- Show to the holder: the holder can reveal the password. There is no automatic sign-in. This is the default, and it also applies to policies created before this setting existed.
- Sign in automatically only: GrantFlow injects the password into browser sessions. The holder never sees it.
- Both: GrantFlow signs the holder in automatically, and the holder can also reveal the password.
After a session controls the toggle Rotate the password at check-in when it was injected. When it is on, GrantFlow rotates the password once the user checks the account in, but only if it injected the password into a session during that checkout. It is on by default. A checkout where the holder only revealed the password does not trigger this rotation.
On Expiry controls the toggle Disable account when password expires. When it is on and Max Password Age is greater than 0, an expired password refuses checkout. A password GrantFlow has never rotated also counts as expired. The section on expired passwords explains what happens next. New policies turn this on by default.
Auto rollover
Auto Rollover controls the toggle Enable automatic password rollover. When it is on, GrantFlow rotates passwords on a schedule inside the window you define. When it is off, GrantFlow removes the policy's schedule. Passwords then change only through manual and event-driven rotations, such as a rotation after a session or a rotation at checkout.
The remaining fields appear only when Auto Rollover is on:
- Time Window: the start and end of the daily window, in 24-hour
HH:MMformat. New policies default to00:00to23:59. - Time Zone: the time zone in which GrantFlow reads the window.
- Allowed Days: the weekdays on which the window opens. You must select at least one day.
Rotation windows
Scheduled rotations run only while a window is open. The window opens at the start time on each allowed day and closes at the end time.
When the end time is at or before the start time, the window runs overnight and closes on the following day. A window from 21:00 to 04:00 with Fri selected opens on Friday at 21:00 and closes on Saturday at 04:00. The allowed days always name the day the window opens, not the day it closes.
GrantFlow reads the window in the policy's time zone, which is an IANA name such as Europe/Vienna or America/New_York. Daylight saving time is handled for you: a 21:00 window in Europe/Vienna opens at 21:00 Vienna time all year. When you leave Time Zone set to UTC, the policy stores no zone and GrantFlow reads the window in UTC. New policies preselect your browser's time zone. Policies created before time zones existed have none, so they keep running in UTC until you pick one.
TIP
Pick the time zone of the team that owns the accounts, so the window badge on the policy card matches the maintenance window those admins expect.
Rotating ahead of expiry
A password must not expire between two windows, because nothing can rotate it on schedule until the next window opens. GrantFlow therefore rotates ahead. While a window is open, an account becomes due as soon as its password would expire before the next window opens. GrantFlow then rotates it in the current window, even though the password has not reached its maximum age yet.
GrantFlow rotates an account ahead at most once per window opening. An account it has already rotated in the current window waits for the next opening, unless its password actually expires in the meantime.
Rotating ahead also covers off-schedule rotations. A rotation after a session or a manual rotation can happen at any time of day, which moves the password's expiry to an arbitrary hour. The next window still catches it.
Scheduled rotation skips an account while it is checked out, while another rotation of it is running, and while its connector is disabled. After a failed rotation, GrantFlow waits before it tries again. The wait starts at 15 minutes and doubles after each further failure, up to once a day.
Maximum age shorter than the gap between windows
When On Expiry and Auto Rollover are both on, GrantFlow checks that the windows can keep up with Max Password Age. It finds the longest gap between two consecutive window openings, counted in whole days by the weekdays you selected. If the maximum password age is shorter than that gap, a password could expire before any window opens, and GrantFlow refuses to save the policy.
For example, with Allowed Days set to Mon and Wed, the longest gap is five days, from Wednesday to Monday. A maximum age of 3 days is refused with this error:
password.maxAgeDays (3) is shorter than the longest gap between rotation windows (5 days): the password would expire before the next window; allow more days or raise maxAgeDaysTo fix it, select more days or raise Max Password Age to at least the gap. A Monday-to-Friday window has a longest gap of three days, from Friday to Monday. Every day of the week has a gap of one day.
The check runs only when you change a field it depends on: Max Password Age, On Expiry, Auto Rollover, the time window, the time zone, or the allowed days. You can still rename an older policy that would fail the check without fixing it first.
Expired passwords
A password expires Max Password Age days after its last rotation. What happens next depends on On Expiry.
When On Expiry is off, an expired password does not block anything. The account can still be checked out, and Auto Rollover rotates the password at its next window.
When On Expiry is on, an expired password refuses checkout, but you do not need to intervene. When a user who is linked to the account checks it out and nobody else holds it, GrantFlow rotates the password first and then completes the checkout with the new password. This rotation ignores the policy's window. If a rotation of the account is already running, the checkout waits for that one instead of starting a second. The checkout takes noticeably longer while this happens. The Account Checkout guide describes what users see.
If the rotation is still running when GrantFlow stops waiting, the checkout is refused with "The account's password is being rotated. Try again in a moment." The user can check out again shortly. If GrantFlow cannot rotate the password at all, the checkout is refused with "account disabled due to expired password, or unassigned password policy". That happens, for example, when the account's connector is disabled or the rotation itself fails because the directory rejects the generated password.
When an expired password refuses a checkout, GrantFlow marks the managed account as Disabled on the Accounts page. The badge records that the refusal happened. It does not block later checkouts, and a later rotation does not clear it.
Checkout limits
Two rules limit checkouts. The policy's Max Request caps the length of each checkout, as described under account settings. Independently of any policy, only one person can hold an account at a time. While a checkout of the account is active, overdue, being checked in, or stuck in a failed check-in, every other checkout is refused with "account already checked out". The refusal does not name the current holder.
Rotation reasons
Every rotation records a reason. The reason appears in the Password Rotation History of each account on the Managed Accounts page.
| Reason | When GrantFlow rotates |
|---|---|
| Scheduled | Auto Rollover rotated the password inside the policy's window. |
| Manual | An administrator selected Rotate Password. |
| Policy Change | An administrator requested a rotation through the API and gave this reason. |
| Compromise | An administrator requested a rotation through the API and gave this reason. |
| Session Use | A user checked the account in after GrantFlow injected the password into a session, and After a session is on. |
| Expired at checkout | A user checked out an account whose password had expired. |
| Credential Rejected | A target refused a password that GrantFlow injected. GrantFlow rotates once per checkout to bring the directory and its stored password back in line. |
| Check-in Resolved | An administrator resolved a failed check-in by confirming that the account was disabled in the directory by hand. |
Manual rotation is refused while the account is checked out, because a new password would break the holder's session. Scheduled rotation skips a checked-out account for the same reason.
Deleting policies
Select the trash icon on a policy card and confirm Delete Policy. You cannot delete a policy that is still assigned to an account. GrantFlow refuses the delete with "policy is assigned to one or more accounts and cannot be deleted". Assign another policy to those accounts first, or clear their policy. Deleting a policy also removes its rotation schedule.
Audit events
GrantFlow records every policy change and every rotation in the audit log. The Audit Events reference lists all event types. These are the most relevant ones:
| Action | Recorded when |
|---|---|
account_policy.create | You create a policy. The event includes its settings, among them the window and time zone. |
account_policy.update | You change a policy. The event includes the previous and new values of each changed field. |
account_policy.delete | You delete a policy. A refused delete is recorded as failed, with the number of assigned accounts. |
account_policy.assign | You assign a policy to an account or clear it. |
password_rotation.scheduled | Auto Rollover creates a rotation. |
password_rotation.trigger | A rotation starts outside the schedule. This covers manual rotations, session use, rejected credentials, and rotations at checkout. |
password_rotation.cancel | You cancel a scheduled rotation. |
account.checkout | A user checks out an account, or a checkout is refused. |
A rotation at checkout is recorded as password_rotation.trigger and attributed to the user who checked out. Its details carry trigger: expired_at_checkout, and joined: true when the checkout waited on a rotation that was already running. A checkout refused because the password was still rotating, or could not be rotated, is recorded as a denied account.checkout with the reason password_rotating or password_expired.