Web-based Distributed Authoring and Versioning (WebDAV) is an often-overlooked protocol that can provide cross-platform file sharing with minimal client-side configuration. This article explains how to configure WebDAV servers on Windows with IIS, on Mac OS X and Linux with Apache, and how to connect using built-in WebDAV clients on all three OSes.

Windows as the WebDAV Server

WebDAV is built in to IIS 5 and later versions. On Windows XP, WebDAV is enabled by default when IIS is running. To enable IIS on Windows XP Pro, install it from Add/Remove programs, Add/Remove Windows Components. Drill down into the IIS component details in the Add/Remove dialog and choose to add the World Wide Web sub-sub-component as shown below. Follow the prompts to install and start IIS:

Once IIS is installed and running, create a folder to share. In this example, we will use f:webdav. To enable WebDAV for a particular folder, browse to it in Windows Explorer, right-click the folder, choose properties, and go to the Web Sharing tab:

Choose the Share this Folder radio button, and set Read, Write, and Directory browsing access permissions, and no Application permissions. The alias listed here is the name IIS will use, and by default is the same as the folder name:

In the IIS MMC console, you’ll now see your shared folder listed as a new virtual directory in the Default Web Site. At this point, the folder is accessible via WebDAV. For increased security, install an SSL certificate and force 128 bit encryption for the webdav virtual directory. For this example, we will stick with the default Windows Integrated Authentication.

OS X as the WebDAV Server

To enable Apache on OS X, go to System Preferences, Sharing, and turn on Personal Web Sharing:

In httpd.conf, uncomment the mod_dav module lines:

$ <strong>sudo vi /etc/httpd/http.conf</strong>
..
#LoadModule unique_id_module    libexec/httpd/mod_unique_id.so
LoadModule setenvif_module      libexec/httpd/mod_setenvif.so
<strong>LoadModule dav_module       libexec/httpd/libdav.so</strong>

..
AddModule mod_so.c
AddModule mod_setenvif.c
<strong>AddModule mod_dav.c</strong>

Still in httpd.conf, add a path for the DAVLockDB and a directory definition that points to the folder to be shared. This Apache configuration requests unencrypted passwords. To increase security, install an SSL certificate and configure the webdav directory to only accept SSL connections:

..
<strong>DAVLockDB /Library/WebServer/davlocks/DAVLockDB
<Directory "/Library/WebServer/Documents/webdav">
  DAV On
  AuthName "WebDAV Login"
  AuthType Basic
  AuthUserFile /etc/httpd/.htpasswd
  <LimitExcept GET HEAD OPTIONS>
    require valid-user
  </LimitExcept>
  Order allow,deny
  Allow from all
</Directory></strong>

Now create the directories and set permissions:

$ <strong>sudo su</strong>
# <strong>mkdir /Library/WebServer/davlocks</strong>
# <strong>chown www:www /Library/WebServer/davlocks</strong>
# <strong>mkdir /Library/WebServer/Documents/webdav</strong>
# <strong>chown www:www /Library/WebServer/Documents/webdav</strong>

Finally, create the user and password file and restart the httpd daemon:

# <strong>htpasswd -m -c /etc/httpd/.htpasswd testuser</strong>
New password:
Re-type new password:
Adding password for user testuser
# <strong>apachectl restart</strong>
/usr/sbin/apachectl restart: httpd restarted

Linux as the WebDAV Server:

On Linux, use your favorite package manager to install Apache. Most distributions will use Apache httpd 2.0 which has mod_dav built-in, so the only editing of the httpd.conf file needed are the DAVLockDB and Directory definitions. Note that you can also authenticate against Active Directory or LDAP using the mod_auth_kerb or mod_auth_ldap Apache modules. For this example, we’ll stick with using htpasswd:

$ <strong>sudo vi /etc/httpd/conf/http.conf</strong>
..
<strong>DAVLockDB /usr/local/apache/var/DAVLockDB
<Directory "/var/www/html/webdav">
  DAV On
  AuthName "WebDAV Login"
  AuthType Basic
  AuthUserFile /etc/httpd/.htpasswd
  <LimitExcept GET HEAD OPTIONS>
    require valid-user
  </LimitExcept>
  Order allow,deny
  Allow from all
