Justin Rummel . com

Sending Mail From OS X Server on Verizon FiOS via Gmail

| Comments

Yes I know this is a lengthy… long… and very specific post title, but I hope it helps someone else in the same predicament.

Overview

I have been fighting OS X Server and Verizon FiOS for months. The shortest explanation is that Verizon blocks port 25 (standard SMTP port) and forces you to use port 465 (SMTP via SSL). I’m Ok with that rule, however, no matter how many times I try to use smtp.verizon.net:465 in OS X Server, I would get an error in the /var/log/mail.log stating you must use TLS. When trying to use port 587 to force TLS, I get an operation timeout error. If I switch to use smtp.gmail.com:[25,465,587] I would get black listed b/c Verizon won’t allow SMTP off their FiOS network that does not originate from a verizon SMTP server.

Solution

Which leads me to today. I was searching (again) a way to fix this by sending a simple sendmail user@domain.tld < filename.txt when I stumbled upon this blog post. The goal of the article is to send TLS mail from postfix on a linux box. While reviewing the commands and comparing to an OS X Server main.cf file (in /Library/Server/Mail/Config/postfix) I noticed a couple key items missing. Unfortunately I took a shotgun approach so I don’t know specifically which line fixed the issue, but here is a copy/paste of the items that I placed at the bottom of my main.cf:

1
2
3
4
5
6
7
8
9
10
11
12
#### Added by jbr 2014-07-08
smtp_connection_cache_destinations = smtp.gmail.com
relay_destination_concurrency_limit = 1
default_destination_concurrency_limit = 5
smtp_use_tls = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_note_starttls_offer = yes
smtp_tls_scert_verifydepth = 5
smtpd_tls_req_ccert =no
smtpd_tls_ask_ccert = yes
soft_bounce = yes

Note

These settings assume that you have configured Mail services to relay to smtp.gmail.com:587 and associated it to a proper Gmail account that can send mail.

Source

Relay mail via Google SMTP with Postfix

Quick Step-by-Step Guide for AutoPKG and JSSImporter

| Comments

Overview

This is a quick step-by-step instructions to get AutoPKG and the JSSImporter to work so Mac Admins can begin testing and evaluating the two products, and see how these tools will help automate the less than glamorous parts of their job. This is not a lengthy description post explaining the awesome work that other Mac Admins have done in creating AutoPKG and JSSImporter, as there are plenty of other posts that explain this better than I can (including their own respective documentation).

Technical assumptions

  • The reference installers for AutoPKG and JSSImporter are .pkg files, so they must be run on a Mac.
  • The JSSImporter assumes that the JSS Distribution Point is either local, or always mounted.

Step-by-Step

  • Download and install autopkg
1
curl -OL https://github.com/autopkg/autopkg/releases/download/v0.3.0/autopkg-0.3.0.pkg
  • Add Default repo
1
autopkg repo-add http://github.com/autopkg/recipes.git
  • Download JSS-addon via autopkg
1
autopkg run JSS-addon.pkg
  • Install JSS-addon pkg
1
sudo intstaller -pkg /path/to/jss-autopkg-addon-0.0.2.pkg -target / -verbose
  • Create an “Standard” User in the JSS with Create, Read, Update rights of JSS Objects.
  • Set plist environment variables (no slashes at the end)
1
2
3
4
defaults write com.github.autopkg JSS_REPO /Volumes/JSS_Dist_Point/Packages
defaults write com.github.autopkg JSS_URL https://test.jss.private:8443
defaults write com.github.autopkg API_USERNAME apiUser
defaults write com.github.autopkg API_PASSWORD apiPassword
  • Test
1
autopkg run TextWrangler.jss

Bonus Round

Use @seankaiser’s autopkg automation LaunchDaemon files to automatically check a list of applications (that you define) and send an email if there are updates!

Sources

DEP and VPP Notes From MacDMV Group Meeting

| Comments

