The Directory Utility application has moved to /System/Library/CoreServices/Applications. Once open, you can use it to bind to directory services, change search policies and even dink around with NIS if you still rock the flannel with your ripped up jeans. But, the thing that I tend to do in Directory Utility the most is look at user and group attributes. To do so, open Directory Utility and click on the Directory Editor tab. In the bar directly below, you’ll see Viewing and In Node. The Viewing option is what type of object you’re going to look at. The In Node option shows the directory domain you’re viewing. Below, we show the local users in /Local/Default.
Click on a user and you will see all of the attributes that exist for that user. Not all users are created equal when it comes to attributes, so if you’re looking for a specific attribute then you can go through different users to see what they have.
Change the In Node option to /LDAPV3/127.0.0.1 (or the name of your directory service such as your Active Directory) to see all the attributes available there. You can then note the names and use them in scripts, etc.
You can also access this information via dscl, but I’ve covered that enough times in the past to be bored with myself for even making the reference. Enjoy.
krypted November 6th, 2014
Previously, we looked at setting up an Open Directory Master in OS X Server. An Open Directory Replica keeps a copy of the Open Directory database available for users even when the Master goes offline. But it can also take a part of the load from the Open Directory Master and when using the new Locales feature, balance network traffic. To get started with an Open Directory Replica, first enable SSH, now disabled by default.
Next, use the changeip to check the host name. While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In OS X Server, I’ve seen each find things that other misses. Additionally, in Yosemite and above, OS X Server now requires to be able to lookup whatever the hostname is set to in order to actually promote either to a replica or a master. To use changeip to verify the hostname is set appropriately:
sudo changeip -checkhostname
The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.
Primary address = 10.0.0.1
Current HostName = odr.krypted.com
DNS HostName = krypted.com
The names match. There is nothing to change.
dirserv:success = “success”
Provided everything is cool with the hostname, use the slapconfig command to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of 172.16.2.23:
/usr/sbin/slapconfig -preflightreplica 172.16.2.23 diradmin
Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica.
When prompted, enter the parent Open Directory server’s host name (likely the name of the Open Directory Master), directory admin user name (the diradmin or custom username provided when Open Directory was configured), and then the directory admin password.
Then click on the Next button again to setup the services.
At the Confirm settings screen, click on the Set Up button and the replica is completed provided there are no issues with the configuration. Check Server app on both the Replica and the Master and verify that the server is displayed under the Master.
Once you’ve created your first replica, you can then start to define replica trees, where each replica looks at one above it, which then looks at another. I’ll do another article later on replica trees.
Note: If there are any problems during promotion, I start over every time using slapconfig along with the -destroyldapserver option to nuke everything in OD:
sudo slapconfig -destroyldapserver
Use the logs to help if you’re having replica creation problems. These can be added using the -enableslapdlog option:
sudo slapconfig -enableslapdlog
You can use the -addreplica option to add replicas manually while running tail on the slapd logs:
sudo tail -f /var/log/slapd.log
Once the replica has been created, you can add more and more until you exceed 32. At that point, you have a fairly large Open Directory environment and you go to add the 33rd replica but you get a funny error that dserr doesn’t have listed. The reason is likely that a single Open Directory Master can only have 32 replicas – and the fact that you’ve made it that far means you get a cookie. Cookie or no, you can have 32 replicas on each replica (thus having a replica tree), ergo allowing for a total of 1,024 replicas and a master. So rather than bind that 33rd replica to a master, move to a replica tree model, trying to offload replicas in as geographically friendly a fashion as possible (thus reducing slap traffic on your WAN links) by repositioning replicas per site. Similar to how Active Directory infrastructures often have a global catalog at each site, if you’ve got a large number of Open Directory Replicas then you should likely try and limit the number that connects back to each master per site to 1.
Assuming that each replica can sustain a good 350 clients on a bad day (and we always plan for bad days), even the largest pure Mac OS X deployments will have plenty of LDAP servers to authenticate to. However, you’re likely going to have issues with clients being able to tell which Open Directory server is the most appropriate to authenticate through. Therefore, cn=config will need to be customized per group that leverages each replica, or divert rules used with ipfw to act as a traffic cop. Overall, the replica trees seem to be working fairly well in Snow Leopard, netting a fairly scalable infrastructure for providing LDAP services.
You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd.
The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.
krypted October 16th, 2014
Mavericks has an application called Contacts. Mavericks Server (OS X Server 3) has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. However, there is a layer of Postgres-based obfuscation between the Contacts service and CalDAV. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.
I know I’ve said this about other services in OS X Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the Contacts entry in the SERVICES section of Server app.
To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.
The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click the Accounts menu and then click on Add Accounts.
At the “Add a CardDAV Account” screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.
When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.
Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.
Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.
At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:
sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase
Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.
The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:
sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443
The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:
sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"
The service is then stopped with the serveradmin command:
sudo serveradmin stop addressbook
And started with the serveradmin command:
sudo serveradmin start addressbook
And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:
sudo serveradmin fullstatus addressbook
The output of which should be as follows:
addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1
If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:
sudo serveradmin settings calendar
By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:
sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001
And then let’s see what it is in addressbook:
serveradmin settings addressbook:MaxAllowedInstances
krypted October 23rd, 2013
Posted In: Mac OS X Server
When you’re configuring a Mac to leverage an existing Windows infrastructure, having the clocks in sync is an important task. Luckily, Windows Server has been able to act as an NTP server for a long time. In this article, we’ll look at configuring Server 2008 R2 to be an NTP server for Mac and Linux clients.
Note: Before you get started, or any time you’re hacking around in the registry, make sure to do a backup of your registry/SystemState!
To enable NTP on Windows Server, open your favorite registry editor and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer. From here, enter a key called Enabled as a dword with a value of 00000001.
The NTP Server should look upstream at another NTP host. To configure this, go ahead and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient and create Enabled as a dword with a value of 0000001 and SpecialPollInterval with a value of 300:
NTP would then need a source, so let’s go ahead and create that in the registry as well. To set that up, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters and then setup the Type key to contain NTP, the Period key to contain freq and the NtpServer key to obtain the IP address of the server followed by ,0x1, as follows (assuming an IP of 10.0.0.8 for the upstream NTP server:
The w32tm service doesn’t start unless your system is on a domain (and should be restarted if the system is already running as a DC). To starts the service automatically (if needed), use the sc command:
sc triggerinfo w32time start/networkon stop/networkoff
Windows systems can also use an NTP server. To configure the NTP client, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient and create Enabled as a dword with a value of 0000001 and SpecialPollInterval with a value of 300:
NTP would then need a source, so let’s go ahead and create that in the registry as well. To set that up, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters and then setup the Type key to contain NTP, the Period key to contain freq and the NtpServer key to obtain the IP address of the server followed by ,0x1, as follows (assuming an IP of 10.0.0.8 for the upstream NTP server:
Finally, you can invoke the w32tm service directly to query peers and verify that no skew has occurred with the clocks:
w32tm /query /peers
Viola, you’ve now achieved what could be done using a checkbox on an OS X Server. Hope you’ve enjoyed noodling around in the registry!
krypted January 3rd, 2013
There are four ways to create users in Mountain Lion Server. The first is using the Server app, the second is using Workgroup Manager, the third is using the Users & Groups System Preference pane and the fourth is using the command line. In this article we will look at creating users in the Server app.
To do so, open the Server app and connect to your server. Then click on the Users entry in the ACCOUNTS list. The list of users is displayed, based on the directory domain(s) being browsed. A directory domain is a repository of account data, which can include local users, local network users and users in a shared directory service such as Open Directory and Active Directory.
The drop-down list allows you to see objects that are stored locally as well as on a shared directory server. Therefore, clicking All Users will show all of the accounts accessible by the system. Click on the plus sign to create a new account. At this point, if the server has been promoted to an Open Directory Master, the account will be a local network account, with no way of choosing a different location to store the account in the Server app.
When prompted, provide the following information about the new user:
Note: Optionally, you can also drag an image onto the image shown in the New User screen if you’d like the user to have an avatar.
Once the account details are as you would like, click on the Done button. The account will then be displayed in the list of available accounts. You can still create local accounts but must do so in the Users & Groups System Preference pane, through Workgroup Manager or through the command line. If the server has not been made an Open Directory server then you would be creating local users through the Server app.
Once the account is created, highlight it and click on the cog wheel icon below the list of accounts. Here, you have the option to edit the account you just created, edit their access to services hosted on the server, configure email information and change their password.
Click Edit User. Here, you have two new features. You can add the user to groups and use the checkbox for “log in” to disable the account.
Click Cancel and then using the cog wheel menu again, click on Edit Access to Services. Here, uncheck each service that the user should not have access to. If the service isn’t running then it’s not a big deal. You can highlight multiple accounts concurrently and then use this option to disable services for users en masse.
krypted September 1st, 2012
Tags: Create Users, directory domain, email address, LDAP, local network user, Mac OS X Server, mac os x server 10.8, mountain lion, mountain lion server, Open Directory, sacls, service restrictions, switching, user management
Open Directory has never been so easy to setup for a basic environment as it is in OS X Mountain Lion Server. It’s also never been so annoyingly simple to use that to do anything cool requires a bunch of command line foo. No offense to the developers, but this whole idea that the screens that were being continually refined for a decade just need to be thrown out and started fresh seems to have led to a few babies thrown out along with them. Not often as I’m kinda’ digging most of the new config screens in OS X Mountain Lion Server, but with Open Directory, it’s just too easy. Features mean buttons. Buttons make things a tad bit more complicated to use than an ON/OFF switch…
Anyway, rant over. Moving on. As with almost any previous version of OS X Server and Open Directory, once you’ve installed the Server app, run the changeip command along with the -checkhostname option to verify that the IP, DNS and hostname match. If (and only if as it will fail if you try anyway) you get an indication that “The names match. There is nothing to change.” then you can move on to setting up the service.
Note: There’s this thing called the Next Steps Drawer. No matter what it says, I still won’t proceed until changeip checks clean.
To set up the Open Directory Master, open the Server app and click on the Open Directory service. From here, click on the ON button.
For the purposes of this example, we’re setting up an entirely new Open Directory environment. At the “Configure Network Users and Groups” screen, click on “Create a new Open Directory Domain” and click on the Next button.
At the Directory Administrator screen, enter a username and password for the directory administrator account. The default account is sufficient, although it’s never a bad idea to use something a bit less generic.
Once you’ve entered the username and password, click on the Next button. Then we’re going to configure the SSL information.
At the Organization Information screen, enter a name for the organization in the Organization Name field and an Email Address to be used in the SSL certificate in the Admin Email Address field. Click on Next.
At the Confirm Settings screen, make sure these very few settings are OK with you and then click on the Set Up button to let slapconfig (the command that runs the OD setup in the background, kinda’ like a cooler dcpromo) do its thing. When the Open Directory master has been configured, there’s no need to reboot or anything, the indicator light for the Open Directory service should appear. If the promotion fails then look to the preflight options I wrote up awhile back.
Once the promotion is complete, you’ll also see the server listed in the Servers list. Here, click on the server and click on the Global Password Policy option in the cog-wheel menu. This is where you can configure the parameters that passwords must meet in order to be usable on the system.
Clicking on the minus (“-“) button while a server is highlighted runs a slapconfig -destroyldapserver on the server and destroys the Open Directory domain if it is the only server. All domain information is lost when this happens.
Next, let’s bind a client. Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane.
To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted.
Click on the Edit… button and then the plus sign (“+”). Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.
It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user.
Provided everything works that’s it. The devil is of course in the details. There is very little data worth having if it isn’t backed up. Notice that the old Archive and Restore options are gone. To run a backup, run the slapconfig command along with the -backupdb option followed by a path to a folder to back the data up to:
sudo slapconfig -backupdb /odbackups
To restore a database (such as from a previous version of the operating system where such an important option was actually present) use the following command (which just swaps backupdb with -restoredb)
sudo slapconfig -restoredb /odbackups
Both commands ask you for a password to encrypt and decrypt the disk image created by them.
krypted August 10th, 2012
My traditional interpretation of Apple’s vision on how iOS devices are used is that everyone has an AppleID. That AppleID enables them to access their apps from any iOS device they own or Mac that they own. That AppleID enables them to access mail, contacts, calendars and even files through iCloud. That AppleID also allows users to remotely wipe their device through Find iPhone and track their friends iOS devices (as in social networking via breadcrumb tracking) through Find Friends. All of this “Just Works” in a consumer sense. And it even allows for a little sharing of content across devices you own. However, larger organizations need more. They need centralized management, content distribution and most other things you find that you rely on traditional desktop computers for.
Over the years, Apple has added tools for centralized control of devices. This started with ActiveSync compatibility and early forms of Mobile Device Management and has grown into a pretty robust, albeit disconnected, set of tools. Of these, Apple Configurator is the latest. Apple Configurator was released about a week ago and since, I’ve been trying to figure where it fits into the solutions architecture that surrounds iOS integrations. There are a number of other tools already available that can aid in the deployment and management of iOS devices, and Configurator is a great addition.
To me, there are 3 classes of management tools for iOS. These were roughly broken up into Over the Air (OTA), cradled (USB) and content management. Apple Configurator ends up fitting into all of these scenarios in some way. Let’s start by looking at the traditional uses of these three and then look at how they are impacted by Apple Configurator.
Mobile Device Management
Over the Air tools, such as Profile Manager, allow for Mobile Device Management (MDM) without cradling, or syncing a devices. These tools allow you to configure policies via profiles. There is also a bit of App pushing built into most MDM solutions. Apple’s Profile Manager can push applications written in-house, but no content from the App Store. 3rd party solutions, such as JAMF’s Casper Suite, Absolute Manage MDM, AirWatch and about 15 others are able to push apps from the App Store as well, leveraging the Volume Purchasing Program (VPP) to issue apps to devices. However, when an app is pushed through one of these tools, the app becomes associated with the AppleID for the user who owns the device.
Note: While we use the term push, the user has to accept all App installations on the device.
For large environments, MDM is a must as it allows for centralized command and control. Pushing apps is one aspect of such control. Policies enforceable through MDM include disabling cameras, configuring passcode policies on devices (not pushing passcodes), disabling YouTube, silencing Siri, unstreaming photos, disabling iCloud Backup, forcing encrypted backups, disabling location services, controlling certificates, blocking pop-ups, controlling cookies, disabling access to the iTunes and App Stores, and controlling what kind of media can be accessed on devices.
Additionally, MDM can be used to push SSIDs for wireless networks (and their passwords/802.1x configuration information), setup mail, setup Exchange ActiveSync, configure VPN connections, configure access shared calendars (iCal shared files, CalDAV and Exchange), configure access to shared contacts (LDAP, CardDAV, Exchange and Exchange Global Address Lists), deploy Web Clips and manage certificates (either with cert files or via SCEP). In short, whether you’re using the practically free Profile Manager from Apple, Mobile Iron, Casper, AirWatch, FileWave or one of the many other tools, there are a lot of things that MDM can configure on devices.
Reporting can also play a major role in how MDM tools are used. iOS Apps are owned by AppleIDs, not devices. MDM does not manage AppleIDs, but you can trigger fields in MDM databases to report back unauthorized AppleIDs being used. Reporting can also identify when devices join non-approved wireless networks (which cannot be blocked through MDM), identify devices that have been jailbroken (a major security concern for many organizations) and report on device use.
Because devices can fall outside of our control, MDM also plays an important role in being able to wipe and lock devices. While some of these types of features are available via Exchange, not all people use ActiveSync. Users and administrators alike can wipe, lock and de-enroll devices at will, potentially crippling what any device with an Enrollment Profile can do.
There are really 3 kinds of MDM tools: those that can push apps, those that can’t and Apple’s Profile Manager. The reason I put Profile Manager into its own class, is that it can push some kinds of apps, it’s cheap ($49.99 one time as opposed to per device per month or per device per year billing) and it’s great for some things. But Profile Manager should be used in very specific environments unless the price is the only decision making factor behind a tool. In larger environments, choosing a MDM solution is one of the most important aspects of managing mobile devices and the iOS platform is no different in that manner than other mobile platforms.
MDM has some limitations, though. A good MDM solution can manage the infrastructure side of device configuration. However, content requires a completely separate tool. Additonally, MDM is a completely opt-in experience. If a user wants, they can remove their device from the MDM solution at any time. Rather than a limitation, think about the opt-in experience this way: if a user removes themselves from MDM then all content that was given to them via MDM is then taken away, except that which they have moved to the local device. Therefore, if an administrator pushes an Exchange configuration then all content from that Exchange profile is forbidden fruit, removed alongside the de-enrollment.
MDM also works with Lion. Policies, centralized management, etc can be integrated with Lion. You can’t do app distribution per se, but you can push out a policy to change where the dock is on the screen, add a printer to a Mac and configure a login hook through a Profile Manager-based policy. Many of the MDM providers have begun adding functionality to their tools to allow for Mac management as well as iOS and I would expect that to become the standard in years to come. iOS is a single-user device and OS X is a multi-user device, which completes that paradigm, but Apple has made it no secret that policy-based management for Mac OS X is moving to the realm MDM (even if that is enforced through a traditional lens of directory services based policy-based management).
One of the unique aspects of the iOS platform is that it doesn’t have a file system that is exposed to users. There’s no /Volumes, no C: drive and no home folders. The devices don’t log into a server, because there’s no way to interpret a server connection. The file system that is exposed to iOS devices is through the lens of each application. Sandbox is a technology that limits each application’s access in terms of memory, hard drive, etc. Each application can only communicate with resources outside of itself if there is an API to do so, APIs mostly reserved for Apple (e.g. photos, contacts, etc). Therefore, when you discuss content management from the perspective of building a large iOS solution, you’re talking about apps.
The apps used for content management come in a few flavors. There are those that allow you to edit content and then there are those that allow you to read content. One way to look at this is through Safari. Sharepoint, WebDAV and various document management portals allow users to access data through the Safari browser on an iOS device. Safari will let you view various file types. But to edit the data, you would need to send it to an app, or copy it to the clipboard and access it in an app. Pages is an example of an app that can browse a file tree via WebDAV and edit content. However, planning how each type of file is accessed and what type of editing can be done on each file type or what type of resources need to be accessible can be difficult (e.g. there are a number of transitions in Keynote presentations that do not work in iOS).
Then there’s iTunes. iTunes allows you to backup and restore devices, update devices, etc. iTunes allows you to drop content into each application. If you look into the ~/Library/Mobile Documents, you can drop content, edit default documents and other tasks that can be done through a command line, then perform a cradled sync to an app. If networking is built into an app then you don’t have to plug a device into a computer. If an app can leverage iCloud, SMB or AFP then you can access data over the air. If you are trying to replace computers with iOS devices (a la post-PC) then you would need to plan each business task that needs to be performed and make sure not only that there is an app for that (or an app you build for that) but also make sure that you can round trip data from a shared repository and back to the network storage that the data resides on.
You can also access many of the benefits of MDM without having an OTA element. This can be done with iPhone Configuration Utility. iPhone Configuration Utility can configure the same policies available through Profile Manager but relies on either a cradled or email/web server/manual way of getting policies onto devices and updating. MDM automates this, but iPhone Configuration Utility is free and can be used as well. Additionally, profiles can be exported from Profile Manager and installed in the email/web server/manual way that iPhone Configuration Utility profiles are installed.
This is all probably starting to seem terribly complicated. Let’s simplify it:
Basically, there’s a few holes here. First, AppleIDs cannot be centrally managed. Second, you need to use gift cards or the Volume Purchasing Program (VPP) to distribute apps, and Third, even when you push an app to an AppleID, the app follows the AppleID to their next organization (which causes many organizations to treat apps like consumables). Fourth, synchronizing content is done primarily through iTunes, which only syncs a device at a time, making preparation of large numbers of systems terribly complicated.
Enter Apple Configurator, a free tool on the Mac App Store. This tool basically fixes all of the problems that we reference, but does so over USB. This means that Apple Configurator is not necessarily a replacement for MDM. In fact, you can deploy Trust and Entrollment profiles for MDM and automate the MDM enrollment for a device through Configurator. Instead, Apple Configurator is a tool that can either Prepare or Supervise an iOS deployment and do so in a manner that is easy enough that you don’t need a firm background in IT to manage devices on a day-to-day basis.
Here is what Apple Configurator can do:
Apple Configurator has some caveats:
I see a number of uses for Apple Configurator. Some of these use cases include:
These can enhance practically every environment I’ve worked with. But unless it’s a small environment (e.g. the labs), Apple Configurator isn’t a replacement for the tools already in use in most cases. Instead, it just makes things better. Overall, Apple Configurator is a welcome addition to the bat belt that we all have for iOS management and deployment. Now that we’ve looked at the when/where of using it, let’s look at the how.
There are two ways to use Apple Configurator. The first is to Prepare Devices. You would use this mode when you’re going to perform the initial setup and configuration of devices but not when the devices won’t be checking back into the computer running Apple Configurator routinely. Preparation settings do not persist. And while applications can be pushed through Preparation, updates for those applications will be tied to the AppleID that purchased the app.
The second is Supervise. Supervising devices is an option when preparing and allows you to have persistent changes to devices, to layer new settings the next time devices are plugged in, to add applications and the most intriguing aspect of iOS management here is reallocating VPP codes to new devices when a user or device is retired. Supervising devices also allows for assigning a given user to a device and thus pushing data into an application.
Setting Up Apple Configurator
Apple Configurator is installed through the Mac App Store. When installed, you are presented with three options. The first (going from left to right) is to Prepare Devices.
Before we get started, we’re going to add our AppleID. The computer running Apple Configurator needs to be able to connect to the App Store and it needs to have an AppleID associated with it if you’re going to use VPP codes. So let’s set that up before moving on. To do so, from Apple Configurator, click on the Apple Configurator menu and click on Preferences… From the Preferences menu, click on Set for the Apple ID and provide an AppleID (not the VPP Program Facilitator).
Then, when prompted, provide the credentials for your AppleID. If you have any problems with this, try Authorizing the computer in iTunes, if you can’t do one it stands to reason you can’t do the other and it’s either an invalid AppleID or that the computer cannot communicate with Apple’s servers (ports, DNS, Internet connectivity, etc might be the issue).
Also, let’s configure the Lock Screen settings, which is what’s displayed to users when you’re supervising devices. If you have user pictures in Open Directory, this will show each user’s photo at the lock screen (we will discuss device supervision later).
Using Apple Configurator to Prepare Devices
In this example, we’re going to prepare some devices for deployment. Before we do anything, we’re going to do a backup of the iOS device to use for testing. To do so, simply click Prepare Devices to bring up the main Apple Configurator screen and then click in the Restore field.
At the Restore menu, click Back Up…
Then choose the device to backup and click on Create Backup… to bring up the screen to select where to save your backup to (by default it should be your Documents but you can save them anywhere, like /iOSBackups). Click Save to make the first backup.
Notice how fast that went (assuming you didn’t load it up with 10 Gigs of crap)? The reason is that we’re not backing up iOS, just the data. This will become a little more obvious the first time we go to restore a device. In the meantime, if you look at your target directory, you’ll see a file with the name you provided followed by .iosdevicebackup. If you aren’t supervising you would need to delete these from the filesystem to remove them from the menu of available backups. If you are supervising then you’ll have a menu to manage the backups. You can also use the Other option in the selection menu to browse to another location and select another backup (e.g. you’re pulling them from other machines, etc.
Now that we have a backup, let’s do some stuff to the device. Let’s join the wireless network, change the wallpaper, create some contacts, make some notes and in general do some of those things that you might do on a base image of a computer, aside from of course configuring local admin (it’s not a multi-user device), installing anti-virus (to date, AV companies for iOS are snake oil salesmen) and other things you might not do. But as with imaging, if you can do something in Profile Manager or Apple Configurator, let’s reserve doing it there. In fact, I would probably try to set everything in Profile Manager or your MDM provider that you can (if you have one) and use Apple Configurator for as little as possible. That goes with imaging as well, do as much in directory services/managed preferences/profiles as you can and keep the image as simple as possible…
Anyway, once you have the device as you want it, make another backup. This is akin to baking an image with DeployStudio or System Image Utility. We can’t asr them out yet, but we’re in a much better place than we were.
Once you have a good backup, let’s leverage Apple Configurator to tell the device erase, update to the latest version of iOS, restore our image, join the SSID of our enrollment network (let’s consider this similar to a supplicant network in 802.1x). Then, let’s add a profile that will throw a Web Clip to our MDM solution and even add a Trust Profile to cut down on the number of taps to enroll (and the confusion of tap here, tap there, etc). From the Prepare screen in Apple Configurator, click on Settings and type the naming convention for your devices (in this case we’re going to call them krypted 1 and up) in the Name field. Then check the box for Number sequentially starting at 1 so it’s going to name them from 1 to 1,000,000 (which is how many iPads my krypted company is going to end up writing off at the testing rate I’m on now). Leave Supervision set to OFF (we’ll look at that later) and set the iOS field to Latest. Then, check the box for Erase all contents and settings and choose your image from the Restore menu.
Now for something that users of iPhone Configuration Utility, Profile Manager and Casper MDM will find familiar, click on the plus sign in the Profiles field and select Create New Profile. Here, we see what is the standard policy sheet (apologies to HIG if that’s not what those are officially called but I’ve not been able to find the right term) and give it a name in the Name field. This is how it will appear in the Profiles section of Apple Configurator. Because you can deploy multiple profiles, I’m just going to configure the SSID and Web Clip and call it MDM Enrollment. Optionally, give it some notes, organization name, etc.
Click on Wi-Fi and then click on the Configure button. Here, enter the SSID of the deployment network (MDMEnroll in this example). We’ll use the Hidden Network field to indicate the SSID is suppressed and we’ll use the network type of WEP and throw the password into the Password field as well. Now, before we move on, notice that there’s a plus and minus sign in the top right of the screen? You can deploy multiple of each, so if you have 10 wireless networks, 4 Email accounts, 9 VPN connections, 29 SSL Certs etc, you could deploy them all easily with multiple entries of each.
Scroll down in the sidebar a little and then click on Web Clips. Click on the Configure button. The Label is how the web clip’s name will appear on the device. We’re going to enter Enroll Here. In the URL field, provide the URL for your MDM server (e.g. When using a Profile Manager server called mdm.krypted.com the URL would be https://mdm.krypted.com/MyDevices). Not to get off topic, but did anyone else notice that Profile Manager in 10.7.3 now requires SSL certs? Anyway, you’ll also choose whether the web clip should be Removable (I think it should if it’s to enroll) and optionally choose an Icon. We’ll skip that (if we were using a 3rd party tool, I’d throw their logo in here; otherwise I usually like to use the company logo. I also like enrollment links to be Full Screen.
Go ahead and click Save and you’ll see MDM Enrollment listed in the Settings. If you notice, you can also click on the profile and then click on the export menu to export the profile or under the plus sign (“+”) you can Import Profile…, which is how we’ll bring in our Trust Profile from Profile Manager. From Profile Manager we already downloaded the Trust Profile. Now we’re going to click on Import Profile… and browse to it on the desktop, clicking on Trust profile.mobileconfig (or whatever name yours may have). Click Open.
We could go a step further and actually enroll the device by exporting the enrollment profile as well, but again, I want each user to provide their username and password so I as an administrator don’t have to go through and attach each device to a user in this scenario. I’ve been looking at importing devices and associating them with users via postgres, but that’s going to be another 3am article, on another night…
Next, check the box for each profile and click on Apps. This is where things start getting kinda’ cool. For this you’re going to need some app ipas. Each app in iTunes is stored as an .ipa file. We’re going to look at two different kinds of apps. The first is a free one and the second is a paid for app, both we’ll pull from iTunes. To do so, open iTunes and click on an app (iBooks in our example) and click on Show in Finder.
Note: Not all app .ipas are called the same thing as the filename. If you Show in Finder from the contextual menu of an app in iTunes it will automatically highlight the correct app in the Finder when it opens a Finder screen.
From the Finder you can either copy the app to the machine running Apple Configurator or if you’re using iTunes on that machine, you can go ahead and drag it to the Apple Configurator apps list. We’re also going to add an App that we used a purchase code from the VPP store to buy. You’ll get an error when you drag the paid app in (or browse to it if you so choose) that indicates the app is paid and in order to deploy it you’ll need to use VPP codes. Once added, you’ll notice it has an error indicator and the number 0 beside it.
Click on the numerical indicator beside the app name and you’ll be able to import redemption codes. These are emailed to you when you buy apps through the Volume Purchasing Program. BTW, no drag and drop in this screen, use the Important Redemption Codes button to browse to the XLS files.
Using Apple Configurator to Supervise Devices
Now, supervising devices may seem more complicated, but it isn’t. Back at the Prepare screen, we set Supervision to OFF. Change the iOS field to No Change. Now, let’s turn it ON. When you do so, the iOS field automatically switches to Latest. This means that supervision is going to require updates (which is fine in my book as updates have yet to break a single app for me). Get all the same settings the same as they were previously.
Once you enable Supervision, click on Prepare in Apple Configurator and connect a device again. The device will then be imaged as with the same settings that you’ve given it from before. However, once it’s done, you’ll be able to click on the Supervise tab and see devices (Note: You supervise devices rather than users).
The subsequent Starts and Stops will now allow you to enable and disable profiles and apps on the fly, as well as restore backups, update devices and as you can see in this screen, reclaim those valuable VPP codes!
Do a Get Info on a device and you’ll also see a bevy of information about that device.
You can also click on Assign, once you’ve enabled Supervision. Assigning devices requires directory services. When you click on Assign, click on the plus sign (“+”) to add the first user. Type the first few letters of the users name and they should appear in the list. Click on them and they’ll be added. You can then use the right panel to assign content to the apps that you assign to that user’s devices.
Once added, the user will by default have no device. To assign a device to a user, use the Check Out box at the bottom of the screen and then match the users with the devices you want them to have.
The final piece of this application is to assign content to users. As I mentioned earlier in this article, the file system of an iOS device is through the lens of the applications that the device has installed. Therefore, we’ll be associating files to applications. DRMd content is not distributed through Apple Configurator. So iBooks, etc, aren’t applicable. The various third party applications can open and therefore host file types that they support, as with iTunes. From the Assign pane of Apple Configurator, click on a user and then click on the plus sign (“+”) to add documents. At the Choose A Target Application screen, choose the application you’ll be loading content into.
When you click Choose, you’ll then be able to select files to use with that application.
Then just dock the iOS device, sync and viola you’ve got content distribution over USB all handled. You can also add groups of devices and groups of users and distribute content to groups of users rather than to one at a time.
Apple Configurator is really a great tool when used in the right scenarios. In learning how it works and interacts I actually learned a lot about both iOS and Mac OS X that I didn’t know before. I hope I did the tool justice with how easy it is to use. This is a fairly long article and it’s probably more complicated than it needs to be in parts, but that’s more my method of trying to figure out what it’s doing than the tool being complicated. It’s not hard to figure out at all. I am sure I could teach any non-technical iOS admin to use it in less than an hour.
My wish list includes logs and OTA. You can’t use iPhone Configuration Utility while you’re using Apple Configurator and therefore, you can’s see up-to-the second logs about things like key bags to figure out why this isn’t working or that. This makes it kinda’ difficult to figure out why a profile doesn’t get installed with an image if you’re not using an AppleID with the tool or other weird little things like that. I’d love to see a little more logging. Obviously, if you could run this thing Over the Air then it would be nerd nirvana. I guess the OTA isn’t as much as wish list for this tool, but features that could be imported into Profile Manager and other tools.
One of the more important aspects is the impact on AppleID use and app ownership. I started this off by saying “My traditional interpretation of Apple’s vision on how iOS devices are used is that everyone has an AppleID.” Well, when using this tool an AppleID is no longer necessary for app deployment.
Overall, we have a new, powerful tool in our arsenal that makes up the iOS administration ecosystem. I hope that I’ve managed to dispel a few rumors with this article and look at some great uses for where this tool should and should not be used. I also hope that no matter what, if you manage iOS devices, that you’ll take a look at it. I expect you’ll find it useful in some part of your management toolkit!
krypted March 15th, 2012
Tags: 802.1x, ActiveSync, AFP, API, Apple, Apple Configurator, AppleID, applications, apps, carddav, company, content management, cradle, deployment, devices, distribution, DRM, DUNS, education, encrypted backups, Exchange, iCloud, ios, iPad, iPhone, iphone configuration utility, ipod touch, itunes, LDAP, lock, management, mdm, mobile device management, mobility, ota, over the air, Prepare, reporting, restore, revoke apps, Safari, SCEP, schools, serial number, sharepoint, SMB, Supervise Devices, Trust Profile, UDID, volume purchasing program, vpn, vpp, Web Clip, webdav, wipe, Wireless
phpLDAPadmin is a tool that can be used to walk LDAP trees and view attributes of objects located within them using a web browser. This isn’t to say that it’s the prettiest tool out there but it works really well and is portable between various flavors of LDAP.
Before you can use phpLDAPadmin you will need Apache. In Ubuntu, Apache can be installed using apt-get:
apt-get install apache2
Once you have Apache installed, downloading phpLDAPadmin and installing it in Ubuntu Server 10 couldn’t be easier, just apt-get the package:
apt-get install phpldapadmin
Now you have the pieces, let’s copy phpLDAPadmin into your web root directory:
cp -R /usr/share/phpldapadmin /var/www/myphpldapadmin
In that new directory you will see a config file. Here, you’ll see some lines that appear as follows:
$ldapservers->SetValue($i,’server’,’name’,’My LDAP Server’); // The name to display
$ldapservers->SetValue($i,’server’,’host’,’127.0.0.1′); // Address of the LDAP server
$ldapservers->SetValue($i,’server’,’port’,’389′); // Port number
$ldapservers->SetValue($i,’server’,’base’,array(‘dc=example,dc=com’)); // Base dn
You’ll want to provide the address, port number (if the port isn’t 389) and DN information of your server and then connected by visiting the website created via Apache (if the server name were ldapserver.local, this might be http://ldapserver.local/phpLDAPadmin). Provide the username and password and you should be able to use phpLDAPadmin. Happy LDAP’ing!
krypted November 17th, 2010
Apple recently announced the end of the Apple Xserve. The data center is a funny thing, and being such rack space is critical to most who spend a lot of time there. Many of the previous Xserve customers will continue to buy Mac Pro’s and use them in racks as tall Xserves. Others will purchase Mac Mini’s and use them for certain situations. But many will move on to using the same iron in the data center that they use for everything else, finding a way to duplicate or replace the functionality that was previously in the Xserve with something else.
Server Admin is not going to run on Linux. But you can get kinda’ close and if you really miss the GUI for DNS (not likely) and the other services (possible and in some cases highly likely) then you can hax0r the stuff to look as much like Server Admin as you want. In fact, given the number of developers and the open source nature, the tools available on Linux are likely to even blow away what you could do before. However, there’s a much steeper learning curve and that’s why many (not all) in the Xserve camp have stuck it out with Apple all these years.
The easiest and most mature of the solutions that can be used here is Webmin. We’re going to look at installing Webmin on an old Dell Dimension 5150 that’s running Ubuntu Server 10. Warning, there’s gonna’ be some command line here to get ya’ started, but feel free to cut and paste.
First up, install the webmin dependencies. Dependencies are to many the most frustrating thing about working with Open Source software. But never fear, the Webmin team has posted their dependencies as perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime and libio-pty-perl. So, let’s install those with elevated privileges, using apt-get:
apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl
Next, let’s install Webmin itself. Download Webmin:
If that fails, check the version at the Webmin site and re-run using the correct URL, listed on the site. Once you’ve downloaded, it’s time to install. One of the reasons (in my opinion) that Ubuntu is so popular is that like Apple they use a package-type of format for installers. Therefore, think of the dpkg command like the installer command in Mac OS X when used with the –install or -i operator. So assuming your working directory is where you downloaded that package to (*.deb)
dpkg -i webmin_1.520_all.deb
Once it’s finished fire up a web browser and go to port 10000 on your box. You should be prompted to authenticate, which can be done using root as the username and the root password of your box as the password. Once done, go to the module page or search for a third party module if the package you’d like isn’t include, and download the modules you need.
I’m not a huge fan of Webmin, but I’ve heard a lot of talk about “wouldn’t it be great if there were something similar to Server Admin”. Well, the way Roles work in Windows Server is similar and Windows Server can pretty much do anything (include make me coffee). If you are averse to Microsoft servers and/or paying per CAL for licensing, plugging modules into Webmin is pretty darn close as well. Looking at services included in Mac OS X Server, Webmin can manage FTP (Frox/WU-FTP/ProFTPd), NFS, Samba, SSH, SpamAssassin, Squid, Apache (and Webalizer), VPN (PPP/PPTP/IPsec), Mail (Dovecot/Postfix/Sendmail/Procmail/Majordomo), database (MySQL/PostgreSQL), Shorewall, LDAP w/ Kerberos, DHCP, Bind, Jabber, CVS/Subversion, VNC and even Bacula (replacing that Time Machine server concept).
You have way more choices (which isn’t always a good thing). Sure, Webmin is not nearly as pretty as Server Admin and it has many of the same issues of interpreting what are in config files and developing a WTF complex if you make a change in one place vs. the other. But it can also manage VMs and do a lot of other things (ie – monitoring). I still prefer Mac OS X Server for a lot of things, but if someone adds Netatalk (trivial), ports the Apple .schema file in and DAViCal/CardDAV, you’ve got a new version of spaghetti open source pretty similar to Server Admin. A little CSS and you can even make it look just like Server Admin.
Not everyone is going to want to use Ubuntu. I personally end up using Redhat more than I do any other flavor of Linux. For Redhat users, getting Webmin installed is actually even easier. Simply run rpm, specifying the package and you’re off to the races:
rpm -U webmin-1.520-1.noarch.rpm
Finally, I really and truly do not condone a knee-jerk reaction to Apple’s decision to terminate the Xserve. Unless Sarah Connor can do something about it I don’t think it’s coming back. If you absolutely have to move certain services to a different 1U box, then here ya’ go. Otherwise, stay with those new MacPro Servers, you’ll be happier with them in the long run!
krypted November 7th, 2010
If you grew accustomed to using Directory.app in Leopard and you’re thinking about an upgrade to Snow Leopard then you might want to pause, if only for a moment. You see, there is no Directory.app in Snow Leopard. If you were using Directory.app to allow users to create Blogs and Wikis, then check out the new web interface and see if the specific functionality you seek is there; otherwise look into SACLs and consider pushing out Workgroup Manager. If you were using it to hook into LDAP and allow for looking up contact information then check out Address Book Server, included in 10.6 Server…
krypted August 29th, 2009