Monthly Archives: January 2012

Mac OS X Mac OS X Server Mac Security Mass Deployment Network Infrastructure

Preflighting slapconfig

Mac OS X Server uses the slapconfig command to promote Open Directory Masters and Replicas. In Lion, there is less and less dependency on slapconfig as not all of the aspects of an Open Directory environment are known throughout the system when performing LDAP operations through the command line (e.g. using -createldapmasterandadmin or -create. For example, if you use the tried and true -destroyldapserver option, the Server.app will no longer be able to promote a new Master and you’ll need to use Server Admin to create and then destroy that Master again in order for Server.app to be OK with your configuration changes.

But there are things we’ll still want to use slapconfig for. One of the better things is to actually check the environment to make sure that it is suitable for being an Open Directory server. For starters, let’s check the version of slapconfig:

/usr/sbin/slapconfig -ver

The version should be 1.2 or higher. However, as with Apache and a few other services, Apple has forked the build from the open source community, so let’s also look at the Apple Version of slapconfig. This is done using a hidden option: -appleversion. To run this, just run the option with slapconfig as follows:

/usr/sbin/slapconfig -appleversion

Then, let’s look at running slapconfig to check that the machine is suitable to be a Master. The command to do so is another hidden option, -preflightmaster. The -preflightmaster option uses the same syntax as -createldapmasterandadmin (and should at this point always be used as a sanity check prior to running -createldapmasterandadmin). Syntax as follows, where positions 1, 2 and 3 are the short name, long name and UID of the initial directory admin account:

/usr/sbin/slapconfig -preflightmaster diradmin "Directory Administrator" 1050

The slapconfig command can also be used 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

Additionally, there are other hidden options for handling all of the certificates that get created, deleted and managed as part of the Open Directory creation process (e.g. -addcaforreplica and -restorerootca), Kerberos (e.g. -cankerberize) as well as handling relays (e.g. -getrelayconfig).

Mac OS X Mac OS X Server Mac Security Mass Deployment

Removing Apps from Profile Manager Using Postgres

There aren’t any options in Lion Server’s Profile Manager to remove applications. There are a number of environments where this can be annoying. For example, if you are upgrading or maybe just accidentally upload an app that you don’t want people to see for the rest of the existence of the Profile Manager server. To see which applications have been installed and which have each id:

psql -U krypted -d device_management -c "select * from public.ios_applications limit 1000 offset 0;"

The above command is a standard psql command, as shown in a previous article I worked on in a previous post. But this time I’m injecting the SQL query into the psql command using the -c option. This expands to output a list of each row in the iOS_applications table. Once you see which apps have which unique id’s, you can then remove entries using their  identifiers (this time we’re throwing in a delete instead of select using the -c):

psql -U krypted -d device_management -c "delete from public.ios_applications where id=2;"

Simply re-run without any constraints around your SQL query to clear out all of the application. For example:

psql -U krypted -d device_management -c “delete from public.ios_applications”

This works for most of the tables within Profile Manager. This allows you to clear out any information stored in its own table, such as printers, tasks, sessions, widgets, etc.

Note: you’re not going to remove apps from devices just because you cleared them from the table.

personal

Underworld: Awakening Trailer

Watching this trailer the past week makes me very happy, so I thought I’d share!

Articles and Books Mac OS X Mac OS X Server Mac Security

Paper.li Test Embed


public speaking

Free MacWorld Exhibit Code and iFan Pass Savings

As usual, there are a lot of great events going on at MacWorld | iWorld. If you’re interested in joining us in a couple of weeks in San Francisco for what I’m sure will be a great conference, then you can use my speaker codes to do so. To do so, during the registration process enter a PRIORITY CODE of: BNB35106

This will give 100 FREE Exhibit Only Passes OR $15.00 OFF an iFan Pass. This code is unique to me, so other speakers have codes as well. The code will stop offering free exhibit passes once the 100th person registers for this. The $15.00 savings off an iFan pass will continue through the show.

I hope to see you there!

Articles and Books

The Elements of Style

Strunk & White’s Elements of Style is one of the best works explaining the rules of writing in the English language that has ever existed (and I’m pretty sure that sentence broke at least five of those rules). I’ve given this book to many a budding writer over the years. I’ve also recently noticed that it’s now all over the Internet, for free. For example, Bartleby has posted the 1918 edition of Elements of Style here.

XKCD's Elements of Style

If you haven’t read Elements of Style then I strongly recommend it. It’s short, concise and explains why that apostrophe goes in that one spot as opposed to the other. If you want to be a writer, this is one of your first stops on your journey.

sites

Removing A Domain Name From A Google Search

When you are searching Google, you can restrict your search to a specific domain. For example, if you would like to find a page with the pattern “man touch” on krypted.com then you can constrain a Google search using the site: operator. The search dialog box would then read:

"man touch" site:krypted.com

But if you don’t find my posts helpful then you can remove the domain name from your Google searches, done by running the same, but with a “-” in front of the domain name, which given the above search inverted would be:

"man touch" site:-krypted.com

The resultant URL is then: http://www.google.com/search?q=site:-krypted.com. To take this a step further, you could also use this awesome application called glims from http://www.machangout.com to actually change your default search site from the standard Google.com search to the above URL and eliminate a given domain name from all future searches.

For more on the the available operators: https://sites.google.com/site/gwebsearcheducation/advanced-operators.

Mac OS X Mac Security

lsregister: How Files Are Handled in Mac OS X

The lsregister command is used to query and manage the Launch Services database, or the database that is used to determine the default application used to open files of various types. lsregister is part of Core Services, and stored in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support. To see the options available to lsregister, run the command with no operators:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister

You can dump the database to the screen using the -dump option:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump

You can then grep the database or redirect the output into a text file for parsing:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump > dump.txt

Sometimes applications don’t open with a given file type. When this happens, you can quickly and easily check if the problem has to do with the launchservices database. To do so run the open command and define the application (using the -a option) followed by the app and then the file. For example, to open an XML file called daneel.xml in TextWrangler (assuming your working directory contains bob.xml):

open -a TextWrangler.app bob.xml

You can force an application to re-register file types for that application using the -f option followed by the application path. For example, to re-register Xcode:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -f /Developer/Applications/Xcode.app

You can also unregister a specific application using the -u option. To unregister Xcode you would use the -u option:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -u /Developer/Applications/Xcode.app

The lsregister command is actually just a front-end management tool for the ~/Library/Preferences/com.apple.LaunchServices.plist file. The file’s contents can be read (in an unparsed form) using defaults:

defaults read ~/Library/Preferences/com.apple.LaunchServices

The launchservices database is also responsible for determining whether a file type is quarantined by default (and those files that are quarantined throw a message to users when opened for the first time). To disable such a feature:

defaults write com.apple.LaunchServices LSQuarantine -bool NO

The database can become pretty large and unwieldy. There are applications registered in the local domain, system domain and each user’s domain. You can always clear these out using the following command, which also recursively rebuilds based on the output of a -lint option:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user

To check the progress:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -v

To set a specific application to open a file type, use the application’s domain out of the -dump output in an LSHandlerRoleAll and the file extension in an LSHandlerContentType in the LSHandlers array of com.apple.LaunchServices, as follows (to change txt for Text Edit – aka com.apple.textedit):

defaults write com.apple.LaunchServices LSHandlers -array '{ LSHandlerContentType = "txt"; LSHandlerRoleAll = "com.apple.textedit"; }';

You can also set the default application for a network protocol (e.g. smb://, rdp://, vnc://, http:// and https://). Because the options for lsregister leave one wanting in some ways (the commands to set file types to a specific application are a bit overly complicated one could argue), there is an awesome front end app from Andrew Mortensen, aptly called duti, available at http://duti.sourceforge.net/index.php. With duti installed, the command to set the default browser for http would be:

/usr/local/bin/duti -s com.apple.safari http

Note: When working with lsregister, one should first clear the state for that application: http://krypted.com/mac-os-x/controlling-saved-application-states.

Finally, there’s a lot that Launch Services does and is involved in. For more information on LaunchServices, check out the Apple developer library information here.

Network Infrastructure

Replacing the Default SSL Cert For SonicWALLs

The default, self-signed certificate that comes on a SonicWALL causes alerts during a Nessus scan. This is because the device uses a certificate that comes on the device and isn’t signed by a valid CA. Chances are, there are limits around who can load the SonicWALL web interface in the first place. But, if you don’t want Nessus to continue alerting, or if you just want to use a certificate signed by a valid CA because it’s a good security practice, you might want to add a new certificate.

The first step is to generate a new CSR. To do so, open the SonicWALL web interface and then click on System in the SonicWALL sidebar. Then click on Certificates and scroll to the bottom of the screen until you see the New Signing Request button.

At the resultant Certificate Signing Request screen, fill out the fields with your information.

Click on the Generate button to bring up the Export Certificate screen. Click Export and then choose where to save the CSR.

Once you receive the certificate, you’ll want to install it. The easiest way to do so is to go back to the Certificates screen (under System in the SonicWALL sidebar) and then scroll down to the bottom, clicking on Import… Here, use Choose File to pick the cert, provide a name for it and the password for it and click on Import.

Next, click on Administration (also under System in the SonicWALL sidebar). Scroll down to the Web Management Settings section of the screen and use the Certificate Selection field to select the newly installed certificate.

And that’s it. I’ve had to restart the device to get it to work properly, but overall, a pretty straight forward process.

Mac OS X Mass Deployment Microsoft Exchange Server Windows Server

How Exchange's Autodiscover Works With Mail.app

Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, Mail.app in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp.

The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For me.com, this might be:

nslookup _autodiscover._tcp.me.com

But note that there’s not a response. This is because me.com doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for 318.com:

nslookup _autodiscover._tcp.318.com

Which looks like this:

Non-authoritative answer:
Name: _autodiscover._tcp.318.com
Address: 66.209.67.173

Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance.

Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed.

Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows:

/Applications/Mail.app/Contents/MacOS/Mail 
--LogEWSAutodiscoveryActivity YES

By reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures.

While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!