Skip to main content

Hello Everyone,

I am still pretty new here so bear with me on this one. Our organization uses binds our Macs to AD and people sign in to create mobile accounts. These accounts have admin privileges but some things are restricted. For example, terminal access on mobile accounts is deactivated. When you open a prompt, the terminal window says "process complete" and doesn't let you enter anything.

 

What kicked this all off is that we recently installed SPSS v. 29 on a machine and noticed that the local Admin account can run it fine but the mobile account cannot. In the local account, we noticed that SPSS launches a few terminal commands to load Java and launch SPSS. We suspect that the mobile account can't launch SPSS b/c the mobile account access to terminal is blocked.

In the process of troubleshooting, we used the chmod 777 command on the SPSS folder in Applications to make sure the mobile user had rights to this program. Then we tried a few ways to modify access to Terminal (with a root account and local account) but nothing worked out. We also tried to grant the mobile account specific access to terminal my going to the "get info" option in terminal and trying to manage permissions from there.

Has anyone else had this issue? I went through our JAMF policies and I don't notice anything that might explain this so I am wondering if this is a protective feature Apple implements. Maybe it is an issue with how we are configuring AD? I can't find much to explain it so any advice would be appreciated.

 

Thank you,

Matt

Hi Matt,

Not sure if this would resolve your problem. But would what was done in this post do the trick? Best of luck.

https://community.jamf.com/t5/jamf-pro/silently-quot-grant-full-disk-access-quot/m-p/186856

/bin/false is a way to disable Terminal login access, and this can be set for mobile accounts in your binding settings.

I'm not sure if you have a Jamf binding config that is doing the AD bind, or if it's being done in a config profile. But in either case, you should check to see if the Default user shell is set to something other than /bin/zsh (or /bin/bash for older OSes). My guess is that setting is set to /bin/false. Someone likely did that to prevent end users from opening a shell prompt.

For your existing devices, you can change the shell for each user account with a script. For example,

/usr/bin/dscl . change /Users/username UserShell /bin/false /bin/zsh

 

/bin/false is a way to disable Terminal login access, and this can be set for mobile accounts in your binding settings.

I'm not sure if you have a Jamf binding config that is doing the AD bind, or if it's being done in a config profile. But in either case, you should check to see if the Default user shell is set to something other than /bin/zsh (or /bin/bash for older OSes). My guess is that setting is set to /bin/false. Someone likely did that to prevent end users from opening a shell prompt.

For your existing devices, you can change the shell for each user account with a script. For example,

/usr/bin/dscl . change /Users/username UserShell /bin/false /bin/zsh

 


That did the trick! Thank you so much :)

Hi Matt,

Not sure if this would resolve your problem. But would what was done in this post do the trick? Best of luck.

https://community.jamf.com/t5/jamf-pro/silently-quot-grant-full-disk-access-quot/m-p/186856


This may actually help with another issue I am having so thank you so much! 

/bin/false is a way to disable Terminal login access, and this can be set for mobile accounts in your binding settings.

I'm not sure if you have a Jamf binding config that is doing the AD bind, or if it's being done in a config profile. But in either case, you should check to see if the Default user shell is set to something other than /bin/zsh (or /bin/bash for older OSes). My guess is that setting is set to /bin/false. Someone likely did that to prevent end users from opening a shell prompt.

For your existing devices, you can change the shell for each user account with a script. For example,

/usr/bin/dscl . change /Users/username UserShell /bin/false /bin/zsh

 


Also, I was looking at our binding set up in AD. It seems that we had it set properly so I think there must be a policy or something that is changing it to bin/false. I am not seeing it but I will keep digging in. Here is a screen shot of what we currently have.

 

 

Also, I was looking at our binding set up in AD. It seems that we had it set properly so I think there must be a policy or something that is changing it to bin/false. I am not seeing it but I will keep digging in. Here is a screen shot of what we currently have.

 

 


Sure, it's entirely possible that there's a policy running a similar command to the one I posted above, but in the opposite direction, going from /bin/bash or /bin/zsh to /bin/false. It's an easy thing to script, so that may be it, especially if it's not being set within your AD binding.

Hopefully you find it and disable it if that's the end goal, because if the policy happens to be set to Ongoing, some of those accounts may end up getting set back to /bin/false for the user shell.

Sure, it's entirely possible that there's a policy running a similar command to the one I posted above, but in the opposite direction, going from /bin/bash or /bin/zsh to /bin/false. It's an easy thing to script, so that may be it, especially if it's not being set within your AD binding.

Hopefully you find it and disable it if that's the end goal, because if the policy happens to be set to Ongoing, some of those accounts may end up getting set back to /bin/false for the user shell.


I appreciate it! I went into the terminal preferences and updated it there and it worked. I just need to figure out why it is forcing it over the /bin/false.

I appreciate your quick and informative responses!

Reply


Terms & ConditionsCookie settings