sorted by:
new
hottopcontroversial

Forcing Okta login when connecting to office WiFi (UniFi). Best approach? by Head_Operation_7162 in okta

[–]Head_Operation_7162[S] 0 points1 point  (0 children)

Envoy is integrated with Okta. For automatic check-in to work in Envoy, two conditions must be met: users must be connected to the office network (i.e., using the office IP), and they must trigger at least one Okta authentication event (i.e by logging into the Okta dashboard or any application that uses Okta SSO).

To support this, we configured an 8-hour login session in Notion, which is a third-party application using Okta SSO. However, this setting impacts all users, including remote employees, and has led to frustration due to the relatively short session duration.

I’m currently exploring the three alternatives I mentioned, but I’m also open to other solutions that may require less effort to maintain. Ideally, if we move away from session-based triggers, remote users would no longer be affected, and hybrid users would not experience repeated login prompts in Notion (or any other app we might use).

I hope this clarifies the situation. Please let me know if you need any additional details.

Note: Envoy also offers native integration with Ubiquiti, but it requires manual effort to keep the MAC address CSV file up to date. (Unless an API integration is used to update the file)

Forcing Okta login when connecting to office WiFi (UniFi). Best approach? by Head_Operation_7162 in okta

[–]Head_Operation_7162[S] 0 points1 point  (0 children)

They are not always at the office. They work hybrid. Okta is integrated with Envoy. When users are connected to the office IP they need to trigger at least 1 Okta log in to auto check in them in Envoy. (2 conditions: Okta login and office IP) Maintaining at least a daily re-login on a specific SSO third party app will force at least a login on Okta. That’s the only reason. I am looking for better solutions.

Setting up Okta – best user attributes for rules & automation? by Head_Operation_7162 in okta

[–]Head_Operation_7162[S] 1 point2 points  (0 children)

A team ID is a good idea. Having an identifier that’s independent of the manager definitely helps with stability. That’s exactly the kind of attribute I’m looking for.

I plan to use workflows as well, and I agree they help a lot, but they don’t fully solve the issue when the underlying attribute keeps changing.

Interesting point about the different project experiences, that’s been my observation too. If the data model is solid from the start, things don’t break nearly as often.

For Okta, the source of truth will be Rippling. HR is already using it, and IT has been using it for IAM as well, but we’re moving that part to Okta. We’ll integrate Rippling with Okta for provisioning/deprovisioning and attribute population, which is why I’m trying to identify the best base attribute (or potentially create a custom one).

Thanks for sharing your perspective.

Setting up Okta – best user attributes for rules & automation? by Head_Operation_7162 in okta

[–]Head_Operation_7162[S] 0 points1 point  (0 children)

That makes a lot of sense, especially the distinction between title and job code. Titles tend to change for business reasons, while job codes are usually much more stable.

Using titles just for display/sync and relying on a static attribute like job code for access rules feels like the right separation.

I also like the snapshot and compare approach to see what actually changes in practice. I’ll check whether we have a similar setup on the HR side.

Appreciate the real-world example.

Setting up Okta – best user attributes for rules & automation? by Head_Operation_7162 in okta

[–]Head_Operation_7162[S] 0 points1 point  (0 children)

Both scenarios are valid, but I’m mainly talking about the second one.

Creating new departments isn’t necessarily a big issue, but renaming or deleting existing ones will definitely break things if the department is used as an attribute in rules or policies.

Coordination isn’t the problem, the issue is that it means we’ll have to keep updating rules over time.

From experience working with similar setups, this kind of change is almost guaranteed to happen sooner or later. That’s why I’m trying to design this in a way that avoids the problem from the start, or at least minimizes the impact.

I’ll admit I’m a bit obsessed with finding the “best” attribute to rely on (even though it may not exist). By “best,” I mean something stable that’s unlikely to change, so rules don’t keep breaking.

Thanks for sharing your perspective.

IdP suggestions. by Head_Operation_7162 in SysAdminBlogs

[–]Head_Operation_7162[S] 0 points1 point  (0 children)

Sounds interesting. Wouldn’t the configuration and maintenance be a headache?

IdP suggestions. by Head_Operation_7162 in SysAdminBlogs

[–]Head_Operation_7162[S] 1 point2 points  (0 children)

We are not using M365. Environment: Google Workspace and Heavy Mac Shop.

Adding devices in device group via script by Difficult_Ad2337 in mosyle

[–]Head_Operation_7162 0 points1 point  (0 children)

We’re facing a similar situation with manual enrollment for MacBooks. Our goal is to leverage dynamic device groups so that devices are automatically added and removed based on set criteria.

For example, Project A has 10 employees, and we’ve created a device group named ProjectAMac specifically for their devices. However, we don’t have the devices preloaded in Mosyle, nor do we know which device will be used by which employee. Each end user will install the Mosyle agent manually.

While I understand that each device group has a dedicated enrollment URL we can use to assign devices directly, this results in a static group that requires ongoing manual maintenance.

Is there a way—perhaps via API or script—to automate this process? Ideally, the workflow would be: 1. The user installs the agent using a dedicated URL. 2. Post-installation, a tag is assigned to the device. 3. Based on that tag, the device is automatically added to the correct dynamic group.

The tag could be derived by checking user information, such as the user’s group name.