</Directory></strong>

Now create the directories and set permissions:

$ <strong>sudo su</strong>
# <strong>mkdir /usr/local/apache/var</strong>
# <strong>chown apache:apache /usr/local/apache/var</strong>
# <strong>mkdir /var/www/html/webdav</strong>
# <strong>chown www:www /var/www/html/webdav</strong>

Finally, on Linux create the user and password file and restart the httpd daemon:

# <strong>htpasswd -m -c /etc/httpd/.htpasswd testuser</strong>
New password:
Re-type new password:
Adding password for user testuser
# <strong>/sbin/service httpd restart</strong>
Stopping httpd:  [ OK ]
Starting httpd:  [ OK ]

Now let’s try it out by connecting some clients!

Windows as the WebDAV Client

In Internet Explorer, go to File Open, check the Open as Web Folder box, and type in the URL of the shared folder. Note: When connecting over non-SSL connections, append a “/#” to the URL here. Windows XP has two built-in methods for connecting via WebDAV. Appending /# is a workaround that forces the use of the Web Folder Client connection, which will authenticate successfully to the WebDav-enabled folder as configured here.

Click OK to open the URL and you will be prompted to login. Enter the username in the form of Domainusername. If you are logging in to IIS using a non-domain local computer account, enter the username in the form of computernameusername, where computername is the hostname of the IIS server. When connecting to Apache as configured here, enter the username and password that you created using the htpasswd command.

On successful login, the WebDAV share opens in a new Windows Explorer window, and a shortcut is added to My Network Places. You can now drag and drop files between this window and the local computer, and edit Microsoft Office documents directly.

OS X as the WebDAV Client

To connect in Finder, choose Go / Connect to server (command-K). Type in the WebDAV server URL and click Connect:

At the login prompt, fill in domain name, username and password. If you are logging in to IIS using a non-Domain account, enter the IIS server computer name in the Domain box. When connecting to Apache, enter the username and password created with htpasswd:

On successful login, the WebDAV folder is mounted:

Linux as the WebDAV Client

To connect on Linux using Konqueror, type in the URL in the address bar using webdav:// instead of http:// . At the login prompt, enter domainusername or computernameusername in the username box when connecting to IIS. When connecting to Apache, the username as configured here is testuser:

On successful login, the WebDAV folder is connected:

On all platforms, WebDAV provides some basic file-locking to prevent simultaneous file modifications. Permissions are handled by the underlying file systems and cannot be modified remotely. WebDAV has some limitations, but can be an easy solution for firewall-friendly cross-platform file sharing.

The post Configuring WebDAV for cross-platform file sharing appeared first on Big Nerd Ranch.

Graphical remote login sessions can be valuable tools for cross-platform server administration. This article is an overview of the best applications for cross-platform GUI remote login in a mixed network of Windows, Mac OS X, and Unix computers.

Windows as the Remote Server

To connect to a Windows computer remotely, use Windows Remote Desktop (aka Terminal Services). While VNC server also runs just fine on Windows, this is one area where the Microsoft solution outshines the open source counterparts–Windows Remote Desktop is faster, more secure, and more full-featured than VNC. In addition to remote screen, keyboard and mouse control, Windows Remote Desktop provides drive mapping between client and server, sound and printer redirection, and encryption of the entire remote session. While I’ve never found much use for printing to a remote computer’s printer via Remote Desktop, the ability to temporarily auto-mount drives between the two computers often comes in handy.

All Windows Remote Desktop traffic is encrypted and sent over a single TCP port (3389 by default). So, like VNC, it’s easy to route/NAT through firewalls. While there are licensing restrictions to deal with, the level of access allowed is generally sufficient for administration purposes. The Remote Desktop server piece is included in Windows XP Pro and in Windows NT 4.0 Terminal Server Edition and all later server versions. XP allows one remote client to connect at a time, whereas Windows Servers allow two concurrent inbound remote administration sessions.

