Practical tools for system, network, security, and operations administrators.

SEC-C0068 · Identity & Access Security

Identity Security Guide

Separate admin accounts, require a second factor, and write the lockout rule before you need it.

Updated 25 October 2026 · Pillar guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

An account is a person or a service, and a factor is a second proof

Identity security is who may sign in, how you know it is them, and how you remove that ability. People get their own accounts. Admin work gets an admin account that is not the everyday mailbox. Service accounts do not get interactive passwords taped to a wiki.

A second factor is a proof besides the password. Prefer a method your organisation can recover when someone loses a phone. The comparison tool on this site lines methods up. It does not enrol anyone. Number matching or a hardware key is a decision. Push prompts with no number are how fatigue happens. The fatigue response guide is the incident. This page is the setup that makes fatigue less useful.

Conditional access is a rule: this account, this application, this place, this device state. The builder drafts a rule. A rule that blocks every sign-in, including yours, is a rule you test on one lab account first, with a break-glass account you have already proven and stored.

The system desk's Active Directory guide is the directory. This page is the security decisions on top of it: admin separation, factor, and lockout.

One lab user, a second factor, a break-glass you tested

Create a lab user who is obviously a lab user. Require a second factor. Sign in once and record that it worked. Then try a sign-in that should fail, such as a blocked legacy protocol, and record the failure. One success and one expected failure are the proof.

The break-glass account is a named account, not a shared password in a ticket. Its secret is in the store. You sign in with it once from the console path, then you do not use it for daily work. If your conditional access rule locks the lab user out, the break-glass path still works. If it does not, fix the rule before you copy it.

Lockout has a threshold and a reset. Write both. A threshold of one failure will lock people out of a typo. A threshold you never reset is a denial of your own service.

Passwords are chosen by the person and are not stored so you can read them back. prompt-for-this in a note means the store has the real value.

A change you can finish

Production starts with one admin role and one application, after the lab rule and the break-glass test. A tenant-wide block is a later window.

Rollback is the previous access rule, which you saved, and the break-glass path if you locked yourself out anyway.

  1. Separate the admin account from the everyday account.
  2. Enrol a second factor on the lab user and complete one sign-in.
  3. Prove the break-glass path before you tighten the rule.
  4. Draft one conditional access rule and test it on the lab user.
  5. Write the lockout threshold and the reset.
  6. Keep secrets out of the ticket.
  7. Copy the rule wider only after the lab failure was the one you wanted.

Mistakes that outlive the command

identity security fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Decisions to write down before the window

One decision for identity security: Admin work uses an admin account. A second factor is required for that account, with a recovery method you have. Break-glass was tested and its secret is not in the ticket. The first conditional access rule hits a lab user. Lockout numbers are written down. Number matching or an equivalent is the push decision. Service accounts are not interactive. The directory structure stays with the Active Directory guide. Rollback is the previous rule. And a leaked password follows the leaked-credentials response, not a quiet reuse.

The hour you stop

Write the hostname or the system name, the owner, and the clock time before you change anything for identity security. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.

A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.

Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.

Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next system waits until someone else can repeat the proof from the notes. identity security is done for this window when the proof is written, not when the tool printed a file.

This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.

Identity checks before the rule leaves the lab

Confirm this before you call the change done: The lab user signed in with the second factor. An expected failure was recorded. Break-glass works and was not the test user. The break-glass secret is not in the ticket. The rule does not apply to every account yet. Lockout threshold and reset are written. No shared admin password was created. prompt-for-this was not left as a real password. A second person saw the success and the failure. The previous rule is saved. Service accounts were not given mailboxes for convenience. The wider rollout is a later ticket. The hostname in the prompt matches the hostname in the ticket for identity security. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for identity security happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: System: Active Directory Fundamentals.