17 Oct 2011

Getting Root on OS X

There is a myth that exists that to have a root prompt on an OS X machine you need to enable the root account by performing some manipulation of the system settings that is non standard and can potentially open your systems (and especially servers) to security risks.

Yes, by default OS X ships with the root account disabled but logging in as root is still possible by the combination of 2 privilege escalating commands. 

sudo su -

sudo (perform with privilege escalation)
su (switch user) - (and switch full shell environment)

The command will give you a root login prompt indistinguishable from logging in as root in the first place and you don't need to enable the root account. You are effectively invoking a shell with root permissions but as "su -" runs all a users login scripts and other things to do with setting up your shell environment it is a lot cleaner than issuing the similar command:

sudo /bin/bash

Going Deeper
Not every user on a system can invoke these commands. *BSD is normally set up so users in the group "wheel" can use sudo and can su -. On OS X we can use trusty Workgroup Manager to investigate whether this is also the case.

Fire up Workgroup Manager and instead of logging into a server type localhost in the login window

and connect with one of the local admin accounts' credentials.

You'll be presented with the familiar Workgroup Manager window but you should be looking at the local directory of the computer that you are on. Mac OS X uses open directory for local machine accounts and we can use this familiar tool to manipulate things about the local machines' user and group structures.


Most of the accounts and groups your computer uses to keep things running are initially hidden. You can show them by using the View menu and selecting "Show system records"
Now select the groups tab in the left side bar and you will see all the groups on the local computer. Quite a lot, huh. Now you'll notice that there is no wheel group on OS X. 

So where does sudo and su - get the information about which accounts to allow to act as root?
Some information is provided by running the command sudo visudo which lets system administrators change which users and groups can run what commands as root on the computer. visudo is a special modification of vi that has syntax checking and other cool stuff for editing the /etc/sudoers file. You should only use visudo for editing /etc/sudoers.

On Mac OS X the "sudoers" file includes these lines:
# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL


So its users in the admin group that can run commands as root. Checking out the "Administrators" group (usually group 80) in Workgroup Manager shows us that its short name is "admin" (as mentioned in the sudoers file) and it should contain all the users marked as admin accounts for your local computer. In fact if you remove a user from this group the tick next to "Allow user to administer this computer" in the accounts section of System Preferences becomes unticked!

Users with benefits 
So lets use all this information about which users can escalate to root and which can't to our admin advantage. Try adding an account to the Administrators group on the local computer. There is a drop down on the pop out tray that allows you to switch nodes in the search path.


You can make any user or group of user from any server your computer is bound to a local administrator on your computer by adding them to the local "Administrators" group!

This means that if I have a bunch of users who want to be admins of the computers they log into I can make a group for them on the server, call it "Local Admins" or something, add their server accounts into it, and then add the "Local Admins" group to the Administrators group on the workstation they use. Boom, no special permissions on the server and they have full control of that machine.

Its no fun having to visit every machine to set this up, but the good news is that there is a Terminal command we can push out via Apple Remote Desktop to add the server group of our "Local Administrators" to the "Administrators" group on every workstation you want them to have access to.

The command we'll use is dseditgroup (DirectoryService edit group)

sudo dseditgroup -o edit -a localadmins -t group admin

The above command adds the "localadmins" group to the admin group on the local computer. Note you have to use the groups short names. Also note that you don't have to specify that the "localadmins" group is coming from an Open Directory server. The command looks for the "localadmins" group in the machines' search path. For more information see the dseditgroup man page

1 Sep 2011

Lion Server and SVN

Whether you upgraded your server and suddenly found your apache configuration eaten by the allegorical Lion and your Subversion Repository inaccessible or whether you’re running Lion Server from fresh and want to get an HTTP or HTTPS based SVN server set up and running you’ll want to read this. I’ll proceed to save you hours of looking through Lion Server’s new readme files and man pages for scarce morsels of information on the new web configuration interface. Lets begin.
vhost or not vhost
Before
After?!?!?!
Server admin wasn’t great for Apache configuration, but Lion Server App isn’t anything. 




