Jamf Connect Login all Okta users are admin problem.

bmcdade
New Contributor III

So working with Jamf Connect Login, and having a problem with the setup and the feature actually working . All users created from Okta are given Admin permissions on the local machine.

It doesn't matter if I have the "CreateUserAdmin" as true or false, or not even in the .plist file, the new setup users get assigned Admin privileges on the machine.

We would want to lock this down so if a user does set them self up on a machine they can not elevate their accounts to Admin. As I see it, it's a security risk as someone can just login on an open machine and get access to another users data. Anyone else having issues with this feature of the software?

5 REPLIES 5

rqomsiya
Contributor III

Can you share your .plist to ensure correct formatting?

bmcdade
New Contributor III

Sure.. I have removed all the sensitive data.

See below. Everything seems to work fine with the problem that the user accounts get Admin Privileges. I don't see anything on the Okta side which would do this either.

<?xml version="1.0" encoding="UTF-8"?> .

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> .

<plist version="1.0">

<dict>

<key>LoginLogo</key>

<string>/usr/local/shared/Logo.png</string>

<key>AuthServer</key>

<string>companyname.okta.com</string>

<key>AutoAuth</key>

<true/>

<key>CreateAdminUser</key>

<false/>

<key>DenyLocal</key>

<true/>

<key>DenyLocalExcluded</key>

<array>

<string>admin</string>

</array>

<key>LocalFallback</key>

<true/>

<key>Migrate</key>

<true/>

<key>MigrateUsersHide</key>

<array>

<string>admin</string>

</array>

<key>OIDCAccessClientID</key>

<string>XXXXXXXXXXXXXXXXXXX</string>

<key>OIDCAdminClientID</key>

<string>XXXXXXXXXXXXXXXXXXX</string>

<key>OIDCProvider</key>

<string>Okta</string>

<key>OIDCRedirectURI</key>

<string>jamfoauth://oauth-callback/okta</string>

</dict>

</plist>

bmcdade
New Contributor III

And this was my own issue. It seems that it does work. I only created one OIDCClientID and used it for both Admin and Access. So it seems all users need to go in a separate OIDC group, and only Admin users in the Admin group as this overrides the CreateUserAdmin value. It does seem to work and will give Admin rights to the user if they are only in the Access group, otherwise they get standard access.
Thanks.

heetch
New Contributor

Hello @bmcdade , where did you find the URL "jamfoauth://oauth-callback/okta"
From the documentation they mention "jamfconnect://127.0.0.1/jamfconnect"

What would be the difference ?

Also, I am not sure I understood your setup. I have a black screen when I have both <key>OIDCAccessClientID</key> and <key>OIDCAdminClientID</key>

It only works if I have one only <key>OIDCAdminClientID</key>

How did you setup Okta ?
Did you create 2 "identical" OIDC apps and just mentioned their Client ID in the plist ?

I'm a little bit lost 😅

bmcdade
New Contributor III

Hi,
Ok.. first you can ignore the url "jamfoauth://oauth-callback/okta" as it's now "jamfconnect://oauth-callback/okta" and this is defined in Okta setup for the Application. The 'jamfoauth" was left over from when I had it as Nomad and i just renamed nomad to jamf. You must define the callback in the Okta account and they must match in your config file.

As for the Admin and the Client ID, they must be two separate keys/applications. I made the mistake of only using one, the same one for both. However every users needs to be in the Access Client ID Application, however only users with Admin Privileges on install would be aded to the Admin Client ID. I recall an issues of a blank screen when the callback was not correctly defined, along with not allowing the login.

I created two different OIDC apps, with different ID's and both must be listed in the plist for it to work correctly.

Hope that clears it up.