Stanford University, ITS CRC; Draft v.9; Noah Abrahamson 2/7/08 (Page 1)

Transcription

1 Configuring cross platform filesharing This is a rough guide to help you configure your Mac server to share files to both Windows and Mac clients. It uses the university s OpenLDAP directory for account provisioning, Kerberos for authentication and Open Directory for access controls. 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 however. 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. 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. 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. Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 1)

2 For Mac file sharing (AFP), ask for an afpserver keytab. For Samba (SMB) ask for a cifs keytab. Optionally, ask for a host keytab for Kerberized ssh. You don t need to bother making a Kerberos 4 srvtab; that service is deprecated in our environment. Bind your Mac to Stanford s OpenLDAP Instructions are on another document, originally written for Mac OS X They still apply with 10.5, though you will want to make one addition. 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. 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 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. 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 cifs/[email protected] 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. Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 2)

3 A little background about Samba on MOSXS Samba is a little different in Leopard than in Tiger. Although both versions are listed as b 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 ( ) or /var/db ( , 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: [global] 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: [global] use kerberos keytab = yes security = user workgroup = WIN realm = stanford.edu acl check permissions = no veto files = /Thumbs.db/ These edits have these effects: Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 3)

4 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. 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). 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 afpserver/[email protected]. 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. Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 4)

5 Create groups in Open Directory Using Workgroup Manager, authenticate to the /LDAPv3/ 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. Security considerations 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. Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 5)

6 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, cifs/[email protected]. 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. Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 6)

7 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. Stanford University, ITS CRC; Draft v.9; Noah Abrahamson [email protected] 2/7/08 (Page 7)