Casper AD Bind Breaking Shell

[kturnbeaugh]

Please forgive me in advance. I am VERY VERY new to Casper and it was pretty much dumped in my lap. I am having an issue when an AD bind is pushed when imaging, the shell for any network user becomes /usr/bin/tcsh. Local accounts have it listed as /bin/bash and in the Directory Bindings of the JSS it lists Default User shell as /bin/bash.

The only thing we pushed besides the OS and Casper AD bind, was the creation of the Casper Admin account and a local Administrator account.

We have
1. Bound the machine manually. This loads the correct shell of /bin/bash.
2. Deleted out the Directory Binding and added it again, making sure we weren't inputting anything (We had inherited all of the previously created binds from the previous admin).

[calumhunter]

In the JSS, under computer management -> Directory Bindings
select your AD Binding, under the User Experience tab, you can enter the default user shell. it should be bash by default.

apple used tcsh back in 10.2 by the way bash came in from 10.3 on

external image link

[mm2270 · Accepted solution]

Hmm. Seems like she already checked that from what I'm seeing-

...and in the Directory Bindings of the JSS it lists Default User shell as /bin/bash

I don't know if this is related or helpful, but a few months back we had an issue where seemingly random users setting up their new imaged Macs weren't able to log into their Mac after their account was created from AD.
We dug into this a bit and tracked this down to be related to a change in AD and some behavior of the Apple AD plug-in. Centrify is used in AD here for users who need access to Unix environments, and we found that if a user changed their default shell in their Unix environment to something other than /bin/bash, it was stored in MCX settings by Centrify for their account. Then a change/upgrade in our AD environment suddenly caused the Apple AD plug-in to start reading that value at the time an AD cached mobile account was created. It would set the new account's User Shell value to what was stored in their AD account, such as /bin/csh or whatever, which prevented proper login since OS X expects /bin/bash.

We resolved it by explicitly setting the User Shell setting to /bin/bash at the time the account is created instead of allowing the setting to be pulled in from AD.
Obviously this never affected local accounts since there wasn't anything to read and pull in, only AD accounts.

Does this sound like what may be happening?

You can check what the shell setting is for an AD account either by locating it in something like Directory Utility and viewing the record details, or just from the command line with the following. Just change the "ORG" to your domain, and change "username" to the short user ID you want to view

dscl "/Active Directory/ORG/All Domains" read /Users/username UserShell

That should report back:

UserShell: /bin/bash

If you see something other than bash, then it may be that the setting stored for that account in AD is being pulled in by the AD plug-in when the account is created, like in our case.

Hope that helps you track it down.

[calumhunter]

d'oh its early and i haven't had a coffee yet thats my excuse :P

very interesting issue that you encountered there mm2270 - good info to know

[kturnbeaugh]

I can't run a command line without fixing Terminal. I did look in Directory Utility and Under Advanced Options - User Experience - Default user shell is checked and lists /bin/bash. If I go into Users & Groups - right click on my network user click Advanced Options it shows Login Shell: /usr/bin/tcsh.

I fixed the shell on my network user, logged out and logged in with a test user account we have, verified the test users shell in Advanced Options shows Login Shell: /usr/bin/tcsh.

Then I logged back in with my fixed network account user ran your script for the test user and it came back with /bin/bash. It seems like your script just shows what is in the Directory Utility of the User instead of the profile of the user.

[mm2270]

Yes, the line I posted is querying AD for the user settings. If you want to look at the local cached account, then replace the "Active Directory/ORG/All Domains" with just a period to indicate the localhost. So...

dscl . /Users/username UserShell

but that will only show most likely that the User Shell is set to /bin/tsch, which you kind of already know.
You can change the setting from dscl as well, but you need to figure out where that's actually coming from. Are you saying if you run the query on the account against AD its returning /bin/bash for the User Shell setting?

[kturnbeaugh]

We dug into this a bit and tracked this down to be related to a change in AD and some behavior of the Apple AD plug-in. Centrify is used in AD here for users who need access to Unix environments, and we found that if a user changed their default shell in their Unix environment to something other than /bin/bash, it was stored in MCX settings by Centrify for their account.

^^ intrigues me though. Is there a possibility that with our old AD system 2003, I believe, the tcsh is already stored in MCX settings and that's where it's pulling the /usr/bin/tcsh from? We create mobile accounts at login. I will test not creating a mobile account when binding and see what the Shell is.

[mm2270]

Yeah, that's kind of why I mentioned all that. Its very possible the shell setting is being pulled from AD at the time the account is getting created, and overriding what the AD plug-in settings are for that. That's essentially what was happening in our case.

[kturnbeaugh]

10.9 pulls the Shell from AD. In our environment it's currently listed as /usr/bin/tcsh. We will work with our Systems Department to get that changed. Thank you mm2270 for your input as it wound up being the issue!!!! And hip hip hooray that Casper wasn't the problem, and I get to pass the proverbial buck on up the chain.

[mm2270]

Awesome! I'm glad that helped someone else besides us!

[calumhunter]

I like Apache Directory Studio to view the AD structure and attributes.
When ever i'm doing an integration, i like to check through some sample user records and what not just to see what attributes are set and what data is in them. Sometimes its cool finding useful information that is populated in there that can be used in the JSS like year level, room, building etc etc. Othertimes you find things that might cause issues like the homedirectory or as you guys have found out the shell! Will add that to my list of things to check.

[RobertHammen]

The Directory Editor component of Directory Utility (found in /System/Library/CoreServices, moved into an Applications sub-folder in Yosemite) can be invaluable in researching these sorts of situations as well.