The red light green light thing shows whether the domain points to your computer or not and is quite cool if your DNS system isn’t too exotic but adding a site seemed maddeningly broken. I read something about adding manually to your apache configs to fix it but that seemed stupid as server.app will happily blow away all your changes in a heartbeat. It so happens that Server only adds the right lines to /etc/apache2/sites/virtual_host_global.conf if you bind the site to a particular IP address. Unlike on snow leopard the order of the vhosts can’t be specified and can be loaded in any order. There is no way to define the same kind of complex configuration you could before.


You need to set up a website here which you will use to access your SVN server. You need the DNS for the domain you specify to point at your server. I settled on something like http://svn.example.com.


EDIT: This broken behaviour is fixed in 10.7.3, and, even more frustratingly, if you do bind your new host to an IP address it will break profile manager as your configuration will override the default one! So in 10.7.3 you need to make sure the IP address box is set to "any".
Plist to meet you
Now comes the fun part. Lion server’s web configuration backend has a cool new plugin type architecture. Its reminiscent of Objective-C’s delegate callback system in as much as they are offering a clearly defined point to insert your own configuration without having to interfere too much in the magic Apple is trying to conduct in the /etc/apache2 directory. It also keeps your special configuration around even after server.app blows away and recreates the /etc/apache2/sites directory for the hundredth time.
man webapp.plist shows you what it can do, which includes adding configuration to a vHost, setting SSL policy, making sure another launchd process is running (e.g. Making sure that if your config is active so is an SQL server) or even requiring another webapp. Web apps are simple to define and follow Apple’s XML property list standard. You don’t need to include all the directives, making them easier to read. Here’s one I made for my subversion server.

<?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">
<!-- See man pages for webapp.plist(5) and webappctl(8) for information about this example webapp.plist -->
<plist version="1.0">
<dict>


<key>name</key>
        <string>com.themacosxserveradmin.subversion</string>

<key>includeFiles</key>
        <array>         <!-- Include files are activated in virtual host when webapp is started -->
                <string>/etc/apache2/svn_configs/subversion.conf</string>
        </array>
               <key>requiredModuleNames</key>
                <array>
                        <string>dav_svn_module</string>
                        <string>authz_svn_module</string>
                </array>
        <key>sslPolicy</key>    <!-- Determines webapp SSL behavior -->
        <integer>1</integer>    <!-- 0: default, UseSSLWhenEnabled -->
                        <!-- 1: UseSSLAlways -->
                        <!-- 2: UseSSLOnlyWhenCertificateIsTrustable -->
                        <!-- 3: UseSSLNever -->
                        <!-- 4: UseSSLAndNonSSL -->
</dict>
</plist>
The included file referenced is exactly the same file from my Snow Leopard server SVN post that defines the /svn/ part of the domain to present an SVNParentPath.
Contents of /etc/apache2/svn_configs/subversion.conf



        <Location "/svn/"> 
                AuthType Basic 
                <Limit GET HEAD OPTIONS CONNECT POST PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> 
                        Require group  developers 
                </Limit> 
                AuthName "svn_auth" 
                SVNParentPath /Groups/developers/repos
                DAV svn
        </Location>



As before this file is set to restrict access to users in the "developers" group by http digest auth.
Webappctl
Web apps can be “started” and “stopped” in a way analogous to a launchd service. There can be a process which is spawned, as chosen in the webapp.plist, and as far as I can tell what starting and stopping a webapp does is alter some config files and reload apache. You can also specify a webapp to attach to a certain vhost only. Using the webappctl tool you can, for example, confine the wiki service to only one vhost
webappctl start com.apple.webapp.collab wiki.example.com


