Category Archives: Mac Security

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

Bushel: The Device Enrollment Program (DEP) In Action

Apple’s Device Enrollment Program (DEP for short) allows you to automatically setup devices with the settings you need on devices that your organization purchases. In Bushel, we give you the ability to link an Apple DEP account up with your Bushel account. This allows devices to add themselves automatically to your Bushel when the devices are activated. We tend to think this is the coolest thing since sliced bread and so we want to make sure you know how to use the feature.

Setup Device Enrollment Program in Bushel

To get started, log into your Bushel and click on Devices. Here, click the button for Device Enrollment Program.

XcKrpO-M0gXF27l0exLKtVbNMLdI1itn8ThiXRqW3xQ

Download your certificate and go to deploy.apple.com and log into your Device Enrollment Program account. Click on Manage Servers in the Deployment Programs sidebar.

Screen-Shot-2014-10-14-at-2.12.49-PM

Next, click on Add MDM Server and provide the certificate we gave you and a name. Once Bushel has been added to your Device Enrollment Program (DEP) account, click on Assign by Serial Number to add your first device. Assuming the device is part of your DEP account, enter the serial number for the device and choose which server (the one you just added) that the device should reach out to on activation to pull settings from.

Screen-Shot-2014-10-14-at-2.13.53-PM

Once you’ve added the server, you’ll be greeted by a screen that says Assignment Complete. You can now wipe the device and upon reactivation the device will pull new settings from your Bushel.

Screen-Shot-2014-10-14-at-2.13.58-PM

The Device Enrollment Program in Bushel

Click OK and you can add more devices. Once your devices are added into the Apple DEP portal they will automatically appear in the DEP screen of your Bushel. Click on a device to assign a username and email address, if you will be using email.

xdWSZrVkYs6wWHgmzfmdkOdmZjSXVMDqrypOkqCaC3w-1

Good luck!

iPhone Mac Security Network Infrastructure

Listen To iOS Network Communications

OS X has a command called rvictl, which can be used to proxy network communications from iOS devices through a computer over what’s known as a Remote Virtual Interface, or RVI. To setup an rvi, you’ll need the udid of a device and the device will need to be plugged into a Mac and have the device paired to the Mac. This may seem like a lot but if you’ve followed along with a couple of the other articles I’ve done recently this should be pretty simple. First we’ll pair:

idevicepair pair

Then tap Trust on the device itself. Then we’ll grab that udid with idevice_id:

idevice_id -l

Next, we’ll setup a rvi with rvictl and the -s option (here I’m just going to grab the udid since I only have one device plugged into my computer):

rvictl -s `idevice_id -l`

Then we can list the connections using rvictl with the -l option:

rvictl -l

Next, we’ll run a tcpdump using this newly constructed rvi0:

tcpdump -n -i rvi0

Next, we’ll get a lot of logs. Let’s fire up the Nike FuelBand app and refresh our status. Watching the resultant traffic, we’ll see a line like this:

22:42:29.485691 IP 192.168.0.12.57850 > 54.241.32.20.443: Flags [S], seq 3936380112, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 706439445 ecr 0,sackOK,eol], length 0

There’s an IP in there, 54.241.32.20. We can look this up and see that the servers are sitting on Amazon Web Services and verify it’s Nike. Watching the traffic with tcpdump we can then obtain GET, POST and other information sent and received. Using wireshark we could get even more detailed data.

Overall though, this article is meant to focus on the iOS side of this and not on debugging and refining the approach to using tcpdump/wireshark. rvictl is a great tool in the iOS development cycle and for security researchers that are looking into how many of the apps on iOS devices exchange data. Enjoy.

Mac OS X Mac OS X Server Mac Security

qlmanage

QuickLook scans file contents before you open those files. Usually this just lets you view a file quickly. But you can also use this same technology from the command line to bring about a change to the Finder without actually opening a file. To access QuickLook from the command line, use qlmanage.

