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.
@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.
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.
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.
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.
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.
@kitzy, you seem to have a @kitzy-fastly alter ego :)
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.
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.
directory services are dead
@calumhunter I see what you did there.
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}"
@calumhunter we've tried to tell the developers at JAMF, but no one will listen to our plea for GAFE integration. Ugghhh.
@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.
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
@eagleone seems likesome has submit a feature request to do this:
Use Google Apps as an alternative to LDAP
and it is 'under review'.
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.
@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!
