Category Archives: Mac OS X Server

Mac OS X Mac OS X Server Mass Deployment

Cascading Software Update Service Updates In Yosemite Server

The swupd.plist file used to daisy chain multiple servers so they act as a cascade of software update servers. The new path for the property list is /Library/Server/Software Update/Config/swupd.plist. Here, the metaIndexURL key is sill the location that points to an internal Software Update Server that the server you are editing should look to for updates.

The default server is http://swscan.apple.com/content/meta/mirror-config-1.plist. To set a server to look at another internal server for software updates, edit the metaIndexURL key in the /Library/Server/Software Update/Config/swupd.plist file to include the path to the new server. The path should always have /content/meta/mirror-config-1.plist after the FQDN of the host name. So if your internal software update server was called daneel.foundation.lan the command to set that as the upstream software update server would be:

defaults write /Library/Server/Software\ Update/Config/swupd metaiIndexURL “http://daneel.foundation.lan/content/meta/mirror-config-1.plist”

This is a minor change, but one that might be frustrating if you were still trying to cascade updates the old way. If you’re new to cascading updates, this is a pretty straight forward configuration change, run from a Terminal command. It’s also worth noting that there are a few other settings in this file that could come in handy. You can limit bandwidth using the limitBandwidth key, purge any old updates using the PurgeUnused key, set a max download speed using the maxDownloadSpeed key, configure the Software Update Server TCP port using the portToUse key (automatically set to 8088), change the path to the updates (e.g. if you mv them and then want to repoint to the new location without downloading them all again) using the updatesDocRoot key, etc. Overall, the settings align with the old settings, but just in a new place.

Note: The keys above correspond to settings found in the following command:

sudo serveradmin settings swupdate

The list of settings is as follows:

swupdate:checkError = no
swupdate:limitBandwidth = no
swupdate:PurgeUnused = yes
swupdate:portToUse = 8088
swupdate:autoEnable = yes
swupdate:valueBandwidth = 0
swupdate:syncStatus = "Initializing"
swupdate:autoMirror = yes
swupdate:syncBandwidth = 0
swupdate:updatesDocRoot = "/Library/Server/Software Update/Data/"
swupdate:autoMirrorOnlyNew = no

Mac OS X Server Xsan

Yosemite Server: Configure Clients In Xsan 4 Environments

Yosemite brings Xsan 4, which brings a new way to add clients to an Xsan. Xsan Admin is gone. From now on, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf. To make the Xsan configuration profile, we’re going to use Profile Manager.

To get started, open the Profile Manager web interface and click on a device or device group (note, these are scoped to systems so cannot be used with users and user groups). Then click on the Settings tab for the object you’re configuring Xsan for.

Screen Shot 2014-10-29 at 11.37.14 AM

Click Edit for the profile listed (Settings for <objectname>) and scroll down until you see the entry for Xsan.

Screen Shot 2014-10-29 at 11.37.32 AM

From the Xsan screen, click Configure.

Screen Shot 2014-10-29 at 11.37.41 AM

This next screen should look a little similar, in terms of the information you’ve plugged into the Xsan 4 setup screen. Simply enter the name of the Xsan in the Xsan Name field, the IP address or host names of your metadata controllers in the File System Name Servers field and the Authentication Secret from the Xsan screen in the Server app into the Authentication Secret field. Click OK to close the dialog.

Screen Shot 2014-10-29 at 11.38.29 AM

Click Save to save your changes. Then you’ll see the Download button become clickable.

Screen Shot 2014-10-29 at 11.44.15 AM

The profile will download to your ~/Downloads directory as Settings_for_<OBJECTNAME>.mobileconfig. So this was called test and will result in a name of Settings_for_test.mobileconfig. That profile will automatically attempt to install. If this is an MDC where you’re just using Profile Manager to bake a quick profile, or if you don’t actually want to install the profile yet, click Cancel.

Screen Shot 2014-10-29 at 11.43.43 AM

If you haven’t worked with profiles that much, note that when you click Show Profile, it will show you what is in the profile and what the profile can do.

Screen Shot 2014-10-29 at 11.43.59 AM

Simply open this file on each client (once you test it of course) and once installed, they’ll automatically configure to join your Xsan. If you don’t have a Profile Manager server, you can customize this file for your environment (YMMV): Settings_for_test.mobileconfig

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 OS X Server

