Tiny Deathstars of Foulness

Stoked that we got to interview Michael Lynn (@mikeymikey) for the MacAdmins podcast. It turned out to be a great episode on the future of Mac management and MDM. I’m glad we were able to have him join in! Pepijn and Marcus did a great job as well, so all round, a great episode. Hope you enjoy!

Or find it on the Podcast site at

October 24th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, MacAdmins Podcast

Tags: , , , , , ,

Leave a Comment

Automating OS installations is going to eventually be about as easy on macOS as it is in iOS (er, if you have MDM that is). But in the meantime, it’s getting a bit more challenging. The obvious way Apple would prefer this to happen these days is via the startosinstall command that first shipped with El Capitan and with brtool getting moved around all the time, and becoming less of a thing, there’s one quick and easy thing you can do:

sudo "/Applications/Install macOS" --applicationpath "/Applications/Install macOS" --agreetolicense --nointeraction --volume /Volumes/Macintosh\ HD

In the above command, we’ve dropped “Install macOS” on a machine. While you’d guess that it would find the application path based on its own surname, we went ahead and supplied it as that seems to basically be a thing. Basically, –agreetolicense keeps us from having to run some expect scripts to accept a license agreement, –nointeraction suppresses as many of the screens as possible, and –volume allows us to install to any volume we’d like. This isn’t fully automated, but I have been able to layer in some more logic to quit apps before the script fires and then expect out other items from the script to automate a restart, watching for osinstallersetupd as a key.

This is all a bit bulkier than just using something like createOSXinstallPkg but it’s important to mention that there are a number of system components that are allowed for in SIP that use osinstallersetupd and so this blessed mechanism is likely the future until you can trigger an OS upgrade (and update I suppose) using an MDM command.

October 23rd, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , , ,

Leave a Comment

macOS Server has long had a VPN service to allow client computers to connect to a network even when they’re out of the office. The server was once capable of running the two most commonly used VPN protocols: PPTP and L2TP. And while PPTP is still accessible via the command line, L2TP is now configured by default when you setup the server using the Server app.

Setting Up The VPN Service In OS X Server

To setup the VPN service, open the Server app and click on VPN in the Server app sidebar. The VPN Settings  screen has a number of options available, as seen here.


The VPN Host Name field is used by administrators leveraging profiles. The setting used becomes the address for the VPN service in the Everyone profile. L2TP requires a shared secret or an SSL certificate. In this example, we’ll configure a shared secret by providing a password in the Shared Secret field. Additionally, there are three fields, each with an Edit button that allows for configuration:

  • Client Addresses: The dynamic pool of addresses provided when clients connect to the VPN.


  • DNS Settings: The name servers used once a VPN client has connected to the server. As well as the Search Domains configuration.


  • Routes: Select which interface (VPN or default interface of the client system) that a client connects to each IP address and subnet mask over.


  • Save Configuration Profile: Use this button to export configuration profiles to a file, which can then be distributed to client systems (macOS using the profiles command, iOS using Apple Configurator or both using Profile Manager).
  • Shared Secret: A passphrase that must be supplied by the client prior to getting a username and password prompt.

Once configured, open incoming ports on the router/firewall. While deprecated(ish) PPTP runs over port 1723. L2TP is a bit more complicated, running over 1701, but also the IP-ESP protocol (IP Protocol 50). Both are configured automatically when using Apple AirPorts as gateway devices. Officially, the ports to forward are listed at

Using The Command Line

I know, I’ve described ways to manage these services from the command line before. The serveradmin command can be used to manage the service as well as the Server app. The serveradmin command can start the service, using the default settings, with no further configuration being required:

sudo serveradmin start vpn

And to stop the service:

sudo serveradmin stop vpn

And to list the available options:

sudo serveradmin settings vpn

