I’ve been underwhelmed (if that’s a word) by the list of common ports used on the Apple platform recently, so I started my own. It’s available at http://krypted.com/guides/common-apple-ports/ if you’re interested. It’s also under the Tools menu of the site. And yes, I’m aware that I can cat /etc/services; this includes some rudimentary notes.
krypted August 17th, 2015
krypted August 3rd, 2015
Posted In: personal
You’ve got Open Directory running and humming beautifully in OS X Server (Server 3.5 on OS X 10.10 Yosemite). You show up to work and the hard drive has died on that perfectly configured Open Directory Master. Luckily, you have a replica and you have an archive of your Master. You can restore or you can promote your Replica to a Master. What to do? Well, I can’t tell you what you should do, but I can tell you that Apple has planned for this. Here, we’re going to look at promoting that Replica to a Master. Because after all, hard drives fail. Let’s look at what all this looks like.
Create An Open Directory Archive
In order to properly restore an Open Directory Master or promote a Replica to a Master, you’ll need the SSL keys. You should also just keep archives of your Open Directory environment around (albeit in a secure location) because you really never know. To create an Open Directory Archive, which has the keys in it as well as data needed to restore a Master, first open the Server app. From within the Server app, click on the Open Directory service.
Towards the bottom of the screen, click on the cog wheel icon.
At the menu, click Archive Open Directory Master…
When prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button.
At the Archive Open Directory Master screen, choose a location to create your archive. Also, provide a password for the archive. Click the Archive button when you’re ready to proceed.
At the Confirm Settings screen, click Archive. The archive is then created. Keep this safe as it has all your base are belong to us in it. You have to do this proactively. Once the hard drive in that Open Directory Master craps out, you’ll need the Archive to put the pieces of Humpty Dumpty back together again.
Promote A Replica To A Master
Provided you have a Replica and an Archive, promoting a Replica to a Master couldn’t be easier in OS X Server. To do so, open the Server app from the Replica and then use the cog wheel icon to bring up the menu.
Here, click Promote Replica to Master.
At the “Promote Open Directory replica to master” screen, provide an Open Directory username and password (e.g. diradmin with the appropriate password). Also, choose the archive you created previously. Then click Next. The Replica will become an archive. Once finished, remove any other replicas and repromote them.
Stop Open Directory
Another option is to stop Open Directory on the replicas until you can get your Master back up and running. To stop Open Directory, open the Server app and click on the Open Directory service.
Click on the OFF button. You’ll then be prompted to verify that you really want to stop directory services on the server. Click OK (which should probably read a bit more ominous, like “OMG, OK”.
The server is then stopped. To completely remove Open Directory from the server, run the slapconfig command, followed by -destroyldapserver:
Also, don’t forget to go to the Master and remove any servers from there as well, once they’ve been fully demoted. View the logs using cat for any other weirdness:
krypted October 16th, 2014
Configuring Calendar Server in Mountain Lion Server is a fairly simple and straight forward process. The Calendar Server is a CalDAV Server, leveraging HTTP and HTTPS, running on ports 8008 and 8443 respectively. To enable the Calendar service in Mountain Lion Server, open the Server application and click on Calendar in the SERVICES section of the sidebar.
Once open, click on Edit to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.
At the Configure Server Email Address screen, provide the type of incoming mail service in use, provide the address of the mail server and then the port number used, if not a standard port for HTTPS-based IMAP (or POP if you’d prefer), the user name and the valid password for the account. Then click on the Next button.
At the outgoing mail server screen, provide the Outgoing Mail Server address, the port, whether or not SSL is in use (it should be if possible), the password protocol, the user name and the password. Then click on the Next button.
At the Mail Account Summary screen, review the settings and if correct, click Finish. Back at the service configuration screen, click on the plus sign (“+”) and provide a type of location, a name for the location, whether or not invitations to the resource are accepted and then enter the account name for any accounts that can manage the location’s calendar (they will auto-complete, so there’s no need to remember users and groups exactly). Click Done to complete the setup. Use the Resource setting in type to configure a resource instead of a location. The two are the same, except the Type field.
There are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command:
sudo serveradmin settings calendar
One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:
sudo serveradmin settings calendar:HTTPPort = 8008
sudo serveradmin settings calendar:SSLPort = 8443
You can then start the service using the start option:
sudo serveradmin start calendar
Or to stop it:
sudo serveradmin stop calendar
Or to get the status:
sudo serveradmin fullstatus calendar
Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Preferences. From the Preferences screen, click on Accounts to bring up a list of accounts. Here, click on the plus sign (“+”) to bring up the “Add an Account” screen.
At the “Add an Account” screen, select CalDAV from the Account Type menu and then enter the User Name and password configured on the server, as well as the address of the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.
Once the server is configured it appears in the list of accounts in the sidebar of the Calendar app. Create calendars in the account and then to share a calendar, right-click on the calendar and click on Share Calendar…
At the Share Calendar screen, provide the name the calendar should appear as to others and click on the plus sign (“+”) and enter any accounts to delegate administration to.
Back at the Calendar Settings screen, use the settings to configure Availability and refresh rate of calendars, as seen above. Click on Server Settings to assign custom port numbers.
Click on the Delegation tab to view any accounts you’ve been given access to.
Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.
Overall, the Calendar service in Mountain Lion Server is one of the easiest to configure. Most of the work goes into settings configured on client systems. This, as with Exchange, dedistributes administration, often making administration more complicated than with many other tools. But that’s a good thing; no one wants to access other peoples accounts, for calendars or mail for that matter, without those users knowing that it was done, as will happen when resetting passwords…
krypted July 30th, 2012
I don’t believe in upgrading major operating systems for servers in place. There, I said it. If I’m doing an upgrade from Snow Leopard to Lion, I’m about 99.9% of the time going to do so with a clean install. Before I do so, I’m going to export all the data from my old server and when I’m done with the fresh, clean, loving installation, I’m going to import that data back into my server. Actually, before I import the data, I’m going to install all of the point releases, application updates and security patches. That’s my process for production servers.
Open Directory isn’t very different. I Archive and Restore servers as often as I reinstall, upgrade or even downgrade Open Directory Masters. I treat Replicas differently: mostly in that I don’t treat them at all. Instead I clean install them and just re-promote them once my Master is back in place. If I have any schema extensions or other mods I’ll just sync those myself prior to promotion. I trust my process, it’s worked for me for more years than I care to admit.
Before You Upgrade
Archiving Open Directory data is a pretty straight forward process. Open Server Admin from /Applications/Server and then click on the Open Directory service. From here, Click on the Choose… button for Archive in: and select a location to store the Open Directory data. Then, click Archive and provide a password. Pretty easy so far.
Now, check your Kerberos Realm, IP address and hostname on the server. For the IP address, you can take screen shots of the Network System Preference pane, or pipe the output of ifconfig to a text file. For the hostname, I don’t trust the GUI of OS X (no offense to the excellent UX developers employed at Apple). Therefore, use scutil for the names. Also, we’ll want that Kerberos information. I usually just grab that from my Server Admin Open Directory screen. Finally, we’re also going to get the OD policies using slapconfig again. In sequence, these commands would be:
ifconfig > ~/Desktop/mytextfile
scutil --get HostName >> ~/Desktop/mytextfile
scutil --get ComputerName >> ~/Desktop/mytextfile
scutil --get LocalHostName >> ~/Desktop/mytextfile
sudo slapconfig -getmasterconfig >> ~/Desktop/mytextfile
sudo slapconfig -getmacosxodpolicy >> ~/Desktop/mytextfile
Also, backup any certificates, custom service principals you may have installed or other service data or data data that is needed on the host, if any.
Once you’ve got all of the important stuff backed up and know what you’re going to call the server moving forward, it’s time to install the operating system. If the server came with a Lion operating system pre-installed, skip this part. Use a Lion computer to create a recovery partition using the Recovery Disk Assistant.
Once you have a valid recovery partition (on a thumb drive for now), boot to it on the server you are upgrading and wipe the system through Disk Utility. This step is probably pretty scary. And it should be. Make sure all your data is backed up before you do it. By the way, if you haven’t copied the mytextfile then think long and hard about whether there’s anything else missing before you start the reformat process on that drive (I seem to have to learn all of my lessons the hard way)… I also like to have a clone of the system as a back-out plan, just in case there are any problems with the upgrade. It adds a little latency but I’ve had to revert a few times with these upgrades, and having that clone sure beats pulling an all nighter…
Once wiped, Choose the Reinstall Lion option and install the operating system. Then install all available patches (10.7.3 or higher is very, very important, btw). Once installed, use the App Store to buy Lion Server and install it, but don’t open it just yet.
Remember those commands from earlier. When possible, Open Directory upgrades the smoothest when the IP address and host name are the same. Therefore, look at your mytextfile. Setup the IP information the same as it was, verifying against ifconfig and then use the first host name from the scutil output to configure the HostName (using mdm.krypted.com as my example):
sudo scutil --set HostName mdm.krypted.com
Then the second host name:
sudo scutil --set ComputerName mdm.krypted.com
And finally, the third:
sudo scutil --set LocalHostName mdm
Now check changeip:
sudo changeip -checkhostname
If it gives you the all clear, you’re ready to proceed. Next, download the Server Admin tools from Apple at http://support.apple.com/kb/DL1488.
Provided that the installation is good, the host names match up in scutil and the IP address is the same as it was, open the Server app for the first time (from /Applications). The server will install the various components that complete the installation. Once installed, click on the Next Steps drawer and verify that the host name is good. If it is, you should see a message similar to the one below.
Now promote your server. It’s going to be tempting to use Server Admin or slapconfig. If you use slapconfig you will regret it unless you use the new options supplied by Apple. Why? Because the Server app gracefully creates SSL certificates used in directory services binding; certificates that are not created with the old style slapconfig commands. Given that I’ve not seen complete documentation for slapconfig (many of the options required for correct scripted promotion in Lion aren’t actually in the man page), I’d just use the GUI for now (and if you don’t like using a GUI, then I challenge you to build OpenLDAP, Kerberos and all the other components setup by the Server app from source – that might cure the CLI snobbiness we all have from time to time). Also, be careful with how you promote/demote – this article outlines some reasons not to use slapconfig -destroyldapserver any more.
From the Server app, click on Users in the Server sidebar. Here, you’ll notice that all of the accounts that are listed are black busts of users. Groups are similar. So far, all users created are automatically local users. If that’s not what you want, remove any of those accounts prior to continuing.
Click on Manage Network Accounts… to bring up the Configure Network Users and Groups wizard. Click Next at the introductory screen.
Then provide the Directory Administrator information (e.g. diradmin with a password of diradmin for the security conscious) and click on Next.
At the Organization Information enter the information you want on the SSL certificate that is automatically generated for Open Directory. This includes the Organization Name and Admin Email address (this might not be enough information for some SSL providers, but it’s a good start) and click on Next.
At the Confirm Settings screen, verify your information is as intended and then click on Set Up. The Open Directory Master is created. Once created, all new users will have the same icon as the local users, with the exception of a globe to indicate they are network accounts. Now check your logs to make sure everything installed smoothly.
Importing Users, Groups and Computers
Provided that the host name and IP address are the same on your server, importing the data back into Open Directory couldn’t be easier. Open Server Admin and then click on Open Directory and then on Archive in the top icon bar. Here, click on Choose and browse to the dmg you created when backing up the server. Click Restore and enter the password previously supplied. You can also import users from within the Server app.
Now that your users are back, it’s time to make sure they’re a member of the groups that provide access to services. These are hidden by default, so in the Server app, use the Show System Accounts option under the View menu or if you’d rather use Workgroup Manager use Show System Records under the View menu to see the groups. Each service has a different group name. For example, Profile Manager is the Profile Manager ACL (or com.apple.access_devicemanagement for the short name) group.
Add each user into the group that needs access to these services, click Save and you’re ready to bind some clients!
Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane.
To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted.
Click on the Edit… button and then the plus sign (“+”). Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.
It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user.
Provided everything works that’s it. The devil is of course in the details. Good luck!
krypted February 15th, 2012
The default, self-signed certificate that comes on a SonicWALL causes alerts during a Nessus scan. This is because the device uses a certificate that comes on the device and isn’t signed by a valid CA. Chances are, there are limits around who can load the SonicWALL web interface in the first place. But, if you don’t want Nessus to continue alerting, or if you just want to use a certificate signed by a valid CA because it’s a good security practice, you might want to add a new certificate.
The first step is to generate a new CSR. To do so, open the SonicWALL web interface and then click on System in the SonicWALL sidebar. Then click on Certificates and scroll to the bottom of the screen until you see the New Signing Request button.
At the resultant Certificate Signing Request screen, fill out the fields with your information.
Click on the Generate button to bring up the Export Certificate screen. Click Export and then choose where to save the CSR.
Once you receive the certificate, you’ll want to install it. The easiest way to do so is to go back to the Certificates screen (under System in the SonicWALL sidebar) and then scroll down to the bottom, clicking on Import… Here, use Choose File to pick the cert, provide a name for it and the password for it and click on Import.
Next, click on Administration (also under System in the SonicWALL sidebar). Scroll down to the Web Management Settings section of the screen and use the Certificate Selection field to select the newly installed certificate.
And that’s it. I’ve had to restart the device to get it to work properly, but overall, a pretty straight forward process.
krypted January 7th, 2012
Posted In: Network Infrastructure
Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, Mail.app in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp.
The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For me.com, this might be:
But note that there’s not a response. This is because me.com doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for 318.com:
Which looks like this:
Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance.
Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed.
Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows:
By reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures.
While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!
krypted January 6th, 2012
krypted August 2nd, 2009
I originally posted this at http://www.318.com/TechJournal
So you installed your new server and youâ€™re having a few problems. Letâ€™s look at the common issues and a few simple fixes for them.
iCal will not start, with log entries that it is unable to create a virtual host:
Check your host name. iCal is going to need the host name to be correct in order to start. Use
scutil --get HostName and then make sure that the host name listed in the iCal Server settings is identical to this value.
You setup a user, check the box in Workgroup Manager for Enable Calendaring and then save your settings but you get the following error in your logs:
Oct 12 15:51:26 cedge Workgroup Manager: +[WPUser userWithGUID::] returned nil!
This is likely caused by the fact that you are enabling a calendar for a local user. Try using an OD based user and see if you get the same error.
You got everything started and the account was created for the user but when you add an account in iCal it fails to connect. Make sure that the port that iCal server is using is located at the tail end of the host name for the iCal Server. One issue that we see here is that unless you are using managed accounts then iCal Server is not likely going to append the port number for you iCal Server. Also verify that you can connect to the remote server, and remember that you can always open the URL of the server followed by a : and then the port number and get a login prompt. If you can authenticate to this as the user whose calendar that you are trying to setup then you can use the information in this screen to determine ACL information and other security settings that could be keeping calendars from working. Also keep in mind that while your default port might be 8008 your default port if you are using SSL is actually 8443.
Once you get this far, you should be able to create an event and see data listed in the Overview tab for iCal. If so then you should be able to about anything you want in the iCal server.
If you prefer to use the serveradmin CLI to control your services, you can also use the
serveradmin settings calendar:ServerHostName = "SomeHostName" variable to change your host name. You can also use the
calendar:HTTPPort to change the port number you are using for connectivity.
krypted November 10th, 2007
Posted In: Mac OS X Server