Configuring Mountain Lion Server's Contacts Server

Mountain Lion has an application called Contacts. Mountain Lion Server has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service was called Address Book in Lion and below and is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange. I know I’ve said this about other services in Mountain Lion Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the name of the server in the Server app. Then click on Settings and check the box for “Enable Apple push notifications”. Provide the username and password for the Apple ID and then click on Finish. To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service. The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click Accounts and then click on the plus icon (“+”). At the Add Account screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.   When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server. To create additional lists of contacts, hover over the name of the server and a plus sign appears, click on it to create a group on the Contacts service. Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field. Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button. At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base: sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears. The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows: sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443 The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command: sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV" The service is then stopped with the serveradmin command: sudo serveradmin stop addressbook And started with the serveradmin command: sudo serveradmin start addressbook And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin: sudo serveradmin fullstatus addressbook The output of which should be as follows: addressbook:setStateVersion = 1 addressbook:logPaths:LogFile = "/var/log/caldavd/access.log" addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log" addressbook:state = "RUNNING" addressbook:servicePortsAreRestricted = "NO" addressbook:servicePortsRestrictionInfo = _empty_array addressbook:readWriteSettingsVersion = 1 If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook: sudo serveradmin settings calendar By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar: sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001 And then let’s see what it is in addressbook: serveradmin settings addressbook:MaxAllowedInstances If two services share a port and share all the same settings and even a binary then are they in fact the same service?
You know, there’s a million fine looking women in the world, dude. But they don’t all bring you lasagna at work. Most of ’em just cheat on you.

Using OpenSSL to Test Connectivity

When you’re testing connectivity to servers and you’re using SSL on those servers then your traditional ways of testing connectivity may been a little augmentation. For starters, you’re going to use the openssl to test connections. For example, if you have a web server you might traditionally attempt to telnet into port 80 and check you banners; however, if you have an SSL certificate on it then you might be better served connecting to port 443 using the openssl command. In the following example we’ll tell openssl to be a generic client (s_client)  and connect (-connect) to krypted.com over port 443:
openssl s_client -connect krypted.com:443
The output would then look similar to the following:
CONNECTED(00000003) depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://CERTAUTHORITY.com//
We could test smtp using the same, whether you’re using port 25 and requiring a certificate or another port. To test with port 25, assuming we can use a generic client again we’re going to change the port number and because SSL can work with smtp directly we’re going to use starttls to do so:
openssl s_client -connect  www.krypted.com:25 -starttls smtp
A valid connection would result in similar output to the following:
CONNECTED(00000003) depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://MYCERTAUTHORITY.com//emailAddress=krypted@mac.com
You could also initiate a new instance of an SSL listener, using s_server or just test the connection timer using s_time. Overall, openssl is a pretty invaluable toolkit that we’ll probably look at more and more on this site.