Unix to Windows

To connect from Unix/Linux to Windows, use rdesktop and tsclient. rdesktop is a Remote Desktop client that speaks the Windows Remote Desktop Protocol (RDP). tsclient is a Gnome-based graphical front-end for rdesktop that looks very much like the Windows Remote Desktop client. tsclient also works for connecting to VNC and X servers. Both rdesktop and tsclient are released under the GPL.

Mac OS to Windows

To connect from Mac OS X to a Windows computer, use Microsoft’s Remote Desktop Connection Client for Mac, a free download from Microsoft. Unlike the Remote Desktop clients for Windows and Unix, the Remote Desktop Connection Client for Mac only allows one remote session at a time.

Mac OS X as the Remote Server

To connect to a Mac remotely, run a VNC server on the Mac. There are two good options for free VNC server software on Mac OS X. The easiest to get started with is the VNC server built in to the Apple Remote Desktop (ARD) client (version 2.1 and later). ARD client is included in Tiger 10.4, and is a free download for earlier OS X versions. While designed to work with ARD server, the ARD client can also be accessed from other OS’s like any other VNC server. The ARD client VNC server is a bit slow when used in this way, but can be sufficient for remote access over high bandwidth LAN connections. Unlike most VNC servers, it also supports sharing multiple-monitor systems.

The best Mac OS VNC server option is OSXvnc, a GPL’d VNC server developed by Redstone software. It’s the fastest and most full-featured free VNC server for Mac OS. Nice features include an option to only accept local VNC connections, good for forcing ssh-tunneled VNC connections. OSXvnc also supports concurrent user sessions when users are logged in locally with fast-user switching enabled.

An optional simplified front-end for OSXvnc is Mike Bombich’s Share My Desktop. Its simple installation and one-button interface make it nice for end-user support. It’s easy to walk someone through its setup over the phone, and, like regular OSXvnc, is faster than the ARD client VNC server.

Windows to Mac

To connect from Windows to a Mac, use a VNC client (aka VNC viewer). RealVNC and TightVNC are both free VNC packages that have Windows VNC clients. Download just the client/viewer, since the server side won’t be used on Windows. To run it, launch the viewer executable–no installation is necessary.

Unix to Mac

To connect from Unix to a Mac, use a VNC client. A VNC client and server are included with most every Unix/Linux distribution. Launch the VNC client (vncviewer) from a shell, or use the tsclient GUI front-end.

Unix as the Remote Server

To connect to a Unix server remotely, run a VNC server on it (xvnc). By default, Unix handles concurrent VNC sessions differently from Mac OS and Windows. On Unix, if you log in remotely as a user who is also logged in locally, a separate user session is started for the remote user. The locally logged on user doesn’t necessarily see the remote user session. When you remotely login to a VNC server running on Mac OS as a user who is actively logged in locally, you essentially take over the desktop of the local user–the local user sees the mouse moving around the screen. On Windows XP, the local session is locked when a Remote Desktop session is started. On Windows Server, you have the option to login as the local console user or establish a separate login session.

Windows to Unix

To connect from Windows to Unix, use a VNC client, just as when connecting to a Mac.

Mac OS to Unix

To connect from Mac OS to Unix, use a VNC client (OSXvnc is server only—it does not include a VNC client). For the Mac OS VNC client, try Chicken of the VNC. It’s fast, lightweight, and has a funny name.

VNC Security Note

VNC login information is encrypted, but the VNC session itself is not. For remote server administration, VNC sessions should always be tunneled over ssh. On Windows, use PuTTY to establish an ssh session that forwards the VNC traffic to the VNC server over ssh.

Text-mode logins remain valuable tools for remote administration, but applications that allow graphical remote logins are a great addition to any cross-platform network administrator’s toolbelt.

The post Cross-Platform GUI Remote Login Roundup appeared first on Big Nerd Ranch.