Demoting An Open Directory Server In Yosemite Server

The command to create and tear down an Open Directory environment is slapconfig. When you disable Open Directory from the Server app you aren’t actually removing users. To do so, you’d use slapconfig along with the -destroyldapserver. When run, you get a little insight into what’s happening behind the scenes. This results in the following:

bash-3.2# slapconfig -destroyldapserver

The logs are as follows:

2014-09-18 14:42:02 +0000 slapconfig -destroyldapserver
2014-09-18 14:42:02 +0000 CopyReplicaArray: ldap_search_ext_s failed
2014-09-18 14:42:02 +0000 Error retrieving replica array
2014-09-18 14:42:02 +0000 Deleting Cert Authority related data
2014-09-18 14:42:03 +0000 Removed directory at path /var/root/Library/Application Support/Certificate Authority/Take Control Books Open Directory Certification Authority.
2014-09-18 14:42:03 +0000 command: /usr/sbin/xscertadmin add --reason 5 --issuer Take Control Books Open Directory Certification Authority --serial 2127185704
CopyCARecordByName: get ldapi node code = 2100 description = Connection failed to node '/LDAPv3/ldapi://%2Fvar%2Frun%2Fldapi'
No such issuer - failed to revoke certificate
2014-09-18 14:42:23 +0000 command: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xscertd.plist
/System/Library/LaunchDaemons/com.apple.xscertd.plist: Could not find specified service
2014-09-18 14:42:23 +0000 command: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xscertd-helper.plist
/System/Library/LaunchDaemons/com.apple.xscertd-helper.plist: Could not find specified service
2014-09-18 14:42:23 +0000 command: /bin/launchctl unload -w /System/Library/LaunchDaemons/com.apple.xscertadmin.plist
/System/Library/LaunchDaemons/com.apple.xscertadmin.plist: Could not find specified service
2014-09-18 14:42:23 +0000 void _destroyLDAPServer(const char *): Failed to find computer record named YosemiteSam.krypted.com$: 0 (null)
2014-09-18 14:42:23 +0000 Updating ldapreplicas on primary master
2014-09-18 14:42:23 +0000 CopyLdapReplicas: Unable to create DSLDAPContainer: 77014 Can't contact LDAP server (-1)
2014-09-18 14:42:23 +0000 CopyPrimaryMaster: CopyLdapReplicas failed
2014-09-18 14:42:23 +0000 Unable to locate primary master
2014-09-18 14:42:23 +0000 Primary master node is nil!
2014-09-18 14:42:23 +0000 Unable to locate ldapreplicas record: 0 (null)
2014-09-18 14:42:23 +0000 Error setting read ldap replicas array: 0 (null)
2014-09-18 14:42:23 +0000 Error setting write ldap replicas array: 0 (null)
2014-09-18 14:42:23 +0000 ODRecord *_getODRecord(ODNode *, NSString *, NSString *, NSArray *): ODNodeRef parameter error
2014-09-18 14:42:23 +0000 int _removeReplicaFromConfigRecord(ODNode *, NSString *): ODRecord not found
2014-09-18 14:42:23 +0000 Error synchronizing ldapreplicas: 0 (null)
2014-09-18 14:42:23 +0000 Removing self from the database
2014-09-18 14:42:23 +0000 Stopping LDAP server (slapd)
2014-09-18 14:42:23 +0000 Stopping password server
2014-09-18 14:42:23 +0000 Removed all service principals from keytab for realm YOSEMITESAM.KRYPTED.COM
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.002.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.003.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.004.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.005.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/__db.006.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/altSecurityIdentities.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-config-realname.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-generateduid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-group-memberguid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-group-nestedgroup.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-group-realname.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/apple-hwuuid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/cn.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/DB_CONFIG.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/dn2id.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/entryCSN.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/entryUUID.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/gidNumber.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/givenName.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/id2entry.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/ipHostNumber.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/log.0000000001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/macAddress.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/mail.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/memberUid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/objectClass.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/ou.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/sn.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/uid.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/openldap-data/uidNumber.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.002.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.003.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.004.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.005.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/__db.006.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/alock.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/authGUID.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/DB_CONFIG.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/dn2id.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/draft-krbPrincipalAliases.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/draft-krbPrincipalName.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/entryCSN.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/entryUUID.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/id2entry.bdb.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/log.0000000001.
2014-09-18 14:42:23 +0000 Removed file at path /var/db/openldap/authdata/objectClass.bdb.
2014-09-18 14:42:23 +0000 Removed directory at path /var/db/openldap/authdata.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd_macosxserver.conf.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd.conf.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/rootDSE.ldif.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d/cn=config.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd.d/cn=config.ldif.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d.backup/cn=config.
2014-09-18 14:42:23 +0000 Removed file at path /etc/openldap/slapd.d.backup/cn=config.ldif.
2014-09-18 14:42:23 +0000 Removed directory at path /etc/openldap/slapd.d.backup.
2014-09-18 14:42:26 +0000 Stopping password server
2014-09-18 14:42:26 +0000 Removed file at path /etc/ntp_opendirectory.conf.
2014-09-18 14:42:26 +0000 Removed file at path /Library/Preferences/com.apple.openldap.plist.

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