qlmanage -p ~/Desktop/MyTowel42.pdf

While open, click the space bar to go back to your Terminal session. The most notable use case here is that when you use qlmanage you don’t run the risk of changing the date/time stamp of the files.

Mac OS X Mac OS X Server Mac Security

Yosemite and statshares in smbutil

The statshares option has an -m option to look at a mount path for showing the path to the mount (e.g. if the mount is called krypted this should be something like /Volumes/krypted):

smbutil statshares -m /Volumes/krypted

When run, you see a list of all the attributes OS X tracks for that mount path, including the name of the server, the user ID (octal), how SMB negotiated an authentication, what version of SMB is running (e.g. SMB_1), the type of share and whether signing, extended security, Unix and large files are supported.

Additionally, if you’d like to see the attributes for all shares, use the -a option after statshares:

smbutil statshares -a

Overall, this is a nice health check type of verb for the smbutil command that can be added to any monitoring or troubleshooting workflow. Other verbs for smbutil include lookup, status, view, and identity. All are very helpful in troubleshooting connections to smb targets.

Mac OS X Mac OS X Server Mac Security Network Infrastructure

Directory Utility in Yosemite. I’m not Dead Yet… Mapping Attributes 101

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. Screen Shot 2014-10-30 at 9.02.04 AM

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.

Screen Shot 2014-10-30 at 9.12.18 AM

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.

Screen Shot 2014-10-30 at 9.04.11 AM

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.

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

Yosemite Server Guide/Page Live

A blog is a great way to communicate information. But pedagogy, yo… Blogs are not great ways to teach in a guided manner. But they can be. So with a little Table of Contents, or a Guide of sorts, you can easily communicate in a fashion similar to a book. And this makes the third annual OS X Server Guide that I’m publishing in this manner; the guides for Mavericks and Mountain Lion are  still available. I doubt I’ll ever actually bother to take them down.

I’ve been working on getting the annual guide up for a few weeks and while there are still some posts remaining, but it’s basically done (some articles just haven’t gone up yet, but they’re basically written). So, if you’re fighting the good fight (and I do think it’s a good fight) and rolling Yosemite Server, click over on http://krypted.com/guides/yosemite-server for the latest guide, covering OS X Server 4 running on OS X Yosemite (which I still like to call Yosemite Server).

Screen Shot 2014-11-04 at 7.49.04 PM

Oh, and if you’re keeping track (doubtful): yah, I know I never finished the Windows Server Guide, but I did write and finish the Xsan one and there might have been a divorce, 2 books, a product release, job change and a few benders mixed in there – one of which might still be ongoing… So I’ll eventually get back to it. Or not….

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

Upgrading To OS X Server (4.0) on Yosemite

Setting up OS X Server has never been easier. Neither has upgrading OS X Server. In this article, we’ll look at upgrading a Mac from OS X 10.8 or 10.9 running Server 2 or Server 3 to OS X 10.10 (Mavericks) running Server 4.

The first thing you should do is clone your system. The second thing you should do is make sure you have a good backup. The third thing you should do is make sure you can swap back to the clone should you need to do so and that your data will remain functional on the backup. The fourth thing you should do is repeat all that and triple check that your data is there!

Once you’re sure that you have a fallback plan, let’s get started by downloading OS X Yosemite from the App Store. I would also purchase the Server app first while Yosemite is downloading. Screen Shot 2014-11-04 at 7.15.56 PM Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad. Once downloaded, you’ll see Install OS X Yosemite sitting in LaunchPad, as well as in the /Applications folder.

Screen Shot 2014-11-04 at 5.09.18 PM

Open the app and click Continue (provided of course that you are ready to restart the computer and install OS X Yosemite).

Screen Shot 2013-10-04 at 4.45.46 PMAt the licensing agreement, click Agree (or don’t and there will be no Mavericks for you).