Errors fail with the message web:state = "STOPPED".  This can also mean your server has started successfully. There is no reason given for any error and no hints as to how to fix it so if you can't start a web app you need to look through all your configuration files and try again. Check you apache config files with apachectl configtest and then go though your webapp.plist to make sure all the tags are balanced and that there is no invalid data or syntax errors.


Check which web apps are currently running with
webappctl status -


Final Bits and Pieces
Unfortunately it looks like you can't complete this elegant process without editing httpd.conf manually. No matter how i tried to require the dav svn modules they still needed to be loaded specifically in the httpd.conf file. So crack out your favourite editor and dive in. I added my lines just under loading the dav module.

LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so
LoadModule authz_svn_module libexec/apache2/mod_authz_svn.so


SSL certificates for all services are now defined in one place, in the Hardware section on the Settings Tab of Server.app. 
This is that place
Certificates. I mange them. Get a free certificate from startSSL.com

However I've been getting SSL errors in Xcode (which uses the command line svn tool) but that seems to be a separate issue in that the svn command isn't talking to keychain anymore about which certificates to trust. sigh. Time to move to git? 


In the end it was a bit of a slog but at least I can commit without having been committed.

31 Aug 2011

On Mobile Accounts and Syncing

I'm still working on the post about Apache and Lion Server. Taking the screenshots is time consuming and i've got a lot on. In the mean time i thought i would share an email conversation I had with a reader recently as I thought it contained some pretty cool stuff.

To: theAdmin@themacosxserveradmin.com
Date: 27 August 2011 17:40:59 GMT+01:00
Subject:Blog Post 6 Feb 2011
Hello:  
I’m relatively new to Mac servers and am trying to configure mobile computer accounts.  I read you blog from February 6, got your e-mail, and decided to drop you a note.  
I can’t get a mobile computer account to sync no matter what I do on a Snow Leopard server.  The manual for Snow Leopard Server is long and bulky but overall doesn’t contain much useful information on this subject; and there’s precious little in any forums about Mac servers other than how to integrate with Active Directory (which I’m not doing).  
I don’t want to be a leech on your time but if you know of a setting that often gets overlooked, on which syncing is dependent, I’d appreciate it if you could let me know.  
Thanks.

I've certainly had fun with mobile accounts.

To: serveradminfan@importantcompany.com
Date: 29 August 2011 11:01:03 GMT+01:00Subject: Re: Blog Post 6 Feb 2011 
Hello
Thanks for the email. I agree mobile accounts are a pain to set up and i’ve had the same headaches as you.  
The answer to this is that, in workgroup manager you have to manage the preferences always and, despite whether you want syncing in the background or not, "background sync" and “manually" HAVE to be ticked for a login and logout sync to trigger. (I know I know)
You can then manage the frequency of the background sync on the last tab to be manual if this is not your desired behaviour. You can also configure away the icon in the menu bar so a manual sync can’t be triggered by the user. 
You also have to set up the sync rules yourself, there aren’t any provided by default if you’re managing them with workgroup manager, despite what the “network home and default sync settings” option would lead you to believe. 
As a final note you don’t have to manage homesync rules through workgroup manager, they are settings available to the user in the accounts pane in System Preferences. Click on the mobile user and click mobile account: settings button. 
Hope this helps you deploy your mobile accounts. 
Cheers 
The Admin
@osxserverblog
Turns out I wasn't on the right track for their issue. Issues can manifest themselves in so many ways and clumps of users in forums complaining about vaguely similar things. Here was the final response.
Hi Admin:  
Thanks for the information.  I ended up talking with Apple tech support about the problem.  They reproduced it and admitted they’ve had some issues with Lion and OD. Here’s what ended up solving the problem:  
  •  Unbind the client.
  • Delete all home folders on client and server.
  • Reset all permissions on the server and client machines using Disk Utility and restart both machines when complete.
  •  Create a separate automount sharepoint on the server for network user home folders.  (Don’t use the default sharepoint as permissions conflicts can happen.)
  •  Re-bind the client machine using a different method than what I had used.  
