UbuntuHelp:ActiveDirectoryWinbindHowto
来自Ubuntu中文
This Howto describes how to add a Ubuntu box in a Active Directory domain and to authenticate the users with AD.
目录
Used software
<rowbgcolor="#E5E5E5">Name | Version |
MS Windows Server | 2003 standard sp1 |
Linux | Ubuntu Breezy 5.10 |
Winbind | 3.0.14a-Ubuntu |
Samba | 3.0.14a-Ubuntu |
krb5-user | 1.3.6-1 |
libpam-krb5 | 1.0-12 |
Used terms
<rowbgcolor="#E5E5E5">term | definition |
AD | Active Directory |
DC | Domain Controller |
lab.example.com | AD domain |
win2k3.lab.example.com | DC FQDN |
10.0.0.1 | DC IP |
LAB.EXAMPLE.COM | Kerberos Realm |
linuxwork | computername of the Ubuntu workstation |
linuxwork.lab.example.com | FQDN of the Ubuntu workstation |
ntp.example.com | timeserver (NTP) |
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
For krb5-user you will need the universe repository.
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. In most cases, this config file will work successfully, but if you want a more streamlined config file (e.g., without all the Kerberos 4 cruft), you can use the following as a template:
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
Notice the two "DNS" directive are commented out. You can elect to use DNS to find Kerberos realm servers, or you can elect to use the krb5.conf
file to define Kerberos realm servers. If you elect to use DNS, uncomment the two lines above and instead comment or remove the entire directive for your realm under the [realms]
heading.
Testing
Request a Ticket-Granting Ticket (TGT) by issuing the kinit
command, as shown (you can use any valid domain account; it doesn't have to be Administrator. You can also omit the domain name from the command if the "default_realm" directive is properly applied in the /etc/krb5.conf
file.
root@linuxwork:~# kinit [email protected] Password for [email protected]: ****
Check if ticket request was valid using the klist
command.
root@linuxwork:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: [email protected] Valid starting Expires Service principal 01/21/05 10:28:51 01/21/05 20:27:43 krbtgt/[email protected] renew until 01/21/05 20:28:51
At this point, your Kerberos installation and configuration is operating correctly. You can release your test ticket by issuing the kdestroy
command.
Join AD domain
Required software
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 smbclient]
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 client ntlmv2 auth = yes encrypt passwords = yes winbind use default domain = yes restrict anonymous = 2 # to avoid the workstation from # trying to become a master browser # on your windows network add the # following lines domain master = no local master = no preferred master = no os level = 0
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. The "winbind separator" directive is optional, and the default value is the usual backslash "\" Domain and User separator. You can use "+" if you know of a specific reason "\" will not work in your environment.
Be sure to restart the Samba and Winbind services after changing the /etc/samba/smb.conf
file:
root@linuxwork:~# /etc/init.d/winbind stop root@linuxwork:~# /etc/init.d/samba restart root@linuxwork:~# /etc/init.d/winbind start
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'
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 [email protected] 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 Using Samba on Debian Linux to authenticate against Active Directory on randompage.org. It largely mirrors this page but has a little more detail.