Tag Archives: profiles

Mac OS X Mac OS X Server Mac Security Mass Deployment

Manage Profiles From The Command Line In OS X 10.9

You can export profiles from Apple Configurator or Profile Manager (or some of the 3rd party MDM tools). You can then install profiles by just opening them and installing. Once profiles are installed on a Mac, mdmclient, a binary located in /usr/libexec will process changes such as wiping a system that has been FileVaulted (note you need to FileVault if you want to wipe an OS X Lion client computer). /System/Library/LaunchDaemons and /System/Library/LaunchAgents has a mdmclient daemon and agent respectively that start it up automatically.

NEWScreen-Shot-2013-10-07-at-3.50.40-PMTo script profile deployment, administrators can add and remove configuration profiles using the new /usr/bin/profiles command. To see all profiles, aggregated, use the profiles command with just the -P option:

/usr/bin/profiles -P

As with managed preferences (and piggy backing on managed preferences for that matter), configuration profiles can be assigned to users or computers. To see just user profiles, use the -L option:

/usr/bin/profiles -L

You can remove all profiles using -D:

/usr/bin/profiles -D

The -I option installs profiles and the -R removes profiles. Use -p to indicate the profile is from a server or -F to indicate it’s source is a file. To remove a profile:

/usr/bin/profiles -R -F /tmp/HawkeyesTrickshot.mobileconfig

To remove one from a server:

/usr/bin/profiles -R -p com.WestCoastAvengers.HawkeyesTrickshot

The following installs HawkeyesTrickshot.mobileconfig from /tmp:

/usr/bin/profiles -I -F /tmp/HawkeyesTrickshot.mobileconfig

If created in Profile Manager:

/usr/bin/profiles -I -p com.WestCoastAvengers.HawkeyesTrickshot

There is a nifty new feature in the profiles command in Mavericks, where you can configure profiles to install at the next boot, rather than immediately. Use the -s to define a startup profile and take note that if it fails, the profile will attempt to install at each subsequent reboot until installed. To use the command, simply add a -s then the -F for the profile and the -f to automatically confirm, as follows (and I like to throw in a -v usually for good measure):

profiles -s -F /Profiles/SuperAwesome.mobileconfig -f -v

And that’s it. Nice and easy and you now have profiles that only activate when a computer is started up. As of OS X Mavericks, the dscl command has extensions for dealing with profiles as well. These include the available MCX Profile Extensions:

-profileimport -profiledelete -profilelist [optArgs]

To list all profiles from an Open Directory object, use 
-profilelist. To run, follow the dscl command with -u to specify a user, -P to specify the password for the user, then the IP address of the OD server (or name of the AD object), then the profilelist verb, then the relative path. Assuming a username of diradmin for the directory, a password of moonknight and then cedge user:

dscl -u diradmin -P moonknight profilelist /LDAPv3/

To delete that information for the given user, swap the profilelist extension with profiledelete:
dscl -u diradmin -P apple profilelist /LDAPv3/
If you would rather export all information to a directory called ProfileExports on the root of the drive:

dscl -u diradmin -P moonknight profileexport . all -o /ProfileExports

Mac OS X Mac OS X Server Mac Security Mass Deployment Xsan

New Startup Profiles In OS X 10.9 Mavericks Profiles Command

I wrote an article on using the profiles command awhile back, available at http://krypted.com/mac-security/profile-manager-and-profiles/. There is a nifty new feature in the profiles command in Mavericks, where you can configure profiles to install at the next boot, rather than immediately. Use the -s to define a startup profile and take note that if it fails, the profile will attempt to install at each subsequent reboot until installed. To use the command, simply add a -s then the -F for the profile and the -f to automatically confirm, as follows (and I like to throw in a -v usually for good measure):

profiles -s -F /Profiles/SuperAwesome.mobileconfig -f -v

And that’s it. Nice and easy and you now have profiles that only activate when a computer is started up.


Restricting Access To Sites On iOS Devices

One of the more common requests we get for iOS devices is to restrict what sites on the web that a device can access. This can be done in a number of ways. The best, in my experience, has been using a proxy.

In Apple Configurator 1.2 there’s an option for a Global HTTP Proxy for Supervised devices. This allows you to have a proxy for HTTP traffic that is persistent across apps.

Each Wi-Fi network that you push to devices also has the ability to have a proxy associated as well. This is supported by pretty much every MDM solution, with screens similar to the following, which is how you do it in Apple Configurator.

The above has I am all about layered defense, though. Or if a proxy is not an option then having an alternative. Another way to disable access to certain sites is to outright disable Safari and use another browser. This can be done with most MDM solutions as well as using a profile. To see what this would look like using Apple Configurator, see the below profile.

Now, once Safari has been disabled, you then need to provide a different browser. There are a number of third party browsers available on the App Store. Some provide enhanced features such as Flash integration while others remove features or restrict site access.