Screen Shot 2013-10-04 at 4.45.48 PMAt the pop-up click Agree again, unless you’ve changed your mind about the license agreement in the past couple of seconds.

Screen Shot 2013-10-04 at 4.45.52 PMAt the Install screen, click Install and the computer will reboot and do some installation fun stuff.

Screen Shot 2013-10-04 at 4.45.54 PMOnce done and you’re looking at the desktop, download the latest version of the Server app you should have purchased previously, if you haven’t already. Then open it.

Screen Shot 2014-11-04 at 5.13.05 PM
If prompted that the Server app was replaced, click OK. Then open the app.

Screen Shot 2013-10-04 at 5.48.52 PMAt the Update screen, click Continue (assuming this is the server you’re upgrading).

Screen Shot 2014-11-04 at 5.13.09 PMAt the Licensing screen, click Agree.

Screen Shot 2014-11-04 at 5.13.12 PMWhen prompted for an administrator account, provide the username and password of an administrator and click OK.

Screen Shot 2014-11-04 at 7.28.07 PMWhen the app opens, verify DNS (absolutely the most important element of this upgrade), etc and then check that configured services still operate as intended. If you end up deciding that you no longer need OS X Server, just delete the app and the contents of /Library/Server and you’re good. Handle with Care.

Mac OS X Mac OS X Server Mac Security Mass Deployment

Encrypt OS X Yosemite Server

Encrypting a volume in OS X Yosemite couldn’t be easier. In this article, we will look at three ways to encrypt OS X Yosemite volumes. The reason there are three ways is that booted volumes and non-booted volumes have different methods for enabling encryption.

Encrypting Attached Storage

For non-boot volumes, just control-click or right-click on them and then click on Encrypt “VOLUMENAME” where the name of the volume is in quotes.

encrypt1

When prompted, provide an encryption password for the volume, verify that password and if you so choose, provide a hint.

encrypt2

Once the encryption process has begun, the entry previously clicked on says Encrypting “VOLUMENAME” where the name of the volume is in quotes.

Before you can encrypt a volume from the command line you must first convert it to CoreStorage if it isn’t already. As volumes on external disks aren’t likely to be CoreStorage, let’s check using diskutil along with corestorage and then list:

diskutil corestorage list

Assuming your volume was already formatted with a non-corestorage format and isn’t listed, locate the volume and document the disk identifier (in this case disk2s3). Then, run diskutil corestorage along with the convert verb and the disk, as follows (no need to run this command if it’s already listed):

sudo diskutil corestorage convert disk2s3

The output should look similar to the following:

Started CoreStorage operation on disk2s3 Reco
Resizing disk to fit Core Storage headers
Creating Core Storage Logical Volume Group
Attempting to unmount disk2s3
Switching disk2s3 to Core Storage
Waiting for Logical Volume to appear
Mounting Logical Volume
Core Storage LVG UUID: 19D34AAA-498A-44FC-99A5-3E719D3DB6FB
Core Storage PV UUID: 2639E13A-250D-4510-889A-3EEB3B7F065C
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Core Storage disk: disk4
Finished CoreStorage operation on disk2s3 Reco

Once converted, the LV UUID (LV is short for Logical Volume) can be used to encrypt the logical volume using a password of crowbar to unlock it:

sudo diskutil corestorage encryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar

The output is similar to the following:

Started CoreStorage operation on disk4 Reco
Scheduling encryption of Core Storage Logical Volume
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Finished CoreStorage operation on disk4 Reco

According to the size, this process can take some time. Monitor the progress using the corestorage list option:

diskutil corestorage list

In all of these commands, replace core storage w/ cs for less typing. I’ll use the shortened version as I go. I know that we rarely change passwords, but sometimes it needs to happen. If it needs to happen on a core storage encrypted volume, this can be done from the command line or a script. To do so, use diskutil cs with the changevolumepassphrase option. We’ll use -oldpassphrase to provide the old password and -newpassphrase to provide the new passphrase.

