Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm using Ubuntu 10.04 Server.

share|improve this question
    
This should have been posted as an answer to a question. Please edit this so it's a question and move what you posted above to be an answer to it. From the FAQ: "It's also perfectly fine to ask and answer your own question, but pretend you're on Jeopardy: phrase it in the form of a question." –  Dennis Williamson Apr 25 '10 at 23:20

1 Answer 1

up vote 24 down vote accepted

[Edit] I've since tested this the full release of Ubuntu 10.04 Server (21/May/2010).

I've configured my Ubuntu 10.04 Server LTS residing on a windows network to authenticate logins using active directory, then mount a windows share to serve as there home directory.

Here is what I did starting from the initial installation of Ubuntu.

  1. Download and install Ubuntu Server 10.04 LTS
  2. Get updates

    # sudo apt-get update && sudo apt-get upgrade

  3. Install an SSH server (sshd)

    # sudo apt-get install openssh-server

    Some would argue that you should "lock sshd down" by disabling root logins. I figure if your smart enough to hack an ssh session for a root password, you're probably not going to be thwarted by the addition of PermitRootLogin no in the /etc/ssh/sshd_config file. If your paranoid or not simply not convinced then edit the file or give the following a spin:

    # (grep PermitRootLogin /etc/ssh/sshd_config && sudo sed -ri 's/PermitRootLogin ).+/\1no/' /etc/ssh/sshd_conifg) || echo "PermitRootLogin not found. Add it manually."

  4. Install required packages

    # sudo apt-get install winbind samba smbfs smbclient ntp krb5-user

  5. Do some basic networking housecleaning in preparation for the specific package configurations to come.

    1. Determine your windows domain name, DNS server name, and IP address for the active directory server (for samba). For conveniance I set environment variables for the windows domain and DNS server. For me it was (my AD IP address was 192.168.20.11):

      # WINDOMAIN=mydomain.local && WINDNS=srv1.$WINDOMAIN && WINDNS_IP=192.168.20.11

      If you want to figure out what your domain and DNS server is (I was contractor and didn't know the network) check out this helpful reference.

    2. We need to christen the Linux box on the new network, this is done by editing the host file (replace the DNS of with the FQDN of the windows DNS):
      # sudo sed -ri "s/^(127\.0\.[01]\.1[ \t]).*/\1$(hostname).$WINDOMAIN localhost $(hostname)/" /etc/hosts

    3. We should also tell the forthcoming installed services where they can find there leader: some networks will have netbios name lookup services, but just in case, add an explicit entry in your /etc/hosts file, in my configuration I added the entry on the third (3) line:
      # sudo sed -ri "3 i $WINDNS_IP $WINDNS" /etc/hosts

    4. The authentication and file sharing processes for the Windows and Linux boxes need to have their clocks agree. Do this with an NTP service, and on the server version of Ubuntu the NTP service comes installed and configured with one (1) NTP sever. Add yours before the Ubuntu one (or replace it entirely). The network I was joining had the DNS server serving up the NTP service too.
      # sudo sed -ri "s/^(server[ \t]+)(.+)/\1$WINDNS\n\1\2/" /etc/ntp.conf
      Restart the NTP daemon:
      # sudo /etc/init.d/ntp restart

  6. Kerberos configuration.
    The instructions that follow here aren't to be taken literally: the values for MYDOMAIN.LOCAL and srv1.mydomain.local need to be replaced with what's appropriate for your network when you edit the files, but do note that where UPPERCASE is used UPPERCASE is needed.
    If, during the apt-get install of Kerberos you had the insight to respond to the "default domain" question correctly, then, goody for you, otherwise you'll have to do the following.

    1. Edit the (previously installed above) /etc/krb5.conf file.

      1. Find the [libdefaults] section and change the key value pair:

        [libdefaults]
        default_realm = MYDOMAIN.LOCAL

      2. Add the following to the [realms] section of the file:

        MYDOMAIN.LOCAL = {
        kdc = srv1.mydomain.local
        admin_server = srv1.mydomain.local
        default_domain = MYDOMAIN.LOCAL
        }

      3. Add the following to the [domain_realm] section of the file:
        .mydomain.local = MYDOMAIN.LOCAL
        mydomain.local = MYDOMAIN.LOCAL

      4. A nice test at this point is to see if your AD controller will issue you a kerberos ticket. This isn't necessary but it can make some of you giddy:
        # kinit <some_windows_domain_user>
        Then to see the ticket:
        # klist
        You'll see stuff about the ticket cache and expiries and renewals. Once the giddiness subsides, you may as well release/destroy the ticket:
        # kdestroy

  7. Configure samba.
    According to the following: There are times when CIFS can not be used or another network filesystem choice is better. If kerberos (krb5/SPNEGO) authentication support is needed for added security, then Samba's smbclient or smbfs must be used instead of cifs
    Alas, cifs support in the kernel for ubuntu 10.04 (based on kernel version 2.6.32.9) is at version 1.61, and according to the kernel documentation, experimental kerberos implementation has been there since version 1.54.
    So there you are. I've no idea if cifs would work so I give you the samba configuration:

    1. Replace /etc/samba/smb.conf (remember I was working from a clean distro of Ubuntu, so I wasn't worried about breaking anything):
      [global]
      security = ads
      realm = MYDOMAIN.LOCAL
      password server = 192.168.20.11
      workgroup = MYDOMAIN
      idmap uid = 10000-20000
      idmap gid = 10000-20000
      winbind enum users = yes
      winbind enum groups = yes
      template homedir = /home/%U
      template shell = /bin/bash
      client use spnego = yes
      client ntlmv2 auth = yes
      encrypt passwords = yes
      winbind use default domain = yes
      restrict anonymous = 2

    2. Start and stop various services.

      # sudo /etc/init.d/winbind stop
      # sudo service smbd restart
      # sudo /etc/init.d/winbind start

  8. Setup the authentication.

    1. Edit the /etc/nsswitch.conf. I was able to run the following command to get what I needed:
      # sed -ri 's/(compat)/\1 winbind/' /etc/nsswitch.conf
      Here are the contents of my /etc/nsswitch.conf file:
      passwd: compat winbind
      group: compat winbind
      shadow: compat winbind
      hosts: files dns
      networks: files
      protocols: db files
      services: db files
      ethers: db files
      rpc: db files

    2. Start and stop various services.
      # sudo /etc/init.d/winbind stop
      # sudo service smbd restart
      # sudo /etc/init.d/winbind start

  9. Join the computer to the domain. I'm not convinced this is necessary; particularly because of the security option in the smb.conf file (security = ads). Perhaps someone can weigh in on this ...
    # sudo net ads join -U any_domain_user_account
    You might get an error DNS update failed!, but that you'll be joined to the domain. If you get an error about not being able to find the server, your DNS records need to be modified. During th Ubuntu installation, the nameserver will often point to your gateway: most routers will do a DNS service. Best practices for windows server administration is the ADC should run DNS as well. In my case my /etc/resolve.conf looks like this:
    nameserver 192.168.20.11
    nameserver 8.8.8.8
    The 8.8.8.8 is a google DNS, a fairly reliable backup in case the windows one goes down.

At this point I could login (perhaps after a reboot), home directories didn't exist, but I could login.

  1. CIFS Mounting on Login
    This next step was the cherry for me; I didn't want the responsibility of backing up everyone's working directories, and the box Ubuntu was to be running was suspect in terms of reliability. By doing the following users could login and see their windows user directory automagically.

    1. Download the pam_mount module:
      # sudo apt-get install libpam-mount
      I wanted the mount point to point be in the traditional /home/<user> location: this part is configured by the /etc/samba/smb.conf file (template homedir = /home/%U). But I needed it to drill through the share and point to their own windows directory. This is accomplished by editting the /etc/security/pam_mount.conf.xml file (which despite it's intention, XML isn't human readable):

    2. Add the following to /etc/security/pam_mount.conf.xml and alter to suit:
      <volume
      user="*"
      server="srv1.mydomain.local"
      path="UserShares"
      mountpoint="home"
      fstype="cifs"
      />

      <cifsmount>mount -t cifs //%(SERVER)/%(VOLUME)/%(USER) %(MNTPT)/%(USER) -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)"</cifsmount>

      Because of my goofy mount point I had to add this line too:

      <umount>umount %(MNTPT)/%(USER)</umount>

      And so that the user directories (for the mount point) would be created automatically find the line and make it so:

      <mkmountpoint enable="1" remove="false" />

      The remove="false" bit is quite important: if it's set to true, pam_mount.so tries to delete the directory mount point which it can't do if a user has logged in multiple times. What you end up with in that case is lots of stray mounts on your system.

      pam_mount.so still doesn't quite deliver as promised. In it's current form the mounts keep piling up and the home directories aren't being created. Somewhere between here and the previous Beta 2 release of 10.04 server, it was working. I can't recreate this though.
      In the mean time for the directory creation I'm relying on pam_mkhomedir.so, and stuck a line immediately before the pam_mount.so line to accommodate.
      I still haven't solved the multiple mounting issue. But until pam_mount.so is fixed, this is what I've got in my /etc/pam.d/common-session file:

      session [default=1]     pam_permit.so  
      session requisite       pam_deny.so  
      session required        pam_permit.so  
      session required        pam_unix.so  
      session optional        pam_winbind.so  
      session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022  
      session optional        pam_mount.so
      

Thats it. It worked for me, and I hope you find it useful.

Numerous resources were considered so I could figure this out. Here is a short list (a number of these links point to mine own questions on the topic):

share|improve this answer
1  
Turning off remote root ssh login is a must. Brute force/dictionary attacks sometimes succeed. If root is compromised, say goodbye to anything you trusted on the machine. –  JR Lawhorne May 21 '10 at 3:26
1  
ubuntu doesn't activate the root account though ... everything is sudo d, or am I missing something? –  Jamie May 21 '10 at 19:02
    
'everything is sudo' -- And this is better... in which way? (If any user account who is entitled to sudo is compromised, it's basically the same thing. And it's basically equally simple [or not] to bruteforce root or user accounts. Best is to setup pub-key only login, and disable all password-based logins.) –  Kurt Pfeifle Aug 6 '10 at 21:02
    
I get that, but consider: "Best is to setup pub-key only login", which would entirely defeat the purpose of this post. –  Jamie Aug 7 '10 at 0:29
    
Wow talk about paranoid not only would this genius have to brute first your password but they would also have to figure out your username, no way to brute force that if you have good usernames –  agilenoob Apr 22 '11 at 5:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.