Blog

The latest in Dark Rhino news

How Can Organizations Attract and Retain Qualified Professionals?

How Can Organizations Attract and Retain Qualified Professionals?

How can organizations attract and retain qualified professionals?

It is a seller’s market right now when it comes to IT employment. Especially in the security and risk field. Consider this, information security has had 0% unemployment for the last three years running and ISACA projects a shortage of 2 million security practitioners next year. Cybersecurity Ventures believes that number will reach 3.5 million by 2021. That’s a lot of unfilled jobs! Not to mention, burnout for security professionals working in an enterprise environment is common to say the least. So, how can organizations attract and retain qualified professionals?

Having spent the last 6 years of my career in IT recruiting, I’ve seen my fair share of approaches.

Ping pong tables, video games, and kegs on premises for the fun and casual work environment.

Flexible schedules, discretionary paid time off, and remote work capabilities to help strike a strong work-life balance.

Clear growth paths and consistent advancement with continuing education. Etc.

These are all well and good, but in my experience, the companies who are offering high salaries and stable employment win out more often than not. Another route many companies take is to train less experienced IT employees into the security field, but this too comes with its own unique set of obstacles…

First, you need to already have at least some security and risk expertise within your organization, as well as the time and the resources available for them to train someone. This is a tall order in an industry that has 1 job vacancy for every 2 employees.

Second, this doesn’t directly address the challenge of balancing employee salaries and company budgets. Sure, you could pay a lower starting salary as one develops his or her skills, but what is to stop them from leaving for greener pastures once they are up to speed?

Unfortunately for employers, this means that the cost of full time employment is steadily rising, as is the prevalence of contracted and project-based hiring. Because of this, finding a balance between offering potential employees the salaries they want, while staying within the company’s budget is becoming more and more difficult.

Enter Dark Rhino Security. As a managed provider, we are separate from your organization, its people, and its politics. We leverage the best industry standards and practices to objectively assess, investigate, and manage your information’s security and risk. With a managed provider, you no longer have to concern yourself with where to find the right people or how to keep them in your organization. We have an expert team of highly dedicated security specialists, supported by strategic and emerging technology partners, who are laser focused on information security for our customers. Combine that with our focus on culture and personal growth, and you’ve found yourself a stable, go-to partner for risk and security.

The Two Key Benefits of Tying O365 To Okta

The Two Key Benefits of Tying O365 To Okta

Most businesses's that we work with utilize Office 365 to varying degrees. No matter which mix of the O365 services that a business uses, you can pretty much guarantee that Email is at the centerpiece of every environment. After performing a few O365 & Okta integrations, I have seen two key benefits of tying in O365 to Okta that aren't immediately apparent.

First off, Office 365's logging features, they exist but the problem is that they are somewhat limited. You can view user metrics such as number of emails sent, last login, app usage, etc. but where do you look for failed or unusual logins? Does a run-of-the-mill IT admin have any indication when their accounts are being bruteforced? If you enable audit logging you then have access to logs of admin access, but these reports are designed to show when an admin accesses a user's account so that you can maintain a paper trail and have record of possible internal leaks. They are not meant to track the actions of external bad actors.

Immediately after doing an O365 integration with one of our customers, we noticed a fair amount of their users were locked out overnight. Okta's reporting features showed us that these users had hundreds of attempted logins to [portal.office.com] from a province somewhere in China. It appeared that they were attempting to bruteforce the accounts, but with no user lockout feature or logging of that capacity, the admins we were working with had NO IDEA that their user accounts were being hammered like that! We also retrieved a nice list of suspect IP's that they were able to cross-reference on their firewall & SIEM to investigate further.

The second way Okta helped was through Dynamic IP Black/Whitelisting. By default, in O365, an admin can maintain an IP address block list within the ‘Exchange Online’ admin center that allows you to configure rules under the 'Connection Filter' section. Unfortunately, the IP addresses you configure here are not dynamic, you are required to maintain the list of IPs yourself. This can be done if you manually update a host file already, but it can not effectively block logins from specific locations like countries or states.

The customer we worked with here was able to apply company-wide GeoIP settings from Okta to O365. Now, a service which previously had spotty access control, was completely barring users that attempted to login from anywhere outside the US. Instead they were redirected to Okta and subjected to the sign-on policies configured there.