diskutil cs changeVolumePassphrase FC6D57CD-15FC-4A9A-B9D7-F7CF26312E00 -oldpassphrase crowbar -newpassphrase hedeservedit

I continue to get prompted when I send the -newpassphrase, so I’ve taken to using stdin , using -stdinpassphrase. Once encrypted there will occasionally come a time for decrypting, or removing the encryption, from a volume. It’s worth noting that neither encrypting or decrypting requires erasing. To decrypt, use the decryptVolume verb, again with the -passphrase option:

diskutil cs decryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar

FileVault 2: Encrypting Boot Volumes

Boot volumes are configured a bit differently. This is namely because the boot volume requires FileVault 2, which unifies usernames and passwords with the encryption so that users enter one username and password rather than unlocking drives. To configure FileVault 2, open the Security & Privacy System Preference pane and then click on the FileVault tab. Click on the lock to make changes and then provide the password for an administrative account of the system. Then, click on “Turn On FileVault…”

encrypt3

If there are multiple users, enable each user who should be able to boot the system. On a server, this only needs to be administrators as you likely don’t have the password for end users.

encrypt4

When prompted with the Recovery Key, document it and then click on Continue. Choose whether to restore the recovery key with Apple. If you will be storing the key with Apple then provide the AppleID. Otherwise, simply click the bullet for “Do not store the recovery key with Apple” and then click on the Continue button.

When prompted, click on Restart to reboot and be prompted for the first account that can unlock the FileVaulted system.

encrypt5

Once encrypted, the FileVault tab in the Security & Privacy System Preference pane shows the encryption status, or percent during encryption.

Use the Enable Users… button to enable additional accounts to unlock the volume (note: by default accounts cannot login until their account has been added here).

That’s it. Managing FileVault 2 using the System Preferences is about as easy as it can get. But for those who require mass management, Apple has provided a tool called fdesetup for that as well.

Using fdesetup with FileVault 2

FileVault 2 now comes with a nifty configuration utility called fdesetup. To use fdesetup to encrypt the boot volume, first check FileVault’s status by entering the fdesetup command along with the –status option (wait, no — required any more!):

fdesetup status

As with most other commands, read the help page before starting to use just in case there are any changes to it between the writing of this article and when you kick off your automated encryption. Done using the help verb:

fdesetup help

After confirming FileVault is off, enable FileVault with the enable option, as follows:

sudo fdesetup enable

Unless additional parameters are specified, an interactive session prompts for the primary user’s short name and password. Once enabled, a Recovery key is returned by the fdesetup command. You can also cancel this by just hitting Control-C so we can look at more complicated iterations of the command. It should be recorded or otherwise stored, something easily done by mounting in a script (e.g. a write-only share in a script for key escrowing). If more complicated measures are needed, of course check out Cauliflower Vest at code.google.com. The fdesetup command is now at version 2.36:

fdesetup version

Now, if you run fdesetup and you’ve deployed a master keychain then you’re going to have a little more work to do; namely point the -keychain command at the actual keychain. For example:

sudo fdesetup enable -keychain /Library//Keychains/FileVaultMaster.keychain

To define a certificate:

sudo fdesetup enable -certificate /temp/filename.cer

Adding additional users other than the one who enabled fdesetup is a bit different than the first:

sudo fdesetup add -usertoadd robin

To remove users, just remove them with a remove verb followed by the -user option and the username:

sudo fdesetup remove -user robin

The remove and add options also offer using the -uuid rather than the username. Let’s look at Robin’s uid :

dscl . read /Users/robin GeneratedUID | cut -c 15-50

Yes, I used cut. If you have a problem with that then take your judgmental fuc… Nevermind. Take that GUID and plug it in as the uuid using the -uuid option. For example, to do so with the remove verb:

sudo fdesetup remove -uuid 31E609D5-39CF-4A42-9F24-CFA2B36F5532