On May 1st, MacDMV’s second “tech” session took place covering Apple’s Device Enrollment Program (DEP) and how it relates to JAMF Software’s Casper Suite, a little about VPPMD (because once you start talking about DEP you can’t help but talk about VPP), and Munki in a Box which is a deployment script for Munki by Tom Bridge.

Here are my notes from the DEP session (with a little VPP knowledge).

  • When an organization signs up for DEP, any device that has been purchased by that organization for the past three years is qualified to be added in your DEP portal. For example, if you sign-up Jan 1st, 2016… only devices purchased by your organization from Jan 1st, 2013 will qualify. So do it now!
  • When configuring “PreStage Enrollment” in your JSS, the default behavior for a skipped item during the Setup Assistant is off. For example; if you select to skip “Location Activation” in your PreStage Enrollment setup, location items will be off. From Apple’s perspective there are privacy concerns regarding location, which require the user to actively enable a privacy sensitive feature. Skipped items cannot be re-activated remotely via Configuration Profile, but end user can enable by touching the device.
  • The T&Cs that you can skip for PreStage Enrollment for DEP is the agreement for the device. If during Setup Assistant you authenticate/create an Apple ID, you will still see the Apple ID T&Cs.
  • If you have a device with Activation Lock enabled, but you don’t have the Apple ID’s password to restore the device (e.g. you have a “brick” in your hand), call AppleCare immediately. You will need to verify that you do own the device so be ready with purchase details.
  • Supervised devices will allow to “push” apps from VPP. So enable Supervision in DEP.
  • DEP is not for BYOD as DEP is for devices owned by the organization (makes sense once you say it out loud)!!!
  • Apple’s License model is you can use VPPMD apps on organization issued devices AND personal device.

Working With VPP and DEP Apple IDs

| Comments

These are notes about getting the Apple IDS and their two-step verification authentication ready for Apples Volume Purchasing Program (VPP) and Device Enrollment Program (DEP). WORST case give yourself two weeks to complete all the items listed below, but realisticly it can be done within three business days.

You will be creating a LOT of Apple IDs. Do yourself a favor and get a password manager, or have some other secure method of recording what/how each new Apple ID is being used. There are two levels of Apple IDs.

[VPP | DEP] Program Agent

This is the individual with purchasing power and/or signature authority.

[VPP | DEP] Program Admin

This is the technical individual that needs to do the work.

If you are the same person, still create multiple accounts as tokens are necessary to make VPP and DEP work and they will expire every year, OR if the password is changed on that account.

Day 1 “Monday”

The assumption is that you do not have an existing VPP account, and since DEP is new, you don’t have an account for that program either.

You will need to create two NEW Apple IDs at https://deploy.apple.com: one for VPP and one for DEP. Both of these may take five days for Apple to validate the individual that made the request (or was requested by someone on their staff) is the responsible person of the organization. The person identified for these accounts MUST be someone within your institution or company who has “signature authority”. In terms of the Job Title, be sure that if there are any public facing websites or social media listings of the person that will be listed as the Program Agent, it matches to what you submit to Apple (Owner, Vice President, Director, etc). Apple has staff validating the information you submit, not an automated system. Apple will call you and verify the information that has been submitted is accurate, so be sure to enter a cell number as the primary way to contact the individual who needs to approve the account.

  • vppmd@domain.tld
  • dep@domain.tld

Day 8 “Monday”

After five business days, you should now have two new Apple IDs. Begin enabling two-step verification authentication as described at: http://support.apple.com/kb/HT5570. Just because you created a VPP or DEP account does not mean that two-step verification authorization has been enabled. You must do this after you login to the new Apple ID accounts. Two-step verification is required for VPP and DEP… so begin two-step verification started immediately once you login. If you happen to be using an old VPP account because you still have money available, your account will need to be converted to allow two-step verification, thus it may take 72 hours for Apple to perform some background routines.

When you enable two-step verification DO NOT CHANGE ANYTHING ELSE. If you change an address, phone number, or security questions it may raise red flags to Apple, thus causing you delays.  1 2

Day 11 “Thursday”