Centralized authentication greatly simplifies network administration. This post teaches how to log in to a Mac or Linux computer using centrally managed user accounts from a Windows Active Directory domain controller. With this configuration, the same Windows user accounts can be used to log in to any of the three operating systems, Mac OS, Linux, or Windows, with the same user network folder auto-mounted.

Requirements
Mac OS X 10.3 or newer, with all updates installed.
SAMBA 3.x on Linux (this example uses Fedora Core 4, but the steps should apply to other distributions as well).
Windows Domain Controller, running Server 2000 or newer.

Abstract
On Windows:
Configure the user network home folder path. Redirect the My Documents folder to the same network path (optional). Configure Kerberos to allow unencrypted connections (additional notes as to why this setup is used are at the end of the post).

On Linux:
Configure Kerberos, SAMBA, and Winbind with the domain settings. Join the domain. Configure NSS and PAM for AD authentication. Set PAM to autocreate local user home folders and auto-mount the network user folder specified in Active Directory. Log in as a domain user to test the configuration.

On OSX:
Configure Active Directory access using the Directory Access utility. Join the domain. Add the Active Directory domain to the Authentication and Contacts search paths. Change login preferences to prompt for username and password. Log in as a domain user to test the configuration.

Detailed Steps
We’ll handle each of the OS’s in order. First, Windows:
The steps below assume a domain named bnr.com in an IP range of 192.168.1.x with a domain user account called student and a domain controller named win-svr1. Adjust these values to match your own setup.

Windows
Configure the network folder that clients will automount:

1. Specify the user’s home folder path on the Profile tab of the user account properties in Active Directory Users and Computers. This is the path that each OS will connect to on login as this user. The parent folder (in this case win-svr1home) is the UNC path of a pre-existing shared folder on a Windows server. The subfolder for this user (win-svr1homestudent) is created automatically:

Redirect the My Documents folder to the same network folder:
This is optional, but it’s a nice bonus having the My Documents files available from the other computers.

1. In the Default Domain Policy User Configuration Windows Settings Folder Redirection My Documents, choose the Basic setting and specify a file server share path. All users’ My Documents folders will be redirected here:

Configure security settings to allow SMB connections:

1. Allow unencrypted connections in the Default Domain Controller and Default Domain Group Policies:
   In the Default Domain Controller Policy Computer Configuration Windows Settings Security Settings Local Policies Security Options, find “Microsoft network server: Digitally sign communications (always)” and “Microsoft network server: Digitally sign communications (if client agrees)”. Define both of these policies as “Disabled”:

1. Make the same change under the Default Domain Policy.

Apply the updated group policy changes:

1. Run gpupdate on the server from a command line to refresh group policy settings:

   c:>gpupdate
   Refreshing Policy…

   User Policy Refresh has completed.
   Computer Policy Refresh has completed.

Now, on to Linux:

Linux
Configure local NTP time source to avoid Kerberos time conflicts:

1. Add a local ntp server to the ntpservers file

   $ sudo vi /etc/ntp/ntpservers
   192.168.1.10
   clock.redhat.com
   clock2.redhat.com

Specify a DNS server for local name resolution:

1. Add a local DNS server to /etc/resolv.conf:

   $ sudo vi /etc/resolv.conf
   search bnr.com
   nameserver 192.168.1.10

Configure Kerberos:

1. Edit krb5.conf

   $ sudo vi /etc/krb5.conf
   [logging]
   default = FILE:/var/log/krb5libs.log
   kdc = FILE:/var/log/krb5kdc.log
   admin_server = FILE:/var/log/kadmind.log

   [libdefaults]
   default_realm = BNR.COM
   dns_lookup_realm = false
   dns_lookup_kdc = false
   ticket_lifetime = 24h
   forwardable = yes

   [realms]
   BNR.COM = {
   kdc = win-svr1.bnr.com:88
   admin_server = win-svr1.bnr.com:749
   default_domain = bnr.com
   }

   [domain_realm]
   .bnr.com = BNR.COM
   bnr.com = BNR.COM

   [kdc]
   profile = /var/kerberos/krb5kdc/kdc.conf

   [appdefaults]
   pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
   }