First, change the login option to use the server, then open Directory Utility, select LDAP, and use the bind function from there.  Previously, my understanding was that the client was bound after selecting the OD server as the login option but apparently, it’s not fully bound until you click on the “Bind” button in Directory Utility.  (The green light beside the server after selecting it for logon is deceiving.)  
Thanks again.

8 Aug 2011

Inside Lion Server


There has been a shift in purpose for Lion Server. In Snow Leopard Server the philosophy seemed to be that all the easy stuff was fairly easy, but there was a steep learning curve for anyone who had never managed a server before. The medium stuff was mostly exposed in a GUI and so relatively easy, admittedly ambiguous at times, but you quickly ran up against a wall when trying to do interesting hard stuff so you had to drop down to Terminal. That was ok, however, as in theory anyone who wanted to do advanced stuff should be able to use the terminal anyway.
Lion is different. The easy stuff is brain-dead easy. Most services apple provides have an on/off simplicity to them that should make even the most beginner server admin stop and think “was that it?!”. My favourite change is the removal of the push notification server. Instead our servers can now hook up to Apple’s push notification servers and deliver notifications through them. Its as simple as clicking a button and we already know it works.
This is all made possible removing a lot of complexity from the Server App, which has more of a spiritual similarity to Server Preferences than Server Admin. The simplicity means a lot of features and settings are no longer GUI accessible, and Server Admin has lost the ability to configure things like web and calendar so medium and hard users now both have to use the Terminal to work OS X server. 
This strategy is no more apparent than in the /etc/apache2 configuration directory, where Apple has written a comprehensive readme to start the intrepid new server admin off on the right track. It lays out what each file and directory is for and what files you can modify without interfering with Server App’s inclination for vomiting configuration over everything. They have engineered a clear point to insert your own apache configurations and hook them onto certain virtual hosts, and even have them depend on certain launchd system services.
Even though they have spent a lot of effort on improving the Terminal based administration  its absolutely dreadful in comparison to a good Linux Server distribution. Most linux servers are designed to be set up on the command line and have standard tools that, if not easy, can be googled with great results. Whether Lion Server gets this same kind of attention remains to be seen. Going on web support for Snow Leopard Server config and issues I imagine support will be sparse.
So why run Lion Server? Why not. It hardly costs anything and you can run it on any computer. With it you get a great backup server for your other macs, you get iCloud features on your own machine with push notifications so you remain in control of your data (for better or for worse). The wiki server is cool and now tonnes better than before and I still believe Lion server is the best tool for managing suites of Macs and network user accounts (we still have Work Group Manager after all).

I guess that means OS X Lion Server has a place wherever you need an easy server for using with a bunch of Macs. 

25 Jul 2011

The Update to Lion

So I jumped in at the deep end and upgraded my home server to Lion. Theres no better way to learn what I'm up against for larger deployments than running into problems and fixing them. Not acceptable when people depend on your infrastructure but if my girlfriend even notices she can submit a ticket ;)

Upgrading to Lion
The app store process got in the way a little bit, but only because i didn't start the process in the way Apple expects. I assume that normally one would go to the app store click to buy Lion and then be prompted that you need the server app too and that the whole bundle would be x amount and would you like to buy them both.

I had already bought and downloaded both on another computer, had popped them on a usb stick and had tried to start the install. The app store recognised the Lion installer and noted that I had it installed but the Server App wasn't recognised. As such when running the installer I was faced with this error.
I clicked in the app store but it seemed to want me to buy both again and verify my payment details so I gave up there and decided to see how far I had to go to get both recognised. In the end I copied the Lion installer and the Server App to the Applications folder, added them both to the Dock for good measure and then logged out and back in again. The install procedure then started.


You can't run the server app in Snow Leopard
over 2 hours!
not even time can stand in the way of progress

