Hey look, there’s a new category on the Jamf Marketplace, available at https://marketplace.jamf.com/apps/#category=AppConfig,
selecting the AppConfig category. The new AppConfig category gives administrators of any MDM that supports AppConfig access to a set of apps that support AppConfig. If you have an app that isn’t listed here, feel free to let me know.
What does this mean? Well, AppConfig is a way of sending data into an app. App config allows a customer to deploy settings into applications on iOS devices in much the same way that settings can be sent into a Mac app via the defaults command. This means an end user could get an app installed on their device from the iOS App Store, a custom app, or a B2B app and that app would have any settings the user might need to connect to servers or configure the experience.
So what is Managed App Config? At it’s most basic, you identify a label and a value in XML and send it to an iOS device that’s running iOS 7 or later (e.g. via Jamf 9 and up). The vendor who makes the app has to basically define what those settings are. Which brings up an interesting problem never fully addressed with defaults domains: standardization and ease-of-use (although MCX was close). AppConfig.org
is a consortium of MDM vendors and software vendors that maintain the emerging AppConfig standards around Managed App Config (within the confines of what Apple gives vendors) and then makes a feed of settings for apps that conform to those standards. Jamf is a founding member of Appconfig.org, along with MobileIron and AirWatch. Examples of what you could put into the AppConfig.org feed include
- Enabling certain features of apps
- Server URLs
- Logos (if they’re pulled dynamically)
- Text labels
- Language packs
To see a list of apps that are available, check out http://www.appconfig.org.
Managed App Config options are set by vendors at compile time within the code and then the XML sent with the app is parsed by the app at installation time. If you’re a software vendor who wants to get started with AppConfig, check out the Spec Creator from Jamf Research or get in touch with the developer relations team from any MDM vendor.
If you’re a customer of an app and would like to leverage Managed App Config and your vendor isn’t listed on the appconfig.org site, get in touch with them, as this is the future of app management and chances are that you won’t be the only organization looking to unlock this type of feature.
Let’s look at how this actually works. The Managed App Config options per supported app are available on a feed. The feed is available at http://d2e3kgnhdeg083.cloudfront.net. Here, as follows, you’ll see a list of all of the apps supported.
You can then copy the path for an app, such as com.adobe.Adobe-Reaser/1/appconfig.xml and append it to the end of the URL to get the feed for that specific app. You can test this using http://d2e3kgnhdeg083.cloudfront.net/com.adobe.Adobe-Reader/1/appconfig.xml to see output as follows.
Here, note that most of these fields are key value pairs defined by Adobe (in this example at least). You can enable or disable features of Adobe Reader using these keys. The same is true with a tool like Box that might want a more granular collection of settings than a feature like Managed Open In.
Once you have the XML, you can then copy it to the clipboard and paste it into the App Configuration tab of an app, as follows.
Finally, Apple has sample code available at https://developer.apple.com/library/content/samplecode/sc2279/Introduction/Intro.html.
krypted March 13th, 2018
Posted In: iPhone, JAMF
appconfig.org, Apple, automated configuration, configure apps, defaults, ios, managed app config, xml
I recently had an issue where QuickLook was crashing every time I clicked on certain file types. I thought they were unsupported by QuickLook. But it turns out that they were animated and trying to start while the QuickLook animation was starting. So disable the QuickLook animation and the files appeared as intended. To do so, write a key called QLPanelAnimationDuration into the global defaults database, with a -float value of 0, as follows:
defaults write -g QLPanelAnimationDuration -float 0
krypted April 16th, 2017
Posted In: Mac OS X
defaults, disable QUickLook animation, macos
When you’re regression testing, you frequently just don’t want any delays for scripts unless you intentionally sleep your scripts. By default Safari has an internal delay that I’d totally forgotten about. So if your GUI scripts (yes, I know, yuck) are taking too long to run, check this out and see if it helps:
defaults write com.apple.Safari WebKitInitialTimedLayoutDelay 0
With a script I was recently working on, this made the thing take about an hour less. Might help for your stuffs, might not.
If not, to undo:
defaults delete com.apple.Safari WebKitInitialTimedLayoutDelay
krypted February 1st, 2017
Posted In: Mac OS X Server, Mac Security
Apple, bash, curl, defaults, MAC, safari delay, scripting, timeout, webkit
The directory services options in macOS has quietly been going through some slow changes over the past couple of years. Many of the tools we use to manage accounts look similar on the outside but sometimes work a little differently under the hood. Account information is still stored in the /var/db/dslocal/nodes directory. Here, the local directory service pulls files from within directories recursively when accountsd loads. You can still create a second instance of the local directory service by copying the Default directory. For example, here we’ll copy the Default directory node to a directory node called NEW:
sudo cp -prnv /var/db/dslocal/nodes/Default /var/db/dslocal/nodes/NEW
If you killall accountsd then wait (this is slower than doing a killall of DirectoryService was), you’ll then see and be able to use this new directory node:
sudo killall accountsd
This is one way to go about forklifting large collections of accounts from one system to another. The dsmemberutil account can still be used to obtain certain information from accounts. For example, you can check group membership by feeding in a uid with the -u option (here using the uid of 509) and a gid with the -g (here a gid of 10) option:
dsmemberutil checkmembership -u 509 -g 10
Each account still has a uuid. This can be obtained with -u for a user or -g for a group (ids):
dsmemberutil getuuid -u 509
And, you can use dsmemberutil to flush the directory services cache resolver, using the flushcache verb:
The files that comprise accounts can also be viewed and changed manually. Here, we’re going to just look at an account called charles:
sudo defaults read /var/db/dslocal/nodes/Default/users/charles.plist
If we used a tool like defaults, plistbuddy or plutil to manually augment one of these accounts, we’d also need to kill accountsd as we did earlier.
krypted October 3rd, 2016
Posted In: Mac OS X, Mac OS X Server
10.12, accountsd, Apple, defaults, MAC, macOS sierra, Open Directory, plist
When I plug my iPad in, Photos opens. I want it to stop opening when I plug it in. To make it stop, write a disableHotPlug key into com.apple.ImageCapture as true:
defaults -currentHost write com.apple.ImageCapture disableHotPlug -bool true
To enable Photos opening when you plug in a device again, just delete the disableHotPlug key:
defaults -currentHost delete com.apple.ImageCapture disableHotPlug
krypted February 7th, 2016
Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security
defaults, disableHotPlug, iPad, open photos
I’ve written a couple of articles about the Caching service in OS X Server 5 for El Capitan. As of OS X Server 5, the Caching service now caches local copies on the computer running the Caching service of iCloud content. This allows you to cache content once and then have it accessed by multiple devices faster. I’m torn on this option. On the one hand, I love the fact that I can cache things and on the other hand I find it frightening that a random user can cache things I might not want them to cache on behalf of another user. I know, I know, they’re encrypted with a device key. But when you have data on disk, it can always be decrypted. I almost feel like there should be a plist on machines that whitelists allowed caching servers. Maybe I should make a feature request on that.
Either way, as it stands now, I might be disabling this option in larger offices. To do so, I can write an AllowPersonalCaching key into the Config.plist file at /Library/Server/Caching/Config/. The most graceful way to do this is using the serveradmin command, followed by the settings verb and then caching:AllowPersonalCaching option, setting that equals no, as follows:
sudo serveradmin settings caching:AllowPersonalCaching = no
To turn it back on:
sudo serveradmin settings caching:AllowPersonalCaching = yes
This can also be done by dropping a Config.plist file into the correct location for new server installations. I’ll have an article out shortly on doing so, as you’d want to normalize a few options in the file before deploying en masse (e.g. if you have a large contingent of Caching servers to manage.
krypted October 16th, 2015
Posted In: Mac OS X Server
allowpersonalcaching, automate caching server, caching service, defaults, heated cache, OS X Server, serveradmin, setup
The tools to automate OS X firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.
Some tricks I’ve picked up with the Mac Firewall/alf scripting:
- Configure the firewall fully before turning it on (especially if you’re doing so through something like Casper, FileWave, Munki, or Absolute Manage where you might kick yourself out of your session otherwise).
- Whatever you do, you can always reset things back to defaults by removing the com.apple.alf.plist file from /Library/Preferences replacing it with the default plist from /usr/libexec/ApplicationFirewall/com.apple.alf.plist.
- Configure global settings, then per-application settings, then enable the firewall. If a remote system, do ;wait; and then enable the first time to make sure everything works before enabling the firewall for good.
- To debug, use the following command: “/usr/libexec/ApplicationFirewall/socketfilterfw -d”
In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:
/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on
To see if block all is enabled:
The output would be as follows, if successful:
Firewall is set to block all non-essential incoming connections
A couple of global options that can be set. Stealth Mode:
/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on
To check if stealth mode is enabled:
/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on
You can also control the verbosity of logs, using throttled, brief or detail. For example, if you need to troubleshoot some issues, you might set the logging to detail using the following command:
/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingopt: detail
To start the firewall:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on
While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:
/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on
To check if you allow signed apps:
This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:
To check if an app is blocked:
/usr/libexec/ApplicationFirewall/socketfilterfw –getappblocked /Applications/MyApp.app/Contents/MacOS/myapp
This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):
/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/MyApp.app/Contents/MacOS/myapp
Once signed, verify the signature:
/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myapp
Once signed, trust the application using the –add option:
/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myapp
To see a list of trusted applications. You can do so by using the -l option as follows (the output is pretty ugly and needs to be parsed better):
If, in the course of your testing, you determine the firewall just isn’t for you, disable it:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off
To sanity check whether it’s started:
Or to manually stop it using launchctl (should start again with a reboot):
launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist
If you disable the firewalll using launchctl, you may need to restart services for them to work again.
krypted July 16th, 2015
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
applicationlayerfirewall, configure, defaults, firewall, global state, MAC, mac firewall, socketfilterfw, start, stop
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
Here’s the thing: I’m not very good with computers. So to keep me from hurting myself too badly, I need the simplest interface available that allows me to run multiple applications. But most of the command keys shouldn’t work in this interface and I should only have Finder, file and Help menus.
Luckily for my poor MacBook Airs, Apple thought of people like me when they wrote the Finder and invented something called Simple Finder which makes OS X even simpler than it is by default to use. To enable Simple Finder, just go to Parental controls, enable controls for a user and then check the box for Simple Finder. Or, if you have an entire population of users like me, who simply can’t be trusted with a full operating environment, you can send the InterfaceLevel key with the contents of simple (easy to remember for those of us who resemble said key) to com.apple.finder and restart our friendly neighborhood Finder:
defaults write com.apple.finder InterfaceLevel simple; killall Finder
Come to think of it, maybe I’m not so awful. Let’s say I want to turn that whole Simple Finder thing right back off. Well, all we have to do is delete that key we created and then restart the Finder:
defaults delete com.apple.finder InterfaceLevel; killall Finder
Actually, I am terrible with these things. So much so that it’s not appropriate for me to use a computer. Therefore, just take it away. I’ll be better off using that Samsung with Windows 8 for awhile. At least there, I won’t be able to get any of my apps open or find any of the administrative tools that could damage the computer!
krypted May 17th, 2013
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
com.apple.finder, defaults, DELETE, enable simple finder, Finder, interfacelevel, killall, parental controls, script, windows 8
Next Page »
For many environments, securing OS X is basically trying to make the computer act more like an iOS device. Some of the easier tasks involve disabling access to certain apps, sandboxing and controlling access to certain features. One of the steps en route to building an iOS-esque environment in OS X is to disable that Go to Folder… option. To do so, set the ProhibitGoToFolder key as true in com.apple.finder:
defaults write com.apple.finder ProhibitGoToFolder -bool true
Then reboot, or kill the Finder:
To undo, set the ProhibitGoToFolder as false:
defaults write com.apple.finder ProhibitGoToFolder -bool false
krypted November 11th, 2012
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
boolean, com.apple.finder, defaults, killall, prohibitgotofolder, true, write