Security policy means different things to different companies. In some environments, using managed preferences to control external drive access would be considered draconian. In others, leaving the Airport card plugged in (or firewire ports connected) is thought of as irresponsible. What can a systems administrator do to limit hardware use on company machines?
One option is to disable use of certain hardware components at a system level. Kernel extensions, the software which allows the system to access hardware, are kept in the /System/Library/Extensions folder. Removing specific extensions from that folder will disable the associated hardware, preventing it from being used. Remove the wrong ones, unfortunately, and the your operating system won't boot.
If you want to prohibit wireless access, those files are AppleAirPort.kext, AppleAirPort2.kext, and AppleAirPortFW.kext. To disable Bluetooth capabilities (and therefore Bluetooth file transfer), you'll want IOBluetoothFamily.kext and IOBluetoothHIDDriver.kext. Apple's iSight cameras can be disabled to prevent video and photographs of your facility by replacing AppleUSBVideoSupport.kext and Apple_iSight.kext. The use of external hard drives is regulated by IOUSBMassStorageClass.kext and IOFireWireSerialBusProtocolTransport.kext.
For every hardware interface, there's a kernel extension file to match.
If your goal is to disable your chosen hardware permanently (so that software updates won't re-enable it), just replace the missing files with empty text files of the same name, then "Get Info" on each file in the Finder and check the "Locked" option so they won't be reinstalled.
Recommended Reading: Apple's very technical explanation of kernel extensions can be found at their developer site. You might also consider controlling hardware access through Open Directory's managed preferences, explained previously in this very blog.
Posted on 3 September 2008 by Ellis Jordan Bojar
When the Macintosh computers on your network don't have a Macintosh server to control them, the result can be chaotic. Some users wind up with multiple passwords to keep track of while others give up by keeping their account passwords blank. Passwords to Windows resources can expire without warning because users have no PC to reset them with, and machines can be reconfigured with passwords that aren't even documented.
It's easy to only see the security implications and administrative issues in this scenario, but take a step back and you'll also understand the frustration Macintosh users have on a network designed without their experience in mind.
Binding workstations to Active Directory allows your existing Windows accounts to be used on Mac OS X. It eases maintenance by enabling the use of network administrative accounts, and improves security by allowing you to enforce password policy. Just as importantly, it empowers the people who use your Macintosh systems, by eliminating multiple passwords and allowing interaction directly with the Windows infrastructure.
To begin, check the "Network" pane in System Preferences, and be sure that your Windows domain is listed in the "Search Domains" for each interface. Then open the Directory Utility application in the Utilities folder, click the "Show Advanced Settings" button, and select "Services" from the toolbar that appears above.
Check "Active Directory" from the available list of services, then hit the pencil symbol at the bottom to edit the binding criteria. Leave the directory forest set to "Automatic" and enter the name of your Active Directory domain and the computer name you wish to bind your machine as. Resist the shiny, pulsing "Bind..." button and instead click the "Show Advanced Options" arrow at the very left hand side. The window will expand, revealing the full range of configuration choices.
Beginning with the "User Experience" pane, check "Create mobile account at login". Without this selected, Mac OS X won't cache account credentials, leaving users locked out of their machine when the Active Directory server can't be reached. This would prevent access not only during network failures, but also for any laptop user unable to connect with VPN (like those commuting by train, on airplanes, or in log cabins).
Next you'll see "Force local home directory" selected automatically. This will store user account data on the individual workstation rather than utilizing the home folder in the user's Active Directory profile. While it is possible to use a Windows server to store Macintosh home directories, the process can be inconsistent and poorly supported (and can lead to significant confusion if the same account is used for both OS X and Windows). To this end, you'll want to uncheck "Use UNC path from Active Directory to derive network home location" as well.
Now select the "Administrative" pane, and begin by unchecking "Allow authentication from any domain in the forest" at the bottom of the window. This will force OS X to locate user accounts only within the domain you've specified. You can then check "Allow administration by", allowing (at a minimum) domain and enterprise administrators to also administer the local machine. You can also add groups from your Active Directory set up, or even specific user accounts (as in the example above) who may not normally have administrative rights on Windows systems.
Having configured your options, click "Bind...", and enter the name and password of a domain administrator when prompted. If there's a pre-existing local account on the bound machine, you'll want to log in with the user's Windows name and password first to dynamically create a new home directory. Then, switch to an administrative account to migrate over the user data from their old home directory in /Users, making sure to match the permissions to the new Active Directory-based account.
When it's all finished, you'll now have the kind of account controls you're so used to on your Windows systems. Happily, your Macintosh users will, too.
Recommended Reading: Active Directory binding is important enough in corporate settings that we've written about it twice, once early on for Tiger and again in this updated Leopard version. It's also important enough that Apple has a resource page dedicated to it, Integrating Mac OS X and Active Directory, at their IT Pro site.
Posted on 13 August 2008 by Ellis Jordan Bojar
Most servers sit behind your company firewall, reachable only through NAT and port forwarding or protected from the outside world entirely. If you've got a machine that needs full access to both the internet and your local network, however, getting both interfaces up and running can seem like a crapshoot. New servers will usually work fine, while those configured on a second network later on will often fail. XServes and Mac Pros come with two ethernet ports, so you'd figure setting them up on two separate networks wouldn't be much of a challenge. And it isn't, if you know the trick.
Unix operating systems (including Mac OS X) can only have one "default route" at a time, the path of last resort for data headed outside your local network. Mac OS X uses whatever you've configured on "Ethernet 1" in the "Network" pane of System Preferences as the default route. That's usually the internal IP on your firewall, proxy server, or router. If you later configure an external IP as "Ethernet 2", your data won't be routed properly and the machine won't respond on the outside interface.
The trick to getting your Mac routing both networks is to set up "Ethernet 1" as your external (or WAN) interface, using the information provided to you by your internet service provider. Mac OS X will then set the router setting from this connection as the default route for the machine. If, for some reason, you have to use your internal interface as "Ethernet 1", remove the IP from the "Router" field. This will force the machine to use the router information from "Ethernet 2" as the default.
Special Thanks: This tip came in a crunch from our colleague Jared Reimer, founder of Cascadeo Corporation, an excellent Seattle-based network consultancy.
Posted on 6 August 2008 by Ellis Jordan Bojar
Aside from the files an OS X Server shares across your entire enterprise, there's often the desire within individual workgroups to have private storage areas for their own projects. These group folders are essential for departments like HR and Accounting, but they can also be helpful for less security-conscious groups as a staging area before sharing their final work company-wide. Fortunately, while the process of creating these file shares isn't obvious, it also isn't complicated.
First, select a group from your Open Directory domain in the "Accounts" pane of Workgroup Manager. Then click the "Group Folders" button, and select a share point under which you'd like the group folders to appear. By default, Mac OS X uses /Groups, which comes pre-configured as a share on a new installation. Next, you'll need to choose an owner for your new folder. Your directory administrator account makes the most sense here, as you'll be using the group (not owner) attribute to determine access permissions. With these options configured, hit "Save".
For whatever reason, you can't actually use Workgroup Manager to create the folder you've just configured (as you can with user's home directories). Instead, you'll need to open the Terminal and type:
sudo CreateGroupFolder
This will build a folder for every group assigned a share point, not just the most recent, so if you're deploying multiple group folders it makes sense to run this command after they've all been set up in Workgroup Manager. This also sets the permissions for each group folder as read-only to the group itself, and only read-write to the individual user defined as it's owner. To remedy this in the Terminal, type the following, replacing PATH-TO-FOLDER with the full Unix path to each group folder:
cd PATH-TO-FOLDER
sudo chmod 770 Documents/ Library/
This will allow access by workgroups to their own group folders with a simple permissions scheme. For more complex sharing setups, you may wish to add an access control list as well, in the sharing pane of Server Admin.
Finally, if you're utilizing managed preferences in an Open Directory environment, you can set group folders to automatically mount when a member of that group logs in to their workstation. Moving to the "Preferences" pane of Workgroup Manager, click the "Login" icon, then the Items button on the far right. Check "Mount share point with user's name and password" and "Add group share point", then click "Apply Now".
Not only can each workgroup have their own private file share, but users will connect to those shares automatically when logging in to their Open Directory account.
Posted on 30 July 2008 by Ellis Jordan Bojar
The first time a VP brought you their iPhone to configure, it was a new toy. It was fun, even if it took twenty minutes of typing on that tiny onscreen keyboard. Now with version 2.0 and Exchange support, the iPhone it isn't new or a toy anymore, but it would still take you weeks to individually configure all the iPhones your company needs.
It's for these enterprise-wide deployments that Apple provided the iPhone Configuration Utility, an OS X native application to create and distribute settings for corporate iPhones. Install the program on any Macintosh (or use the web-based version for Windows) and you can create .mobileconfig files that set passcode policy, wireless networks, VPN, POP/IMAP or Exchange email, and more.
First, open the iPhone Configuration Utility, select "Configuration Profiles" and click "New" in the toolbar above. Moving through each of the application's tabs, fill in the appropriate access and account information for your network. Individual account names and passwords need to be input on each device by the user, but security certificates can be pre-loaded by your administration team. You can create as many configurations as are reasonable for your environment, offering different setups for different classes (or departments) of employee.
Once your policy and access information is in place, you can distribute each configuration by clicking "Export" to save the file to disk then upload it to any web server. This method (preferred over email distribution for large deployments and new devices) requires that your web server transmit .mobileconfig files uncompressed and with a MIME type of application/x-apple-aspen-config. Mac OS X Server 10.5.3 and above are pre-configured this way, while Windows users can set this in the server Properties page of IIS Manager. Those running earlier versions of OS X can add this information using the MIME Types pane of the Web settings in Server Admin.
By simply browsing to the appropriate URL, each iPhone will automatically begin the installation. While this process will prompt the user for their domain authentication criteria before configuring the device, it's still advisable to limit access to the URL by only serving the .mobileconfig file to your intranet. Also, while adding a signed profile in the "General" pane (using a certificate issued by one of Apple's pre-installed trusted root authorities) isn't required, it's simpler to get a new security certificate issued for this purpose than try explaining to users why it's OK to install an unverified profile that lacks the attractive green "Trusted" icon.
With very little work up-front, this process offers not just a way to minimize initial deployment times company-wide, but also allows a method to distribute network access changes across your entire enterprise down the line.
Recommended Reading: For further information on customizing iPhone configuration, download Apple's iPhone Enterprise Deployment Guide [PDF - 728KB].
Posted on 23 July 2008 by Ellis Jordan Bojar
Earlier Posts »