The download of the additional server components was faster than expected and the installation restarted the computer. I was able to complete the Q and A part of the install over remote desktop to the server with the credentials of the local admin account.
And then the server rebooted into Lion...

I logged into the local admin account and fired up server. Oh Boy.
Web services were completely unconfigured, directory services were misbehaving, there are a complete lack of options for a lot of services.

The old server tools are a separate download and are needed to configure DNS and DHCP, among other services. The configurations for these remained unchanged. A little poking around revealed a Previous Systems folder in the computer's root directory which considerably had a copy of /etc and /Library from before the upgrade.

Conclusion
When upgrading from Snow Leopard Server use caution. Do not expect your services to work uninterrupted. Do not expect it to be easy to fix. All the tools you know are now different. Lots of options are gone and you will be left scratching your head. Turning to old friends doesn't yield much right now and potentially it never will. Right now The Admin recommends setting up Lion server on a separate machine and learning to duplicate what you currently do before moving away from Snow Leopard server.

Its all a bit wild west, but this is why I chose to upgrade at home first. With parallels to the recent final cut pro backlash not entirely lost on me I go forward. This is the beginning of the curve, lets crack out the Terminal.

21 Jul 2011

Roar!

So I upgraded to Lion and the Snow Leopard Server admin tools were deleted from my hard drive. Uh ho. When trying to install the old Snow Leopard Server Admin tools you get the following:

Oh noes! You can't install Snow Leopard Server Admin Tools on Lion!.

Before freaking out I checked out Apple's downloads page and found Lion Server Admin Tools posted. I downloaded and tried out and thankfully they work and I can fully admin my 10.6 Servers again.

I will be upgrading them to Lion soon, and I intend to post gratuitously about it but at least I still have time to consider my migration strategy.

7 Jul 2011

Looking forward to Lion

So here we are with 10.6.8, at the beginning of July with Lion and the scary new, simplified server round the corner and while I hope I've re-made the net restore images for the last time it means there are some bugs in Snow Leopard Server that will always be in Snow Leopard Server. I'm going to dedicate this post to two particularly annoying ones.

The dreaded inherited ACL duplication issue

This issue is well documented here but its still annoying.
The gist is that if your users shuffle around and duplicate a lot of nested folders, like bundles (which means pages and numbers documents, applications and others), then eventually any ACLs, including inherited ones, will be duplicated over and over again geometrically (only linearly over AFP, thank god) and quickly hit the Finder's internal limit for the number of ACLs it can handle resulting in an "Error -41" when trying to do something to the item in the finder.