2. Test Kerberos by requesting a TGT (any domain account will work, but domain here is case-sensitive):

   $ kinit student@BNR.COM
   Password for student@BNR.COM:

3. Check if ticket request was valid by listing active Kerberos tickets:

   $ klist
   Ticket cache: FILE:/tmp/krb5cc_500
   Default principal: student@BNR.COM

   Valid starting Expires Service principal
   09/30/05 12:37:36 09/30/05 22:37:39 krbtgt/BNR.COM@BNR.COM
   renew until 10/01/05 12:37:36

Read on for more Linux configuration steps

Configure Samba for domain access:

1. Edit smb.conf

   $ sudo vi /etc/samba/smb.conf
   [global]

   # workgroup = NT-Domain-Name or Workgroup-Name
   # workgroup = mygroup
   workgroup = BNR
   ..
   # Security mode. Most people will want user level security. See
   # security_level.txt for details.
   # security = domain
   security = ads
   ..
   #============================ Share Definitions ============================
   idmap uid = 16777216-33554431
   idmap gid = 16777216-33554431
   # template shell = /bin/false
   template shell = /bin/bash
   winbind use default domain = no
   # username map = /etc/samba/smbusers
   password server = win-svr1
   realm = BNR.COM

2. Start/restart Winbind:

   $ sudo /etc/init.d/winbind restart

Join the AD Domain:

1. First, clear the way:
   Before joining the domain, make sure a computer account for this computer does not exist on the Domain Controller. The computer account is created automatically when joining the domain. Also, if the /etc/samba/secrets.tdb file exists, rename it. This file is created when joining the domain.

2. Next, use “net ads join” to add the computer to the domain:

   $ sudo net ads join -U administrator
   administrator’s password:
   Using short domain name – BNR
   Joined ‘fed1’ to realm ‘BNR.COM’

3. Test the domain connection by listing all domain users:

   $ wbinfo -u
   BNRadministrator
   BNRguest
   BNRsupport_388945a0
   BNRwin-svr1$
   BNRkrbtgt
   BNRmac1$
   BNRstudent
   BNRfed3$

4. List all domain groups:

   $ wbinfo -g
   BUILTINsystem operators
   BUILTINreplicators
   BUILTINguests
   BUILTINpower users
   BUILTINprint operators
   BUILTINadministrators
   BUILTINaccount operators
   BUILTINbackup operators
   BUILTINusers
   BNRdomain computers
   BNRdomain controllers
   BNRschema admins
   BNRenterprise admins
   BNRdomain admins
   BNRdomain users
   BNRdomain guests
   BNRgroup policy creator owners
   BNRdnsupdateproxy

Configure NSS to use Winbind:

1. Edit nsswitch.conf

   $ sudo vi /etc/nsswitch.conf
   ..
   #passwd: files
   #shadow: files
   #group: files
   passwd: files winbind
   shadow: files winbind
   group: files winbind
   ..
   ethers: files
   netmasks: files
   networks: files
   #protocols: files
   protocols: files winbind
   rpc: files
   #services: files
   services: files winbind

   #netgroup: files
   netgroup: files winbind
   publickey: nisplus
   automount: files
   aliases: files nisplus

2. Test NSS Winbind connection by listing users from the passwd file with getent:

   $ getent passwd
   ..
   BNRadministrator::16777218:12777216:Administrator:/home/BNR/administrator:/bin/bash
   BNRstudent::16777217:16777216:student:/home/BNR/student:/bin/bash
   ..

3. List groups using getent:

   $ getent group
   ..
   BNRdomain admins:x:16777219:BNRadministrator
   BNRdomain users:x:16777216:
   BNRdomain guests:x:16777217:
   ..

Configure system-auth to use Winbind with PAM:

1. First, backup your system-auth file:

   $ sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.backup