The output of which shows all of the VPN settings available via serveradmin (which is many more than what you see in the Server app:

vpn:vpnHost = "" = "/var/log/ppp/vpnd.log" = 1 = 128 = "jamfsw.corp" = "" = "" = "" = "1" = "" = "2" = "" = "vpn/" = no = "PPTP" = "PPP" = 5 = 1 = "EAP-RSA" = "DSACL" = 1 = 0 = 1 = 1 = 60 = 1 = "MSCHAP2" = 0 = "DSAuth" = "/var/log/ppp/vpnd.log" = 1 = 7200 = "MPPE" = _empty_array = "" = "" = _empty_array = _empty_array = "Manual" = "" = 128 = 0 = "/var/log/ppp/vpnd.log" = 1 = "jamfsw.corp" = "" = "" = "" = "1" = "" = "2" = "" = "vpn/" = yes = "L2TP" = "PPP" = 5 = 1 = "EAP-KRB" = "DSACL" = 1 = 0 = 1 = 60 = 1 = "MSCHAP2" = "DSAuth" = "/var/log/ppp/vpnd.log" = 7200 = "Keychain" = "" = "" = "SharedSecret" = "" = "None" = <> = _empty_array = "" = "" = _empty_array = _empty_array = "Manual" = "IPSec" = "Yq!XdGsVyAY?o;9jnj[X"

To disable L2TP, set to no:

sudo serveradmin settings = no

To configure how long a client can be idle prior to being disconnected:

sudo serveradmin settings = 10

By default, each protocol has a maximum of 128 sessions, configureable using

sudo serveradmin settings = 200

To see the state of the service, the pid, the time the service was configured, the path to the log files, the number of clients and other information, use the fullstatus option:

sudo serveradmin fullstatus vpn

Which returns output similar to the following:

vpn:servicePortsAreRestricted = "NO"
vpn:readWriteSettingsVersion = 1 = "MSCHAP2" = 0 = yes = "MPPEKeySize128" = "PPP" = "PPTP" = "DSAuth" = "MSCHAP2" = "PPP" = yes = 0 = "L2TP" = "DSAuth"
vpn:servicePortsRestrictionInfo = _empty_array
vpn:health = _empty_dictionary
vpn:logPaths:vpnLog = "/var/log/ppp/vpnd.log"
vpn:configured = yes
vpn:state = "STOPPED"
vpn:setStateVersion = 1

Security folk will be stoked to see that the shared secret is shown in the clear using:

Configuring Users For VPN Access

Each account that accesses the VPN server needs a valid account to do so. To configure existing users to use the service, click on Users in the Server app sidebar.


At the list of users, click on a user and then click on the cog wheel icon, selecting Edit Access to Services.


At the Service Access screen will be a list of services that could be hosted on the server; verify the checkbox for VPN is highlighted for the user. If not, click Manage Service Access, click Manage and then check the VPN box.


Setting Up Client Computers

As you can see, configuring the VPN service in macOS Server 5.2 (running on Sierra) is a simple and straight-forward process – much easier than eating your cereal with a fork and doing your homework in the dark.. Configuring clients is as simple as importing the profile generated by the service. However, you can also configure clients manually. To do so on a Mac, open the Network System Preference pane. From here, click on the plus sign (“+”) to add a new network service.


At the prompt, select VPN in the Interface field and then either PPTP or L2TP over IPSec in the VPN Type. Then provide a name for the connection in the Service Name field and click on Create.


At the list of network interfaces in the Network System Preference pane, provide the hostname or address of the server in the Server Address field and the username that will be connecting to the VPN service in the Account Name field. If using L2TP, click on Authentication Settings.


At the prompt, provide the password entered into the Shared Secret field earlier in this article in the Machine Authentication Shared Secret field and the user’s password in the User Authentication Password field. When you’re done, click OK and then provided you’re outside the network and routeable to the server, click on Connect to test the connection.


Setting Up the VPN service in macOS Server 5.2 is as simple as clicking the ON button. But much more information about using a VPN can be required. The natd binary is still built into OS X at /usr/sbin/natd and can be managed in a number of ways. And if you’re using an Apple AirPort as a router (hopefully in a very small environment) then the whole process of setting this thing up should be super-simple.

October 16th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , , ,

One Comment

The changes in the Server app were far more substantial in the El Capitan version (OS X Server 5) than in the macOS Server 5.2 version that we’re now looking at. All of the options from OS X are still there and the dnsconfig command line interface for managing the service are basically unchanged. The DNS service in OS X Server, as with previous versions, is based on bind 9 (BIND 9.9.7-P3 to be exact). This is very much compatible with practically every DNS server in the world, including those hosted on Windows, OS X, Linux and even Zoe-R.

The first time you open the DNS Service click on the DNS service in the ADVANCED section of the list of SERVICES.


Then, click on the cog wheel icon below the list of records and click on Show All Records.


At the Records screen, you’ll now see forward and reverse record information. Click the Edit… button for the Forwarding Servers field. Here, you’ll be able to enter a Forwarders, or DNS servers that resolve names that the server you’re using can’t resolve using its own DNS records.


Click the plus sign to enter the IP address of any necessary Forwarders. Enter the IP address of any Forwarding servers, then click OK to save your changes.


Once back at the main DNS service control screen, click the Edit… button for Perform lookups for to configure what computers the DNS server you are setting up can use the DNS service that the server is hosting.


At the Perform Lookups screen, provide any additional subnets that should be used. If the server should be accessible by anyone anywhere, just set the “Perform lookups for” field at the DNS service screen to “all clients”.

All you have to do to start the DNS is click on the ON button (if it’s not already started, that is). There’s a chance that you won’t want all of the records that are by default entered into the service. But leave it for now, until we’ve covered what everything is. To list the various types of records:

  • Primary Zone: The DNS “Domain”. For example, would likely have a primary zone of
  • Machine Record: An A record for a computer, or a record that tells DNS to resolve whatever name is indicated in the “machine” record to an IP address, whether the IP address is reachable or not.
  • Name Server: NS record, indicates the authoritative DNS server for each zone. If you only have one DNS server then this should be the server itself.
  • Reverse Zone: Zone that maps each name that IP addresses within the zone answer with. Reverse Zones are comprised of Reverse Mappings and each octal change in an IP scheme that has records mapped represents a new Reverse Zone.
  • Reverse Mapping: PTR record, or a record that indicates the name that should respond for a given IP address. These are automatically created for the first IP address listed in a Machine Record.
  • Alias Record: A CNAME, or a name that points to another name.
  • Service Record: Records that can hold special types of data that describe where to look for services for a given zone. For example, iCal can leverage service records so that users can just type the username and password during the setup process.
  • Mail Exchanger Record (aka MX record): Mail Exchanger, points to the IP address of the mail server for a given domain (aka Primary or Secondary Zone).
  • Secondary Zone: A read only copy of a zone that is copied from the server where it’s a Primary Zone when created and routinely through what is known as a Zone Transfer.


When you click on the plus sign, you can create additional records. Double-clicking on records (including the Zones) brings up a screen to edit the record. The settings for a zone can be seen below.


These include the name for the zone. As you can see, a zone was created with the hostname rather than the actual domain name. This is a problem if you wish to have multiple records in your domain that point to the same host name. Theoretically you could create a zone and a machine record for each host in the domain, but the right way to do things is probably going to be to create a zone for the domain name instead of the host name. So for the above zone, the entry should be rather than (the hostname of the computer). Additionally, the TTL (or Time To Live) can be configured, which is referenced here as the “Zone data is valid for” field. If you will be making a lot of changes this value should be as low as possible (the minimum value here is 5 minutes). Once changes are made, the TTL can be set for a larger number in order to reduce the amount of traffic hitting the server (DNS traffic is really light, so probably not a huge deal in most environments using a macOS Server as their DNS server). Check the box for “Allow zone transfers” if there will be other servers that use this server to lookup records.

Additionally, if the zone is to be a secondary zone configured on another server, you can configure the frequency to perform zone transfers at this screen, how frequently to perform lookups when the primary name server isn’t responsive and when to stop bothering to try if the thing never actually ends up coming back online. Click on Done to commit any changes made, or to save a new record if you’re creating a new zone.

“Note: To make sure your zone name and TLD don’t conflict with data that already exists on the Internet, check here to make sure you’re not using a sponsored TLD.” —

Double-click on a Machine record next (or click plus to add one). Here, provide a hostname along with an IP address and indicate the Zone that the record lives in. The IP Addresses field seems to allow for multiple IPs, which is common in round robin DNS, or when one name points to multiple servers and lookups rotate amongst the servers. However, it’s worth mentioning that when I configure multiple IP addresses, the last one in the list is the only one that gets fed to clients. Therefore, for now at least, you might want to stick with one IP address per name.

Screen Shot 2015-09-08 at 10.29.37 PM

Note that the above screen has the domain in the zone field and the name of a record, such as www for the zone called, for example, krypted.lan. Click Done to commit the changes or create the new record.

Next, let’s create a MX record for the domain. To create the MX for the domain, click on the plus sign at the list of records.

Screen Shot 2015-09-08 at 10.31.46 PM

Select the appropriate zone in the Zone field (if you have multiple zones). Then type the name of the A record that you will be pointing mail to. Most likely, this would be a machine record called simply mail, in this case for krypton.lan, so mail.krypted.lan. If you have multiple MX records, increment the priority number for the lower priority servers.

As a full example, let’s create a zone and some records from scratch. Let’s setup this zone for an Xsan metadata network, called krypted.xsan. Then, let’s create our metadata controller record as starbuck.krypted.xsan to point to and our backup metadata controller record as apollo.krypted.xsan which points to First, click on the plus sign and select Add Primary Zone.

Screen Shot 2015-09-08 at 10.33.11 PM

At the zone screen, enter the name of the domain you’re setting up (e.g., also known as the zone), check the box for Allow zone transfers (there will be a second server) and click on the Done button. Click on the plus sign and then click on Add Machine record.


At the New Machine Record screen, select the appropriate zone as the Zone and then enter starbuck as the Host Name and click on the plus sign for IP Addresses and type in the appropriate IP. Click on Done to commit the changes. Repeat the process for each host that needs an address and then click Done to create the records.

Setting Up Secondary Servers

Now let’s setup a secondary server by leveraging a secondary zone running on a second computer. On the second macOS Server, click on the plus sign for the DNS service and select Add Secondary Zone.


At the Secondary Zone screen, enter krypted.xsan as the name of the zone and then the IP address of the DNS server hosting that domain in the Primary Servers field. Click Done and the initial zone transfer should begin once the DNS service is turned on (if it hasn’t already been enabled).

Managing DNS From The Command Line

Now, all of this is pretty straight forward. Create a zone, create some records inside the zone and you’re good to go. But there are a lot of times when DNS just needs a little more than what the Server app can do for you. For example, round robin DNS records, bind views, etc. Therefore, getting used to the command line is going to be pretty helpful for anyone with more than a handful of records. The first thing to know about the DNS command line in macOS Server is to do everything possible using the serveradmin command for global management and dnsconfig for record and zone management. Once you start editing configuration files, the user interface can become unstable and other updates may or may not override the updates you make in those configuration files.

To start the service, use the start option:

sudo serveradmin start dns

To stop the service, use the stop option:

sudo serveradmin stop dns

To get the status of the service, including how many zones are being hosted, the last time it was started, the status at the moment, the version of bind (9.8.1 right now) and the location of the log files, use the fullstatus option:

sudo serveradmin fullstatus dns

A number of other tasks can be performed using the settings option. For example, to enable Bonjour Client Browsing, an option previously available in Server Admin, use the following command:

sudo serveradmin settings dns:isBonjourClientBrowsingEnabled = yes

Subnets can be created programmatically through serveradmin as well. Let’s look at what our krypted.xsan subnet looks like, by default (replace your zone name w/ krypted.xsan to see your output):

sudo serveradmin settings

Now, let’s say we’d like to disable bonjour registration of just this zone, but leave it on for the others on the server:

sudo serveradmin settings = no

The entire block can be fed in for new zones, if you have a lot of them. Just remember to always make sure that the serial option for each zone is unique. Otherwise the zones will not work properly.

While serveradmin is one way to edit zone data, it isn’t the only way, you can also use the dnsconfig options described in In /private/var/named are a collection of each zone the server is configured for. Secondary zones are flat and don’t have a lot of data in them, but primary zones contain all the information in the Server app and the serveradmin outputs. To see the contents of our test zone we created, let’s view the /Library/Server/named/db.krypted.xsan file (each file name is db. followed by the name of the zone):

cat /var/named/db.krypted.xsan

Add another record into the bottom and stop/start DNS to immediately see the ramification of doing so. Overall, DNS is one of those services that seems terribly complicated at first. But once you get used to it, I actually find manually editing zone files far faster and easier than messing around with the Server app or previously Server Admin. However, I also find that occasionally, because the Server app can make changes in there that all my settings will vanish.

Troubleshooting is another place where the command line can be helpful. While logs can be found in the Server app, I prefer to watch log entries live as I perform lookups using the /Library/Logs/named.log file. To do so, run tail -f followed by the name of the file:

tail -f /Library/Logs/named.log

Also, see for information on forcing DNS propagation if you are having issues with zone transfers. Finally, you can manage all records within the DNS service using the new /Applications/ command line tool. I’ve written an article on managing DNS using this tool, available here.

October 13th, 2016

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , , , , , , ,

Leave a Comment

Mail is one of the hardest services to manage. Actually, mail is pretty simple in and of itself: there’s protocols people use to access their mail (such as IMAP and POP), protocols used to communicate between mail servers and send mail (SMTP, SMTPS) and then there’s a database of mail and user information. In macOS Server 5.2 for Sierra, all of these are represented by a single ON button, so it really couldn’t be easier. But then there’s the ecoysystem and the evil spammers.

As the former systems administrator of a large number of mail servers, I firmly believe that there is a special kind of hell where only spam is served at every meal for spammers. Here, the evil spammers must also read every piece of spam ever sent for eternity. By the end (aka Ragnarok), they should have the chemically induced stamina of a 16 year old with the latest Sports Illustrated Swimsuit issue, enough pills of other types to not be able to use that stamina, plenty of African princes looking to donate large sums of money if only they can be helped out of their country (which should cost about 100,000 compared to a 5,000,000 payout, not a bad ROI, right?!?!?), have their conflicting stamina situation at the top of the search engines and of course, have lost all of the money made from their African princes due to getting their credit card hijacked by about 9,000 phishing scams. All in all, a special kind of hell…

But back to the point of the article, setting up mail. The things that mail administrators need to focus on to keep that mail server flowing mail to and from everyone else in the world:

  • Static IP address. The WAN (and LAN probably) address should be static.
  • Port Forwards. Port forwards need to be configured on the gateway for the SMTP port at a minimum and more than likely other ports used to access mail on client devices (25, 143, etc)
  • DNS records. An MX record and some kind of type of record should definitely be configured for the DNS servers that are authoritative for the domain. There should also be reverse records for the address of the server, usually created by the Internet Services Provider, or ISP, that match that record.
  • Check the RBLs. If you have a new IP address you’ll be putting a DNS server on, check all the major Realtime BlackLists to make sure that some evil spammer hasn’t squatted on the IP before you got to it. This is true whether you’re in a colo, hosted on an IP you own or moving into space formerly occupied by a very standup company. A lot of IP addresses are blocked, as are blocks of IPs, so before moving mail to an IP, check it.
  • Mail filtration (message hygiene). OS X Server has a number of mail filters built in, including clam for viruses, the ability to leverage RBLs, block specific addresses and of course RBL checking. However, this is often not enough. Third party services such as MXLogic help to keep mail from coming into your network. You also end up with an external IP to send mail that can cache mail in the event the server is down and keep mail off your network in the event that it’s spam.
  • Backup. I am firmly of the belief that I’d rather not have data than not have that data backed up…

Once all of that is taken care of (I’ll add more as I think about it) then it’s time to enable the mail service in the Server app running on Yosemite. Actually, first let’s setup our SSL certificates. To do so, open the Server app and click on Certificates in the SERVER section of the sidebar. Here, use the “Secure services using” drop-down list and click on Custom… for each protocol to select the appropriate certificate to be used for the service.


Click OK when they’re all configure. Now let’s enable the mail service (or outsource mail). To do so, open the Server app and click on Mail in the SERVICES list in the sidebar.


At the configuration screen is a sparse number of settings:

  • Edit Permissions: Limits the IP addresses capable of connecting to the server.
  • Domains: Configures all of the domains the mail server will listen for mail for. Each account on the server has a short name and each domain name will be available for each short name. For example, an account with a shortname of charles will be available for email addresses of and per the Domain Name listing below.screen-shot-2016-09-26-at-9-35-20-pm
  • Authentication: Click Edit for a list of sources that accounts can authenticate against (e.g. Active Directory, Open Directory, Custom, Local, etc) and in some cases the specific password algorithms used for mail.screen-shot-2016-09-26-at-9-35-49-pm
  • Push Notifications: If Push is configured previously there’s no need to use this option. Otherwise, use your institutional APNS account to configure Push Notifications.screen-shot-2016-09-26-at-9-36-13-pm
  • Relay outgoing mail through ISP: Provide a server that all mail will get routed through from the server. For example, this might be an account with your Internet Services Provider (ISP), an account on an appliance that you own (such as a Barracuda) or with an external filtering service (such as MXLogic).screen-shot-2016-09-26-at-9-36-45-pm
  • Mailbox size: Configure the total amount of mail a user can have in the mail store, in Megabytes.
  • Edit Filtering Settings: Configure antivirus, spam assassin and junk mail filters. The “Enable virus filtering” checkbox enables clam. The “Enable blacklist filtering” checks the RBL (or RBLs) of your choice to check whether a given server is a “known” spammer and the “Enable junk mail filtering” option enables spam assassin on the host, configuring it to block based on a score as selected using the slider.

Once you’ve configured the settings for the Mail service, click on the ON slider to enable the service. At this point, you should be able to telnet into port 25 of the host to verify that SMTP is listening, preferably from another mail server:

telnet 25

You can also check that the mail services are running using the serveradmin command along with the fullstatus option for the mail service:

sudo serveradmin fullstatus mail

Which returns with some pretty verbose information about the service, including state, connections, running protocols and the rest of the following:

mail:startedTime = ""
mail:setStateVersion = 1
mail:state = "STOPPED"
mail:protocolsArray:_array_index:0:status = "ON"
mail:protocolsArray:_array_index:0:kind = "INCOMING"
mail:protocolsArray:_array_index:0:protocol = "IMAP"
mail:protocolsArray:_array_index:0:state = "STOPPED"
mail:protocolsArray:_array_index:0:service = "MailAccess"
mail:protocolsArray:_array_index:0:error = ""
mail:protocolsArray:_array_index:1:status = "ON"
mail:protocolsArray:_array_index:1:kind = "INCOMING"
mail:protocolsArray:_array_index:1:protocol = "POP3"
mail:protocolsArray:_array_index:1:state = "STOPPED"
mail:protocolsArray:_array_index:1:service = "MailAccess"
mail:protocolsArray:_array_index:1:error = ""
mail:protocolsArray:_array_index:2:status = "ON"
mail:protocolsArray:_array_index:2:kind = "INCOMING"
mail:protocolsArray:_array_index:2:protocol = "SMTP"
mail:protocolsArray:_array_index:2:state = "STOPPED"
mail:protocolsArray:_array_index:2:service = "MailTransferAgent"
mail:protocolsArray:_array_index:2:error = ""
mail:protocolsArray:_array_index:3:status = "ON"
mail:protocolsArray:_array_index:3:kind = "OUTGOING"
mail:protocolsArray:_array_index:3:protocol = "SMTP"
mail:protocolsArray:_array_index:3:state = "STOPPED"
mail:protocolsArray:_array_index:3:service = "MailTransferAgent"
mail:protocolsArray:_array_index:3:error = ""
mail:protocolsArray:_array_index:4:status = "OFF"
mail:protocolsArray:_array_index:4:kind = "INCOMING"
mail:protocolsArray:_array_index:4:protocol = ""
mail:protocolsArray:_array_index:4:state = "STOPPED"
mail:protocolsArray:_array_index:4:service = "ListServer"
mail:protocolsArray:_array_index:4:error = ""
mail:protocolsArray:_array_index:5:status = "ON"
mail:protocolsArray:_array_index:5:kind = "INCOMING"
mail:protocolsArray:_array_index:5:protocol = ""
mail:protocolsArray:_array_index:5:state = "STOPPED"
mail:protocolsArray:_array_index:5:service = "JunkMailFilter"
mail:protocolsArray:_array_index:5:error = ""
mail:protocolsArray:_array_index:6:status = "ON"
mail:protocolsArray:_array_index:6:kind = "INCOMING"
mail:protocolsArray:_array_index:6:protocol = ""
mail:protocolsArray:_array_index:6:state = "STOPPED"
mail:protocolsArray:_array_index:6:service = "VirusScanner"
mail:protocolsArray:_array_index:6:error = ""
mail:protocolsArray:_array_index:7:status = "ON"
mail:protocolsArray:_array_index:7:kind = "INCOMING"
mail:protocolsArray:_array_index:7:protocol = ""
mail:protocolsArray:_array_index:7:state = "STOPPED"
mail:protocolsArray:_array_index:7:service = "VirusDatabaseUpdater"
mail:protocolsArray:_array_index:7:error = ""
mail:logPaths:Server Error Log = "/Library/Logs/Mail/mail-err.log"
mail:logPaths:IMAP Log = "/Library/Logs/Mail/mail-info.log"
mail:logPaths:Server Log = "/Library/Logs/Mail/mail-info.log"
mail:logPaths:POP Log = "/Library/Logs/Mail/mail-info.log"
mail:logPaths:SMTP Log = "/var/log/mail.log"
mail:logPaths:List Server Log = "/Library/Logs/Mail/listserver.log"
mail:logPaths:Migration Log = "/Library/Logs/MailMigration.log"
mail:logPaths:Virus Log = "/Library/Logs/Mail/clamav.log"
mail:logPaths:Amavisd Log = "/Library/Logs/Mail/amavis.log"
mail:logPaths:Virus DB Log = "/Library/Logs/Mail/freshclam.log"
mail:imapStartedTime = ""
mail:postfixStartedTime = ""
mail:servicePortsRestrictionInfo = _empty_array
mail:servicePortsAreRestricted = "NO"
mail:connectionCount = 0
mail:readWriteSettingsVersion = 1
mail:serviceStatus = "DISABLED"

To stop the service:

sudo serveradmin stop mail

And to start it back up:

sudo serveradmin start mail

To configure some of the settings no longer in the GUI from previous versions, let’s look at the full list of options:

sudo serveradmin settings mail

One that is commonly changed is the subject line added to messages that are marked as spam by spam assassin. This is stored in mail:postfix:spam_subject_tag, so changing would be:

sudo serveradmin settings mail:postfix:spam_subject_tag = "***DIEEVILSPAMMERSDIE*** "

A number of admins also choose to disable greylisting, done using the mail:postfix:greylist_disable option:

sudo serveradmin settings mail:postfix:greylist_disable = no

To configure an email address for quarantined mail to go, use mail:postfix:virus_quarantine:

sudo serveradmin settings mail:postfix:virus_quarantine = ""

The administrator, by default, doesn’t get an email when an email containing a file infected with a virus is sent through the server. To enable this option:

sudo serveradmin settings mail:postfix:virus_notify_admin = yes

I also find a lot of Mac environments want to accept email of pretty much any size. By default, message size limits are enabled. To disable:

sudo serveradmin settings mail:postfix:message_size_limit_enabled = yes

Or even better, just set new limit:

sudo serveradmin settings mail:postfix:message_size_limit = 10485760

And to configure the percentage of someone’s quota that kicks an alert (soft quota):

sudo serveradmin settings mail:imap:quotawarn = 75

Additionally, the following arrays are pretty helpful, which used to have GUI options:

  • mail:postfix:mynetworks:_array_index:0 = “″ – Add entries to this one to add “local” clients
  • mail:postfix:host_whitelist = _empty_array – Add whitelisted hosts
  • mail:postfix:blacklist_from = _empty_array – Add blacklisted hosts
  • mail:postfix:black_hole_domains:_array_index:0 = “” – Add additional RBL Servers

The client side of the mail service is straight forward enough. If you are wondering where in this article we discuss using webmail, er, that’s not installed by default any longer. But the open source project previously used, roundcube, is still available for download and easily installed (the pre-reqs are all there, already). Check out the roundcube wiki installation page here for more info on that. Also, mail groups. I hope to have a post about that soon enough. Unless, of course, I get sidetracked with having a life. Which is arguably not very likely…

October 11th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , , , ,

Leave a Comment

macOS Server 5.2, running on Sierra, comes with a few new alerting options previously unavailable in versions of OS X. The alerts are sent to administrators via servermgrd and configured in the 5th version of the Server app. To configure alerts on the server, open the Server app and then click on Alerts in the Server app sidebar. Next, click on the Delivery tab.


At the Delivery screen, click on the Edit button for Email Addresses and enter every email address that should receive alerts sent from the server. Then click on the Edit button for Push Notifications. Here, check the box for each administrator of the server. The email address on file for the user then receives push notifications of events from the server.


Click on OK when you’ve configured all of the appropriate administrators for alerting. Click on the Edit… button for Push and if Push notifications are not already enabled you will run through the Push Notification configuration wizard.


Then, check the boxes for Email and Push for each of the alerts you want to receive (you don’t have to check both for each entry). Alerts have changed in macOS Server, they are no longer based on the SMART status of drives or capacity; instead Delivery is now based on service settings.

Finally, as with previous versions of macOS Server, snmp is built in. The configuration file for which is located in the /private/etc/snmp/snmpd.conf and the built-in LaunchDaemon is, where the actual binary being called is /usr/sbin/snmpd (and by default it’s called with a -f option). Once started, the default community name should be COMMUNITY (easily changed in the conf file) and to test, use the following command from a client (the client is in the following example):

snmpwalk -On -v 1 -c COMMUNITY

October 9th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , ,

Leave a Comment

macOS Server 5.2 running on Sierra 10.12) has an adaptive firewall built in, or a firewall that controls incoming access based on clients attempting to abuse the server. The firewall automatically blocks incoming connections that it considers to be dangerous. For example, if a client attempts too many incorrect logins then a firewall rule restricts that user from attempting to communicate with the server for 15 minutes. If you’re troubleshooting and you accidentally tripped up one of these rules then it can be a bit frustrating. Which is why Apple gives us afctl, a tool that interacts with the adaptive firewall.

