How are folks without AD/LDAP infrastructure handling user info in the JSS?

kitzy
Contributor III

Here's the situation: all users are being managed through Okta and Google Apps. Until now, this met all needs as most things today will integrate with at least one of those. Unfortunately, Casper does not, and will only talk to LDAP.

We tried going down the route of having a cloud based LDAP sync with Okta, but unfortunately having users auth to the JSS for enrollment and self service don't work unless we disable 2FA, which isn't going to happen here.

Is anyone else in this situation? Have you come up with a clever way to make it work?

20 REPLIES 20

bpavlov
Honored Contributor

Are you trying to have users enroll on their own?

I'm not well versed so I'm just thinking out loud here, but would it be possible to have either of those services sync up with a some other LDAP one way. That LDAP would not have 2FA and would only be used for the JSS. Then you can connect the JSS to that specific LDAP.

kitzy-fastly
New Contributor

@bpavlov

The issue is that we have to disable 2FA for all requests coming from whatever server is hosting LDAP, and our security team won't allow that.

bpavlov
Honored Contributor

Well if Security won't budge, have you given thought to re-thinking how you want to deploy these computers? Why are the end users enrolling themselves? Why not have IT prepare the computer before the user gets their hand on it?

Or one thing you could do, you can have one general local account login for the JSS that the end users uses to register. Then have a policy (could be a package with a postinstall script or a script) that runs on enrollment that will prompt the end-user for their username and use the API or recon to assign the appropriate user to the computer. You can use AppleScript, CocoaDialog, etc. for the prompt.

kitzy-fastly
New Contributor

We have a very small IT staff, so having IT touch every machine (including the hundreds that are already in users hands that need enrolled) just isn't possible for us. Ultimately we're going to use DEP to enroll new machines, but we still want authentication to happen during enrollment in order to get the user data tied to the machine automatically.

bpavlov
Honored Contributor

The option I provided should work in either situation then. You can use the API to lookup the user and display the appropriate info in a user dialog/prompt. Then the "sudo jamf recon -endUsername" command to then allow the username to be assigned to that computer. You will need that generic user login to enroll, but if security wants to play hardball then you don't really have much a choice.

kitzy
Contributor III

I have a feeling that security would veto that as well, as there's no way for the user to prove who they are. For example, I could put in someone else's username and potentially gain access to applications I shouldn't have access to.

mm2270
Legendary Contributor III

@kitzy, you seem to have a @kitzy-fastly alter ego :)

kitzy
Contributor III

Yeah, two accounts for accessing different assets. I try to only post with this one but sometimes I forget which one I'm logged into.

bpavlov
Honored Contributor

The best I could tell you at that point is to go to your management and explain the situation. Tell them that feature X does not exist in the product you are using. You can either:
1) Make an exception for this instance to bypass 2FA in specialized LDAP instance so at least all enrollments are unique
or
2) Make a generic account and script a solution to capture the username and assign it to the computer
or
3) Evaluate other products that do offer integration with the services you use
or
4) Hire more IT staff so that IT can prepare the machines before handing it off to the user

Maybe I missed an alternative or maybe someone has some other idea.....

You can throw this back at Security and let them know that if they need to have these computers managed then they need to play ball. I imagine aside from the ease of management that there are security implications for being able to manage these computers as well. So something has to give. Good luck.

calumhunter
Valued Contributor

directory services are dead

kitzy
Contributor III

@calumhunter I see what you did there.

calumhunter
Valued Contributor

@kitzy ;) hehehe

bmarks
Contributor II

I don't know if this solves any of your needs, but this script will upload the local cached LDAP user info from a Mac to a JSS. This is for AD and needs to be run when logged in as the mobile user, but what it doesn't require is connectivity to LDAP from the Mac (at the time the script runs) or any user prompts. At the very least, maybe this will give you an example of what you can do silently without user intervention. For our workflow, we have provisioners set up Macs for users in advance (because we require FileVault to be enabled before the user can take possession of the machine) and then we have this script run once the Mac has been provisioned with a mobile user account:

#!/bin/bash

### Specify the AD ###

AD=

######### DO NOT MODIFY BELOW THIS LINE #########

### Get the currently logged in user information ###
ConsoleUser=`ls -l /dev/console | cut -d " " -f4`

### If the currently logged in user is an AD Mobile account then update the end username information to the jss ###
if

dscl /Active Directory/$AD/All Domains/ -read /Users/"${ConsoleUser}" > /dev/null 2>&1 ;then

ConsoleUserRealName=`dscl /Active Directory/$AD/All Domains/ -read /Users/"${ConsoleUser}" RealName | tail -n 1 | cut -c2-`
ConsoleUserEmail=`dscl /Active Directory/$AD/All Domains/ -read /Users/"${ConsoleUser}" | grep EMailAddress | cut -d ' ' -f2`
ConsoleUserJobTitle=`dscl /Active Directory/$AD/All Domains/ -read /Users/"${ConsoleUser}" JobTitle | tail -n 1 | cut -c2-`
ConsoleUserPhone=`dscl /Active Directory/$AD/All Domains/ -read /Users/"${ConsoleUser}" PhoneNumber | tr -d '
' | awk '{$1 =""; print }' | sed '1s/^.//'`

fi

# Submit the user information to the JSS
sudo jamf recon -endUsername "${ConsoleUser}" -realname "${ConsoleUserRealName}" -email "${ConsoleUserEmail}" -position "${ConsoleUserJobTitle}" -phone "${ConsoleUserPhone}"

eagleone
New Contributor

@calumhunter we've tried to tell the developers at JAMF, but no one will listen to our plea for GAFE integration. Ugghhh.

Chris_Hafner
Valued Contributor II

@eagleone I would easily second that request! I'm not sure what the conflicts or other such difficulties would be for JAMF to implement something like that but it would 'probably' make my life far happier seeing as I generally do anything I can NOT to use any type of mobile account.

gregleeper
New Contributor

I am hoping that since we heard in the JNUC about SAML support coming soon, we can tie that in with google apps single sign on. http://googleappsupdates.blogspot.com/2015/10/manage-multiple-saml-and-oidc-based.html

tcam
Contributor

@eagleone seems likesome has submit a feature request to do this:

Use Google Apps as an alternative to LDAP

and it is 'under review'.

tobiaslinder
Contributor II
Contributor II

The only ugly workaround I found was importing the users from google apps into a local AD and have the AD sync with Google Apps with Google Apps Directory Sync. GADS is setup to not touch the existing users in Google Apps as long as I don't delete them in AD.

Like this I only have to create the users locally. What is a big mess is the password. The users have to change the password in AD to make it replicate to Google Apps. If they change it in Google Apps the password is not in sync anymore.

Chris_Hafner
Valued Contributor II

@tobiaslinder We have a similar process except that we use GAM on the backend. Our MySQL based portal acts as the link between AD and Google. If our users change their passwords via our internal portal all is well. If they change something directly from Google, then they won't sync. Fixing it is as simple as having them update their password via our portal but it's not ideal. I've got to get my head around SAML at some point though as I keep hoping this can be a tool to help!

mwoodruff
New Contributor III
New Contributor III

Update: Casper Suite v9.93 has been released with SAML support today.

Casper Suite 9.93 Release Notes

Configure SAML support with Google Apps
Configure SAML support with Okta