In this example we’re using the K9 Web Protection Browser. This browser is going to just block sites based on what the K9 folks deem appropriate. Other browsers of this type include X3watch, Mobicip (which can be centrally managed and has a ton of pretty awesome features), bSecure (which ties in with their online offerings for reporting, etc) and others.

While this type of thing isn’t likely to be implemented at a lot of companies, it is common in education environments and even on kiosk types of devices. There are a number of reasons I’m a strong proponent of a layered approach to policy management for iOS. By leveraging proxies, application restrictions, reporting and when possible Mobile Device Management, it becomes very possible to control the user experience to an iOS device in such a way that you can limit access to web sites matching a certain criteria.

Mac OS X Mac OS X Server Mac Security Mass Deployment

Automating Profile Manager Enrollment Through DeployStudio

When planning to migrate from managed preferences to profiles, one of the important aspects to consider is automated enrollment. One of the more important aspects of automating a traditional managed preferences environment is to automate the binding to directory services. You do not bind to Profile Manager; however, you do enroll devices. Much like binding computers to Lion Server’s Open Directory (by default), certificates and host names are important aspects of the enrollment process.

Much as with local managed preferences, management via profiles can be done through the command line and without any involvement from a centralized source. I had written an article awhile back on using profiles from the command line.

You can also instead enroll devices into Profile Manager. Previously, I had looked at configuring Profile Manager. Manual enrollment in Profile Manager is the same as enrollment from iOS. But instead of using Apple Configurator to automate enrollment, you’ll use your existing imaging solution for automated enrollment of Mac OS X based clients. Therefore, we’ll use DeployStudio as an example for automating enrollment at imaging time.

To get started, you’ll need a functional DeployStudio configuration. You’ll also need a functional Profile Manager configuration. From within Profile Manager, click on the plus sign (“+”) in the lower left corner of DeployStudio and click on Enrollment Profile. Then click on the New Enrollment Profile entry that was created and click on the Download button to download the profile onto the server (when it attempts to install, simply click cancel to cache it to your ~/Downloads directory).

Click in the drop-down menu in the upper right hand corner of the screen and then click on Download Trust Profile. This will download the Trust Profile for the MDM solution to the client (when it attempts to install, simply click cancel to cache it to your ~/Downloads directory).

Next, drag the cached profiles into the ConfigurationProfiles directory of the DeployStudio repository. Now that you have the profiles that will be required for automated enrollment, open DeployStudio Admin (if it was open before, close it and then re-open it once you have copied the profiles to the DeployStudio repository). From within DeployStudio, we will create a new workflow, here called “Deploy Lion with Enrollment”. We will then choose to restore a target volume and automate the task.

Next, click on the plus sign (“+”) to add a new workflow item, sliding the task selection screen out automatically.

Next, drag the Automatic Enrollment Task item into the workflow. Once present, choose Previous task target from the Target Volume field. Next, choose the enrollment profile in the Enrollment profile field. Also choose the Trust profile that you just downloaded from the Trust profile field. Finally, check the Automate box and save your workflow.

