Active Directory Authentication in Ubuntu 8.04

Uncategorized

Goals:

1. Make an Ubuntu 8.04 server a member server of an Active Directory domain. [Note: In 8.10 and newer, this is greatly simplified by using Likewise-Open. I’ll provide a post on that in the future.]

2. Grant console login rights to only a single AD group and sudo rights to the same (or a separate) AD group.

3. Allow a local administrative account to log in at any time (like the Windows local administrator account can) whether the Active Directory domain controller is visible or not.

While there is a utility available for Ubuntu that will join Active Directory, it’s been hit or miss for me, so I decided to dig into the innards of Linux and flex my brain to come up with a more reliable means that accomplishes the specific goals of a more useful Active Directory integration.

Important:

While you read this, keep in mind that letter case is relevant. There’s a reason some information is in all capital letters, yet not other information.

Also, keep in mind that this is a first draft of this particular post. No doubt there may be a few typos in here. Let me know if you run into bugs.

Domain Information:

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

(again, why not)

The Active Directory user group that will have login access to your Linux boxes:

linuxusers

The AD user group that will have sudo access once they’ve logged in:

linuxadmins

Make linuxadmins a member of linuxusers (after all, if they have administrative rights, they have login rights)

Pick or make three AD users. One will be a member of linuxadmins, one a member of linuxusers, and the third a member of neither.

The name of the server we are adding will be:

linux01

Process:

Do a basic installation of Ubuntu Server 8.04 and set an initial username of “sysadmin” (system admin) or “ladmin” (local admin) or whatever is appropriate. However, whatever you choose, it must not exist now, or ever, as a member in your Active Directory domain. This will be your local administrative username on all of your Ubuntu boxes. NOT ROOT! The root account on your Ubuntu boxes should never get a password and, thus, never be enabled for direct access. Although you can become root by elevating your local administrative user to root with:

sudo su –

or

sudo -s

Install openssh-server during base installation.

Once installed, do the first reboot then log in as your new administrative user account.

Become root with

sudo su –

Make sure you can ping your domain controller by IP:

ping 192.168.0.5

Also be sure that your DNS configuration on your Ubuntu box is configured to use the IP address of your primary domain controller’s DNS service. For Kerberos and Active Directory to work, everything needs to have the same DNS server.

A quick check would be to do a host lookup on your domain controller:

host dc01

Which should return something similar to…

dc01 has address 192.168.0.5

If you can’t look up DNS entries or ping your domain controller, get that cleared up before moving on.

We need to create a couple of authentication files on our Ubuntu box. Let’s make some backups:

for f in common-account common-auth common-session sudo
{
cp -p /etc/pam.d/${f} /etc/pam.d/${f}.bak
}

Now we’ll need to create new versions of each of those files:

cat < /root/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
EOF

cat < /root/common-auth
auth sufficient pam_winbind.so
auth required pam_unix.so nullok_secure use_first_pass
EOF

cat < /root/common-session
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
EOF

cat < /root/sudo
auth sufficient pam_winbind.so
auth sufficient pam_unix.so use_first_pass
auth required pam_deny.so
@include common-account
EOF

Make sure your system’s clock is synchronized with the clock on your domain controller (did you know — Active Directory servers have a standard NTP Server Service installed by default that all of its Windows clients automatically update against)

ntpdate 192.168.0.5

You may want to add an appropriate entry to root’s crontab to have it update the clock every few hours. I use this:

17 * * * * /usr/sbin/ntpdate 192.168.0.5 >> /var/log/ntpdate.log

Note that crontab needs the full path to the command because by default it has no environment variables. I send the output to a log file for later reference.

You could also install the NTP daemon on every Linux box that you have and let it automatically keep the system’s clock up to date. Both accomplish the same goal, except this one requires only one additional configuration line (in crontab) where ntpd requires a configuration file and some tweaking to make it work. I like the easier way.

Install the packages needed for domain authentication:

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

When those packages install, they’ll prompt you to provide the full domain name of your primary domain controller. If you have two or more, enter at least two of them, separated by spaces.

For example, assume we have dc01 and dc02, enter on the first prompt:

dc01.mydomain.net dc02.mydomain.net

At the second prompt, enter only the administrative server of the two — that is, your primary domain controller. We’ll enter:

dc01.mydomain.net

This will generate the needed kerberos config file.

Back at the prompt, attempt to connect to the domain controller with this:

kinit john@MYDOMAIN.NET

You’ll be prompted for that administrator’s password.

Check to see that a ticket was granted with:

klist

You should see a TGT granted for user “john” in “MYDOMAIN.NET”

Kerberos is configured.

Now we need to set up authentication. For that, we use Winbind and Samba.

apt-get -y install winbind samba

Back up the existing Samba configuration file:

cp -p /etc/samba/smb.conf /etc/samba/smb.conf.bak

Then create a new Samba config:

cat < /etc/samba/smb.conf
[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
printcap name = /dev/null
load printers = no
EOF

Now, we restart Winbind and Samba in the right order to enable user authentication:

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

And try to join this server to the domain:

net ads join -U john@MYDOMAIN.NET

After a moment, you should see a message that the server linux01 was joined to the domain MYDOMAIN.NET. Success!

But we’re not done yet.

Reboot.

Log in as the local administrative user.

Become root again (sudo su -)

Log in to kerberos again:

kinit john@MYDOMAIN.NET

Make sure a TGT was issued

klist

Can we see domain info on users and groups with winbind?

wbinfo -u
wbinfo -g

Almost there…

Back up the existing NSSwitch file:

cp -p /etc/nsswitch.conf /etc/nsswitch.conf.bak

And build a new one with this:

cat < /etc/nsswitch.conf
passwd: compat winbind
group: compat winbind
shadow: compat
hosts: files dns
EOF

(Note: In Ubuntu “compat” is synonymous with “files”)

Enumerate all domain users:

getent passwd

And groups

getent group

To the end of /etc/sudoers, add this:

%linuxadmins ALL=(ALL) ALL

You’re done! Reboot so we can test all of the changes to make sure it works.

Proving:

1. Log in as the AD user who is a member of neither linuxusers nor linuxadmins. It should fail.

2. Log in as the AD user who is a member of linuxusers, but not linuxadmins. The login should succeed.

3. As the linuxusers member, attempt to sudo a command (sudo ls /root). Provide that user’s domain password. The command should fail.

4. Log out.

5. Log in as the AD user who is a member of linuxadmins. The login should succeed.

6. As the linuxadmins member, attempt to sudo a command (sudo ls /root) and provide that user’s domain password. The command should succeed.

7. Log out.

8. And, finally, log in as your local administrative user. The login should succeed.

Now, there’s no excuse not to use the free Ubuntu Server as member servers in your Active Directory environments.

I don’t know what the next Long Term Support version of Ubuntu (likely 10.4) will bring as far as Active Directory integration. If it’s anything like 8.04, then the update will be pretty easy. I can say, though, that we’ll be upgrading all of our machines to the next LTS version as quickly as possible after it’s released, so I’ll try to keep this page updated with relevant information.

Please let me know if this information was useful, helpful, or otherwise had any positive or negative impact on your Ubuntu deployments.