Let’s say you have a Window Active Directory domain configured with any number of Windows servers and workstations, but you want to add your Ubuntu 7.04 Linux servers to the domain. Let’s also say that you want only specific people (an AD security group, for example) to have shell access to the Ubuntu boxes. Let’s also assume that you want only a smaller subset of those users to have sudo access on the Linux servers…

Okay, I’m actually describing a dilemma that I had with an Ubuntu rollout into a purely Windows domain.

I’ll describe the steps needed to add your Linux servers to the domain, allow a group of users shell access, allow sudo access for a group, and still permit root logins on the local machine.

Let’s define some domain information — keep in mind that the letter case of the terms below is relevant and important:

• Workgroup Name: WORKGROUP

• Kerberos Realm: MYDOMAIN.NET

• FQDN of the MYDOMAIN.NET Primary Domain Controller: dc01.mydomain.net with an IP of 192.168.0.5

• A domain administrator on MYDOMAIN.NET: john (why not)

• The name of the server we are adding will be: linux01

• And its IP address will be: 192.168.0.10

• Obviously, our subnet will be: 255.255.255.0

• Our gateway is: 192.168.0.1

1. Now that the particulars are out of the way, go ahead and either do a basic build of Ubuntu Server 7.04 without DNS or LAMP services. You can add those later.

2. You’ll need to create an initial username and password on Ubuntu. For the sake of this howto, the username will be “Bob”. It doesn’t matter, really, as you’ll be deleting it once the installation is complete anyway.

3. The build will take about 10 minutes or so. In the meantime, open Active Directory Users and Computers for your domain and create:

• a linuxusers security group
• a linuxadmins security group (make it a member of linuxusers)
• a testuser1 account — and make it a member of linuxusers
• a testuser2 account — and make it a member of linuxadmins

4. Complete your Ubuntu build and reboot the machine when prompted.

5. Log in as Bob.

6. Become root:

sudo su -

7. Type Bob’s password when prompted by the sudo command.

8. Set a root password if you don’t already have one:

passwd

9. Once you have a root password, make sure your clock is up to date:

ntpdate 192.168.0.5

10. While we’re at it, let’s add a cron job to automatically update the clock once per day. You could use crontab -e or you can use this instead:

echo "45 8 * * * ntpdate 192.168.0.5" >> /var/spool/cron/crontabs/root

This will add 45 8 * * * ntpdate 192.168.0.5 to the end of root’s crontab file to update the clock at 8:45AM every day. It will take effect after a reboot, but don’t reboot yet.

11. Make a backup of /etc/hosts

cp /etc/hosts /etc/hosts.bak

12. Then edit /etc/hosts and make sure you have only these two lines

127.0.0.1  localhost
192.168.0.10  linux01  linux01.mydomain.net

Note: I don’t have any IPV6 switches in any of my production level environments, so I don’t use it — can’t help if you need it in yours.

13. Fetch a few needed programs:

apt-get -y install krb5-user libpam-krb5 krb5-config libkrb53 libkadm55

14. Once those programs are installed, you’ll need to change /etc/krb5.conf, but be sure to make a backup.

15. Now, edit /etc/krb5.conf, delete its contents, then replace with this:

[logging]
 default = FILE:/var/log/krb5.log

[libdefaults]
 ticket_lifetime = 24000
 clock_skew = 300
 default_realm = MYDOMAIN.NET

[realms]
 $kerbrealm = {
  kdc = dc01.mydomain.net:88
  admin_server = dc01.mydomain.net:464
  default_domain = MYDOMAIN.NET
 }

[domain_realm]
 .mydomain.net = MYDOMAIN.NET
 mydomain.net = MYDOMAIN.NET

[login]
 krb4_convert = true
 krb4_get_tickets = false

16. Get a ticket-granting ticket from your domain controller:

kinit john@MYDOMAIN.NET

You’ll be prompted for John’s password for mydomain.net.

17. Now that you have a ticket, you can install winbind and samba:

apt-get -y install winbind samba

18. Make a backup of /etc/samba/smb.conf then edit the file, delete its contents, then add:

