This blog post is an update to Philip Greer’s excellent blog for the 6.4.x “Configuring Microsoft’s Azure Security Assertion Markup Language (SAML) Single Sign On (SSO) with Splunk Cloud” using the “Azure Classic Portal”.
In this post, I'll step you through the configuration using Splunk Cloud version 6.6.x and using the most recent Azure Portal. Some of this blog will repeat the prior version's content, however there are updates to the Azure Portal configuration and the Splunk Cloud configuration as part of this blog.
So, let’s get right down to it. Below is a quick how-to on setting up Azure to provide SAML SSO with your Splunk Cloud 6.6.x instance.
Who do you need?
- An administrator for your Azure instance
- An administrator for your local Identity Management system (Active Directory most likely; if you’re investing into an Azure instance, you most likely leverage Microsoft software infrastructure on-premise)
- An administrator for your Splunk Cloud instance
If they’re all the same person (you), you’re in luck. Otherwise you’ll have to run the calendar dice and find time for you all to discuss SAML integration, put in change control, schedule a time to implement, etc.
Here’s what you do...
Read all of the below Integration steps. There are some pieces that you may need to perform in your Identity Management environment before you integrate with Azure. There are also possible effects to your current locally-defined users in Splunk Cloud, and there may be other topics that could require further discussions among your team members or with Splunk.
This step is requested so that our Splunk Cloud Support and Operations staff will know that you are integrating your instance with Azure. It provides a mechanism to more effectively support you in your efforts to integrate in case anything may go amiss, or if you have further questions around Azure configuration that are not addressed in this blog post.
- Log into your Splunk Customer Portal and create a Splunk Customer support case
- A Priority of P3 or P4 is adequate
- For the ‘Splunk installation is’ choose ‘All configuration issues and any other case…’
- In the ‘Subject‘ enter in something along the lines of ‘SAML Integration with Azure’
- For the ‘I need help with…’ choose ‘Authentication & Security‘
- For the ‘Feature / Component / App‘ choose ‘SAML’
- For ‘Deployment Type’ choose ‘Splunk Cloud’
- Add a summary in the ‘Description‘ that you are going to integrate your Splunk Cloud instance with Azure, and possibly a date/time you will be performing the integration (if needed)
Initially, configuration of Azure was a bit more "manual." With the awesome work of other Splunkers (Rahul Dimri et. al.), there is a pre-canned app in the Microsoft Azure Gallery/Marketplace which reduces the number of steps required for an SSO integration.
1. Login to https://portal.azure.com
2. Navigate to your directory by selecting the Azure Active Directory on the left-hand panel. If you want a separate directory then create one by clicking New, or else select the directory in which you want users to access Splunk by clicking Switch directory.
3. Click on “Enterprise Applications”
4. Next click “New Application"
5. Browse categories “All” and search for “splunk” in the "Add from the gallery" search field.
6. Click on the “Splunk Enterprise and Splunk Cloud” application. You can rename the application at this time before you add.
Next select the “Add” button bottom right corner to deploy the app.
7. After the “Splunk Enterprise and Splunk Cloud” installation completes, you are brought back the "Splunk Enterprise and Splunk Cloud – Quick start" panel.
We have several required steps; the recommended and optional steps can be performed at a later time.
a. Click "Assign a user for testing (required)" in the right panel. The “Users and Groups” panel displays.
b. Add a test user for testing.
c. Return Back to the "Splunk Enterprise and Splunk Cloud – Quick Start"
Click on "Configure single sign-on (required)"
d. Select “SAML-based Sign-on”
8. Enter the “SIGN ON URL"—this is the landing page on which users are taken to in case of IdP initiated flow. This would be the base URL for your Splunk Cloud instance: "https://<acme>.splunkcloud.com" where <acme> is the canonical DNS name of the instance and/or search head (in case of multiple search heads or clustered search heads, such as a general ad-hoc search head at "https://acme.splunkcloud.com" and a separate search head for Enterprise Security at "https://es-acme.splunkcloud.com").
Enter the “IDENTIFIER,“ this is essentially the "entity ID" for the SAML configuration. In Azure, you must use a URI – so use the URL of your Splunk> Cloud instance: "https://acme.splunkcloud.com"
Enter the “REPLY URL.” This is the SAML target and is the URL: "https://<acme>.splunkcloud.com/saml/acs" where again "<acme>" is the DNS name of the instance.
9. Now let’s add “SAML Token Attributes” by checking the box “View and edit all other user attributes.” Then select “Add attribute”—we will add 2 attribute values.
10. For the 1st entry, click on “Add attribute” and enter “realName” for the *Name field then select the “user.displayname” for the *Value field. Click Ok.
11. The 2nd entry, click on “Add attribute” again and enter “mail” for the *Name field then select the “user.mail” for the *Value field. Click Ok.
12. Scroll down on the Single Sign-on configuration page, click on “Download Metadata XML” and save it to a file on your local system. This file will be needed when configuring the Splunk Cloud instance for SAML in later steps.
13. Scroll down and click the checkbox to “Show Advanced certification signing settings.”
Click the Signing Option dropdown and select: Sign SAML response and assertion
Click the Signing Algorithm dropdown and select: SHA-256
14. In the same section, click the checkbox to “Make new certificate active.” When passing the response back, this will be the cert passed as part of the response.
15. Click on Save to record your added attributes. Since “Make new certificate active” is checked, a popup will display asking about making the rollover certificate active. Select OK. This will make sure the current Azure certificate will be passed as part of the SAML response for validation.
Recommendation: Splunk roles are mapped to the groups a user is part of in Azure Active directory. Typically, users are already assigned to a set of Azure/AD groups based on their role within the organization. However, we recommend setting up a new set of groups that are specific to and solely for the users that will need access to the Splunk Cloud instance search head(s).
For example, you can create a group “splunk_admins” and “splunk_users” (as examples) in your Azure/AD. You can then assign your users that need "admin" role in Splunk or just ‘"user" role in Splunk to those two groups. Setting up the group to Splunk roles mapping is covered a little later in these instructions.
16. When Azure passes information on the groups that a user is assigned to within the SAML Assertion, they are passed along by the group’s unique “Object ID” and not by the Azure/AD group’s name. So for the ability to map Azure/AD groups to Splunk roles, we will need to collect information about the Groups that you are using. The “Object ID” for each group you are using can be found by going to your Azure Directory Page and then navigating to the group whose Object ID is to be retrieved.
For example, the image shows a group that is named “splunk_admin”. When passed along to Splunk in the SAML Assertion (XML) it is passed along by the “OBJECT ID” of “7c34<blahblahblah>76“.
So for the group to Splunk role mapping, we will need to record that “Object ID” for later use.
I suggest a simple document or spreadsheet that contains the “DISPLAY NAME," then use the "copy to clipboard" button to the right of the “OBJECT ID” to copy/paste into the document/spreadsheet. Then add the Splunk role or roles (you can map to more than one Splunk role if desired) that you will be mapping to.
NOTE: At this time, the use of Object ID is the only way to map groups to Splunk roles for Azure. There is an enhancement request to find another way that is more user friendly to map roles. Hopefully, future versions of Splunk and/or Azure will provide a mechanism that is more intuitive for this mapping mechanism.
1. Log into your Splunk Cloud instance as a user with the admin role
2. Go to the Settings > Access Controls menu option.
Click on the "Authentication method" link. Click on the "SAML" radio button
Click on the "Configure Splunk to use SAML" link below the SAML radio button.
3. The SAML Configuration popup window will appear.
4. Click on the "Select File" button next to the "Metadata XML File" entry row. Select the metadata XML file that you saved from Azure earlier. Once selected click the "Apply" button.
Several of the fields will populate from the XML data, such as:
- Single Sign On (SSO) URL
- Single Log Out (SLO) URL
- Entity ID: Type in the same URL that you used earlier as the "IDENTIFIER" on step 8 of the Azure App configuration earlier. It should be something like ‘https://<acme>.splunkcloud.com'
- Sign AuthnRequest: Check or Uncheck
- Sign SAML response: Check (required)
Note: The "Sign AuthnRequest" can be checked or unchecked as Azure will work either way. The "Sign SAML response" checkbox should be checked. This will be a requirement moving forward in Splunk Cloud for security best practices, so please make sure this is checked.
5. Scroll down within the configuration dialogue and Click on the “Alias” section.
For Azure, the SAML Assertion sends over data within a few schema named attributes. Enter the following values in each attribute:
NOTE: There have been multiple instances where the ‘*/emailaddress’ attribute is not being passed by Azure.
If the accounts are sourced from Microsoft Azure Active Directory (most often the case where Azure is connected to internal), then most likely the e-mail address will be coming across through the “Attribute Alias Mail” of http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.
If the accounts are Microsoft accounts, then they will have the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress attribute.
6. Scroll down to the Advanced Settings section
“Name Id Format” – With Azure, the account name (nameID) for the user may come across as that user’s unique Object ID. Some of you will be OK with this, most will not. Having a long obtuse string of numbers and characters as the Splunk> account name is not all that optimal when researching things within the internal indexes – looking for stuff to answer questions like ‘what users are doing what in my Splunk> instance?’.
In 6.6.x of Splunk, there is a way we can set the account name to use the value within the e-mail address that comes across via the SAML Assertion.
Once this setting has been put into place for you, your users when they come across via Azure SAML will obtain Splunk> account names that are populated with the value of the email address.
To set to use the e-mail address click the “Name Id Format” dropdown: Select “Email Address” from the dropdown.
Fully qualified domain name or IP of the load balancer: Enter in the FQDN of your Splunk instance—aka https://<acme>.splunkcloud.com
Redirect port – load balancer port: Enter in a ‘0‘ (zero)
Save: Click Save to save the configuration.
7. The next step is to set up the AD/Azure Group to Splunk Role mappings.
Remember that list of group Object IDs we had you record earlier when setting up Azure? Get that out for reference.
Click on the green "New Group" button in the upper right hand corner of the SAML Groups configuration screen in Splunk.
In the "Create new SAML Group" configuration dialogue, paste in the first Object ID into the "Group Name" field. Then choose one or more "Splunk Roles" that you wish to map to users that are assigned to that group from the "Available Item(s)" box; the items you choose will populate over into the "Selected Item(s)" box. Click the green "Save" button once finished.
Perform this step for all AD/Azure groups (Object IDs) that you are going to be mapping.
Note: We have not come across an Azure Object ID for a group that has had capital letters within it. That being said, Splunk will convert all letters to lowercase in the "Group Name" field once the mapping is saved. Behind the scenes, when the SAML Assertion comes over from an IDP into Splunk, all groups within the "Role" attribute will be set to lower case before looking up mapping settings.
The Azure Object ID is long enough and random enough that there should never be a conflict between group names (Object IDs) caused by the lower case action. So this note is more just to notify you of the behavior in case you see a difference in case between what you’ve entered and what was saved and listed in the SAML Groups screen.
8. Now that you have mappings and the SAML configuration, your Splunk Instance is set to re-direct authentication to your Azure IDP.
Test your setup by entering a new browser session or open up an incognito session of your browser. Go to your https://acme.splunkcloud.com URL and it should re-direct you to authenticate via your Azure instance.
NOTE: If stuff isn't working, there is a URL that will get your directly to your login auth page for your locally defined Splunk accounts. For your Splunk Cloud instance, use the URL of the form:
You will be presented with the ole tried and true local authentication page to login to a locally defined Splunk account.
Also, it's highly recommended to have a SAML tracer plugin for your browser (Chrome, Firefox, etc. all have a SAML tracer). This will allow you to easily capture the data that is being passed between your IDP and Splunk to determine what values are being passed within the Assertion attributes, etc., making it much easier to troubleshoot anything that might not be working or is not optimal for your preference.
9. You should authenticate into Splunk. Click on your test user’s account name in the top menu, choose the menu option for "Account Settings" and check the values that are populated in the "Full Name" and "Email address" fields.