2. Now, add the Winbind entries to the system-auth file:

   $ sudo vi /etc/pam.d/system-auth
   #%PAM-1.0
   # This file is auto-generated.
   # User changes will be destroyed the next time authconfig is run.
   auth required /lib/security/$ISA/pam_env.so
   auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
   auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
   auth required /lib/security/$ISA/pam_deny.so

   account required /lib/security/$ISA/pam_unix.so broken_shadow
   account sufficient /lib/security/$ISA/pam_localuser.so
   account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
   account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_winbind.so
   account required /lib/security/$ISA/pam_permit.so

   password requisite /lib/security/$ISA/pam_cracklib.so retry=3
   password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
   password sufficient /lib/security/$ISA/pam_winbind.so use_authtok
   password required /lib/security/$ISA/pam_deny.so

   session required /lib/security/$ISA/pam_limits.so
   session required /lib/security/$ISA/pam_unix.so

Configure PAM to auto-create network home directories:

1. Add the pam_mkhomedir.so module. If the home directory does not exist, it will be created on first login.

   $ sudo vi /etc/pam.d/login
   ..
   session required pam_selinux.so multiple open
   session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

2. Add the pam_mkhomedir.so module to gdm.

   $ sudo vi /etc/pam.d/gdm
   ..
   session optional pam_console.so
   session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

Create a local directory for storing domain user profiles:

1. All domain user local profiles (local home directories) will be auto-created under this folder:

   $ sudo mkdir /home/BNR

Set the network folder to automount:

1. Create a file that contains your domain login information (fill in your actual username and password):

   $ vi ~/.smbpass
   username = student
   password = mypassword
   

2. Set the file to readable only by root:

   $ sudo chmod 600 ~/.smbpass
   $ sudo chown root ~/.smbpass

3. Create a directory to be used as the mount point:

   $ mkdir ~/nethome

4. Add an entry to fstab to mount the share on login (this is the last line of fstab, all on one line):

   $ sudo vi /etc/fstab
   //win-svr1/user /home/BNR/student/nethome smbfs
   credentials=/home/BNR/student/.smbpass,dmask=777,fmask=777 0 0

Try it out:

1. Restart and login using domainuser username format. In this example, the login name is bnrstudent. On first successful domain user login, you will see a message that the user’s local home folder is created, and the network folder is mounted:

Read on for OS X Configuration

Finally, the OS X configuration:

OS X
Configure DNS:

1. In the TCP/IP configuration of your network device, add a DNS server and search domain for local DNS resolution:

Configure Directory Access:

1. Open Directory Access from Applications, Utilities. In the Services screen, highlight Active Directory and click Configure:

1. In the Active Directory configuration, enter the Domain name and computer name:

1. Under Advanced Options, User Experience, set home location to use SMB, and set default user shell:

1. Under the Administrative Advanced Options, allow administration by domain and enterprise admins, and allow authentication from any domain in the forest:

Join the AD Domain:

1. Click Bind to join the Mac to the Windows Domain. Enter username and password of a Windows user that has permission to join a computer to the domain. Check options to use AD for authentication and contacts:

1. Under Directory Access, Authentication, make sure Active Directory is in the search path:

1. Under Directory Access, Contacts, make sure Active Directory is in the search path:

1. Under Directory Access, Services, configure SMB/CIFS, adding the Workgroup name and WINS server address:

Configure login options:

1. Launch System Preferences, Accounts. Under Login Options, uncheck ‘Automatically login’, and choose ‘Display login window as: Name and password’

Try it out:

1. Restart and login using domainuser username format. In this example, the login name is bnrstudent. The user’s network home folder will automount and appear as a folder on the dock:

All done!

Final Notes

With the release of Service Pack 1 for Windows Server 2003, Windows domain controllers require encrypted communications by default. While SAMBA 3.0 and Mac OS X 10.4 and newer also support encrypted SMB communications, this Windows server change has broken some SMB interoperability. As a result of this change, the current workable solution is to disable Microsoft’s digital signing of network communications as specified in the steps above. Be warned that this configuration results in a less secure network.

The post Mac OS/Linux/Windows Single Sign-On appeared first on Big Nerd Ranch.