Ubuntu Wiki

This Howto describes how to add a Ubuntu box in a Active Directory domain and to authenticate the users with AD.

Used software

Used terms

Confirm Connectivity

The first step to configuring an Ubuntu client for participation in an Active Directory (AD) network is to confirm network connectivity and name resolution for the Active Directory domain controller. An easy way to verify both of these is to ping the fully-qualified domain name (FQDN) of the AD DC on your network.

root@linuxwork:~# ping win2k3.lab.example.com

PING win2k3.lab.example.com (10.0.0.1) 56(84) bytes of data.
64 bytes from win2k3.lab.example.com (10.0.0.1): icmp_seq=1 ttl=128 time=0.176ms

The output of the ping response shows successful resolution of the FQDN to an IP Address, and the confirmation of connectivity between your Ubuntu workstation and the AD DC.

Time settings

Time is essential for Kerberos, which is used for authentication in Active Directory networks. The easiest way to ensure correct time syncronization is to use a NTP-Server. Every Active Directory Domain Controller is also an NTP server, so for best results, use the FQDN of an AD DC in Ubuntu's default ntpdate application, which syncs time at startup or on demand.

file: /etc/default/ntpdate

# servers to check
NTPSERVERS="win2k3.lab.example.com"
# additional options for ntpdate
NTPOPTIONS="-u"

root@linuxwork:~# /etc/init.d/ntpdate restart

* Synchronizing clock to win2k3.lab.example.com...    [ ok ]

FQDN

A valid FQDN is essential for Kerberos and Active Directory. Active Directory is heavily dependent upon DNS, and it is likely that your Active Directory Domain Controllers are also running the Microsoft DNS server package. Here, we will edit the local hosts file on your Ubuntu workstation to make sure that your FQDN is resolvable.

file: /etc/hosts

127.0.0.1 linuxwork.lab.example.com localhost linuxwork

You can test your configurating by PINGING your own FQDN. The output should be similar to the PING output above, from the Network Connectivity test (of course, the FQDN will be your own, and the IP address will be 127.0.0.1).

Set up Kerberos

The first step in setting up Kerberos is to install the appropriate client software. This process assumes that you have opened up all the Breezy main and security sources in your sources.list as well as the Universe repository.

Required software

To properly install the necessary Kerberos packages, you should use the following apt-get command to install the software:

root@linuxwork:~# apt-get install krb5-user libpam-krb5

attachment:IconsPage/IconNote.png For krb5-user you will need the universe repository.

attachment:IconsPage/IconNote.png The Kerberos config package (/etc/krb5.conf) is not necessary, if the DNS service records are correct configured for Kerberos. If you do not intend to acquire a Kerberos ticket at login, you need not install the libpam-krb5 package.

This command will also fetch the additional packages krb5-config, libkrb53, and libkadm55.

The krb5-config installation will present a prompt:

What are the Kerberos servers for your realm?
win2k3.lab.example.com

What is the administrative server for your Kerberos realm?
win2k3.lab.example.com

These prompts should be answered according to the Active Directory Domain Controller in charge of your domain. The krb5-config process customize the /etc/krb5.conf file for your installation.

file: /etc/krb5.conf

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

[libdefaults]
    ticket_lifetime = 24000
    clock_skew = 300
    default_realm = LAB.EXAMPLE.COM
#   dns_lookup_realm = false
#   dns_lookup_kdc = true

[realms]
    LAB.EXAMPLE.COM = {
        kdc = win2k3.lab.example.com:88
        admin_server = win2k3.lab.example.com:464
        default_domain = LAB.EXAMPLE.COM
}

[domain_realm]
    .lab.example.com = LAB.EXAMPLE.COM
    lab.example.com = LAB.EXAMPLE.COM

Testing