Creating Users In Yosemite Server

There are three ways to create users in Yosemite Server (the Server app running on Yosemite if you’re so bored you feel the need to try and correct me). The first is using the Server app, the second is using the Users & Groups System Preference pane and the third is using the command line. In this article we will look at creating users in the Server app.

To do so, open the Server app and connect to your server. Then click on the Users entry in the ACCOUNTS list. The list of users is displayed, based on the directory domain(s) being browsed. A directory domain is a repository of account data, which can include local users, local network users and users in a shared directory service such as Open Directory and Active Directory.

Users1

The drop-down list allows you to see objects that are stored locally as well as on a shared directory server. Click on the plus sign to create a new account in the chosen Directory Domain.

Users2

When prompted, provide the following information about the new user:

  • Full Name: Usually the first and last name of the user.
  • Account Name: A shorter representation of that name with no spaces or special characters.
  • Email addresses: The email address to use if the account is going over quotas, has calendar invitations sent, or used for email hosted on the server, etc.
  • Password: The password the user will use to access services on the server.
  • Verify: The password a second time to make sure there are no spelling errors.
  • Allow user to administer this server: Optional field that grants the user administrative access to the server.
  • Home Folder: Optional field that by default creates local home directories for users that use the account but that also allows you to select a directory shared using the File Sharing service as a location for home folders. Each user in OS X has a home folder, this option defines whether that folder will reside on their computer or on a central server.
  • Keywords: Tags to make it easier to find users (a new feature for the Server app in Yosemite Server, but an old feature in the old Workgroup Manager).
  • Disk Quota: Define the amount of space an account can take up on servers.
  • Notes: Any information you’d like to enter to remember things about the user.

Note: Optionally, you can also drag an image onto the image shown in the New User screen if you’d like the user to have an avatar as done in the above screenshot.

Once the account details are as you would like, click on the Done button. The account will then be displayed in the list of available accounts. If the server has not been made an Open Directory server then you can only create local users through the Server app.

Once the account is created, right-click click on the user to see the option to edit the account you just created, edit their access to services hosted on the server, configure email information and change their password.

Users3

Click Edit User. Here, you have two new features. You can add the user to groups and use the checkbox for “log in” to disable the account.

Users4

Click Cancel and then using the cog wheel menu while the user is highlighted, note that you can, click on Edit Access to Services. Here, uncheck each service that the user should not have access to. If the service isn’t running then it’s not a big deal. You can highlight multiple accounts concurrently and then use this option to disable services for users en masse. Here, you can also edit your user templates (which are settings inherited by new users who you select that template for) as well as edit advanced options, such as changing the UID, default group, short name, aliases, default shell and home directory path. As the screen indicates, only change this stuff if you know exactly what you’re doing.

Users5

Mac OS X Mac OS X Server Mac Security Mass Deployment

Configure Messages Server In OS X Yosemite Server

Getting started with Messages Server couldn’t really be easier. Messages Server in the OS X Yosemite version of the Server app uses the open source jabber project as their back-end code base (and going back, OS X has used jabber since the inception of iChat Server all the way through Server 3). The sqlite setup file is located at /Applications/Server.app/Contents/ServerRoot/private/var/jabberd directory and the autobuddy binary is at /Applications/Server.app/Contents/ServerRoot/usr/bin/jabber_autobuddy. The actual jabberd binary is also stored at /Applications/Server.app/Contents/ServerRoot/usr/libexec/jabberd, where there are a couple of perl scripts used to migrate the service between various versions as well.

