# APM SSO method explainer > The eight SSO methods APM's own chapter defines, each card carrying the verdict that decides outages: a misconfigured SSO object for any non-form method can disable SSO for every method in that user's session; Form Based and Forms - Client Initiated are the only exempt ones. Kerberos ships its full prerequisite list, including the line worth framing: APM Kerberos SSO does not need or use a keytab file. - Tool: https://ronutz.com/en/tools/f5-apm-sso-explainer - Family: Identity & tokens --- # APM SSO method explainer The job of BIG-IP Zero Trust Access (formerly BIG-IP APM - Access Policy Manager) after authentication is to keep authenticating for you, and the Single Sign-On Methods chapter defines exactly eight ways it does that: HTTP Basic, NTLMv1, NTLMv2, Kerberos constrained delegation, Form Based, Forms - Client Initiated, OAuth Bearer, and SAML. This tool renders each as a card with its mechanism, its credentials plumbing, its prerequisites, and its quirks, all condensed faithfully from the chapter and the method-specific guides. The verdict on every card is the chapter's own blast-radius paragraph, and it is the operational headline: a misconfigured SSO object for HTTP Basic, NTLMv1, NTLMv2, Kerberos, OAuth Bearer, or SAML can disable SSO for all authentication methods in that user's session. Form Based and Forms - Client Initiated are the only two methods not disabled when another method's object is broken. One bad Kerberos SSO configuration and every application in the session can lose its SSO; one bad form configuration and only that application does. That asymmetry decides how carefully each object class deserves to be handled. The Kerberos card carries the full prerequisite list: a delegation account in Active Directory per server realm, its SPN entered as the Account Name in SPN format, the realm in uppercase, Resource-Based Constrained Delegation for multi-realm estates, and the manual's own line, worth framing: APM Kerberos SSO does not need or use a keytab file. Its natural front doors are the methods where the password never travels in clear text, client certificates and NTLM among the chapter's own examples. NTLMv2 carries the documented quirk that a 401 with more than one WWW-Authenticate: NTLM header makes SSO fail, expected behavior per the manual. Forms - Client Initiated carries its design's cleverest detail: the JavaScript APM inserts assigns the password parameter a token rather than the actual password, so the credential never sits in the page. The plumbing note on every lookup ties the methods to the machinery: access-policy agents populate the session variables SSO consumes, the classic wiring being a Logon Page followed by SSO Credential Mapping, feeding session.logon.last.* into session.sso.token.last.*. Everything runs locally; nothing you type leaves the page. ## Standards and references - [BIG-IP APM: Authentication and Single Sign-On 14.0 - Single Sign-On Methods (the eight-method list; the isolation paragraph: a misconfigured object for Basic/NTLMv1/NTLMv2/Kerberos/OAuth Bearer/SAML can disable SSO for all methods in the session, the two form methods exempt; HTTP Basic's base64 header; the 225-character name bound)](https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-access-policy-manager-authentication-and-single-sign-on-14-0-0/single-sign-on-methods.html) - the method table's mechanisms and the isolation verdict on every card - [BIG-IP APM 12.1 - Single Sign-On Methods (the NTLMv2 quirk verbatim: more than one WWW-Authenticate: NTLM header in a 401 makes NTLMv2 SSO fail, expected behavior)](https://techdocs.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-12-1-0/23.html) - the NTLMv2 quirk - [BIG-IP APM 15.1 - Kerberos Single Sign-On Method (delegation account per server realm, SPN-format Account Name, uppercase realm, the no-keytab line verbatim, password-less front-door pairing; 17.1 adds the multi-realm RBCD guidance)](https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-access-policy-manager-single-sign-on-concepts-configuration/kerberos-single-sign-on-method.html) - the Kerberos card's prerequisites - [BIG-IP APM Single Sign-On Configuration Guide (the Forms - Client Initiated flow: logon-page detection, inserted JavaScript, and the password parameter assigned a password token rather than the actual user password; NTLM Domain defaulting to session.logon.last.domain)](https://techdocs.f5.com/en-us/bigip-17-1-0/big-ip-access-policy-manager-single-sign-on-concepts-configuration/single-sign-on-methods.html) - the FBCI card and the session-variable wiring notes ## Related reading - [APM SSO Methods: One Bad Object Can Dim the Whole Session](https://ronutz.com/en/learn/bigip-apm-sso-methods.md): APM's chapter defines eight SSO methods and states a blast radius most designs ignore: a misconfigured object for any non-form method can disable SSO for every method in the session; the two form methods are the only exempt ones. Plus the Kerberos prerequisites (no keytab, by the manual's own words), NTLMv2's single-header quirk, and the FBCI password token. - [Session Variables: Where APM Keeps Everything It Learned](https://ronutz.com/en/learn/bigip-apm-session-variables.md): Every access-policy action writes its results into session.* variables, named by an anatomy the manual draws and read by three official syntaxes. The layer has one contract worth memorizing: secure variables are encrypted, hidden from reports and logs, and readable only with -secure, which makes a bare mcget on a password the classic silent empty read.