You can customize the number of times that you enter an incorrect password before you get the password hint in the loginwindow on OS X. To do so, use the defaults command to send a RetriesUntilHint integer key into com.apple.loginwindow.plist stored at /Library/Preferences using the following command:
defaults write /Library/Preferences/com.apple.loginwindow RetriesUntilHint -integer 10
krypted March 25th, 2014
Posted In: Mac OS X, Mass Deployment
defaults, loginwindow, MAC, os x, password hint, retries
The Login Window in OS X is the screen you see while you’re typing in a username and password. There are a number of customizations used in some environments to make the system easier for users to use, or to make it more specific to a given user environment. One such is customizing the Login Window’s background, which can be done by replacing this file with one that you would like to use:
You can also configure a message to be shown to users. This message, often referred to as an Acceptable Use Policy, can be used as a policy banner that users must accept in order to log into a computer. To set a policy banner, create a file called PolicyBanner.txt, PolicyBanner.rtf, or PolicyBanner.rtfd with the information you want displayed for end users. Save this file to /Library/Security. Then, the contents of the file will be used as a login banner users will be required to click on the Accept button in order to login.
You can also use Profile Manager and Managed Preferences to manage the items from the System Preferences pane and set a message at the LoginWindow as well. These are available under the Login Window section of Profile Manager.
Update: Those crazy kids at AFP548 have posted a video on YouTube with additional info on Profile Manager. That video can be found here.
krypted August 6th, 2011
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
acceptable use policy, appleLinen, change background of loginwindow, Lion, lion server, loginwindow, OS X 10.7, Policies, profile manager, security policy
OK, by now I’m sure everyone has heard that OS X Server is a download off the App Store. For a whoppin’ $50 you get the OS that was once called “Open Source Made Easy” until someone at Apple realized that GPLv3 might mean that Open Source doesn’t always mean “free as in beer”. Wait, did I say that out loud? Point is, there are bigger changes here than just moving the server to the App Store.
There are also some pretty big changes to the GUI of OS X Server. The first and most obvious is the LoginWindow, which is different in OS X in general. It obviously looks different. The ability to click on the items above the username and password is gone. You can still see indicators of green and orange in the username field to indicate directory service availability though, which was one of the bigger things we’ve used that for over the past few years.
Once downloaded, the Server app will be in the /Applications directory, in Launchpad and useable. But the Server Admin tools are a separate (free) download from the Apple downloads page. This is a nice nickel and dime way of keeping the Server app small. Once installed, note that if you open About this Mac, the OS does reflect that you are running Mac OS X Server Lion (not OS X Server Lion btw for all you marketing nerds), so it is actually a registered different version of the operating system.
Now open up Workgroup Manager. The Inspector option in Workgroup Manager is gone. Actually, this is kinda’ true. The option is greyed out in the Workgroup Manager prefs (com.apple.WorkgroupManager.plist) but easily enabled using defaults to add the -dict for “Application Preferences” with a key of “Show \”All Records\” Tab” set to a value of 1. But more importantly, there’s now a tool called the Directory Editor that is part of Directory Utility (still located at /System/Library/CoreServices). It looks a lot like the Inspector, but it’s a bit more appropriate for local stuff.
Now open up Server Admin. Most of the services are gone. We’re left with nat (does anyone really still use OS X Server as a border device?!?!) and a few other services that were either too boring to get moved to the Server app or too unwanted. Expect these to disappear one by one if there are future releases of OS X Server. In fact, if OS X Server is $50 I’d say building a better DHCP (that maybe has a GUI for DHCP options and other cool stuff) or a better DNS is a worthy of a $10 or $20 app on the app store. After all, given the Mini platform it seems a decent platform as a network appliance in that fashion… But back to it.
Now go into Server. Wow. Super easy. The only challenging thing in here is Profile Manager. And the only challenging thing about it is that it a) most people aren’t going to let it build Open Directory for them (but should) and b) some people are going to get stumped when asked for a username and password for a developer account. Get yourself an Apple ID with a developer cert and Profile Manager will be really easy to use, especially if you’re used to working with Workgroup Manager to build Managed Preference manifests. Once in, if you will even note that you can assign specific defaults domains and push keys to clients. Of course, the big thing here is the wipe. The most important thing to note about that is that the clients need to run FileVault and there’s not a great mass deploy strategy for that yet (IMHO).
While I said Profile Manager could be challenging, there are some really cool things waiting for people to start hacking away at. The fist is scripting profile creation and management. Profiles are stored in /var/db/ConfigurationProfiles/Store. Much to the chagrin of 3rd party MDM developers, this solution works great for OS X and iOS. Much to the delight of MDM developers, the whole App Store look and feel that someone like JAMF has is still something that really sets them apart and the ability to have Casper assist you with managing those VPP keys is what will be the crazy huge value add that it will continue to bring to the table. Having said that, a lot of smaller organizations can now use Profile Manager where they might have just used iPhone Config Utility before.
Profiles can be pushed out in a number of ways. The user can download it out of the goodness of their heart. In iOS you’re kinda’ stuck with that deployment methodology. But not in OS X. Help comes in the form of the profiles command, located in /usr/sbin. Profiles is explained further in this other post of mine here.
The serveradmin app (serveradmin list shows a few less results than it used to), slap* commands and other tools server admins are used to are all still there. There’s a better webmail (much, much better), Wiki’s are a little different (not much), NFS (kinda’) and FTP are gone, Podcast Producer keeps getting easier, the twisted stuff (iCal and Address Book Server) is the same as it was in Snow Leopard and Server app gets more functional whereas Server Admin gets less functional. Server got a little easier. Or at least on the outside. But presumably it can, given that it’s likely to be asked to do less than it once was moving forward.
But as with previous versions of OS X Server, there are a lot of settings under the hood that aren’t exposed in any app. Let’s look at the devicemgr service, which is Profile Manager in the GUI:
sudo serveradmin settings devicemgr
One thing I do find interesting is the inclusion of postgres in serveradmin but not in Server app or Server Admin. MySQL is gone, but postgres is there.
You’ll also see settings like mdm_acl and user_timeout that can be pretty helpful (which is why they’re in there in the first place) but aren’t in the GUI. I’m all for keeping GUI’s clean, not giving admins the ability to easily enable something they shouldn’t and keeping away from having screens and screens of rolling settings. So for the most part I’m OK with this. My point with this paragraph (and every paragraph should have a point even though I forget that sometimes) is that if there’s a setting you need that you think got taken out or if there’s a setting that would be cool to have, check serveradmin settings and see if it’s there before just taking the Server app’s word for it…
krypted July 20th, 2011
Posted In: Mac OS X Server
10.7, admin tools, App Store, DNS, download, enable inspector, GUI, Lion, loginwindow, os x lion, OS X Server, server, server admin, show all records
Scripting a log out event seems like the kind of thing that would be pretty simple, and if you use the AppleScript later it does appear simple, unless you want to force the event to occur immediately. Why would we want to do such a thing? Most commonly there are two requests. One is to invoke the script with the screen saver to meet some form of policy that requires a log out after a certain amount of time whether the user has saved their data or not (seems a big mean, but it’s not unheard of). The second is to invoke the script as part of a deployment or as a postflight script. You can force the system to shut down by running the shutdown command with the -h option specified as now as you can see here:
shutdown -h now
You can also restart a system by running the shutdown command with a -r option and the same now as before, as follows:
shutdown -r now
You can also replace the now with a specific time and date to set the system to shut down and/or restart in the future. But these don’t log the system out and leave you at a login window without first actually rebooting a computer we might not be ready to reboot (or we might not want to reboot/shut down). One way to get close is to use the options we referenced yesterday to invoke fast user switching
. But it’s one of those things that there’s no real framework for at this time. Again, there is close. You can use AppleScript, but it’s going to ask the user to log out
tell application “System Events” to log out
You can then send this through the shell using osascript:
osascript ‘tell application “System Events” to log out’
Once the screen comes up you could send a subsequent command to click on the Log Out button. However, this can be cancelled by a screen that can’t be closed or a file that needs to be saved (which is by design given that you don’t typically want to risk loosing work) or because an application is unresponsive. We could quit all the open applications using a loop, such as the one I use in the hide all apps application, but then we would need to determine logic on how to answer certain questions that could come up. It was suggested to use killall with the -u option to kill all processes for our current user:
killall -u cedge
But that introduced a little loginwindow instability. So maybe we could just kill loginwindow for the user. To do so we first need to get the pid for loginwindow:
ps -Axjc | grep loginwindow | cut -c 13-16
Once we have that, we can feed it to kill:
kill -9 `ps -Axjc | grep loginwindow | cut -c 13-16`
Which can then be sent through AppleScript as:
tell application “Finder”
do shell script “kill -9 `ps -Axjc | grep loginwindow | cut -c 13-16`“
Now that it can be done through bash and AppleScript you have a variety of ways to run it against a client system. It’s not as clean as I’d like (throws a few errors in the logs and seems like a hack), so perhaps there’s a better way…
krypted May 4th, 2010
Posted In: Mac OS X, Mac Security, Mass Deployment
kill, loginwindow, Mac OS X, script, script to log out current user
You can capture screenshots from the command line using the screencapture command. Basically just typing screencapture followed by the path and name of the file to be created will result in a capture of the entire screen. You can also use -c to capture to the clipboard instead of to a file (or Command-Shift-3 if you’re in the GUI). By default screencapture does not get the mouse. You can add the mouse location and pointer to your screenshot using the -C option in your command.
Because you have multiple monitors in many cases you may only want to capture a single monitor. You can specify that using the -m option. If you’re looking to email screen shots (yes, even automatically) you can use the -M option to open a message and paste the screenshot into the message. It would require an osascript to do then send that mail programatically or you could use a screencapture command in an automator workflow.
If you’re using screencapture as an anti-theft or spying on the thief once stolen mechanism of some sort you can use the -x option to suppress the sounds that it will make. Otherwise the thief might get freaked out when they hear a photo sound in the background repeatedly. You can email files created or ftp them to a server if the computer has connectivity using shell scripts.
The binary can also be copied to a jump drive and used for other purposes – which is how I grab the screenshots for the startup sequence and/or the login window of Mac OS X for books.
Overall, the screen shot functionality of Mac OS X is one of the best in the IT industry, partially because so much can be done programatically.
krypted March 25th, 2008
Posted In: Mac OS X
boot process, booted to disk, jump drive, loginwindow, Mac OS X, screen shot, screencapture