The fix?
chmod -R -N ./*
Which will remove all the ACLs on items in scope. Then re-propogate.

The Hot-Desking Carbon API Kerfuffle

So you have Open Directory set up and AFP remote home folders and your users are hot desking on managed machines. Only some of the time, and sometimes completely randomly the icons on the desktop don't show up, or the Finder will prompt that the /Network/Servers/yourserver.com/Users Alias has broken and needs fixing. There are loads of other odd symptoms that come and go even between logins.

Interestingly that directory path isnt an alias at all, but a mount point being managed by OS X's automounter. The thing is that the finder is still using a Carbon API to access at least this part of the file system and unlike OS X's BSD underpinnings, which see the file system as one whole tree with other volumes attached at certain folders, the Carbon API sees each device as a separate tree. The finder literally has no ability to process that traversing a folder might also traverse a volume.

The dirty hack is that these volume traversals within the file system are presented to Carbon applications as aliases. Something seems to be being cached between users which means that while the mount point changes with the user, whatever service the Finder is using to keep track of these mountpoint to alias conversions is getting stuck and reporting the prior alias, which becomes invalid with the new user's credentials.

Long story short means that for the most part everything is fine (and in fact the finder can still read the user's home folder and make changes) but the seemingly crufty Desktop Services part of the Finder trips up and bothers my users and my support ticked system is full of "No desktop icons" reports.

My Fix?

set Apple Remote Desktop to combo update all the machines each night until I can identify which cache I need to delete with a logout hook.

13 Feb 2011

Open Directory Demotion: Just Don't

I've been having this problem recently where I try to use Workgroup Manager and I get authentication errors. It affects all computers bound to my open directory so its a server issue, except I can still get kerberos tickets and all other services function as expected. I can even work with Server Admin.

After a good googling I found this little gem. (among others)

The two pieces of advice I gleaned from the internet were:

  1. Fiddle around with the security options in the binding pane
  2. Demote and re-promote your open directory, effectively restoring to defaults
I have a problem with "solutions" that consist of tossing everything and starting again from system defaults. Yes it will probably work but I didn't make computer science my profession to take the easy route and go back to the defaults every time a niggling issue crops up. I couldn't administer the directory but at least the services were all up.

Anyway being a bit time poor this week I fiddled around with the binding options until I could log in again and left it.
This doesn't show the options that worked, but read on to find out why that probably doesn't matter anyway...
The only problem was that the authentication issue kept cropping up over the week and to top it off I was annoyed that suddenly the security options that I had been using for ages were apparently no longer usable.

Come the weekend and with non critical time to work on the server I set about trying to solve the problem once and for all. Out of frustration I decided to go with option 2 above. It would mean a lot of work but I was at the end of my tether. So I backed up the directory and demoted the server to a stand alone directory. The server was re-promoted to Open Directory Master and I tried to merge the backup back into the directory. 

It failed repeatedly. (You know how that feels)

The backup kept failing on merge so I decided to try importing and replacing the directory, in spite of the fact that this step would probably re-introduce the problem. When you import the directory, however, users that had admin rights have those rights stripped. I assume thats a security thing. I then had a directory with no admin user in it.

So another demotion and re-promotion was required, but this time I gave the diradmin user a different UID and a different short name. The idea is to have an admin user that won't clash with users that are in your directory backup. The hunch paid off and the directory merged this time and after restoring admin rights to my original diradmin user I was back where I started.

At this point reading the fine manual seemed like a good idea.

Page 87 talks about authenticated binding. While this is a nice idea it also causes a world of hurt when used with DHCP and...
Important: If you choose “Encrypt all packets (requires SSL or Kerberos)” and “Enable authenticated directory binding,”make sure your users are using one or the other for binding and not both.
I made the decision that authenticated binding wasn't needed on my network and then proceeded to turn on all the other security measures. Also from the manual:
Note: If you change the security policy for the LDAP directory of an Open Directory master, you must disconnect and reconnect (unbind and rebind) every computer connected (bound) to this LDAP directory
So then if you change these settings without rebinding your clients then you may end up with strange issues, perhaps issues such as authentication issues with workgroup manager (maybe). I imagine the authentication started to work when I changed the settings back to what they were originally when the directory was first set up and clients initially bound.

So with the lesson that the Snow Leopard Server manuals are actually pretty good learned and sane options chosen all thats left is to rebind all the clients(!)

6 Feb 2011

The different types of Open Directory users

So you have a snow leopard server and you have set up Open Directory and a reverse DNS entry for the server and you're other computers have joined the domain. Well done on getting that far. Now you want to decide how to set up your user account(s) so that it works the best for you. How do you configure them and what is fastest or most practical? This is a guide to help you figure out exactly how you want your Open Directory (OD) set up and then give you some tips for migration.

Local, Remote, or Mobile?
There are 3 main types of account you can have on OS X when attached to an Open Directory server (not including administrative and restricted user, a status which can apply to any of these 3 accounts). Each type of user has benefits and drawbacks.

A local account
is probably what you have now. Accounts created in the accounts pane on an OS X computer are local accounts and they can be administrative or restricted or managed by parental controls whether on the local computer or on a remote computer. You can run a local account in an OD setup no problems. If there is an account on the server with the same short name as on your local computer then Snow Leopard on your client machine is smart enough to be able to pick that up and ask if you want to set up the services that have been provided for you.


Pretty sweet. This type of user can also get kerberos tickets from the server, but you'll have to do it manually every login. Either with a kinit command in Terminal or by tricking iCal to store your Kerberos credentials in your Keychain. (it then automatically kinits for you). But that kinda defeats the point of "Single sign on" if you have to change the kerberos password in your keychain every time you have to change your actual password.

Another problem is that this user will not be affected by managed preferences set up with workgroup manager. I like using managed preferences to auto mount network shares and setting up some common settings for every computer I log in to, and even some for all users on the network. Look into managed preferences and you'll be considering the switch of account type to one of the others...

A remote account
is an account that lives entirely on the server. You add the account on the server and set a home directory for the account and then you can log in with the same user environment on all computers attached to your directory. Perfect if you have multiple computers and want to move, seamlessly, between them. You get your Kerberos ticket automatically at login so you are truly in a single sign on environment. You can also manage the preferences of the remote users so you can add stuff to the dock or auto mount shares from your server and loads of other cool things in Workgroup Manager. Great! 

The drawbacks can be quite large. As your home directory typically exists on the network the speed of your computer is limited by the speed of your network. AirPort users beware, you'll really want to be hooked up by ethernet for anything more than document editing, which I have done successfully over an AirPort connection. You can be sneaky and set up a remote account's home directory to point to /Users/ in Workgroup Manager. 
Look at that. A local directory for a remote account!? Whoda thunk it.

This then creates a home directory on each of the computers you log in to. You do lose that same environment on every computer you log into, but you get Single sign on and the speedup is great. The only other major issue is that you will still need to be able to access your server to log in. This isn't great for portable computers. And so enter the

Mobile Account!
These accounts are designed to be the "best of both worlds" between local and remote accounts. The remote account that you take with you. Configure an account (or computer) in workgroup manager to be able to set up a mobile account and you're away. Your computer makes a copy of the user information in your Open Directory and keeps it in sync whenever it can. You get a kerberos ticket automatically at login and you can log in from outside the reach of your directory server.

Your data is all stored on your local computer and you have the option to sync it back your network home directory. This can be a pain to set up and can add extra time to logins and logouts so it depends on how much you want to trade off the convenience of having all your data everywhere vs login and logout times. Mobile accounts also refresh their managed preferences whenever you log in within sight of your directory server.

For me, personally, I run a mobile account with home syncing off. I think its the perfect balance between the nice benefits of SSO and being part of a directory with the ability to use my laptop as a laptop. I use managed preferences to set up my user environment the way I like it for when I log on to other machines and when I change my password on my computer it propagates to the server and changes it everywhere. 

The best thing is that you can easily convert your current home directory to a mobile account directory. Simply backup (always backup first), then delete your user on your local machine. When it gives you the option you want to select "Don't change the home folder". Your home folder is then renamed to user.old. Log in with your mobile account. This will create your mobile account on your local computer and make a new home directory. Then log out and replace the newly created home directory with your old one, remembering to reset the ownership of all the items to your new user. (even though the users might have the same name they may have a different UID, and certainly a different UUID. The permissions need changing)

If you have any questions about local, remote or mobile accounts please leave them in the comments. It can be quite confusing at first but figure out what you want from your snow leopard server and then pick the account type to suit.

iCal to kerberos: Secretly I hate you

So last week iCal Server stopped authenticating via kerberos. My machines were getting tickets all fine for other services but calDAV just was refusing to authenticate. SSL off or on I kept getting the error:
"The server responded with “HTTP/1.1 401 Unauthorized” to operation CalDAVAccountRefreshQueueableOperation."
I read several help threads that seem to describe a myriad of things that you can do to help in this situation and just about all of them amount to voodoo.

Deleting my user's caches wouldn't work because it affects different users on the same machine.
Backup, Demotion and re-promotion of my Open Directory server is a drastic measure I don't want to take lightly.

To make the riddle more confusing I had the following log lines in the Password Service Server Log:
KERBEROS-LOGIN-CHECK: user {0x00000000000000000000000000000000, admin} is in good standing.
KERBEROS-LOGIN-CHECK: user {0x00000000000000000000000000000000, admin} authentication succeeded.
So authentication succeeded but something else was well and truly broken.

In the end, after a lot of head banging the solution for me was simple. To get authentication to my CalDAV server to start working again I had to type in the FQDN (fully qualified domain name) explicitly in server admin for the CalDAV service

Save, restart, all good. Why it was working previously for months without that explicitly in there is a mystery to me. Also a mystery is CalDAV in general. From reading the internet this issue probably isn't your issue at all but it is a nice quick fix to add to your arsenal before you rebuild your Open Directory.

7 Jan 2011

Snow Leopard Server and Apache: Know your defaults!

Configuring web in Server Admin is much much easier that writing config files by hand, but it gets a lot easier when you know what the hell its doing. I recently had a conversation with someone on twitter about the mysteriousness of this particular server admin screen. I think its also far too easy to open your server up to attack with no clear way of setting up defaults for the inexperienced.

The server admin web panel basically sets up vHosts when you are configuring "Sites". The configuration files are stored in /etc/apache2/sites/. For the tweak inclined if you want to modify these files in any way at all then you can add an include line at any part of the file to include any extra configuration that you want to make (or override). Server Admin likes to overwrite these files a lot but it wont remove any extra configuration files you may have included!


Example:
Include /etc/apache2/myconfigs/com.macosserveradmin.extraconfig


So another little tid bit is that the order matters. I've mentioned this before but it can't be said enough. The entries at the top override the ones lower down in the list. This means that if you add a particularly broad wildcard server alias to any site that you configure near the top of the list then that site will serve the request, not any site below it that may have a more specific hostname match.

This on its own would not be too much of a problem but I've both read around the internet and seen first hand that server admin seems to have a habit of adding * to the server aliases randomly and of its own accord. This means that a particular site answers all queries, effectively blocking off sites lower in the list. <virtual sigh>

Now the wiki services. Whatever your opinion on the wiki services (its only apache underneath so feel free to roll your own) you need to be very, very careful about making sure the boxes in the web services section are either ticked or unticked to your liking. Even if you have a different document root for the site and its serving 100% your own content (not the wiki server) and you accidentally have the calendar box ticked then you are opening up a potential attack vector to your server without realising it. When the calendar box is ticked directives are added to the site configuration generated by server admin that effectively turn apache into a proxy server for the calDAV server, whether thats local or another server on your network!! You can try it out by ticking the calendar box and then navigating to
http://yoursite.com/principals/

While great for enabling easy access to calDAV for any devices you may have on the internet it makes me a little uneasy that its so easy to set up proxying to a calendar server on your local network (it can use any calendar server see Settings>Wiki>External Web Services) that you may not be looking at for intrusion attacks. Especially when a site may be responding to the internet that you didn't expect. Also it may bypass the remote access server if you have that configured. This would mean any user could access calendars remotely even if you have set a whitelist in remote access.

My Configuration
So I thought I would post my configuration and maybe you can figure out why I've done what I've done and with the information in this article you can avoid some of the pitfalls with the web service in snow leorpard server.


I have 2 default sites, one for SSL and one for normal web services (port 80) that are very restrictive and only serve a page saying "Default Configuration". Make sure to disable all options, including CGI-Execution, Overrides and Directory Listings (you wouldn't want to completely fail would you). These have * in the alias section. I can then play around with my DNS server to check that my server isn't responding in an insecure way to unexpected domain names.

I then layer my other services up on top and here you can see my SVN Repo site, my main domain website, and my developer portal which uses wiki server. I have calendar services enabled on SSL for my main domain so that I can sync calendars with my iPhone on the go. 

Any questions, leave a comment!