Author: Pratik Bhatt
Audience: Those who works with OKTA or any other similar IAM Products will find it more interesting and useful.
Bias Information: Current Okta Customer and working in IAM area.
================================================================================================================
Title may sound weird (not to earn click bates 😊) but seriously, this is the first topic I thought I should be writing because you may find plenty of search results about what okta can do and about their capabilities.
We also find some comparison also with other vendors about the capabilities.
What I am going to write is bit at granular level, means it will not list a big jargons or feature names, but some detailed features that I (or any other okta customer) wants to have in their environment
I discovered these things while working with OKTA and few of these are features that I-myself has requested to okta but still waiting for them to get added.
[1] Not Refusing NTLM 1.1 Authentication
So, it all started with the Splunk Guy in our team who was getting alerts based on the logs and saw NTLM 1.1 Authentication requests are being observed and that too on OKTA IWA Servers.
Upon investigation we came to know that whenever Okta IWA Agent fails to authenticate (for any reasons), as a default fallback NTLM authentication requests are being accepted by Okta.
Well, any IT Security guy like me will defiantly not like NTLM being used, but as we all know that when either client or server or both are not joined to a domain (or not part of the same trusted domain environment), Windows will instead use NTLM for authentication between client and server(https://en.wikipedia.org/wiki/Kerberos(protocol)#cite\note-MSTN-Kerberos-Auth-5)
The problem is it was even accepting NTLM 1.1 which is quite riskier then NTLM 2. So, I have been asked to configure OKTA in a way that it does not accept NTLM 1.1
I knew we do not have direct setting that can be changed inside OKTA, so I contacted OKTA support and below is the response I received.
_ We currently do not have the functionality to refuse NTLM v1. I believe however, this is quite a viable Feature that would be great to implement in the future." _
Refuse NTLM v1.1 and Use NTLM 2.0 only : https://ideas.okta.com/app/#/case/127772
[2] Update Certificate for Custom Domain accounts via the API (Let's Encrypt) [Planned]
If you are working with SSL Certificates, you may have heard of Let's Encrypt (https://letsencrypt.org/) which is free, automated, and open certificate authority provides free SSL certificates.
If your organization has custom domain, (like yourorg.okta.com) then you will need SSL Certificate to be uploaded (Settings-Customization-General-Custom URL Domain)
In the era of automation and APIs. Still OKTA does not support uploading the certificates via API with automation. However, the good news is that this feature has been planned to be developed by OKTA, but we will have to wait until its released as there are no timelines yet for the same.
Also, the certificates provided by Lets Encrypt are 4096bits length while OKTA only supports 2048 bits length keys
So moral of the story is you need to get 2048-bit length SSL certificates by paying some amount 😊 (unless you have somehow found a free source)
Both features are requested by customers and if you want to get it speed up then click on the links below and upvote the feature (can be done if you are okta customer/having okta id)
Support 4096-bit private key within Custom URL Domain: https://ideas.okta.com/app/#/case/107241
Update certificates for custom domain accounts via the API: https://ideas.okta.com/app/#/case/118815
[3] Group of Network Zones
While setting up OKTA, you may have to configure the Network Zones to segregate traffic of company network and outside network
The problem is you can have multiple Zones but while creating policies for region you will have to create separate policies and you cannot combine the Network Zones into a group or may forget to add zone
Create Groups of Network Zones: https://ideas.okta.com/app/#/case/105945
[4] Email notification IP addresses are blacklisted for your organization instance.
This is also a required feature as OKTA Threat insight is logging and blocking IP Addresses for 24 Hours (based on your settings in Security-General-Okta Threat Insight Settings) if there are multiple failure login attempts. But we do not come to know this until and unless some genuine user from your company reports it. In era of CI/CD Pipelines it may happen that there may be multiple instances running from single public IP(mostly in Cloud) and if one of the systems account are resulting somehow in failed login, OKTA will block IP and other system will not be accessible
You will only come to know from noises inside your company, so it will be better that OKTA send email to Admins when it blocks the IP (not every time but as a summary at least twice a day)
So, these was a small list, that may help you to know, and it may help you when you are consulting your customer or senior management in your company.
Share your views or something new so I can update the article and publish it here in the space.