Setting CentOS / Redhat to use Active Directory for Authentication Only

I was recently faced with a situation where I was establishing a lone Linux server in a Windows native environment.  A small set of users would be using this server infrequently but we wanted to make sign on convenient and traceable. What we did is set the server to pass authentication back to the domain controllers. The local user list is then edited with those domain user IDs we wish to have access to the system.

For this example lets assume the following:

Domain:  contoso.com 

Domain controllers: dc1, dc2,dc3

Time Server:  time.contoso.com

Test user account:  atest@contoso.com

Sync Time with the Domain:

Be sure the system clock is  syning with domain with the following crontab entry:

0 0 * * * rdate –s time.contoso.com

Kerberos Configuration:

Replace the contents of /etc/krb5.conf with the following (capitalization does matter):

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = CONTOSO.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes

[realms]
CONTOSO.COM = {
  default_domain = contoso.com
  kdc = DC1.CONTOSO.COM
  kdc = DC2.CONTOSO.COM
  kdc = DC3.CONTOSO.COM

  admin_server = DC1.CONTOSO.COM
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
   validate = false
 }

The last “validate=false” command ensures that TGT validation (which may not be supported at Contoso) is not used, it will cause authentication failure.

Test with kinit:

# kinit atest@CONTOSO.COM

# klist     (to see if a ticket was created)

Enable Kerberos:

Use the system-config-authentication GUI to enable Kerberos user authentication.

Click OK

Change system-auth:

Setup /etc/pam.d/system-auth to use Kerberos authentication first then unix authentication by setting up the auth section like this:

auth        required      pam_env.so
auth        sufficient      pam_krb5.so     nullok try_first_pass
auth        sufficient    pam_unix.so       nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

Fix local su access:

Setup /etc/pam.d/su to use pam_unix as the first choice so su to root doesn’t trigger a bad auth request against Kerberos

auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            sufficient      pam_unix.so try_first_pass
auth            include         system-auth
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

STOP HERE if you only want to ‘authenticate’ again AD. You can simply place the user in passwd (using useradd or other scripts) and they will have access. Using the conventional linux user management tools along with ‘Kerberos only’ authentication may allow you to customize the home directory and track group IDs easier than full AD integration using winbind.

Installing the Code::Blocks IDE on CentOS / Redhat

Install the following packages before starting:

zip
make
gettext
autoconf
automake
libtool
m4
intltool
gcc-c++
libstdc++-devel

In CentOS, you might do this with:

su -c 'yum groupinstall "Development Tools"'

su -c 'yum install intltool'

OR here is an alternate command you can copy/paste to get it done:

yum –ty install zip make gettext autoconf automake libtool m4 intltool gcc-c++ libstdc++-devel

Gather the installation files:

codeblocks-10.05-src.tar.bz2
wxWidgets-2.8.11.tar.gz

Extract and place folders in /usr/local/src

cd /usr/local/src
tar xvzf ~/wxWidgets-2.8.11.tar.gz
tar xvjf ~/codeblocks-10.05-src.tar.bz2

Install wxWidegets

cd /usr/local/src/wxWidgets-2.8.11/

./configure --prefix=/opt/wx/2.8
make
make install

Add the path to the system path

vi /etc/profile

before the export statement append to the end of the path so it looks like this:

PATH=$PATH:/opt/wx/2.8/bin
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC

Add the following line to /etc/ld.so.conf

/opt/wx/2.8/lib

Reload the profile configuration with the new path info

ldconfig
source /etc/profile

Install Code Blocks

cd /usr/local/src/codeblocks-10.05-release
./configure
make
make install

At this point a reboot would be good

Run codeblocks

In an x terminal session type the command to start code Blocks

codeblocks

Dealing with network connections on Linux VM templates in Lab Manager

So you have a VM template you are pulling into a configuration, and each time you do you frustratingly end up with eth1 instead of eth0 for your default interface.  Here is the solution and what is going on.

Start the VM as a template, configure it.  Then once you are done  be sure to run these commands as the last thing you do then shut the system down.

sudo rm –f /etc/udev/rules.d/70-persistent-net.rules
sudo rm –f /etc/sysconfig/network-scripts/ifcfg-eth*

You can now shutdown, undeploy, and publish the template.

The issue is with the hardware regeneration of MAC addresses when you create a VM based on this template in your configuration.  The new MAC is detected as a new interface on boot so the system creates new interface configuration files but has the old ones left as well. 

So if you ever fire up that template in the future to make changes just keep in mind that you will need to run these again before you shut down.  I like to keep a script on my CentOS templates to take care of this.

vCenter Lab Manager 4.0 (4.0.2.1269)