Setting up the Messages service is simple. Open the Server app and click on Messages in the Server app sidebar.

Messages1

Click on the Edit… button for the Permissions. Here, define which users and interfaces are allowed to use the service.

Once open, click on the checkbox for “Enable server-to-server federation” if you have multiple iChat, er, I mean, Messages servers and then click on the checkbox for “Archive all chat messages” if you’d like transcripts of all Messages sessions that route through the server to be saved on the server. You should use an SSL certificate with the Messages service. If enabling federation so you can have multiple Messages servers, you have to. Before enabling the service, click on the name of the server in the sidebar of Server app and then click on the Settings tab. From here, click on Edit for the SSL Certificate (which should be plural btw) entry to bring up a screen to select SSL Certificates.

Messages2

At the SSL Certificates screen (here it’s plural!), select the certificate the Messages service should use from the available list supplied beside that entry and click on the OK button. If you need to setup federation, click back on the Messages service in the sidebar of Server app and then click on the Edit button. Then, click on the checkbox for Require server-to-server federation (making sure each server has the other’s SSL certificate installed) and then choose whether to allow any server to federate with yours or to restrict which servers are allowed. I have always restricted unless I was specifically setting up a server I wanted to be public (like public as in everyone in the world can federate to it, including the gorram reavers that want to wear your skin).

Messages3

To restrict the service, then provide a list of each server address capable of communicating with your server. Once all the servers are entered, click the OK button.
Obviously, if you only have one server, you can skip that. Once the settings are as you wish them to be, click on the ON/OFF switch to light up the service. To see the status of the service, once started, use the fullstatus option with serveradmin followed by the jabber indicator:

sudo serveradmin fullstatus jabber

The output includes whether the service is running, the location of jabber log files, the name of the server as well as the time the service was started, as can be seen here:

jabber:state = "RUNNING"
jabber:roomsState = "RUNNING"
jabber:logPaths:PROXY_LOG = "/private/var/jabberd/log/proxy65.log"
jabber:logPaths:MUC_STD_LOG = "/var/log/system.log"
jabber:logPaths:JABBER_LOG = "/var/log/system.log"
jabber:proxyState = "RUNNING"
jabber:currentConnections = "0"
jabber:currentConnectionsPort1 = "0"
jabber:currentConnectionsPort2 = "0"
jabber:pluginVersion = "10.8.211"
jabber:servicePortsAreRestricted = "NO"
jabber:servicePortsRestrictionInfo = _empty_array
jabber:hostsCommaDelimitedString = "mavserver.pretendco.lan"
jabber:hosts:_array_index:0 = "mavserver.pretendco.lan"
jabber:setStateVersion = 1
jabber:startedTime = ""
jabber:readWriteSettingsVersion = 1

There are also a few settings not available in the Server app. One of these that can be important is the port used to communicate between the Messages client and the Messages service on the server. For example, to customize this to 8080, use serveradmin followed by settings and then jabber:jabberdClientPortSSL = 8080, as follows:

sudo serveradmin settings jabber:jabberdClientPortSSL = 8080

