Lately I’ve been building lab environments using Linux virtual machines. I start by installing a model system to use as my source. In this case I’m using a custom install of Ubuntu Server 11.04.  The usual process is to copy the vm file to create the clones then make basic network adjustments such as changing the host name, IP address and MAC address.  Some vm environments will detect that you’re operating from a copy and dynamically assign a new MAC address for you.  If not, you’ll need to generate a new address in the NIC properties.

One obstacle you’re likely to encounter is that your networking fails to work after changing the MAC address.  The likely cause is that your system detected this new address and assumed it to be a new ethernet connection but your IP settings are still assigned to your original ethernet interface, probably eth0.

The solution is to make your original network configuration aware of your new MAC address.

Locate the udev rules file for network devices:

/etc/udev/rules.d/70-persistent-net.rules

This rules file should contain a single entry for every ethernet interface in your system.  My original vm just had eth0, but after booting my clone, the new MAC address of 00:1c:42:ab:fe:96 was detected and added as eth1.

# PCI device 0x8086:0x100f (e1000)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:1c:42:de:60:fb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth0"
 
 # PCI device 0x8086:0x100f (e1000)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:1c:42:ab:fe:96", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth1"

Since the original ssytem was setup with eth0, ifconfig doesn’t know about eth1 so it simply needs to be removed and the new MAC address needs to be assigned to eth0.  Edit 70-persistent-net.rules and remove the first entry containing the original MAC address and change the second entry to eth0.

# PCI device 0x8086:0x100f (e1000)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:1c:42:ab:fe:96", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth0"

So, there you have it.  Reboot the system to affect the change.

There are a couple different ways to integrate Linux systems to Active Directory to achieve centralized password security. The simple and secure way is to use Winbind, but If you’re the rebellious type or your environment requires it, you can use LDAP instead. Read on for instructions in using this method.

Environment

In this setup we will be binding to the LDAP services that’s included with Active Directory. This configuration assumes the use of Red Hat based Linux systems, including Fedora and CentOS and the server components are running on Windows 2003 based Active Directory. It should also work on Windows 2008 if the domain functional level of is set for compatibility with Windows 2003.

We’ll use a domain named example.local with a controller named DC1 that we will authenticate to. It’s IP address is 10.7.0.3.

We have setup a user account in AD called ldapuser in an OU called Users that is used to authenticate the LDAP service. This user account has it’s password set to ldappassword

Step 1 – Prepare your Linux Systems

Verify that LDAP and the proper authentication modules are installed on the system. I used rpm but you could use yum instead if you wish.

Query your installed packages with a search for ldap:

rpm -qa | grep ldap

You should see the following packages listed with versions equal or greater to those listed:

openldap-clients-2.3.43-3.el5
openldap-2.3.43-3.el5

If they’re not installed, locate the appropriate .rpm files and install using rpm -i, for example:

rpm -i openldap-clients-2.3.43-3.el5.rpm
rpm -i openldap-2.3.43-3.el5.rpm

Then check for the PAM authentication modules:

rpm -qa | grep pam

Ensure that you have the following packages:

pamccreds-3-5
pamsmb-1.1.7-7.2.1
pamkrb5-2.2.14-1.el52.1
pampasswdqc-1.0.2-1.2.2
pampkcs11-0.5.3-23 pam-0.99.6.2-3.27.el5


If necessary, download and install these packages as well.

Step 2 – Configure LDAP and PAM

Change the following configuration files to match the examples given. Don’t forget to make backups of your original files in case you need to revert your changes.

/etc/openldap/ldap.conf

host 10.7.0.3
base dc=local,dc=example
binddn cn=ldapuser,cn=Users,dc=local,dc=example
bindpw ldappassword
scope sub
ssl no
nssbasepasswd dc=proteus,dc=local
nssbaseshadow dc=proteus,dc=local
nssbasegroup dc=proteus,dc=local
nssmapobjectclass posixAccount user
nssmapobjectclass shadowAccount user
nssmapobjectclass posixGroup group
nssmapattribute uid sAMAccountName
nssmapattribute uidNumber msSFU30UidNumber
nssmapattribute gidNumber msSFU30GidNumber
nssmapattribute loginShell msSFU30LoginShell
nssmapattribute gecos name
nssmapattribute userPassword msSFU30Password
nssmapattribute homeDirectory msSFU30HomeDirectory
nssmapattribute uniqueMember msSFU30PosixMember
nssmapattribute cn cn
pamloginattribute sAMAccountName
pamfilter objectclass=User
pampassword ad

/etc/nsswitch.conf

passwd: files ldap
shadow: files ldap
group: files ldap


/etc/pam.d/

auth required /lib/security/$ISA/pamenv.so
auth sufficient /lib/security/$ISA/pamunix.so likeauth nullok
auth sufficient /lib/security/$ISA/pamldap.so usefirstpass
auth required /lib/security/$ISA/pamdeny.so
account required /lib/security/$ISA/pamunix.so brokenshadow
account sufficient /lib/security/$ISA/pamsucceedif.so uid < 100 quiet
account [default=bad success=ok userunknown=ignore] /lib/security/$ISA/pamldap.so
account required /lib/security/$ISA/pampermit.so
password requisite /lib/security/$ISA/pamcracklib.so retry=3
password sufficient /lib/security/$ISA/pamunix.so nullok useauthtok md5 shadow
password sufficient /lib/security/$ISA/pamldap.so useauthtok
password required /lib/security/$ISA/pamdeny.so
session required /lib/security/$ISA/pammkhomedir.so skel=/etc/skel umask=0077
session required /lib/security/$ISA/pamlimits.so
session required /lib/security/$ISA/pamunix.so

Step 3 – Run a Test LDAP Query

To verify your progress so far you can run a query against Active Directory using the ldapsearch command. The following statement should login as user pcornell.

ldapsearch -x -h 10.7.0.3 -D "cn=ldapuser,cn=Users,dc=local,dc=example" -b dc=local,dc=example -W '(sAMAccountName=pcornell)'

If your query works you’ve successfully authenticated to AD! You should be able to login to the Linux shell using an AD account, for example:

ssh pcornell@linuxserver.local

Next, you can configure Samba for integrated security.

Step 4 – Setup Samba

This assumes that Samba is already installed. If not find the appropriate RPMs and install it.

Setup your Samba configuration file accordingly. Adjust the shares to match your needs:

/etc/samba/smb.conf

[global]
workgroup = example
server string = Samba Server
interfaces = 10.7.0.220/24
security = DOMAIN
passwd program = /usr/bin/passwd %u
username map = /etc/samba/smbusers
unix password sync = Yes
log file = /var/log/samba/%m.log
max log size = 250
socket options = TCPNODELAY SORCVBUF=8192 SO_SNDBUF=8192
preferred master = No
local master = No
ldap ssl = no
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
hosts allow = 192.168.1., 10.7., 127. , 10.8.
template shell = /bin/false
winbind use default domain = no

[homes]
comment = Home Directories
valid users = @domaingroup
read only = No
browseable = No

[fileshare]
path = /data/fileshare
valid users = @domaingroup
read only = No
force create mode = 0755
force directory mode = 0775

[public]
comment = Public Share
path = /data/public
read only = No

The changes made to smb.conf will take effect after restarting Samba:

service smb restart

Voila! Now users should be able to access the Samba share from a Windows client and authenticate using their Active Directory accounts. Go to a Windows box and test it out to make sure.