Or for good measure, we can basically replicate -user w/ -uuid for a nice stupid human trick:

sudo fdesetup remove -uuid `dscl . read /Users/robin GeneratedUID | cut -c 15-50`

All of the fdesetup commands can be run interactively or using options to define the variables otherwise provided in the interactive prompt. These are defined well in the man page. Finally, let’s look at -defer. Using -defer, you can run the fdesetup tool at the next login, write the key to a plist and then grab it with a script of some sort later.

sudo fdesetup enable -defer /temp/fdesetupescrow.plist

Or define users concurrently (continuing to use the robin test user):

sudo fdesetup enable -user robin -defer /temp/fdesetupescrow.plist

FileVault accounts can also use accounts from Directory Services automatically. These need to synchronize with the Directory Service routinely as data is cached. To do so:

sudo fdesetup sync

This is really just scratching the surface of what you can do with fdesetup. The definitive source for which is the man page as well as a nicely done article by Rich Trouton.

Encrypting Time Machine Backups

The last full disk encryption to discuss is Time Machine. To encrypt Time Machine backups, use Time Machine’s System Preference pane. The reason for this being that doing so automatically maintains mounting information in the Operating System, rather than potentially having an encrypted drive’s password get lost or not entered and therefore not have backups run.

To enable disk encryption for Time Machine destinations, open the Time Machine System Preference pane and click on Select Backup Disk… From the backup disk selection screen, choose your backup target and then check the box for “Encrypt backups”. Then, click on Use Disk.

At the overlay screen, provide a backup password twice and if you would like, a hint as to what that password is. When you are satisfied with your passwords, click on the Encrypt Disk button.

Now, there are a couple of things to know here. 1. Don’t forget that password. 2. If you use an institutional FileVault Key then still don’t forget that password as it will not work. 3. Don’t forget that password…

Scripty CLI Stuff

We’ve always been able to enable FileVault using scripts thanks to fdesetup but now Apple’s taken some of the difficulty out of configuring recovery keys. This comes in the form of the changerecovery, haspersonalrecoverykey, hasinstitutionalkey, usingrecoverykey and validate recovery options. These options all revolve around one idea: make it easier to deploy centrally managed keys that can be used to unlock encrypted volumes in the event that such an action is required. There’s also a -recoverykey option, which indicates the number of the key if a recovery key is being used.

To use the fdesetup command to check whether a computer has a personal recovery key use the haspersonalrecoverykey verb, as follows:

fdesetup haspersonalrecoverykey

The output will be a simple true or false exit. To use the fdesetup command to check whether a computer has an institutional recovery key, use the hasinstitutionalrecoverykey verb, as follows:

fdesetup hasinstitutionalrecoverykey

To enable a specific personal recovery key, provide it using the changerecovery verb, as follows:

fdesetup changerecovery -personal

This is an interactive command, so when prompted, provide the appropriate personal key. The removerecovery verb can also be used to remove keys. And my favorite, validaterecovery is used to check on whether or not a recovery key will work to unlock a host; which can be tied into something like an extension attribute in Casper in order to store a key and then validate the key every week or 4. This helps to make sure that systems are manageable if something happens.

The enable verb also has a new -authrestart which does an authenticated reboot after enabling FileVault. Before using the -authrestart option, check that a system can actually run it by using fdesetup with the supportsauthrestart verb and it will exit on true or false.

Defer mode is nothing new, where FileVault waits until a user password is provided; however, a new verb is available called showdeferralinfo which shows information about deferral mode. This is most helpful as a sanity check so you don’t go running commands you already ran or doing things to systems that have already been provided with tasks to perform otherwise.

Overall, there’s a lot of really enterprise-friendly options new in Yosemite that those who do larger-scale deployments of Yosemite will be interested in using!

Conclusion