[global]
 security = ads
 realm = MYDOMAIN.NET
 password server = 192.168.0.5
 workgroup = WORKGROUP
 idmap uid = 10000-200000
 idmap gid = 10000-200000
 winbind enum users = yes
 winbind enum groups = yes
 template homedir = /home/%D/%U
 template shell = /bin/bash
 client use spnego = yes
 client ntlmv2 auth = yes
 encrypt passwords = yes
 winbind use default domain = yes
 restrict anonymous = 2
 domain master = no
 local master = no
 preferred master = no
 os level = 0

You may be able to spot some of the obvious settings in here, but we’re also setting the UID and GID numbers that Linux should assign to our AD users when they authenticate, the home directory and default shell of new AD users, and whether Samba should ever assert itself (rather, not) as the domain master browser whenever a Samba election takes place. Normally, your domain controller has that role.

19. Restart Winbind and Samba in the right order:

/etc/init.d/winbind stop
/etc/init.d/samba restart
/etc/init.d/winbind start

20. Reboot — we made changes to authentication and need to reboot for the next steps:

init 6

21. Once the machine restarts, log in as root. You did set a root password, yes?

22. Get another ticket-granting ticket from your domain controller:

kinit john@MYDOMAIN.NET

23. Type John’s password when prompted.

24. Attempt to join the domain:

net ads join

25. You should see a confirmation that the machine was successfully joined. If you get a failure, be sure to check: network, /etc/hosts for the right IP address and name of the new server, that your clock and time zone settings are accurate and up to date.

26. For grins, check your domain controller to see if linux01 was added to the Computers OU.

27. Reboot. Yes, just joining the domain requires a reboot:

init 6

28. Once rebooted, log back in as root then get another ticket-granting ticket:

kinit john@MYDOMAIN.NET

Of course, type John’s password when prompted.

29. Now we need to attempt to enumerate all users and groups from our AD server:

wbinfo -u

The wbinfo command may take a few seconds or several minutes to run — it’s going to dump every username from Active Directory to stdout. Be patient.

30. If it worked, repeat the process for groups:

wbinfo -g

31. Backup then replace /etc/nsswitch.conf with the following:

passwd:         compat winbind
group:          compat winbind
shadow:         compat

32. Attempt to get users’ authentication information from AD:

getent passwd

33. Then repeat for groups:

getent group

34. Backup and replace these files with the text shown:

/etc/pam.d/common-account

account [default=1 success=ignore] pam_succeed_if.so quiet uid >= 10000
account required pam_succeed_if.so debug user ingroup linuxusers
account sufficient pam_winbind.so
account required pam_unix.so

/etc/pam.d/common-auth

auth sufficient pam_winbind.so krb5_auth krb5_ccache_type=FILE
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required pam_deny.so

/etc/pam.d/common-session

session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel

/etc/pam.d/sudo

auth sufficient pam_winbind.so
auth sufficient pam_unix.so use_first_pass
auth required pam_deny.so
@include common-account

35. Note that the /etc/pam.d/common-account file is where we define which AD group can have login rights. In this case, it’s linuxusers.

36. To define who has sudo or administrative rights on this machine, we have to edit /etc/sudoers — best to do that with the visudo command — then add this line to the end of it:

%linuxadmins ALL=(ALL) ALL

37. Reboot the machine one more time. When it comes back up, attempt to log in with testuser1, which you created early on in the process. You should be able to log in. Once logged in, attempt to sudo a command. For example, type

sudo ifconfig

then provide testuser1’s domain password then the command should fail (as expected). This is because that user is a member of the linuxusers AD security group and only members of the linuxadmins AD security group would have sudo access.

38. Log out of the testuser1 account then log in as testuser2 with his domain password. Now, try the same sudo command as testuser2:

sudo ifconfig

Once you give it testuser2’s domain password, you should see the results of the ifconfig command.

39. Remember the user, Bob, that you created during the installation? As testuser2, try to delete Bob’s account and home directory:

sudo userdel bob

40. If you already authenticated to run the ifconfig command, you won’t be prompted for your password again. Otherwise, provide it, and the user Bob should be deleted. Don’t forget to delete Bob’s home directory, too:

rm -rf /home/bob

Congratulations, your domain authentication on Ubuntu 7.04 is complete. There may, in fact, be a much, much easier way to do this — probably just a one-line command for all I know — but I have no idea what it would be.