IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Cheat sheet & pop quiz
Here is the whole track on one page. You get the key ideas, an audit checklist and five scenarios to test what stuck.
Eight ideas that secure a workforce
| # | If you remember nothing else… |
|---|---|
| 1 | A directory is a tree of entries named by DNs. LDAP is the protocol, not a product. A search has a base, a scope and a filter. Escape every typed value (RFC 4515), or a * matches everyone. Bind over TLS. Never treat an empty-password bind as a login. |
| 2 | In Active Directory, the forest, not the domain, is the security boundary. Security groups grant access. Distribution groups only send mail. Sync works when each fact has one source of authority. |
| 3 | Kerberos: prove the password once to get a TGT. Then trade it for one service ticket per service. The krbtgt key protects every TGT. If it leaks, reset it twice. With NTLM, a stolen hash can sign in by itself. Measure NTLM, then restrict it. |
| 4 | Stop domain attacks by removing what they reuse. Use managed, long, random service-account passwords and AES against Kerberoasting. Keep pre-authentication on against AS-REP roasting. Never reuse credentials across machines, to stop pass-the-hash. |
| 5 | Governance answers who has access, who approved it, and whether it is still right. Birthright covers the routine. The rest is requested and approved by the manager and the resource owner. Block toxic combinations when requested, and scan for them later. Do both. |
| 6 | Tier 0 is whatever controls identity, plus anything that controls that. Examples are the backup agent, the jump server and the PAM vault. Manage down, never sign in down. Start admin sessions from a PAW. Aim for zero standing privilege. |
| 7 | NIST SP 800-63B-4: ask for 15 characters when the password is the only factor. Allow at least 64. Use no composition rules and no scheduled expiry. Add a blocklist. Welcome password managers. Use throttling, not a quick lockout. Sprays hide under per-account limits, so look across accounts. |
| 8 | Give the device a vote. It needs its own key (ideally in a TPM) and a compliance state. Conditional access joins user, device, place, app and risk. ZTNA opens one app per session, not a whole network. Sign-in rules cannot see a stolen session. |
Before you sign off an enterprise estate, ask…
| The question | Where it is answered |
|---|---|
| Does every app that searches the directory escape user input, and bind over TLS with a least-privilege account? | Directories |
| Which service accounts still have human-chosen passwords or RC4? Where is NTLM still used? | Kerberos & NTLM |
| Who approves each sensitive entitlement? Which pairs must no one hold together? | Identity governance · Access reviews |
| What is in Tier 0, including agents, jump servers and vaults? Does any Tier 0 account sign in lower down? | Privileged access · Break-glass |
| Does the password policy match current NIST guidance? What happens after the hundredth wrong guess? | Password policy |
| Which apps need a compliant device? Who is excluded? Which old protocols are still allowed? | Device trust & conditional access |
Pop quiz — five questions
Q1 · A partner app finds a user with the filter (uid=whatever was typed). Then it binds as the entry it found, using the typed password. Someone types * as the username and leaves the password empty, and gets in. What went wrong, and what are the fixes?
Two mistakes. The unescaped * turned an exact lookup into a "match everyone" search. That is LDAP injection. So the app picked some real account. Then a bind with a DN and an empty password is an unauthenticated bind. It proves nothing, but the app treated it as success. Fixes: escape every typed value per RFC 4515 (* becomes \2a). Check usernames against an allow-list. Refuse empty passwords before binding. Bind over TLS. Have the app search with a least-privilege account (directories).
Q2 · Bot A's service account has a password a person chose years ago. RC4 is still allowed for it, and it is a member of Domain Admins. Any employee can request a ticket for its service. Which attack is this bait for, and which three changes close it?
Kerberoasting. Any user can ask for a service ticket. Part of it is locked with a key made from the service account's password. The attacker guesses that password offline, with no lockout. RC4 makes it fastest. Close it like this. Move the account to a managed service account, which has a long random password that Windows rotates. At minimum, use a random password of 25 or more characters. Make sure tickets use AES, not RC4. Take the account out of Domain Admins, so a cracked password buys little. Also watch for bursts of service-ticket requests (Kerberos & NTLM).
Q3 · Role mining for the Finance Ops team shows four people with the same three entitlements. One of them also holds the "approve payment" right. Priya, new to the team, still holds the "create vendor" right from an old project. She now asks for "approve payment" too. What should the role contain, and what should happen to her request?
The role gets only what everyone shares. That one person's right is an outlier. If it were mined in, the whole team would get a toxic pair with the "create vendor" right. Priya's request is also a toxic combination. One person could invent a supplier and pay it. A preventive separation-of-duties rule blocks it, or forces a logged exception with extra sign-off. The clean fix is to remove the old "create vendor" right, then grant the request with manager and resource-owner approval. Let the scheduled detective scan catch any pairs that slip in later (identity governance).
Q4 · To save time, a domain admin fixes printers by signing in to users' laptops. The backup agent runs on every machine as an account with domain-admin rights. The team says the domain controllers are safe because they sit in their own network segment. Why is that not enough?
The credentials travel to the laptops. A sign-in usually leaves reusable credential material on the machine. Anyone who gets admin rights there can take it and replay it. So every laptop becomes a path to the domain controllers, whatever the network looks like. The keyboard, not the destination, sets the trust level. Tiering fixes it. A Tier 2 help-desk account fixes printers. The backup agent gets separate least-privileged identities for each tier. Domain admins sign in only from a Tier 0 PAW. Elevation is granted just in time (privileged access).
Q5 · After a password spray, a manager proposes two fixes. One is to lock accounts after three failures. The other is to require a compliant device for every app, so that stolen passwords stop mattering. What is wrong with each, and what would you do instead?
A spray tries each account only once or twice, so a three-strike lockout never trips. Yet it lets anyone who knows a username lock people out. Instead, ask for 15 characters. Add a blocklist, so the sprayed passwords cannot be chosen. Use throttling with growing delays, detection across accounts, and MFA (password policy). The device rule helps, but conditional access decides at sign-in. A stolen session cookie replayed elsewhere never signs in, and old protocols may skip the rule. Block legacy protocols, bind sessions to devices and re-check them all the time (device trust & conditional access).
That is Enterprise Identity. You met the directory every login reads. You met the tickets that replace passwords on the wire. You met governance that catches toxic pairs. You saw admin tiers that stop one click from reaching the domain controllers. You saw a password policy people can live with. You saw devices that get a vote in every decision. Next, see how attackers go after the people behind these accounts, and the defense for each trick. Start Identity Attacks & Defenses with its start lesson.
You have learned it. Now build it. Browse our free security micro-tools at the tools shelf. Explore our services. Talk to our team when you are ready to design the real thing.