Encrypting data in OS X can take on other forms as well. The keychains encrypt passwords and other objects. Additionally, you can still create encrypted dmgs and many file types have built in encryption as well. But the gist is that Apple encrypts a lot. They also sandbox a lot and with the addition of gatekeeper are code signing a lot. But encrypting volumes and disks is mostly about physical security, which these types of encryption provide a substantial solution for.

While all this security might seem like a lot, it’s been in Apple’s DNA for a long time and really security is about layers and the Mac Systems Administrator batbelt needs a lot of items to allow us to adapt to the changing landscape of security threats. OS X is becoming a little more like iOS as can be expected and so I would suspect that encryption will become more and more transparent as time goes on. Overall, the options allow encrypting every piece of data that goes anywhere near a system. The mechanisms with which data is now encrypted are secure, as is the data at rest. Once data is decrypted, features like Gatekeeper and the application layer firewall supplement traditional network encryption to keep well secured.

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

Yosemite Server And Logs

OS X Yosemite running the Server app has a lot of scripts used for enabling services, setting states, changing hostnames and the like. Once upon a time there was a script for OS X Server called server setup. It was a beautiful but too simplistic kind of script. Today, much of that logic has been moved out into more granular scripts, kept in /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in Yosemite Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python. And the scripts tend to change year over year/release over release.

One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of OS X Server intend for certain tasks to occur.

Looking At Services

This is also where I learned that Apple had put an Open Directory backup script in /Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup/opendirectorybackup (that still requires a password). But what I haven’t seen in all of these logs is bumping up the logging level for services before performing tasks, so that you can see a verbose output of what’s going on. To do this, it looks like we’re going service-by-service. So let’s look alphabetically, starting with Address Book:

sudo serveradmin settings addressbook:DefaultLogLevel = “warn”

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings addressbook:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings addressbook:ErrorLogFile=error.log

You can change either by changing what comes after the = sign. Next is afp. This service logs output to two places. The first is with errors to the service, using /Library/Logs/AppleFileService/AppleFileServiceError.log, the path designated in the following:

sudo serveradmin settings afp:errorLogPath = “/Library/Logs/AppleFileService/AppleFileServiceError.log”

The second location logs activities (open file, delete file, etc) rather than errors and is /Library/Logs/AppleFileService/AppleFileServiceAccess.log, defined using:

sudo serveradmin settings afp:activityLogPath = “/Library/Logs/AppleFileService/AppleFileServiceAccess.log”

The activity log is disabled by default and enabled using the command:

sudo serveradmin settings afp:activityLog = yes

The events that trigger log entries are in the afp:loggingAttributes array and are all enabled by default. There are no further controls for the verbosity of the afp logs. The next service is calendar. Similar to address book, the caldav server uses DefaultLogLevel to set how much data gets placed into logs:

sudo serveradmin settings calendar:DefaultLogLevel = “warn”

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings calendar:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings calendar:ErrorLogFile=error.log

You can changing either by changing what comes after the = sign.
Profile Manager is called devicemgr in the serveradmin interface and I’ve found no way to augment the logging levels. Nor does its migration script ( /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/80-devicemgrmigration.sh ) point to any increased logging during migration.

The dirserv (aka Open Directory) uses the slapconfig back-end, so I use slapconfig to increase logging:

sudo slapconfig -enableslapdlog

The DNS service uses named.conf, located in /etc to set log levels and has no serveradmin settings for doing so. Here, use the logging section and look for both the file setting (by default /Library/Logs/named.log) for where the log is stored as well as the severity setting, which can set the logging levels higher or lower.

By default Messages, or iChat Server, logs a lot. See the following for what is logged:

sudo serveradmin settings jabber:logLevel = “ALL”

Adding the -D option to the LaunchDaemon that invokes jabber will increase the logs. Logging long-term is handled in each of the xml files that make up the features of jabber. See the Logconfiguration section of the c2s file via:

cat /Applications/Server.app/Contents/ServerRoot/private/etc/jabberd/c2s.xml

