In the realm of Linux authentication, PAM (Pluggable Authentication Modules) configurations often use complex control flags that can be confusing. Let's dissect the behavior of success=n in a real-world example from /etc/pam.d/common-auth:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

The success=2 control value means that when pam_unix.so succeeds, PAM will skip the next 2 modules in the stack and jump directly to pam_permit.so. However, if pam_unix.so fails, the behavior depends on the default=ignore clause.

Let's examine both scenarios:

1. Successful authentication via pam_unix.so:

   1. pam_unix.so → SUCCESS → skip 2 modules (pam_winbind.so and pam_deny.so)
   2. Continue at pam_permit.so
   

2. Failed authentication via pam_unix.so:

   1. pam_unix.so → FAIL → default=ignore → continue to next module
   2. pam_winbind.so → if success, skip 1 module (pam_deny.so)
   3. pam_permit.so (if winbind succeeded) OR pam_deny.so (if winbind failed)
   

Here's a more complex PAM configuration demonstrating multiple skip scenarios:

# Example from a Kerberos + LDAP + local auth setup
auth    [success=3 default=ignore]      pam_krb5.so minimum_uid=1000
auth    [success=2 default=ignore]      pam_ldap.so use_first_pass
auth    [success=1 default=ignore]      pam_unix.so nullok try_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_sss.so

When troubleshooting PAM configurations:

• Use pam_tally2 or faillock for authentication failure logging
• Test with pamtester utility to verify module order effects
• Remember that requisite failures immediately terminate the stack

For more complex scenarios, you can use value lists in control fields:

auth    [success=ok default=die]        pam_securetty.so
auth    [success=3 bad=ignore default=4] pam_listfile.so item=user sense=allow file=/etc/sshd/allow_users

The bad=ignore parameter tells PAM to treat certain return codes specially, while the numerical values in success and default control module skipping.

In PAM (Pluggable Authentication Modules) configuration, the success=n control value is one of the most powerful yet misunderstood flags. When you see [success=2 default=ignore] in your pam.conf or pam.d/* files, here's exactly what happens:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

The number after success= specifies how many modules to skip forward upon successful authentication. In your Kerberos example:

• If pam_unix.so succeeds: Skips next 2 modules (pam_winbind.so and pam_deny.so), landing at pam_permit.so
• If pam_unix.so fails: The default=ignore makes PAM continue to pam_winbind.so
• If pam_winbind.so succeeds: Skips 1 module (pam_deny.so), going to pam_permit.so

Here's a more complex SSH authentication stack demonstrating control values:

# /etc/pam.d/sshd
auth    [success=3 default=ignore]      pam_google_authenticator.so
auth    [success=2 default=ignore]      pam_ldap.so use_first_pass
auth    [success=1 default=ignore]      pam_unix.so try_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

Watch for these issues when working with PAM control flags:

1. Counting Errors: Remember that PAM counts modules, not lines (comments and blank lines don't count)
2. Negative Jumps: Some PAM implementations allow negative numbers for backward jumps (e.g., success=-1)
3. Stack Verification: Always test with pam_tally2 or pam_exec.so debug options

For complex authentication flows, consider these patterns:

# Two-factor auth with failover
auth    [success=ok default=1]          pam_duo.so
auth    [success=ok default=ignore]     pam_unix.so
auth    required                        pam_deny.so

The [success=ok default=1] syntax provides more granular control than simple numeric jumps.