Has anyone seen this before? Suddenly when trying to sign in(for the first time) to newly enrolled AD joined macs, I am getting this lego block icon with an OK option. Click it, screen goes black then hit any key and youre back at the login screen.
The only changes I made yesterday were with application policies. I would start there, but first I need to know what this icon is? Literally cant find anything about it online. Pretty frustrating. Has anyone seen this before? I also dont follow the logic of "removing old app policies and fixing ones that havent been working" breaks AD logins?
I join new devices manually. I set primary domain controller, add directory admin group, create local account at login without confirmation, dont set UNC path, home directory is /bin/bash. Nothing has changed. I just set one up yesterday and its fine.
Im assuming its related to policy changes I made, some how, but I cant find anything about this useless error icon. Has anyone seen this? Thank you.
Suddenly cannot sign in to AD joined Macbooks
+4Best answer by AntMac
I actually know now what my problem is with the domain join issue - name. I have a script I was working on some time ago but I never could get it to work correctly. I want to have a window that pops up during enrollment that allows me to enter the computer name - this takes my entry and runs it against scutil --set LocalHostName, HostName and ComputerName.
Currently, all devices get thrown into JAMF after enrollment as "MacBook Pro" or "MacBook Pro(2)" if I set up 2 at once. So the first thing I do after enrollment is go to JAMF, set the name and asset tag, then login with the local jamf admin account and open terminal - scutil --set yada yada for all 3 names. Then I AD bind. Then reboot. Then machine is mainly done. Especially now that I got a lot of the software policies fixed yesterday.
If you have any advice here, its greatly appreciated. Have a good evening.
Not sure if you still need the information.
We have AD bindings defined as another person mentioned above. Then a policy set to apply the binding and reboot the device. This is run after the rename script I mention below.
This what we use to set the names on our devices. This is triggered by a manual click from self service:
#!/bin/bash
ComputerName=`/usr/bin/osascript <<EOT
tell application "System Events"
activate
set ComputerName to text returned of (display dialog "Please Input New Computer Name" default answer "" with icon 2)
end tell
EOT`
#Set New Computer Name
echo $ComputerName
sudo jamf setComputerName -name $ComputerName
# set Computer ID for AD binding
scutil --set HostName $ComputerName
Sleep 10
echo Rename Successful
sudo jamf recon
exit 0
@imnotajamfadmin wrote:
home directory is /bin/bash.
ummm.... the home directory should definitely NOT be /bin/bash
+4
@imnotajamfadmin wrote:
home directory is /bin/bash.
ummm.... the home directory should definitely NOT be /bin/bash
I guess I should say the default user shell is /bin/bash
I took over mac duties from someone who left abruptly, and leaving the user shell to the default /bin/bash has always been the process. I just looked this up a little - should it be /bin/zsh? /Users/Username?
Thanks!
+4Ok - so something is blocking the creation of local user accounts. I uncheck the create mobile account at login and there is no error.
Anyone know what would block the creation of mobile accounts?
I guess I should say the default user shell is /bin/bash
I took over mac duties from someone who left abruptly, and leaving the user shell to the default /bin/bash has always been the process. I just looked this up a little - should it be /bin/zsh? /Users/Username?
Thanks!
It should be /Users/{username}.
Ok - so something is blocking the creation of local user accounts. I uncheck the create mobile account at login and there is no error.
Anyone know what would block the creation of mobile accounts?
I highly suggest using Directory Bindings and setting up a policy to have consistency in your AD joining.
Are any of your other policies doing anything with permissions on the disk? Can you manually create /Users/{username} with an admin account?
Below is a test directory binding I setup that mirrors mine, only sanitized:
+4I highly suggest using Directory Bindings and setting up a policy to have consistency in your AD joining.
Are any of your other policies doing anything with permissions on the disk? Can you manually create /Users/{username} with an admin account?
Below is a test directory binding I setup that mirrors mine, only sanitized:
I have actually gone through this and it never worked. However, the conflicts that I cleared up could potentially have been part of the issue? Thank you a ton for sending that. Ill give it a shot using your guide.
The above issue I think I have resolved... I think I had some software policies set to ongoing that shouldnt have been. I changed them all to once per computer and now... I can login? I have to either re-enroll or rebuild it seems. No real rhyme or reason yet.
+4I highly suggest using Directory Bindings and setting up a policy to have consistency in your AD joining.
Are any of your other policies doing anything with permissions on the disk? Can you manually create /Users/{username} with an admin account?
Below is a test directory binding I setup that mirrors mine, only sanitized:
I actually know now what my problem is with the domain join issue - name. I have a script I was working on some time ago but I never could get it to work correctly. I want to have a window that pops up during enrollment that allows me to enter the computer name - this takes my entry and runs it against scutil --set LocalHostName, HostName and ComputerName.
Currently, all devices get thrown into JAMF after enrollment as "MacBook Pro" or "MacBook Pro(2)" if I set up 2 at once. So the first thing I do after enrollment is go to JAMF, set the name and asset tag, then login with the local jamf admin account and open terminal - scutil --set yada yada for all 3 names. Then I AD bind. Then reboot. Then machine is mainly done. Especially now that I got a lot of the software policies fixed yesterday.
If you have any advice here, its greatly appreciated. Have a good evening.
+10I actually know now what my problem is with the domain join issue - name. I have a script I was working on some time ago but I never could get it to work correctly. I want to have a window that pops up during enrollment that allows me to enter the computer name - this takes my entry and runs it against scutil --set LocalHostName, HostName and ComputerName.
Currently, all devices get thrown into JAMF after enrollment as "MacBook Pro" or "MacBook Pro(2)" if I set up 2 at once. So the first thing I do after enrollment is go to JAMF, set the name and asset tag, then login with the local jamf admin account and open terminal - scutil --set yada yada for all 3 names. Then I AD bind. Then reboot. Then machine is mainly done. Especially now that I got a lot of the software policies fixed yesterday.
If you have any advice here, its greatly appreciated. Have a good evening.
Not sure if you still need the information.
We have AD bindings defined as another person mentioned above. Then a policy set to apply the binding and reboot the device. This is run after the rename script I mention below.
This what we use to set the names on our devices. This is triggered by a manual click from self service:
#!/bin/bash
ComputerName=`/usr/bin/osascript <<EOT
tell application "System Events"
activate
set ComputerName to text returned of (display dialog "Please Input New Computer Name" default answer "" with icon 2)
end tell
EOT`
#Set New Computer Name
echo $ComputerName
sudo jamf setComputerName -name $ComputerName
# set Computer ID for AD binding
scutil --set HostName $ComputerName
Sleep 10
echo Rename Successful
sudo jamf recon
exit 0
+4Not sure if you still need the information.
We have AD bindings defined as another person mentioned above. Then a policy set to apply the binding and reboot the device. This is run after the rename script I mention below.
This what we use to set the names on our devices. This is triggered by a manual click from self service:
#!/bin/bash
ComputerName=`/usr/bin/osascript <<EOT
tell application "System Events"
activate
set ComputerName to text returned of (display dialog "Please Input New Computer Name" default answer "" with icon 2)
end tell
EOT`
#Set New Computer Name
echo $ComputerName
sudo jamf setComputerName -name $ComputerName
# set Computer ID for AD binding
scutil --set HostName $ComputerName
Sleep 10
echo Rename Successful
sudo jamf recon
exit 0
Thank you for the extra info. This whole ordeal along with a separate secure token/self service issue has basically moved me off of AD Binding. I set up a kerberos SSO push which works and works WONDERFULLY. I just need to figure out a solution for multi-user spaces. NoMAD went EOL by JAMF dec 31, 23.
+10Thank you for the extra info. This whole ordeal along with a separate secure token/self service issue has basically moved me off of AD Binding. I set up a kerberos SSO push which works and works WONDERFULLY. I just need to figure out a solution for multi-user spaces. NoMAD went EOL by JAMF dec 31, 23.
Totally understand about moving away from AD binding, it is a pain and we are moving away from it as well in favour of JAMF Connect and Device Compliance.
Just passing on in case you are not aware. NoMad is basically rebadged as JAMF Connect now since JAMF acquired it. It does have a licensing fee attached per device unlike NoMad. But if you want to keep using this kind of functionality Connect would be worth looking into.
Thank you for the extra info. This whole ordeal along with a separate secure token/self service issue has basically moved me off of AD Binding. I set up a kerberos SSO push which works and works WONDERFULLY. I just need to figure out a solution for multi-user spaces. NoMAD went EOL by JAMF dec 31, 23.
Did you ever happen to figure out exactly what was causing the problem or just switch over to the SSO push?
We're working towards going with Jamf Connect but we aren't ready to roll it out and I can't get my user logged in to a freshly setup machine. It's been wiped multiple times and still gives the little lego piece when trying to login with a domain account.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.