The mail service has a number of options for logging, much of which has to do with the fact that it’s a patchy solution made up of postfix, etc. Global log locations are controlled using the mail:global:service_data_path key, which indicates a path that logs are stored in (as usual many of these are in /Library/Server):

sudo serveradmin settings mail:global:service_data_path = "/Library/Server/Mail"

To see the virus database logging levels (which should usually be set to warn):

sudo serveradmin settings mail:postfix:virus_db_log_level

To see the spamassassin logging levels:

sudo serveradmin settings mail:postfix:spam_log_level

To see the actual postfix logging level:

sudo serveradmin settings mail:postfix:log_level

To enable timestamps on logs:

sudo serveradmin settings mail:imap:logtimestamps = yes

To set the dovecot logging to info:

sudo serveradmin settings mail:imap:log_level = “info”

To set increased logging per function that dovecot performs, see the config files in /Applications/Server.app/Contents/ServerRoot/private/etc/dovecot/default/conf.d, each of which has a logging section to do so.

The NetBoot service is simple to configure logging for, simply set the netboot:logging_level to HIGH (by default it’s MEDIUM):

sudo serveradmin settings netboot:logging_level = “HIGH”

The Postgres service uses a log directory, configured with postgres:log_directory:

sudo serveradmin settings postgres:log_directory = “/Library/Logs/PostgreSQL”

The /private/etc/raddb/radiusd.conf has a section (log {}) dedicated to configuring how the radius service logs output.

The Xsan service logs output per volume to both the System Log and volume-based log files, stored in /Library/Preferences/Xsan/data.

The smb service has a file /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist with a key for log level that can be used for more verbose output of the service.

The PPTP VPN service logs output to the file specified in vpn:Servers, configured with these:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:LogFile = “/var/log/ppp/vpnd.log”
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:LogFile = “/var/log/ppp/vpnd.log”

By default, verbose logging is enabled, which you can see with:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:VerboseLogging

The last service is web (Apache). The default access logs are per-site, with a key called customLogPath existing for each. The defaultSite uses the following for its logs:

sudo serveradmin settings web:defaultSite:customLogPath

Swap out the defaultSite with another site to see its log paths. There’s also a key for errorLogPath that shows errors. These are per-site so that administrators can provide access to logs for the owners of each site and not fear them having access to logs for other users. Global error logs are stored in /private/var/log/apache2/error_log as defined in /private/etc/apache2/httpd.conf. Find LogLevel in this file and set it to configure how in depth the logs will be, using debug for the most verbose and info, notice, warn, error, crit, alert, and emerg to get incrementally less information.

Additionally the log formats can be set in /private/etc/apache2/httpd.conf, allowing administrators to configure Yosemite Server’s built-in web service to conform to the standards of most modern web log analyzers.

Conclusion

Overall, there’s a lot of information in these logs and administrators can spend as much time reviewing logs as they want. But other than standard system logs, the output is typically configured on a service-by-service basis. Some services offer a lot of options and others offering only a few. Some services also offer options within the serveradmin environment while others use their traditional locations in their configuration files. I’ll end this with a warning. There can also be a lot of output in these logs. Therefore, if you set the logging facilities high, make sure to keep a watchful eye on the capacity of the location you’re writing logs out to. The reason I looked at paths to logs where applicable was because you might want to consider redirecting logs to an external volume when debugging so as not to fill up a boot volume and cause even more problems than what you’re likely parsing through logs looking to fix…

Mac Security

Need A Password? There’s An App For That!

Remember this comic:

Regrettably, password policies don’t allow for a few random words at most organization, so a special character, a capital letter and a number are basically required in most passwords these days. However, if you need a quick and dirty generator that includes a phrase and those additional characters, consider MyPhrase from Björn Albers. It’s simple to use, fast and easy. Good luck out there!

iPhone_6_Vert_SpaceGray_sRGB_0914