Many organizations are in the process of moving applications to cloud-based service offerings. This includes big, well-known services like productivity suites Office 365 and G-Suite, and point-solutions, such as online meeting services and external file storage/sharing services. But as companies continue these moves, they retain their core on-premise infrastructure because moving completely to the cloud is more difficult than it seems. Plus, there are always good reasons to keep some servers/services on-premise. The most popular on-premise service that is retained is Active Directory, since it is the core directory service that everything is built upon in a Microsoft-based network.
Active Directory services get extended to cloud services via proprietary directory synchronization tools such as Microsoft’s Azure AD Connect (previously known as DirSync) or Okta’s AD Agent. In the case of Okta, the AD Agent is a small service that runs on one (or more) servers on-premise, synchronizes directory users into Okta and acts as an authentication relay agent using a method refereed to as Delegated Authentication.
Okta becomes an organization’s central cloud-services authentication hub. This is where [Active Directory] users authenticate to gain access to the organization’s growing cloud-based services catalog. This centralization of authentication helps organizations control cloud-service sprawl and therefore the number of places where they can be attacked. But this also means that the passwords that grant access into an organization’s Okta tenant are even more important to protect.
Okta does have an option for preventing the use of the most common bad passwords. But not only is this blacklist small, it only protects Directory Users when they choose to change their password from inside the Okta portal (which is a feature that is not even enabled by default). Most directory users still use plenty of on-premise applications and still use a computer that is joined to the company’s Active Directory. These users will be changing their passwords against Active Directory, directly interfacing with one of their organization’s Domain Controllers. Okta’s bad password prevention feature is not involved in these password change events. This is why you still need Password Firewall for Windows to protect your Okta environment, as well as Active Directory and anything else linked to it.
Not only is Password Firewall’s blacklist far more extensive and our solution more configurable, but most importantly, it catches these on-premise password change (and Admin/Helpdesk password reset) events that are happening directly with Active Directory. Without Password Firewall’s protection of your on-premise Active Directory passwords, your Okta tenant is at risk.
