The first thing I want to walk through is Open Directory, OS X’s directory services implementation (roughly analogous to Microsoft’s Active Directory). Many of OS X Server’s other services rely upon or make use of a directory in some way, so it’s important to know how it works.

Veterans can probably skip this section, since the basics of Open Directory in Lion Server is basically identical to previous versions. Pick back up in the Profile Manager section for things that will be new to you.

For those of you who have no experiences with directory services, a brief explanation: imagine you’re the IT support person for a business of, say, 50 employees, and each of those employees has a computer. So you don’t have to manage all of the user accounts on those computers manually, you want to have all of their usernames and passwords stored on your server so that you can keep better track of them. You can also organize users into groups, so that if you have one particular attribute to apply to many different accounts, you can do it once to the group instead of once for every member of the group. This is the essence of Open Directory and other directory services.

It goes further than that: with centrally stored credentials, you can also more easily manage access permissions on file shares or enable your employees to use the same username and password to login to multiple computers. You can control password requirements and store relevant information (email addresses, etc.) about your users. You can also tie other products into your directory so that your users can use the same credentials to access email or internal websites. The list goes on.

OS X Server can either host its own directory (using Open Directory), tie into another, pre-existing directory service (like Active Directory), or both (using Active Directory to manage credentials but Open Directory to manage Apple-specific functionality - Apple calls this a “golden triangle” configuration, and it’s a bit outside the scope of this review). For our purposes, we’ll setup a standalone Open Directory that we’ll then use with other services throughout the review.

Open Directory setup is one of the few things that can still be done with both Server.app and Server Admin, though the approaches differ:

In Server.app: Go to the Manage menu and click Manage Network Accounts.

You’ll be asked to create a Directory Administrator account (which will differ from the local administrator account) - this is done to enable users to manage the directory without giving them control over other server functions. The default is diradmin, and that’s what we’ll go with.

Enter your organization’s name and your admin’s email address, and click through the rest of the prompts - you’ll have a quick and easy directory setup with a minimum of fuss.

In Server Admin: To enable Open Directory in Server Admin, make sure the Open Directory service is viewable, and select it. In the Settings tab, click the Change button next to the server’s Role.

Here, you’re given three choices. We’ll want to set up an Open Directory master, but you can also connect your Mac to another directory (like Active Directory) or set up an Open Directory replica here. For the uninitiated, an Open Directory replica connects to an existing Open Directory master and mirrors every change made to the master - this can provide for load balancing (in an organization with many Macs) or automatic failover in the event that one or the other server crashes (Macs connected to an Open Directory master will automatically fall back to the replica if the master fails and vice-versa).

Anyway, elect to setup an Open Directory master, input your desired Directory Administrator credentials, input your organization name and admin email address, and you’re set, same as with Server.app. If you want to set a different Kerberos realm or LDAP search base, you can also do it here (but if you don’t know what that means, the default settings are fine).
(screenshot)

You can also use Server Admin to backup or destroy a directory you’ve made - to backup, just use the Archive tab to save and restore copies of your directory’s data. To delete the directory, go to the Settings tab, click Change next to the server’s Role, and select Set up a standalone directory.

Once it's running, you can go ahead and bind client computers to it: in OS X, this is accomplished by going to the Accounts preference pane, clicking Login Options, and clicking the Join button next to Network Account Server.