Finally, we’ll add a Configure task to set the hostname (note that your workflows may already be far more flushed out than mine here. Click on Save and then test the workflow.

Once booted, if you are automatically enrolled then the process was a success. You should be able to see the device in Profile Manager.

Mac OS X Mac OS X Server Mac Security Mass Deployment

What Mac App Store ID is Bessie Using in Lion?

Users can log into the Mac App Store using their personal Apple ID. Users can also log into the Mac App Store with an AppleID that is linked to a company owned email address instead. The AppleID itself should be a company owned asset so that if/when users leave the organization, the organizations till owns the software that they purchase. Whether purchasing software through a volume purchasing program or directly, those dollars are wasted if the user is purchasing software through a personal AppleID. Therefore, you need a way to look at what AppleID that a user is using and to make sure that the organization has a way to link that account information back to the host the user is using and/or change the information if the user were to move to a different system.

In order to find the AppleID that a user is using, look into com.apple.storeagent. As the user, simply run defaults and read that domain along with the AppleID key:

defaults read com.apple.storeagent AppleID

When you run this, you see the Email address of that user. The DSPersonID is then listed here as well, as well as any other accounts (by DSPersonID) that have AppleIDs attached to the host. That DSPersonID is used throughout iCloud, actually. If you have installed iCloud through the system preference pane you will end up with Back to My Mac keys and other keychain assets that reference back to the keychains.

Now, to defaults write data into this domain isn’t as simple as you might think. The problem is that you would need to know the AppleID’s DSPersonID. You would also need to deploy the keychain items for the AppleID application password and the certificate for the AppleID, which has a com.apple.idms.appleid.prd.CN, or common name.

iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment

Dealing With Profile Manager Conflicts in Lion

Changing OS X Settings for Profiles bound to clients results in Managed Client changes (mcxread shows them) and inserts the info into Managed Client in this order:

  1. User
  2. Computer
  3. Computer Group
  4. Everyone
  5. User Group

The data in the managed client attributes is replaced completely and not per-key.

Installing profiles from the command line provides more information as to what is going on behind the scenes. Having said this, in some cases I can get a Provisioning Profile Validation: failed to read CMS (-25257) error when attempting to install the same profile a second time. In other cases it just fails if I try to run verbosely (in those cases it doesn’t ever install at all). For example, if I run a user group profile twice, the command completes. You should be able to use -CP or L to validate whether it ran and to validate whether it was already run. Keeping a good naming convention on the ProfileIdentifier should keep from too many weird conflicts and you can always read MCX to see if it got pushed out, since it’s all just MCX anyway.

Troubleshooting conflicts can be a bit tricky. The -v operator should return an exit code that indicates that there is overlapping namespace in the Organization but can cause a null return (in fact -v fails with some combinations outright when it shouldn’t). The “profiles -L” command does show that the profile is installed, so you could check that before running, escaping out the generated ID and .alacarte. Running with a -C shows the profiles for the computer, -P for everyone (btw, running profiles -CPL returns inconsistent results so I’ve been scripting them to run separately). Installing profiles from the command line seems to usually require a log out and log in in order to see the changes. killall dock or killall finder don’t result in the changes, unless they’re coming from MDM, at which point they are instant. Installing profiles from the GUI usually means instant changes though.

The above information includes installing profiles. When you have policies being overlaid from Exchange, the most restrictive settings will win and be read granularly. For example, if you have a passcode minimum in a profile and a complexity requirement in Exchange then both would be applied to clients.

iPhone Mac OS X Server Mac Security Mass Deployment

Lion Server: Using Profile Manager's Debug Mode

I’ve seen a lot of traffic about people troubleshooting problems with Mac OS X Server’s new Profile Manager service. One of the more useful things in troubleshooting anything (including Profile Manager in Lion) is the debug mode. It’s easy to turn on, just run the following command from any Lion Server with Profile Manager installed:

sudo defaults write /Library/Preferences/com.apple.ProfileManager debugMode 3

You will then get more information in the logs and be well armed to troubleshoot issues that arise in Mac OS X Server 10.7′s Profile Manager.

Mac OS X Server Windows XP

Change H: on SMB PDCs

Samba can be a PDC, allowing Windows clients to join a single line domain name and then access domain resources (such as roaming profiles) as though the domain were Windows NT-based. When you set this up the default behavior for Mac OS X Server based domains is to create a drive mapping for H: to the users profile path (as specified in the homeDirectory attribute) on the server. H: is kinda’ low for some computers with a lot of drives and it can also conflict with other drive mappings you may choose to use. Therefore you may find that in some cases you need to change the H:.

To do change the drive letter that the logon drive uses, look to the /var/db/smb.conf file. Here, you’ll notice a logon drive variable which is set (funny enough) to H:. Specify any letter of the alphabet that you’d like it to use (preferably higher than H:) and then save the changes to the file and restart the service. Now you should see a new drive letter assigned at your next login event. You can also change a number of other variables in these files, so it’s recommended to back the file up before making any changes.

Mac OS X Mac Security

Sandboxed Out of My Own Boxen

Playing with Sandbox can be tricky. The other day my own box (luckily one not FDE’d) started to kernel panic and I’d just activated about 12 sandbox profiles. To fix, I booted to single user mode (Command-S), mounted the drive (using the command mount -uw /). Then I did a find for all *.sb files (assuming you use the sb extension for your sandbox files) touched that day, deactivated them and rebooted. Oddly, still no dice. Did I miss one? Next, just to verify it was a sandbox issue, I went back into single user mode, remounted the volume and used this command to move the Seatbelt kernel extension to a temp directory.
mv /System/Library/Extensions/Seatbelt.kext /Temp/Seatbelt.kext

That fixed the problem. Now I’m really curious. Put it back, verify permissions, still busted. Next, boot without it and try to manually kextload it. Bam, still busted. So after about an hour of trying to figure it out, I grabbed a Seatbelt.kext file from another host and popped it into the /System/Library/Extensions directory. Viola, issue resolved. Not sure how/why, but my Seatbelt.kext was corrupt. No logs of disk/file corruption. I can’t imagine a sandbox profile could corrupt the kernel extension, but it seems like too much an anomaly that I was working on sandbox profiles when it got corrupted…

Mac OS X Server

Mac OS X Server: Disable Roaming Profiles Globally

To disable roaming profiles you can just edit the smb.conf, adding a blank path to the logon path setting disables roaming profiles.  So just add this line to your global /etc/smb.conf settings:

logon path =