Scope of this Document
The task is to maintain user data for Windows and Linuxin a single place , i.e. on the Windows ActiveDirectory domain controller, and use it to login to Windows and UNIX.
I tried the hard way of integrating a Linux machine into a Windows Domain by configuring LDAP and Kerberos manually, which means touching a lot of configuration files. My experience is that Samba can save you a lot of headaches with this task.
Environment, Task
In the the lab I had:
- A Windows 2003R2 Domain Controller:
W2k3DC.lab.demo, - An openSUSE 10.3 Linux running on VMware ESX:
SuseTux.lab.demo
Preparation
Be sure that DNS forward and reverse resolution works and that your
demo-lab DNS domain is properly delegated from the next higher level
domain. Even though some services accept IP-addresses instead of
fully qualified domain names, it usually makes your life easier.
There are enough other steps, which can fail. In openSUSE the
commands to configure this are yast2 dns and
yast2 lan.
Make sure the clock of the Linux system is in sync
with the domain controller. You can use the DC as an NTP server.
The openSUSE command is yast2 ntp-client. If you
hate menu driven configuration, you can use
yast2 ntp-client add server=W2k3DC.lab.demo
yast2 ntp-client enable
yast2 ntp-client status
Make sure the installation source is set up correctly
(yast2 inst_source), because you may have to add
some packages.
It's a good idea to have the home directories mounted from a central NFS server rather than having them locally on each individual Linux machine, since you can access the same files, no matter which machine you log in. However you should not be logged in simultaneously with a graphical login on two different machines with the same user account, since access to some configuration files may conflict. For this reason, you should disable auto-login on all machines, which use this central home directory.
Windows
Even though ActiveDirectory features an LDAP server, it uses different attributes than the the Linux machine expects. A schema extension is necessary to add home directory, logon shell (bash, csh, ksh, ...), numeric UNIX user ID (UID) and numeric UNIX group ID (GID). Before Windows Server 2003R2 this extension was contained in "Services for UNIX (SFU)". With R2 the schema and the name changed to "Identity Management for UNIX". That's what I recommend and what I use in the rest of this document.
To Go to "Manage Your Server | Add or remove a role | Add or Remove Programs | Windows Components | Active Directory Services | Identity Management for UNIX". Then add the UID to the affected users and the GID to the affected group. I gave "Domain Users" the GID 100 which openSUSE uses as the default GID for "users".
Linux
Simply do a yast2 samba-client
Membership = "LAB" instead of "WORKGROUP"
Check "Also Use SMB Information for Linux Authentication"
and "Single Sign-On for SSH"
When you press "F10" for "finish", the system
checks your domain membership and may ask you for the Administrator
password to join the domain. Then you have to make a few adjustments
to /etc/samba/smb.conf;
idmap gid = 10000-20000
idmap uid = 10000-20000
Adjust these ranges, so that the IDs in your AD fall into that range
and that the IDs defined in your local /etc/passwd are
outside (usually below) that range.
template homedir = /home/%D/%U
template shell = /bin/bash
template primary group = "Domain Users"
You don't need these lines, because the values come from AD
netbios name = SuseTux
password server = W2k3DC.lab.demo
winbind use default domain = yes
passdb backend = tdbsam
idmap backend = ad
idmap uid = 100-20000000
idmap gid = 100-20000000
winbind nss info = rfc2307
Add these lines! Especially the last line tells Samba that you use "Identity Management for UNIX".
Restart winbind (/etc/init.d/winbind restart) or reboot
the machine. I found out that you may have to clear the cache:
/etc/init.d/winbind stop for f in /var/lib/samba/*.tdb; do tdbtool $f erase; done /etc/init.d/winbind start
Now test getent passwd LoginName and make sure that
this does not come from the local passwd file (grep LoginName /etc/passwd).
Do a ls -l /home and check if the owners of the home directories
are displayed with the correct user and group name and not just with the
numeric UID and GID. Finally try to login with your Windows Username and
password. You can also list all domain users by wbinfo -u.