These two features help provide improvement and insight into any O365 environment that hasn't already invested heavily into configuring Microsoft's security tools and provided a uniform access policy across ALL of their cloud apps.

Troubleshooting O365 Provisioning Errors in a Cloud-Based Infrastructure

Troubleshooting O365 Provisioning Errors in a Cloud-Based Infrastructure

As simple as it sounds, there are many pitfalls when it comes to integrating your directory with Office 365. The bulk of these issues stem from the provisioning side of the integration by not matching up the correct unique identifiers in both of the user accounts. In some cases, Office 365 is not listing an Immutable ID for an end user or Office 365 is not recognizing a certain account from your cloud-based directory.

While this solution will only work for certain use cases, like the ones I mentioned above, this error is a common problem that you’ll run into if you’re finding provisioning issues to Office 365. I’ll walk you through the process of manually setting an Immutable ID in Powershell and your source directory so that the two accounts can correctly match up.

By manually setting an Immutable ID for certain end users, your source directory and Office 365 will be able to successfully recognize the user and provision him or her directly to Office 365.

1: Open Powershell and run it as an administrator

2: If you haven’t already, you’ll need to install the Office 365 powershell cmdlet. You can do that by running the following command: “Install-Module MSOnline”. If prompted, type “Y” to finish the installation.

3: Run “Connect-MsolService” to connect Powershell to your Office 365 tenant. You’ll then see a screen asking you to sign into your Office 365 Tenant. If your domain is already in a federated state, I highly recommend logging in with a .onmicrosoft.com domain global administrator account.

4: After that, have a list ready of your problematic users that aren’t syncing correctly with Office 365. For these users, you’ll first need to change the User Principal name before you change the Immutable ID. The reasoning for this step is because you cannot alter an immutable ID for a user that’s a part of a federated domain. Run the following command to change the UPN from @domain.com to @tenantname.onmicrosoft.com:

Set-MsolUserPrincipalName -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -NewUserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it.

5: Once the user’s UPN is changed to a .onmicrosoft domain, you’ll now be able to alter or create an immutable ID manually. To accomplish this, I recommend visiting  https://www.guidgenerator.com/ to generate your unique Immutable ID value. This is similar to what a Source directory would do to map the Immutable ID attribute.

Note: Make sure Base 64 encoding is checked before you generate your GUID

6: Now that you have your randomly generated GUID value, you can change the Immutable ID. Go ahead and run this script:

Set-Msoluser -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -ImmutableID <GUID Value Here>

7: Since you’ve successfully changed the user’s Immutable ID, you’ll now need to change the user’s UPN back to its original state. Modify the command from step four to make it so you’re changing the UPN from the .onmicrosoft domain to the federated domain.

Set-MsolUserPrincipalName -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. -NewUserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it.

8: At this point, you can now verify that the new Immutable ID is showing up in the user’s office profile via Powershell. Run “Get-MsolUser -UserPrincipalName This email address is being protected from spambots. You need JavaScript enabled to view it. | select *” to make sure the Immutable ID is correctly showing up in the user’s profie.

While we completed the Office 365 portion of this configuration, we’ll still need to make the necessary changes in the cloud directory (I’ll be using Okta as my cloud directory example).

9: In Okta, you’ll need to make sure that the provisioning Options (Create, Update, Deactivate, Sync Password) are all disabled. If the user is assigned to Office 365 currently, go ahead and unassign the user from Office 365.

10: Next, Reassign the user to Office 365. After you click assign, you’ll be prompted for a space to manually input the newly created Immutable ID. Feel free to copy/paste the value into the Immutable ID textbox.

All that’s left to do now is to assign the correct licenses and roles to the end user inside Okta and you should be all set. You’re now able to turn back on the provisioning features inside Okta to master all of your O365 users in one central location. Test authentication with the problematic user and verify that the authentication flow is successful.

Although manually setting/resetting a problematic user’s Immutable ID is not always the fix to a provisioning solution, it’s a good place to start when it comes to diagnosing certain provisioning problems. These steps offer a great way to rule out any chance that your error is stemming from a unique ID issue.  If the Immutable ID fix did not correct the user synchronization, there is likely something else deeper at play. Look for other attributes that could be causing the Sync to fail, and then resync the values between Office 365 and Okta.

News

Subscribe to Our Newsletter

Image
Image

Address (United States)

5695 Avery Road
Dublin, OH 43016

Talk to us

+1 (614)-401-3025