I realize now that writing technical articles in a word processor isn't the best way to go, since it's a pain to revisit and edit things later (once you find a mistake, which is invitable). So, I'm taking the original article I wrote and reprocessing it here. (Figuring out how to make a nifty inline box for easier reading of code entries helped out, too.)
This article's a broad-stroke outline on how to integrate Samba 3, OpenLDAP, Kerberos and AFP in Leopard Server, specifically as it would apply here at Stanford. What this gets you:
- Filesharing services to both Macs and Windows clients
- Using the campus' OpenLDAP directory for account provisioning
- Using the main campus Kerberos realm for authentication
- Using Open Directory for delegating share access using ACLs
Things that need to be done:
- Install and update Mac OS X 10.5 Server.
- Install a proper edu.mit.Kerberos file.
- Request an AFP and CIFS keytab from the Kerberos group.
- Bind your Mac to Stanford's OpenLDAP directory.
- Make your Mac an Open Directory Master.
- Import your keytabs to your Mac server.
- Configure your smb.conf.
- Edit your AFP plist.
- Create sharepoints.
- Create groups in Open Directory.
- Create access control lists.
- Test from Vista, XP and Mac OS X.
- Secure your server.
Install Mac OS X 10.5 Server
There are best practice guides available, so I'll leave this up to you. Make sure you're installing the "Advanced" configuration option. If you have initially configured your server in "Standard" or "Workgroup" modes, you will need to change it to "Advanced." This is a one-way-only conversion; you can't revert back.
These instructions don't take into account a machine upgraded from 10.4 Server (Tiger); those administrators may have additional steps or considerations not covered in this document.
You will absolutely need to make sure your Mac has DNS properly configured and that your server's fully qualified domain name resolves forwards and backwards. This doesn't mean actually running DNS services on your Mac server. It simply means making sure you've properly entered your server's information in NetDB, your Mac is pointed to the campus BIND name servers, and the name variables in the operating system are matching accordingly.
Primary address = 172.24.198.14
Current HostName = pixiedust.Stanford.EDU
DNS HostName = pixiedust.Stanford.EDU
The names match. There is nothing to change.
Make sure you've updated to at least 10.5.2, as well.
Install a proper krb5.conf file
Apple doesn't really use this name for the Kerberos configuration file. It's called edu.mit.Kerberos instead, using the reverse-DNS naming convention that's all the rage. It's the same file, however, just with a different name and location as what some users would expect. You can get this file either by copying it from /usr/pubsw/etc/krb5.conf on any of the campus Unix/Linux cluster machines (cardinal, vine, bramble, etc), or installing the Kerberos for Macintosh Configuration Tool from Essential Stanford Software. You can actually call it /etc/krb5.conf if you want, but if you have a /Library/Preferences/edu.mit.Kerberos file, the latter will take precedence.
Request your keytabs
You will need to request at least two keytabs from the Kerberos group. Information is found on the Unix Group's Kerberos instructions webpage. Simple send an email with the requisite information.
- For Mac file sharing (AFP), ask for an afpserver keytab.
- For Samba (SMB) ask for a cifs keytab.
- Optionally, ask for a rcmd keytab for Kerberized ssh.
Bind your Mac to Stanford's OpenLDAP
Instructions are on another document, originally written for Mac OS X 10.4. They still apply with 10.5, though you will want to make one addition (for our purposes here). Add the record type Groups with the attribute posixGroup and the same search base as the Users record. Although user group in our OpenLDAP directory are inaccessible (for the purposes of creating ACLs), this dummy mapping makes Workgroup Manager happy.
Make your Mac an Open Directory Master
You need this to create the local LDAPv3 directory, which you will use to create groups for the purposes of regulating access. Theoretically, you can get away with just using the /Local/Default directory, but you'll want the advanced features of LDAPv3 and not the plist files that replaced NetInfo in Leopard.
Additionally, if you can, find another Leopard server to make an Open Directory replica, especially if you have a lot of accounts or want to use MCX for "group policy" type management actions on Mac client workstations.
Also, double-check that your OD Master doesn't rewrite your edu.mit.Kerberos file or populate your keytab with local service principles. You can prevent this by making sure you don't click the "Kerberize..." button in Server Admin's Open Directory management pane (or when first creating the OD Master). Kerberos should be shown as "Stopped" in the information window. It's not the end of the world if your OD master dumps 80 or so service principles in /etc/krb5.conf, but using
ktutil all day to delete those is a pain best avoided.
Import your keytabs to your server
You probably created your keytabs on one of the Unix/Linux clusters, and hopefully they're in an exceptionally secure directory in your AFS space. Use
scp to securely bring them down to your server and use the
ktutil command to read and write them to your server's /etc/krb5.keytab file.
Keep in mind that all Leopard machines are their own KDC (both Server and client versions of the operating systems). Don't be worried about seeing LKDC service principles, but make sure you see something like
email@example.com when listing.
Configure your smb.conf file
This is where it gets fun. Not unsurprisingly, you will need to use your favorite text editor along with Server Admin.
A little background about Samba on MOSXS
Samba is a little different in Leopard than in Tiger. Although both versions are listed as 3.0.25b-apple, there are considerable changes (not least of which is support for packet signing). For our work, we need to know that there are a couple configuration files in play when setting up Samba (which are not present with Tiger).
When you make changes in Server Admin, your input will write out an XML plist file at /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist. A launchd process will then notice the changes and kick off /usr/libexec/samba/synchronize-preferences. This binary will then read your XML plist and output an abbreviated (but typical looking) smb.conf file in either /var/run (≤10.5.1) or /var/db (≥10.5.2, subject to change). Finally, in the master /etc/smb.conf file, there's a hook to add those values in this supplemental configuration file.
If you hand-edit the smb.server.plist or the supplementary smb.conf file, your changes will be overwritten.
Adding your own variables unavailable in Server Admin requires hand editing the master smb.conf file in /etc --and then, only at the bottom after the comments. Since smb.conf files are read "top-down" any variables that contradict attributes earlier in the file (or in the supplementary smb.conf file) will be heeded. So, for example, if you edit /etc/smb.conf and add:
log level = 10
Your addition will supersede the "log level = 1" above in the same file, as well as the "log level = 3" that may be found in the supplementary smb.conf file in either /var/db or /var/run.
If you edit anywhere other than below the bottom comments in /etc/smb.conf, your edits risk being expunged in future OS updates.
Do not attempt to set the immutable bit on any of the Samba configuration files to thwart Server Admin. It will result in smbd not launching properly.
Stanford-specific edits, suggested parameters
Add the following to the bottom of your /etc/smb.conf file:
use kerberos keytab = yes
security = user
workgroup = WIN
realm = stanford.edu
acl check permissions = no
veto files = /Thumbs.db/
These edits have these effects:
- use kerberos keytab = yes will tell Samba to use your /etc/krb5.keytab which you've added the stanford.edu service principles. This will allow Kerberos authentication. This is actually a default earlier in one of the smb.conf files, but it won't hurt to add it again--just make sure it's somewhere.
- security = user means that the users' account information will be passed to the passdb backend, specified by default with the odsam variable.
- workgroup = WIN allows the use of spnego (itself permitted earlier in the default configuration). "WIN" is for our environment here on campus; change accordingly.
- realm = stanford.edu is the Kerberos realm for Samba as specified in the server's edu.mit.Kerberos file.
- acl check permissions = no is to override a bug in Samba where Windows machines don't properly honor the ACLs at the root level of the share.
- veto files = /Thumbs.db/ will make this small file invisible to Windows users. This miniature database holds meta-information from Leopard, such as a thumbnail preview.
You can add other variable here in the [global] preference realm, such as increasing the verbosity of logging.
A word about how to configure Samba shares
Use Server Admin to set up your shares. This is different from Tiger Server, where Workgroup Manager is used.
Do not add your own Samba shares in /etc/smb.conf.
Like with the supplemental smb.conf written as output from Server Admin and hooked in the master /etc/smb.conf, Samba shares are similarly configured in the modular fashion. Each share that's made available by SMB will have a discrete configuration file located in /var/samba/shares. In the master /etc/smb.conf file, there's a hook to include these configuration files.
Unfortunately, there's currently a bug in Apple's distribution where hand-edits to Samba shares are not honored or cause problems. If you edit the /var/samba/shares/myshare file and add, say, "read only = yes" directive in the file, your edits will be expunged or rewritten when the share is modified again using Server Admin. If you delete the share in Server Admin and add your share information at the end of your /etc/smb.conf file, the testparm command will report errors and you will lose some functionality of Server Admin to modify access.
Edit your AFP property list
This is far simpler. Using your favorite text editor, edit /Library/Preferences/com.apple.AppleFileServer.plist so that the key
kerberosPrinciple has the string
From Server Admin, you can set AFP to permit Kerberos connections exclusively, or you can continue to permit standard authentication mechanisms (Diffie-Helman Key Exchange 2) while forcing the user to enter her or his SUNet ID and password.
Create groups in Open Directory
Using Workgroup Manager, authenticate to the /LDAPv3/127.0.0.1 domain and create a new group. When adding members to this group, select entities from the /LDAPv3/ldap.stanford.edu domain, and/or the local domains.
Create access control lists
Using Server Admin, select your share; begin creating granular ACLs by adding your ACEs pulled from any directory. For example, you can allow the "ITS People" found in the local Open Directory to read the share; the "ITS People" entity itself may contain users found only in Stanford's OpenLDAP directory. You could also add a singular user entity from OpenLDAP and give her full read/write privileges. You could add a user from the local Open Directory LDAPv3 directory and give him admin rights to the share. Finally, you may wish to grant full access to an account found only in the /Local/Default directory (an account created in System Preferences).
Test from Vista, XP and Mac OS X
From a Vista or XP workstation, connect to your Mac server. If your PC has been added to Active Directory, you will likely be logging in using your SUNet ID and password (your WIN domain credentials). You will not need to re-authenticate to access the shares for which you have permission. If your PC has not been added to AD, you will get a prompt for your username and password; enter WIN\sunetid as the username.
On the Mac, connect via the Finder to your server using AFP.
Mac users cannot connect via SMB.
If properly configured, you should be able to connect to the same sharepoint using AFP on a Mac and SMB/CIFS via Windows. Files open on one machine using one protocol should prohibit changes attempted by another machine using a different protocol.
You must take extra measures to secure your server from unauthorized access.
By default, new shares created using Server Admin are created with traditional Unix permissions of 775 and root:admin for owner and group. Since the "world" octet refers to any user in any directory (including Stanford's OpenLDAP directory), your files may be unintentionally exposed to the whole campus.
You may wish to use Service Access Controls to allow/disallow access via a protocol, or you may wish to set permissions on each sharepoint to 770 or 750, or use TCP wrappers, or deny access connections outside a network using ipfw2. A combination of these measures is recommended.
• Samba and extended attributes
• Samba and ADS
• Hiding directories in Samba that have spaces in the name
• Scary Excel "Share Workbook" feature behavior with Samba (See also Apple KB article.)
• Invalid characters in extended attributes on Samba directories
Questions and answers
Does this work with Mac OS X 10.4 Server?
I haven't tried it, but I doubt it.
Why not bind your Mac server to Active Directory and use the so-called "magic triangle" configuration?
There is a bug in Apple's Samba distribution preventing some cross-realm authentication mechanisms.
Stanford's unique AD environment presents specific challenges. When your bind your Mac to AD, the Macs' OS wants to create a keytab with service principles based on information from the AD domain controllers. To the DCs your Mac may have a name like, "myserver.su.win.stanford.edu" thus your service principles look like, "firstname.lastname@example.org". When the server tries to resolve the name "myserver.su.win.stanford.edu" it will consult the campus BIND name servers (where it fails, because its FQDN is really "myserver.stanford.edu"). Kerberos thus fails.
Why not just use NTLMv2 instead of Kerberos?
There's another bug in Samba: When a Vista client attempts to connect to your Mac server, it initially presents its Kerberos credentials. Instead of gracefully falling back to NTLMv2, the Vista client is denied altogether. Windows XP, on the other hand, works properly, as it may be trying to offer NTMLv2 first.
Why can't Macs use SMB/CIFS to connect to the Mac server?
I'm not entirely sure. It requires a level understanding of spnego that I don't have. I recently bound a Mac to AD and tried to connect via SMB and it didn't work. I didn't pursue it further.
AppleTalk is [ _______ ]. Do I really have to enable it?
You couldn't enable AppleTalk if you wanted to. It's not supported in Mac OS X. And AFP is not "AppleTalk over IP" either.
(Alright--that's not entirely accurate. A certain AppleTalk sub-protocol, called "printer access protocol" or PAP, is still commonly used for communicating with printers on a local network. That's all that's left of AppleTalk.)
Besides, you really want your Macs to use AFP and not SMB. It's mature and stable; it supports a full suite of nice things, like large file support, dynamic and robust reconnections from sleeping computers, Unicode long names, and so on.
Do Windows workstations need to be added to the domain first?
No. Standalone Windows computers need only to present WIN domain credentials or a Kerberos TGT to connect.
Do I need to pre-configure my Mac workstations?
No. When connecting via AFP, users need only provide their SUNet ID and password to connect. If the server administrator permits only Kerberos authentication, your users will need to have installed a proper edu.mit.Kerberos file (available by installing the Essential Stanford Software components).
Can't I compile Samba from the project's website and install that?
Go nuts. You'll want to get it from Apple's open source Darwin project however. There are lots of little Apple things to take into account, like that odsam passdb backend and the HFS+ filesystem.
I really want to plug in external groups into my Open Directory groups for really hands-off access provisioning. Can I do that?
I don't think so, but it'd be nice. I don't know enough about the university's OpenLDAP configuration to answer that, but out-of-the-box, I can't see groups when bound to this directory. There are privgroups, which is what we want, but I don't know how to map those.