To change the location of the saved Messages transcripts (here, we’ll set it to /Volumes/Pegasus/Book:

sudo serveradmin settings jabber:savedChatsLocation = “/Volumes/Pegasus/Book”

To see a full listing of the options, just run settings with the jabber service:

sudo serveradmin settings jabber

The output lists each setting configurable:

jabber:dataLocation = "/Library/Server/Messages"
jabber:s2sRestrictDomains = no
jabber:jabberdDatabasePath = "/Library/Server/Messages/Data/sqlite/jabberd2.db"
jabber:sslCAFile = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.chain.pem"
jabber:jabberdClientPortTLS = 5222
jabber:sslKeyFile = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.concat.pem"
jabber:initialized = yes
jabber:enableXMPP = no
jabber:savedChatsArchiveInterval = 7
jabber:authLevel = "STANDARD"
jabber:hostsCommaDelimitedString = "mavserver.pretendco.lan"
jabber:jabberdClientPortSSL = 5223
jabber:requireSecureS2S = no
jabber:savedChatsLocation = "/Library/Server/Messages/Data/message_archives"
jabber:enableSavedChats = no
jabber:enableAutoBuddy = no
jabber:s2sAllowedDomains = _empty_array
jabber:logLevel = "ALL"
jabber:hosts:_array_index:0 = "mavserver.pretendco.lan"
jabber:eventLogArchiveInterval = 7
jabber:jabberdS2SPort = 0

To stop the service:

sudo serveradmin stop jabber

And to start it back up:

sudo serveradmin start jabber

It’s also worth noting something that’s completely missing in this whole thing: Apple Push Notifications… Why is that important? Well, you use the Messages application to communicate not only with Mac OS X and other jabber clients, but you can also use Messages to send text messages. Given that there’s nothing in the server that has anything to do with texts, push or anything of the sort, it’s worth noting that these messages don’t route through the server and therefore still require an iCloud account. Not a huge deal, but worth mentioning that Messages server doesn’t have the same updates built into the Messages app. Because messages don’t traverse the server, there’s no transcripts.

iPhone Mac OS X Mac OS X Server

Configure Apple Push Notifications In Yosemite Server

Push Notifications can be used in most every service in the Server app, especially in 3.5 for Yosemite (which I still like to call Yosemite Server as it makes me think of Yosemite Sam in a tux, pouring champagne). Any service that requires Push Notifications will provide the ability to setup APNS during the configuration of the service. But at this point, I usually just set up Push Notifications when I setup a new server.

Push1

To enable Push Notifications for services, you’ll first need to have a valid AppleID. Once you have an AppleID, open the Server app and then click on the name of the server. At the Overview screen, click on Settings.

Push2

At the Settings screen for your server, click on the check-box for “Enable Apple push notifications.” At the Apple Push Notification Services certificate screen, enter an AppleID if you have not yet configured APNS and click on OK. The Apple Push Notification Service certificate will then be configured.

Push3

The certificate is valid for one year, by default. Administrators receive an alert when the certificate is due to expire. To renew, open the same screen and click on the Renew button.

Mac OS X Mac OS X Server Mac Security Mass Deployment

Changing the Xcode Server Log Path in OS X 10.10 Yosemite Server

The logs in Xcode Server (Server 3) by default point to /Library/Server/XcodeLogs/credserver.log. This takes all of the output from xcscredd and xcscredhandler. If you’re doing a lot of debugging then logs can be pointed to another location, such as another drive. The path to the logs is defined in the /Applications/Server.app/Contents/ServerRoot/System/Library/LogConfiguration directory. The file to edit is a standard property list, XCSCredentialServer.plist:

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>

<plist version=”1.0″>

<dict>

<key>claimedFacilities</key>

<array>

<string>servermgrd</string>

<string>servermgr-listener</string>

<string>servermgr-notify</string>

</array>

<key>claimedSenders</key>

<array>

<string>servermgrd</string>

<string>servermgr-listener</string>

<string>servermgr-notify</string>

</array>

<key>logMaximumLevel</key>

<string>debug</string>

<key>logPath</key>

<string>/Library/Server/Logs/servermgrd.log</string>

</dict>

</plist>

Once open, look for a key called logPath. Change that to the desired path, such as /Volumes/MyDrive/Logs/credserver.log and then restart the service:

serveradmin stop xcode; serveradmin start xcode

Mac OS X Server Mass Deployment

Reset the Server App in Yosemite Server

The Server 3 app that comes with Yosemite (aka Yosemite Server if you’re a Yosemite Sam fan) is great. But when you go making changes to some things, you’re just going to cause problems, sometimes something as simple as just upgrading to the latest and greatest version of Server… I know, you’ve been told that host name changes and IP changes are all kinds of OK at this point; “look, Charles, there’s a button!” Well, go ahead, click it. Don’t mind me, you might just be alright. But then again, you might not… And upgrades that use a migration wizard… Um, when it works it’s a thing of beauty. But when it doesn’t, you might be restoring some stuff from backup. But just before you do that restore, let’s try one more thing. Let’s try and rebuild some certificates and configuration settings that shouldn’t impact actual service operation. Let’s try to reset the Server app and let a fresh install of the Server see if it can fix issues.

Now, I want to be clear, this is the last resort before restoration. I’ve had a lot of luck with services remaining functional and preserving settings when I do this, but don’t expect that. Basically, we’re going to do what we looked at doing back in ’09 with AppleSetupDone but one designed just for servers, so the file is in the same place (/var/db) and called .ServerSetupDone. To remove it, close Server app and run the following command:

sudo rm /var/db/.ServerSetupDone

Once removed, open the Server app again and then let the Server app run as though it’s new. Cruft, begone!