The most basic task you can do with the firewall is to disable all of the existing rules. To do so, simply run afctl (all afctl options require sudo) with a -d option:

/Applications/ -d

When run, the adaptive firewall’s rules are disabled. To re-enable them, use the -e option:

/Applications/ -e

Turning off the rules seems a bit much for most troubleshooting tasks. To remove a specific IP address that has been blacklisted, use the -r option followed by the IP address (rules are enforced by IP):

/Applications/ -r

To add an IP to the blacklist, use the -a option, also followed by the IP:

/Applications/ -a

To permanently add a machine to the whitelist, use -w with the IP:

/Applications/ -w

And to remove a machine, use -x. To understand what is going on under the hood, consider this. The blacklisted computers are stored in plain text in /var/db/af/blacklist and the whitelisted computers are stored in the same path in a file called whitelist. The afctl binary itself is stored in /usr/libexec/afctl and the service is enabled by /System/LIbrary/LaunchDaemons/, meaning to stop the service outright, use launchctl:

launchctl unload


The configuration file for afctl is at /etc/af.plist. Here you can change the path to the blacklist and whitelist files, change the interval with which it is run, etc. Overall, the adaptive firewall is a nice little tool for Mac OS X Server security, but also something a number of open source tools can do as well. But for something built-in and easy, worth using.