Enter your server's address in the box that pops up and click OK. If successful, you should now see a green dot followed by your server's address, and you should be able to login to your client computer with any of the user accounts you create (we'll go over that next).

Now that you've got a working directory server with some clients attached, let's show you what you can do with it.
Server.app and Server Admin Overview Open Directory: Creating Users and Groups and using Workgroup Manager
Comments Locked

77 Comments

View All Comments

  • HMTK - Wednesday, August 3, 2011 - link

    OK so you can definitely run a Mac OS X vm on vSphere 5 but only on Apple hardware. What a joke! Probably Apple idiocy rather than a technical limitation.
  • Spazweasel - Wednesday, August 3, 2011 - link

    Apple is a hardware company. OS/X and iOS exist to make hardware sales possible (thus the cost of development is included in the pricing for Apple hardware, something the Apple haters conveniently overlook) Allowing the running of OS/X on non-Apple hardware reduces Apple hardware sales, so they don't do it.

    "Idiocy"? Yeah, sure, whatever.
  • HMTK - Wednesday, August 3, 2011 - link

    Not allowing Mac OS to run under a hypervisor on non-Apple branded hardware won't help them either. Or do you think a halfway decent IT-department would put a desktop machine or a hard disk posing as a server in a data center? They'd rather pay a few 100 € more for a license if they could run it on ESXi/XenServer/Hyper-V and reliable hardware.
  • Spazweasel - Wednesday, August 3, 2011 - link

    Apple makes its money on the desktop, not the server room. I doubt it's worth the effort. OS/X in the server room is a niche product, and Apple know it; it's much more suited as a workgroup/small office server, and those environments do not have ESX or Xen installations.

    Apple has no incentive to support OS/X in a VM, and plenty of reasons not to. Really, I don't see why this is a surprise.
  • HMTK - Thursday, August 4, 2011 - link

    I'm not saying it's a big surprise, I'm saying it's stupid. why not make good manegement tools for their iOS available in a way that companies can integrate better in their infrastructure?

    You might be surprised as to how many small shops are going the virtualization route. Even if you have only a single server it makes sense in the long run when the time comes to replace the hardware. Just import the VM on the hypervisor on the new hardware and you're done.
  • GotThumbs - Tuesday, August 2, 2011 - link

    This is an interesting article and I enjoyed the depth of detail. As a builder of my own systems for years, does the use of this software bind you to using only a ready built Apple system? It seems Apple is slowly trying to create a close proprietary system where you have to use apple hardware and apple software. I know their are hackintosh systems but it seems its still going to be quite a bit of effort and so far seems to be a waste of time for me. As the article mentions, there are lots of alternatives available. Apples MO seems to be offering zero options for using outside sources. Apple consumers are being channeled to Itunes and the Mac App Store for all purchases. I'm personally not a fan of that trend and have no intentions of bowing down to that kind of control. I can see where the general consumer who has very little technical knowledge is quite accepting of Apples controls as its a very simple and somewhat brainless system packaged in a slick looking package.
  • GrizzledYoungMan - Tuesday, August 2, 2011 - link

    Or is it still something we're all going to pretend works, when it very clearly doesn't out in the real world (If it worked, why would DAVE exist)? I'm referring here to the myriad of permissions issues and oodles of useless garbage sidecar files that pop up after a few days of operation in a mixed environment.

    Haven't read the article. Probably won't. Sorry. Apple is a joke at anything that designing anything that doesn't fit in your pocket/surrogate vagina of choice.

    I get this feeling, deep in my angry muscle, every time some imbecile waves around his iThing, raving about Apple's genius, while I'm thinking about all the time that has been wasted trying to get OS X desktop clients to do things that have worked out in the real world for years now.
  • blueeyesm - Tuesday, August 2, 2011 - link

    Not in Lion, as Samba moved to GPL3 licensing.

    http://www.appleinsider.com/articles/11/03/23/insi...
  • GrizzledYoungMan - Tuesday, August 2, 2011 - link

    You know what's wild? I should actually be excited they're moving to a new standard - the NAS' I often recommend to clients support SMB2, and see useful performance gains from it.

    But then I read "Windows networking software developed by Apple" and my heart sinks. Realistically, what are the odds this is going to work?

    Honestly, I don't really blame the design teams over there so much as a closed corporate culture that both ignores the feedback of their customers and denies any complaints exist.

    They're really missing out on the sorts of improvements that most big software developers make using the information gathered during large, open betas and the like.
  • repoman27 - Tuesday, August 2, 2011 - link

    As the article you linked to points out, since version 10.2 Mac OS X has shipped with Samba, an open-source, reverse engineered version of SMB 1.0. With Lion, Apple dropped Samba and added native support for SMB2 while maintaining the ability to connect with SMB 1.0 machines as long as they use UNICODE and extended security. This means Mac OS X 10.7 can no longer connect out of the box with some SMB 1.0 or Samba machines (which it had done for the last 9 years), but it does have full support for SMB2.

    As for GrizzledYoungMan's "oodles of useless garbage sidecar files," it's not like Mac users have any use for a thumbs.db file either. Just hide the metadata files, or don't allow write permissions on the folder if you don't want to see that kind of stuff, but these types of files are most likely only going to become more prevalent as time goes by.

Log in

Don't have an account? Sign up now