Contents
SSO Login Problems
While setting up Single-Sign On (SSO) for Cisco Umbrella, there was a need to convert existing Umbrella accounts to use SSO. What should have been a straight-forward process turned out to be cumbersome. From getting an error that SSO was not working, to an account having been locked out for 10 minutes, or being redirected to the OpenDNS portal instead of Umbrella — needless to say, Cisco/OpenDNS caused some confusion. In this post, I will:
- Briefly explain what Umbrella is and why SSO is important for security and the user experience
- Go over some SSO security considerations
- Share how we troubleshot the problem
- Uncover what the cause was
- Present how we fixed the issue
At the end of the article, I will summarize the exact steps needed to get an Umbrella account converted to use SSO.
What Are Umbrella and SSO?
Cisco Umbrella
In 2006, OpenDNS was founded to help, among other goals, speed up DNS queries and make the web safer to browse. It later created Umbrella and was acquired by Cisco a few years after. In essence, Umbrella proxies DNS requests to secure traffic — almost like Websense, a web filtering and content gateway solution — except it does so by looking at the DNS level. Clients go through its public DNS servers, and predefined policies decide what Internet resource can and cannot be visited. This makes for a quick, first layer of defense against malicious websites and other types of threats. The product can also perform SSL decryption to gain some (not complete) visibility into encrypted traffic.
Single-Sign On
Single-Sign On (SSO) allows for an individual to sign into one or more services with one account and password instead of having one for each resource. In addition, administrators can better manage access to resources through a central identity provider (IdP), such as Azure AD, and enforce policies like multi-factor authentication, auditing, and compliance rules.
In this post, I will not dive into how to set up SSO. Umbrella configuration with Azure AD, for instance, was actually quite straight-forward through the exchange of Metadata XML files between the IdP and Service Provider (SP). Instead, this is for readers who already have SSO configured correctly and enabled for their instance of Umbrella, but ran into the issue of converting existing Umbrella accounts to use SSO.
SSO Enabled: Now What?
Native or SSO Login
Umbrella allows you to sign in with either a native, local (to Umbrella), non-SSO account or via SSO. Once you enable Single-Sign On, one should ONLY be able to log in through that method, and the native, local way should cease to function. This ensures that the user cannot bypass SSO by simply using the non-SSO Umbrella username and password.
What some administrators may not realize, however, is that some service providers (like Concur) may allow a user to sign in with both methods: the non-SSO and SSO way (instead of ONLY allowing the latter.) Why is that a security issue?
Let’s look at what should happen when an employee leaves a company:
- Account gets disabled on the identity provider side (like Active Directory and Azure AD)
- SSO is blocked for the user
- Access to local resources is cut off
- Access to cloud resources stops
- Note: this may not happen immediately as SAML Access and Refresh tokens may not yet have expired
- When the former employee tries to reset the password to his SSO and non-SSO accounts, this should not be possible
- Email access should also not be available to prevent password recovery
So, what if the employee knows the password to his non-SSO login? What if he had performed a password reset for it prior to being terminated? Despite SSO being disabled, he could still access the resource. That’s where a disgruntled employee could potentially cause damage to the organization.
If the native, non-SSO login cannot be disabled, at minimum, change its account password to something the user (and admin) does not know, and block the ability to reset it.
Allowing both non-SSO and SSO sign-on is a potential security and compliance issue
Prevent Non-SSO Login
The importance of preventing non-SSO login once SSO is enabled cannot be stressed enough to ensure that an employee can no longer access the resource upon termination or in unauthorized ways. This can be accomplished in various ways, depending on what the service provider supports:
- Only allow SSO login (by disabling non-SSO access)
- Change the non-SSO password to something the user does not know
- Prevent the password reset of the non-SSO account
The last one is of special note: If the user has the ability to change the non-SSO password, he or she may do so prior to being terminated. The person has now gained the ability to log in through both SSO and non-SSO. When the employee (and SSO account) is terminated, because he knows the non-SSO credential, he could still log in without anybody knowing.
A terminated employee may still have the ability to log in despite the SSO account having been disabled
SSO Not Working
During testing, my colleague (who wishes to remain anonymous) and I discovered that there was no option to reset the existing Umbrella account’s password. You could only Delete. That’s fair in preventing an administrator to sign in as someone else. Delete and re-add the account with the NameID Claim the SAML configuration is expecting. Generally, that is the email address. The person would receive an email with an invitation to sign in to Umbrella, and the account status would be “Pending”:
Take note of the Invitation Email: it greets the user and states that someone has sent an invitation to join Umbrella. Remember this for later.
Once you click on “Confirm Invite”, the user is taken to https://login.umbrella.com, and oddly, one of several things may occur:
- SSO is not available for the account
- Account is locked out for 10 minutes due to too many, invalid attempts
- User lands on the OpenDNS portal instead of Umbrella
OpenDNS Portal
Why did SSO not work? Why did OpenDNS pop up, and what is its relationship with Umbrella? The Umbrella dashboard still showed the user as “Pending”.
If you recall, OpenDNS created Umbrella and was later purchased by Cisco. What we later found was that even though the invited account was not “Active” in Umbrella, the same identity also existed on the OpenDNS portal side. This conflict prevented Umbrella to complete its invitation process. Who knew? Furthermore, if the user was already logged in to Umbrella, next time he visited the site, he was logged on to OpenDNS instead. How do we remove that conflict?
Delete the OpenDNS Account
We had to find a way to delete the OpenDNS account so one could complete the Umbrella SSO invitation. To do so, one must gain access to their shadow OpenDNS account. But there was a problem: the user’s non-SSO Umbrella password did not work at https://login.opendns.com. One would have to perform a Password Recovery. More on that later.
If the user was already logged in to OpenDNS, try deleting the OpenDNS account by going to the My Account tab > Delete Account > provide the current password and click the “Delete Account” button as shown below:
Did account deletion work? No. The Umbrella password entered was invalid even if you typed it in right:
In short, even though the OpenDNS account existed, we did not know what its password was. It was not the same as what was used to log in to Umbrella.
OpenDNS Password Reset
To delete the OpenDNS account, one must first perform a password recovery. Provide the email address for the Umbrella account to reset, and an email should be received with a link to set a new password:
Once the user has gained access to his OpenDNS account, he can now delete it:
Re-Invite to Umbrella
The Umbrella administrator needs to remove the user’s invitation and send a new one. With the OpenDNS account conflict gone, the user will now get a different invitation email from what was received previously (right). In the new one (left), it no longer shows who sent the invite.
The user can now “click this link” from the invitation email, taking him to the SSO login page where he inputs the email address for the account. SSO will now sign him in, the account will change to “Active” in the Umbrella dashboard, and he can even try to log in through the non-SSO login page. Note: No matter what password is entered on the non-SSO login, SSO will take over. If Multi-Factor Authentication has been set up for Azure AD, the account may even get challenged with it, depending on the configured MFA policies.
Umbrella SSO Password Recovery
I had previously shared that when SSO is enabled for an account, the user should NOT be allowed to reset the password for the non-SSO Umbrella account. Password changes should be handled from the Identity Provider (IdP) side, such as Active Directory or Azure AD, for centralized account management and security.
Indeed, with SSO now properly working with Umbrella, trying to perform a password recovery will result in an error, as it should:
Resolution Summary
Let’s summarize the steps needed to convert an Umbrella native account to use SSO.
Take note of the user’s Umbrella account email address and assigned role- Delete the user’s Umbrella account
- Direct user to https://login.opendns.com and click on the “Forgot Password?” link
- An email from OpenDNS will be sent to the user to set a new password
- From the OpenDNS Dashboard, have the user go to: My Account tab > Delete Account > provide the newly-set password > click on Delete Account button
- Create a new Umbrella invitation with the user’s email address and desired role
- User should get an invitation email with a link to the Umbrella SSO login page
- After providing the account’s email address, the user should be logged in to Umbrella
Conclusion
Converting a service provider’s native accounts to SSO should be a pain-free process with as little involvement from the users as possible. As can be seen here, Cisco and OpenDNS have some integration challenges to work out, forcing us to have the users perform a password recovery and account deletion before their SSO could be enabled. Thankfully, our Umbrella users are all technical and were not too bothered by having to do some legwork.