We can now invite Admin accounts for VPP and DEP. VPP Admins should be for specific Profile Manager servers OR for specific departments (who have their own Profile Manager) 3 that need to control expenses on what apps are purchased. So think of it as:

  • pm01@domain.tld
  • pm02@domain.tld
  • pm03@domain.tld

We can also now invite our DEP Admin. DEP Admins should be invites to individual’s work email account as it identifies the individual who can add devices to your MDM server. However, if that account already exists just create “DEP” accounts as needed. 4

Notes


  1. [1] DEP cannot use iCloud, therefore you MUST be able to accept SMS messages on your phone. Remember, two factor authentication is for login and *purchases*. The cell phone with SMS must be the “Admin’s” phone, because as soon as you begin to purchase apps (Free or Paid), you will get a request for the SMS four digit code each time as you must authentication with two-step verification if items are purchased! 
  2. [2] If iPhones are issued by a School or a Government agency, sometimes cellular providers impose a block on SMS to prevent unnecessary charges (such as the ability to vote for your favorite singer on American Idol). This restriction may stop any Apple SMS messages; call your provider to get the block removed. 
  3. [3] If you are using another MDM besides Profile Manager, you only need one token per department or sub-organization that wants to control what apps are being purchased. See your MDM Provider for details. 
  4. [4] At this point it reminds me that Google Accounts automatically have an alias feature where you can add a plus sign and something else between the username and the “@” symbol. So an example:
    • email address: myaccount@gmail.com
    • alias address: myaccount+dep1@gmail.com
    Both emails will be sent to the same gmail account, however, they are still unique and different so this trick could be used to create additional Apple ID accounts based off your work address. 

Using .p12 or JKS Files With OS X

| Comments

Overview

My test CrashPlan PROe (CPPe, a.k.a “Black”) environment has been troubled with this VMware Fusion bug where linking a shared folder has some issues with read/write. The end result was anytime a client (Mac or Windows) running CrashPlan PROe had to restart, CrashPlan PROe Server would go into a deep prune session that would last for days (more info in the logs, but you get the idea). Not very reassuring when dealing with backups.

It took some time, but with the help of Code42 support the best recommended route was to remove my VMware Fusion VMs from the equation and run direct on my VM host, a couple of 2010 MacMini Servers. The process was pretty easy by:

  • Prep the CPPe database
  • Do a database dump
  • Find/replace some settings (done by Code42 support)
  • Install CPPe Server on host
  • launchclt unload /Library/LaunchDaemons/com.crashplan.proserver.plist
  • place converted db in /Library/Application\ Support/CrashPlan/PROServer/db/
  • launchclt load /Library/LaunchDaemons/com.crashplan.proserver.plist

Certificates

So WHY is this titled referencing .p12 and .jks files? I originally used this script to generate JKS files in Ubuntu Server. This allowed me to create the JKS, import the RootCA, IntermediateCA, CSR, and then finally copy the signed cert to a single file that was then imported into CPPe’s management console. When migrating to OS X, I had already had a signed certificate for the server (web services)… so starting from the beginning wasn’t an option.

Exporting from the System Keychain has been an issue since the 10.5 days. You think the file is exported properly with both the public and private key… but it was always missing the private key for some reason.

The solution is to enable root on your server. You can enable root by launching Directory Utility ( /System/Library/CoreServices/Directory\ Utility.app ) or by following Apple’s kbase.

Login as root, find and select BOTH the public and private certificate in Keychain Access and export to a .p12. This process will ask you to use a password to make sure things are secure as you are EXPORTING THE PRIVATE KEY.

Once you have the .p12, this simple one-line will convert the .p12 to a .jks so you can import into CPPe’s management console.

1
keytool -importkeystore -destkeystore NEW-SERVER.jks -deststorepass Pass#word -srckeystore certificate-export.p12 -srcstoretype PKCS12 -srcstorepass Pass#word

As a best practice, I usually create .jks, .p12, or even .cer files with the server’s FQDN to make things easy to read in the future. Hope this helps someone from pulling out their hair.