6.2 Other Authentication Options & Enabling Multifactor Authentication

Other Authentication Options & Multifactor Authentication

The Authentication Schemes Splunk Supports

authType in the [authentication] stanza of authentication.conf accepts Splunk (native, the default), LDAP, Scripted, SAML, and ProxySSO:

Native accounts always remain available alongside an external scheme. Splunk tries native authentication first. It moves on to LDAP only when the username does not exist locally, and on Splunk Enterprise it tries scripted authentication after that.

SAML 2.0 Integration & Federated Identity

Security Assertion Markup Language (SAML 2.0) enables federated Single Sign-On (SSO), allowing users to authenticate via enterprise identity providers such as Okta, Microsoft Entra ID (formerly Azure AD), or PingFederate.

SAML Architecture Roles

• Service Provider (SP): The Splunk Enterprise Search Head hosting Splunk Web.
• Identity Provider (IdP): The external corporate authentication server holding user credentials and executing authentication policies.

Metadata Exchange Architecture

1. Service Provider (SP) Metadata: Splunk generates an XML metadata document defining its unique entityId, the Assertion Consumer Service (ACS) URL (https://<searchhead>:8000/saml/acs), and and its single logout settings.
2. IdP Metadata: The administrator imports the IdP's metadata XML file into Splunk, providing the IdP Entity ID, IdP SSO Redirect URL, and the IdP's public X.509 signing certificate.

SAML Stanza Configuration in authentication.conf

[authentication]
authType = SAML

[saml]
# Entity Identifiers
entityId = splunk-prod-sh
idpSSOUrl = https://login.microsoftonline.com/tenant-id/saml2
idpSLOUrl = https://login.microsoftonline.com/tenant-id/slo

# Cryptographic Certificates
idpCertPath = $SPLUNK_HOME/etc/auth/idpCerts/idp_signing.pem
signAuthnRequest = true

signedAssertion = true

[authenticationResponseAttrMap_SAML]
# Only needed when the IdP uses different attribute names than role/realName/mail
role     = http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
realName = displayname
mail     = emailaddress

[roleMap_SAML]
admin = Azure_Splunk_Admins
power = Azure_Splunk_PowerUsers
user  = Azure_All_Employees

SAML Attribute Mapping

When a user authenticates at the IdP, the IdP sends an HTTP POST containing a cryptographically signed SAML assertion to the Splunk ACS URL. Splunk validates the assertion signature against idpCertPath and expects three attributes, named by default:

• role: group values matched against [roleMap_SAML] to assign Splunk roles.
• realName: the user's display name.
• mail: the user's email address.

If your IdP sends different attribute names, map them in [authenticationResponseAttrMap_SAML]. When a SAML username collides with a native account, authTypePreferredForUserCollision (default Splunk) decides whose roles apply.

Session Timeout Coordination

Administrators must coordinate two distinct session timeouts:

• Splunk Web Session Timeout: Configured in web.conf under [settings] via tools.sessions.timeout = 60 (default 60 minutes).
• IdP Session: Configured in the IdP. If the Splunk Web session expires while the IdP session is still valid, the SAML redirect usually signs the user back in without a password prompt.

Multifactor Authentication (MFA)

Splunk Enterprise supports two MFA vendors: Duo Security and RSA SecurID (RSA Authentication Manager). You can use only one of them at a time. Duo works with native, LDAP, and scripted authentication. It is not compatible with SAML or other SSO methods. When users sign in through SAML, MFA is enforced by the identity provider.

Steps to Enable Duo MFA (blueprint 6.3)

1. In the Duo Admin Panel, protect Splunk as an application. Duo provides an integration key, a secret key, and an API hostname.
2. Enroll users and their devices in Duo; users need the Duo Mobile app or another supported Duo factor.
3. In Splunk Web on each instance that users log in to: Settings > Authentication Methods, then choose Duo Security under multifactor authentication and enter the values from Duo. You can instead configure authentication.conf as shown below.
4. Choose the failure behavior with failOpen (default false, so users are blocked if Duo cannot be reached) and a connection timeout.
5. Optionally enforce MFA on REST with enableMfaAuthRest = true. REST clients then need a session key obtained through a Duo-verified login.
6. Test with a non-admin account before rolling the change out.

Duo Settings in authentication.conf

[authentication]
authType = LDAP
authSettings = corp_active_directory
externalTwoFactorAuthVendor = Duo
externalTwoFactorAuthSettings = duo-mfa

[duo-mfa]
apiHostname      = api-xxxxxxxx.duosecurity.com
integrationKey   = <20-character integration key>
secretKey        = <40-character secret key>
appSecretKey     = <40+ character locally generated key; required only when universalPrompt = false>
universalPrompt  = true
failOpen         = false
timeout          = 10
enableMfaAuthRest = false

• externalTwoFactorAuthVendor turns MFA on for the chosen vendor, and externalTwoFactorAuthSettings names the stanza that holds that vendor's settings.
• Splunk obfuscates integrationKey, secretKey, and appSecretKey before saving them.
• Universal Prompt is the default (universalPrompt = true). Duo has deprecated the Traditional Prompt, so Splunk tells older versions to upgrade and migrate.
• The instance needs outbound HTTPS access to the Duo API hostname.

RSA SecurID

For RSA, set externalTwoFactorAuthVendor = RSA and configure the RSA stanza with values from RSA Authentication Manager, such as authManagerUrl (the REST endpoint) and accessKey. You can also set it up in Splunk Web under Settings > Authentication Methods.

Operational Troubleshooting & Diagnostic Reference