There’s a nice little command called hb_summary located in /Applications/ that provides statistics for blocked hosts. To see statistics about how much the Adaptive Firewall is being used, just run the command with no options:


The output provides the following information (helpful if plugging this information into a tool like Splunk):

  • Date
  • Date statistics start
  • Number of hosts blocked
  • Addresses blocked
  • Number of times each address was blocked
  • Last time a host was blocked
  • Total number of times a block was issued

October 8th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , ,

Leave a Comment

DNS is DNS. And named is named. Except in OS X Server. Sometimes. The configuration files for the DNS services in macOS Server are stored in /Library/Server/named. This represents a faux root of named configuration data, similar to how that configuration data is stored in /var/named on most other platforms. Having the data in /Library/Server/ makes it more portable across systems. The current version of BIND is BIND 9.9.7-P3 (Extended Support Version).

Traditionally, you would edit this configuration data by simply editing the configuration files, and that’s absolutely still an option. In macOS Server 5.2 (for Sierra), a new command is available at /Applications/ called dnsconfig. The dnsconfig command appears simple at first. However, the options available are actually far more complicated than they initially appear. The verbs available include help (show help information), list (show the contents of configurations and zone files), add (create records and zones) and delete (remove records and zones).

To view data available in the service, use the list verb. Options available when using the list verb include –acl (show ACLs), –view (show BIND view data), –zone (show domains configured in the service), –rr (show resource records) and –rrtype (show types of resource records). For example, let’s say you have a domain called pretendco.lan and you would like to view information about that zone. You could use the dnsconfig command along with the list verb and then the –zone option and the domain name:

/Applications/ list --zone=pretendco.lan

The output would show you information about the listed zone, usually including View data:

allow-transfer: none
allow-update: none 

To see a specific record, use the –rr option, followed by = and then the fqdn, so to see ecserver.pretendco.lan:

/Applications/ list --rr=ecserver.pretendco.lan

By default views are enabled and a view called is created when the DNS server first starts up. You can create other views to control what different requests from different subnets see; however, even if you don’t create any views, you’ll need to add the –view option followed by the name of the view (– to any records that you want to create. To create a record, use the add verb. You can add a view (–view), a zone (–zone) or a record (–rr). Let’s start by adding a record to the pretendco.lan from our previous example. In this case we’ll add an A record called www that points to the IP address of

/Applications/ add --zone=pretendco.lan --rr=www A

You can add a zone, by providing the –view to add the zone to and not providing a –rr option. Let’s add krypted.lan:

/Applications/ add --zone=krypted.lan

Use the delete verb to remove the data just created:

/Applications/ delete --zone=krypted.lan

Or to delete that one www record earlier, just swap the add with a delete:

/Applications/ delete --zone=pretendco.lan --rr=www A

Exit codes would be “Zone krypted.lan removed.” and “Removed 1 resource record.” respectively for the two commands. You can also use the –option option when creating objects, along with the following options (each taken as a value followed by an =, with this information taken by the help page):

  • allow-transfer Takes one or more address match list entry. Address match list entries consist of any of these forms: IP addresses, Subnets or Keywords.
  • allow-recursion Takes one or more address match list entry.
  • allow-update Takes one or more address match list entry.
  • allow-query Takes one or more address match list entry.
  • allow-query-cache Takes one or more address match list entry.
  • forwarders Takes one or more IP addresses, e.g.
  • directory Takes a directory path
  • tkey-gssapi-credential Takes a kerberos service principal
  • tkey-domain Takes a kerberos realm
  • update-policy Takes one complete update-policy entry where you can grant or deny various matched objects and specify the dentity of the user/machine that is allowed/disallowed to update.. You can also identify match-type (Type of match to be used in evaulating the entry) and match-name (Name used to match) as well as rr-types (Resource record types that can be updated)

Overall, this command is one of the best I’ve seen for managing DNS in a long time. It shows a commitment to continuing to make the service better, when you add records or remove them you can instantly refresh the Server app and see the updates. It’s clear a lot of work went into this and it’s a great tool for when you’re imaging systems and want to create records back on a server or when you’re trying to script the creation of a bulk list of records (e.g. from a cached file from a downed host). It also makes working with Views as easy as I’ve seen it in most platforms and is overall a breeze to work with as compared to using the serveradmin command to populate objects so the GUI doesn’t break when you update records by hitting files directly.

October 5th, 2016

Posted In: Mac OS X Server, Mac Security

Tags: , , , , ,

Leave a Comment

macOS Sierra (10.12) 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 macOS Server 5.2 called serversetup. 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/, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in OS X 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. The easiest way to view logs is to use the Server app, clicking on Logs in the sidebar. The dropdown at the bottom of the screen provides quick access to service-based logs.

Screen Shot 2015-09-25 at 8.47.29 PM

One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of macOS Server intend for certain tasks to occur. However, you can also use the Console app from /Applications/Utilities, as with any other Mac, to look at standard logs.

Screen Shot 2015-09-25 at 8.48.50 PM

Looking At Services

This is also where I learned that Apple had put an Open Directory backup script in /Applications/ (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/ ) 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/

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/, 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/ 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 = “/var/log/ppp/vpnd.log”
sudo serveradmin settings = “/var/log/ppp/vpnd.log”
sudo serveradmin settings = “/var/log/ppp/vpnd.log”
sudo serveradmin settings = “/var/log/ppp/vpnd.log”

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

sudo serveradmin settings
sudo serveradmin settings
sudo serveradmin settings
sudo serveradmin settings

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 OS X  Server’s built-in web service to conform to the standards of most modern web log analyzers.


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…

October 5th, 2016

Posted In: Mac OS X Server, Mac Security

Tags: , , , , , ,

Leave a Comment

By default, OS X now updates apps that are distributed through the Mac App Store (MAS). Server running on macOS Sierra is really just the Server app, sitting on the App Store, installed on a standard Mac. If the Server app is upgraded automatically, you will potentially experience some adverse side effects, especially if the app is running on a Metadata Controller for Xsan, runs Open Directory, or a major release of the Server app ships. Additionally, if you are prompted to install a beta version on a production system, you could end up with issues. Therefore, in this article we’re going to disable these otherwise sweet features of OS X.

To get started, first open the System Preferences. From there, click on the App Store System Preference pane.


From the App Store System Preference pane, uncheck the following boxes:

  • Automatically Check For Updates: Unchecking this box disables the download in the background option and the installation of app updates.
  • Automatically Download Apps Purchased on Other Macs: If you buy an upgrade, you could accidentally install that upgrade on production servers you don’t intend to install the upgrade on.

Once disabled, you’ll need to keep on top of updates in the App Store manually. My recommendation is still to create an image of your server before each update.

If you see the field, click Change for “Your computer is set to receive beta software updates” and then click


You can also set these from the command line. To disable automatic app store updates:

defaults write /Library/Preferences/ AutoUpdate -bool FALSE

To disable automatic macOS updates:

defaults write /Library/Preferences/ AutoUpdateRestartRequired -bool FALSE

And to disable automatic Software Update update checks:

defaults write /Library/Preferences/ AutomaticCheckEnabled -bool FALSE

Overall, be careful with automatic updates. I like leaving checking enabled so when I sit down at the console of a server I get prompted to update; however, I don’t want servers updating and restarting unless I tell them to, after I’ve performed a comprehensive regression test on the updates.

September 29th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

Next Page »