![]() ![]() But do check that official documentation for information about Single Sign out. The steps described so far are basically the same as but with more context and screenshots. In the Example that follows, we’ve selected “AD SAM account name”, which is the shortname/jdoe format… In the scenario we’re using for this post, you can tell Okta to feed whatever username format you want as long as it works as an account name on the Macs, in Jamf Pro, and we can reliably match it up with something is Azure AD. If you want the account name in Jamf Pro or on your Macs to be something other than the Okta long username, select it in the “Application username format” dropdown. You could designate that only members of a Mac Users group have the ability to enroll a device in management, for example. Jamf Pro uses group membership for other permissions too. But if you only care about a couple groups like one for admins and one for the help desk, then you can set this differently so only the groups you care about get sent over. Go down to the group claims section and select “Matches Regex” and “.*” if you want to include every group. I want to be able to assign permissions to admins in Jamf Pro based on group membership, so we have to tell Okta to include a list of a user’s groups every time a user signs in. Switch to the “Sign On” tab and click “Edit”. ![]() First, add some users or groups to the app. Your app has now been created and you can now make some additional configurations. Search for “Jamf” and pick “Jamf Pro SAML”. In the Admin console, navigate to Applications and click “Browse App Catalog” The way we’re going to discuss in the rest of this post requires some attribute mapping so it’s more work, but it might end up being the cleaner approach. That might be easier to implement since you don’t have to deviate from any of the defaults in your IdPs, Directory Services, or Jamf. Oh… and before we get started, I should mention that there’s another way to get the user experience where they login with their short name but the account’s username is actually their long name so you might be better positioned for the future… create your local accounts on the Mac using the user’s full UPN, then add an alias with the shortname… sudo dscl. Whatever you send is going to appear as the username when an admin logs into Jamf Pro and/or will be used to create the initial account on the Mac when a user logs in when going through Setup Assistant during an automated enrollment flow on a new Mac or when logging in for User Initiated ( ) Enrollment. If you have your AD feeding user information into Okta, you can send their shortname or mail nickname. You can tell Okta to feed whatever value you want back to Jamf Pro as the username -It doesn’t have to be the Okta username. And users have gotten used to using these formats to log into their Macs and Windows PCs so having a local or mobile account on a Mac that looks like an anything else just seems weird. But in some orgs there are still lots of systems that still use the shortname (AD’s SAMAccountName/“jdoe” format) or mailNickName (jane.doe format). Lots of web sites use that username format, so people are totally used to it by now. In many orgs, that’s the same thing as the user’s email so the users don’t know there’s any distinction. In Okta, we always login with a standard Okta username, which normally corresponds to the UPN in Active Directory. You might use different SAML providers for login or a different directory service, but the principles are the same. Using Jamf Pro, I wanted to to use Okta for authentication, Azure AD as a Directory Data provider, and I wanted the local accounts on the Macs to be the user’s short name or first.last format. ![]()
0 Comments
Leave a Reply. |