Request a TGT (doesn't have to be Administrator, any valid domain account can be used).

root@linuxwork:~# kinit Administrator@LAB.EXAMPLE.COM
Password for Administrator@LAB.EXAMPLE.COM: ****

Check if ticket request was valid.

root@linuxwork:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@LAB.EXAMPLE.COM

Valid starting     Expires            Service principal
01/21/05 10:28:51  01/21/05 20:27:43    krbtgt/LAB.EXAMPLE.COM@LAB.EXAMPLE.COM
        renew until 01/21/05 20:28:51

Join AD domain

Required software

attachment:IconsPage/IconNote.png For Windows 2003 Server SP1 Winbind version 3.0.14a is necessary. In Hoary is only version 3.0.10, but you can find 3.0.14a in Breezy.

root@linuxwork:~# apt-get install winbind samba smbfs

attachment:IconsPage/IconNote.png The package smbfs is optional, but includes useful client utilities, including the smbmount command. Also useful is the smbclient package, which includes an FTP-like client for SMB shares.

Join

file:  /etc/samba/smb.conf 

[global]
        security = ads
        realm = LAB.EXAMPLE.COM
        password server = 10.0.0.1
        workgroup = LAB
        winbind separator = +
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        winbind enum users = yes
        winbind enum groups = yes
        template homedir = /home/%D/%U
        template shell = /bin/bash
        client use spnego = yes
        encrypt passwords = yes
        winbind use default domain = yes

attachment:IconsPage/IconNote.png The "winbind use default domain" parameter is useful in single-domain enterprises and makes winbind assume that all user authentications should be performed in the domain to which winbind is joined. Omit this parameter if your environment includes multiple domains or if your account domain differs from the resource domain.

Request a valid Kerberos TGT for an account, which is allowed to join a workstation into the AD domain.

root@linuxwork:~# net ads join
Using short domain name – LAB
Joined 'linuxwork' to realm 'LAB.EXAMPLE.COM'

attachment:IconsPage/IconNote.png If the Kerberos auth was valid, you should not get asked for a password. However, if you are not working as root and are instead using sudo to perform the necessary tasks, use the command sudo net ads join -U username and supply your password when prompted. Otherwise, you will be asked to authenticate as root@LAB.EXAMPLE.COM instead of a valid account name.

Testing

# wbinfo -u

You should get a list of the users of the domain.

And a list of the groups.

# wbinfo -g

Setup Authentication

nsswitch

file: /etc/nsswitch.conf

passwd:         compat winbind
group:          compat winbind
shadow:         compat

Testing

Check Winbind nsswitch module with getent.

root@linuxwork:~# getent passwd

root:x:0:0:root:/root:/bin/bash
...
LAB+administrator:x:10000:10000:Administrator:/home/LAB/administrator:/bin/bash
LAB+gast:x:10001:10001:Gast:/home/LAB/gast:/bin/bash
...

root@linuxwork:~# getent group

root:x:0:
daemon:x:1:
bin:x:2:
...
LAB+organisations-admins:x:10005:administrator
LAB+domänen-admins:x:10006:manuel,administrator
LAB+domänen-benutzer:x:10000:
LAB+domänen-gäste:x:10001:
LAB+linux-admins:x:10004:manuel
...

PAM

With this config you can access the workstation with local accounts or with domain accounts. On the first login of a domain user a home directory will be created. This PAM configuration assumes that the system will be used primarily with domain accounts. If the opposite is true (i.e., the system will be used primarily with local accounts), the order of pam_winbind.so and pam_unix.so should be reversed. When used with local accounts, the configuration shown here will result in a failed authentication to the Windows/Samba DC for each login and sudo use. This can litter the DC's event log. Likewise, if local accounts are checked first, the /var/log/auth.log will be littered with failed logon attempts each time a domain account is accessed.

This PAM configuration does not acquire a Kerberos TGT at login. To acquire a ticket, use kinit after logging in, and consider using kdestroy in a logout script.

file: /etc/pam.d/common-account

account sufficient       pam_winbind.so
account required         pam_unix.so

file: /etc/pam.d/common-auth

auth sufficient pam_winbind.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required   pam_deny.so

file: /etc/pam.d/common-session

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

file: /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

Final configuration

Each domain needs a directory in /home/.

root@linuxwork:~# mkdir /home/LAB

Usage

Logon with DOMAIN+USERNAME, unless you included "winbind use default domain" in your smb.conf, in which case you may log in using only USERNAME.

login: LAB+manuel
Password: *****
...
LAB+manuel@linuxwork:~$

Troubleshooting

If the Winbind PAM module in /var/log/auth.log says, that the AD-user is not existing, restart winbind. Probably it's best to restart the whole workstation.

root@linuxwork:~# /etc/init.d/winbind start

External Docs

Also see [http://wiki.randompage.org/index.php/Using_Samba_on_Debian_Linux_to_authenticate_against_Active_Directory Using Samba on Debian Linux to authenticate against Active Directory] on randompage.org. It largely mirrors this page but has a little more detail.

CategoryDocumentation