Ohjeah! » Linux

Linux SSH + PAM + LDAP + SSSD+ 2008 R2 AD Deployment

jro — Thu, 09 Jun 2011 18:58:17 +0000

As an update to my previous post “Linux SSH + PAM + LDAP + 2003 R2 AD Deployment“, SSSD is now part of the base RHEL6 repository (soon CentOS6 as well) which makes it much faster and easier to implement LDAP/AD authentication. In regards to configuring Active Directory, not too much has changed since my previous post so you’ll need to hit up the previous guide for a complete guide. So lets get to it..

Installing and Configuring PAM/LDAP/SSSD (tested on RHEL6):

Get some base packages:

# yum install openldap pam pam_ldap pam_krb5 ntp sssd

Configure /etc/sssd/sssd.conf (make sure you update ldap_default_authtok to your LDAP/AD user password). If you recreate sssd.conf be sure to chmod 600 or the service will fail to start:

# vi /etc/sssd/sssd.conf
 
[sssd]
domains = LDAP
services = nss, pam
config_file_version = 2
sbus_timeout = 30
 
[nss]
filter_groups = root
filter_users = root
 
[pam]
offline_credentials_expiration = 0
 
[domain/LDAP]
description = LDAP domain with AD server
debug_level = 9
enumerate = false
min_id = 1000
 
access_provider = ldap
# Restrict access to a certain group, update or comment this out
ldap_access_filter = memberOf=cn=LinuxUsers,ou=Groups,dc=domain,dc=com
 
id_provider = ldap
chpass_provider = krb5
 
ldap_uri = ldap://dc1.domain.com, ldap://dc2.domain.com
ldap_search_base = dc=domain,dc=com
 
tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_cacertdir = /etc/pki/tls/certs
 
# User that can read from AD, any normal user should work.  Update as necessary
ldap_default_bind_dn = cn=ldapuser,ou=Users,dc=domain,dc=com
 
# Leave this as password
ldap_default_authtok_type = password
 
# The ldap users actual password, update as necessary
ldap_default_authtok = ldapusers_password
 
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_cacertdir = /etc/pki/tls/certs
ldap_schema = rfc2307bis
ldap_user_principal = userPrincipalName
ldap_user_fullname = displayName
ldap_user_name = sAMAccountName
ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_force_upper_case_realm = True
 
# kerberos config
auth_provider = krb5
krb5_server = dc1.domain.com, dc2.domain.com
krb5_realm = DOMAIN.COM
krb5_changepw_principle = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15
cache_credentials = True

Configure /etc/krb5.conf:

# vi /etc/krb5.conf
 
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
 default_realm = DOMAIN.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes
 
[realms]
 KEMPERVALVE.COM = {
  kdc = dc1.domain.com
  kdc = dc2.domain.com
 }
 
[domain_realm]
 .DOMAIN.COM = DOMAIN.COM
 DOMAIN.COM = DOMAIN.COM
 
 domain.com = DOMAIN.COM
 .domain.com = DOMAIN.COM
[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

Update authentication methods (if authconfig is unavailable you’ll have to manual edit the order in /etc/pam.d/password-auth):

# authconfig --enablemkhomedir --enablesssdauth --updateall

Verify nsswitch.conf was updated with sss:

# vi /etc/nsswitch.conf
 
passwd:     files sss
shadow:     files sss
group:      files sss

Enable SSSD on boot, start if necessary (should be running already):

# chkconfig sssd on
# /etc/rc.d/init.d/sssd start

Giving SUDO permissions (Optional) Add the group you configured in AD to your sudoers file using %groupname (case sensitive). Example:

# vi /etc/sudoers
 
# Give our Windows Group linuxusers (system admins), ALL commands.
%LinuxUsers     ALL=(ALL)       ALL

Test AD authentication and that the users home directory was created (/home/username). Be sure to add ntpdate to a cron job to keep the time in sync with your domain controller.

Linux Update Password Script

jro — Wed, 04 Mar 2009 15:51:47 +0000

In my last post I showed a good example for using expect in a script. Here is another good example I use for updating local user passwords across a group of servers without using ssh keys. This assumes the user you are resetting can ssh to the host and the old password is the same on all hosts.

#!/bin/sh
# $Id: password_change.sh 6 2009-03-09 18:57:02Z jaredo $
#
# Copyright (c) 2009 Jared Orzechowski <jaredo at ameritech dot net>
#
# Description:  This script will ssh to servers and change the specified
# users password (assuming user can ssh).  Requires expect package.
 
USER=""
OLDPW=""
NEWPW=""
 
function resetpw()
{
        if [ "$1" ]; then
          echo
          echo "Attempting to reset password for $USER on host $1.."
 
              CMD="ssh -l root $1 passwd $USER"
              expect -c "
              match_max 100000
              spawn $CMD
 
              expect {
                \"Are you sure you want to continue connecting (yes/no)?\" {
                send \"yes\r\"
                exp_continue
                }
                \"s password:\" {
                send \"$OLDPW\r\"
                exp_continue
                }
                \"UNIX password:\" {
                send \"$NEWPW\r\"
                exp_continue
                expect -re \"$USER*\"
                }
              }
              "
        else
          echo "Missing hostname.."
        fi
}
 
#Syntax: resetpw hostname
#Example:
resetpw myserver1
resetpw myserver2
resetpw myserver3
resetpw myserver4

Remote Server Shutdown

jro — Tue, 03 Mar 2009 17:34:08 +0000

One of my recent projects was to initiate a server-wide shutdown should our UPS ever run low. I currently have Zenoss monitoring the health status of the UPS, including the remaining charge on the battery. Using Zenoss thresholds, I can make a script execute if the battery ever runs low.

Our Zenoss deployment currently runs on CentOS, so I put down a method to shut down each type of host from a linux platform. After much researching and testing, this is what I came up with (and am currently using in my shutdown script).

For Windows:

net rpc SHUTDOWN -C "Automated shutdown" -f -I "$server" -W $domain -U $username%$password

I replaced my arguments with some that would be more readable. User and password are separated with %.

For Linux:

CMD="ssh -l $username $server shutdown -h now"
              expect -c "
              match_max 100000
              spawn $CMD
 
              expect {
                \"Are you sure you want to continue connecting (yes/no)?\" {
                send \"yes\r\"
                exp_continue
                }
                \"password:\" {
                send \"$password\r\"
                expect -re \"$username*\"
                }
              }
              "

I wanted to shutdown linux servers without using keys but had to overcome the “do you want to connect” prompt. In order to do that I had to use exact which can be installed with “yum install exact”

By turning these into functions and passing arguments, you can make a shutdown script in a couple of minutes.

Linux Kernel Caching in Action

jro — Tue, 09 Dec 2008 15:58:18 +0000

[jaredo@zim ~]$ cat /proc/meminfo
MemTotal:     32962112 kB
MemFree:        237376 kB
Buffers:        235768 kB
Cached:       20340388 kB

Monitoring after a recent reboot:

Linux Apache + Subversion + Active Directory Authentication

jro — Fri, 03 Oct 2008 20:21:34 +0000

I found Subversion (svn) over HTTP to be very easy to deploy on top of our existing setup, and only took about 15 minutes. It simplifies user management by allowing us to manage users through Active Directory, and makes it easier on staff by using URLs for access. Here is a quick demonstration on a Fedora 9 box, assuming you have already performed a basic or default apache install.

Requirements:

Install the necessary svn packages:

# yum install subversion mod_dav_svn

Configure AD:

Create a user to bind to, this user needs no special permissions. I used svnuser in this demonstration.

Create a security group, users will need to be a member of this group in order to access our repositories. I used SVN_Access in this demonstration.

Create Repositories:

Create the following directories in your http root if you have not done so (/var/www on most systems):

# mkdir /var/www/svn
# mkdir /var/www/svn/repos

This will be the location for all of our repositories. Now to create a repository (test in this example):

# svnadmin create /var/www/svn/repos/test

Grant apache access to the repository:

# chown -R apache.apache /var/www/svn/repos/test

Configure Apache:

Create an httpd/apache include file for our subversion configuration, this may have already been created for you. Depending on your distro, you may need to integrate this directly in to your httpd.conf:

# touch /etc/httpd/conf.d/subversion.conf

Example subversion.conf:

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so
 
#
# Example configuration to enable HTTP access for a directory
# containing Subversion repositories, "/var/www/svn".  Each repository
# must be readable and writable by the 'apache' user.  Note that if
# SELinux is enabled, the repositories must be labelled with a context
# which httpd can write to; this will happen by default for
# directories created in /var/www.  Use "restorecon -R /var/www/svn"
# to label the repositories if upgrading from a previous release.
#
 
   DAV svn
   SVNParentPath /var/www/svn/repos
   SVNListParentPath on
 
      order allow,deny
      allow from all
      Options Indexes
      AuthzLDAPAuthoritative On
 
      AuthName "My Repository"
      AuthType Basic
      AuthBasicProvider ldap
 
      AuthLDAPBindDN svnuser@domain.com
      AuthLDAPBindPassword Test123
 
      AuthLDAPURL "ldap://dc.domain.com:3268/dc=domain,dc=com?sAMAccountName?sub?(objectCategory=person)"
      Require ldap-group CN=SVN_Access,OU=Groups,DC=domain,DC=com
 
      REQUIRE valid-user

You should now be able to access your test repository at http://website/repos/test

PXE and Kickstart, Automated Installations for Linux via WDS

jro — Thu, 25 Sep 2008 01:18:51 +0000

Today I decided to setup automated installations for Linux distros (RHEL, Fedora, CentOS), similar to how we deploy our Windows installations via PXE. Since we already had WDS running for installing Windows, it was just a matter of reconfiguring WDS, setting up the necessary structure and kickstart files for our automated Linux installations. While I do not cover the initial WDS installation process, I will attempt to go over the steps performed after the basic WDS install (native or mixed).

What you will need:

Windows server running WDS (and working via DHCP).
A recent copy of SYSLINUX (extracted to a folder somewhere on the WDS server).
An HTTP or anonymous FTP server to hold your installation media.

Currently when I boot my computer with PXE enabled, I am prompted to hit F12 for network boot. When I press F12, I am prompted by “Windows Boot Manager” to select my boot images that I setup in WDS. Since I can’t install Linux images directly using the WDS interface, an alternative boot image is necessary. That is where SYSLINUX/PXELINUX takes over.

Pre-Setup

Create the necessary directory structure inside the WDS RemoteInstall directory (this was specified during the WDS installation).
- Inside the x86 folder (RemoteInstall\Boot\x86\), create the following folders (including pxelinux.cfg):
  - conf
  - img
  - knl
  - pxelinux.cfg

Preparing Installation Media

Setup an FTP server to hold your installation media (HTTP works also): Currently the average size of a Red Hat distribution is about 5GB, so make sure the server you select will have the necessary disk space. You will need separate installation media for both distribution specific 32bit and 64bit installs. If you want Fedora 9, CentOS 5.2, and RHEL 5.2 images (both 32bit and 64bit), that will be about 30GB. As long as you’re not archiving old distributions, this should not be an issue.
- On my FTP server in the root/path, I created a directory for each of my installation media. Also, creating a standard naming convention will help with editing the configuration files later and any case sensitivity issues. Example: My directory names are DistroVersion_arc (Fedora9_32bit), as you will see later on.
- Copy the entire installation dvd media to the corresponding directories you created (not the .iso, extract its entire contents).
In the FTP root directory for the media you copied, create a kickstart file (ks.cfg). (Example: ftp://ftpserver.domain.com/Fedora9_32bit/ks.cfg) I have included example kickstart files at the bottom of this article.
Once you have copied the installation media for a distro to your FTP server, you need to copy 2 files from that specific distro media to your WDS server.
- From the (installation media\images\pxeboot) directory, copy the following:
  - Copy vmlinuz to the following directory on the WDS server (RemoteInstall\Boot\x86\knl\). Rename the file to an identifying name such as vmlinuz-fedora9-32bit.
  - Copy initrd.img to the following directory on the WDS server (RemoteInstall\Boot\x86\img\). Rename the file to an identifying name such as initrd-fedora9-32bit.

When it comes time to configure your option menus, you will need to specify these files for each version/distro you plan on making available.

Configuring WDS

From inside the downloaded SYSLINUX archive, copy the following files:
- pxelinux.0 from the (syslinux\core) directory to your (RemoteInstall\Boot\x86\) directory on the WDS server.
- menu.c32 and vesamenu.c32 from the (syslinux\com32\menu) directory to your (RemoteInstall\Boot\x86\) directory on the WDS server.
Inside the (RemoteInstall\Boot\x86\) directory, create copies of the following files, rename them accordingly (you can copy paste then rename):
- Make a copy of pxeboot.n12, save it as pxeboot.0
- Make a copy of abortpxe.com, save it as abortpxe.0
Inside (RemoteInstall\Boot\x86\pxelinux.cfg\), create a file called default. This will be the initial menu you see during PXE boot, edit the file and give it the following contents:

       # File: wdspath\RemoteInstall\Boot\x86\pxelinux.cfg\default
       # Default boot option to use
       DEFAULT menu.c32
       TIMEOUT 50
       # Prompt user for selection
       PROMPT 0
       # Menu Configuration
       MENU WIDTH 80
       MENU MARGIN 10
       MENU PASSWORDMARGIN 3
       MENU ROWS 12
       MENU TABMSGROW 18
       MENU CMDLINEROW 18
       MENU ENDROW 24
       MENU PASSWORDROW 11
       MENU TIMEOUTROW 20
       MENU TITLE Main Menu
 
       # Menus
       # Windows
	LABEL Windows
	MENU LABEL Windows Installer
	KERNEL pxeboot.0
       # x86
       LABEL x86
         MENU LABEL Linux 32bit Installs (x86)
         KERNEL menu.c32
         APPEND conf/x86.conf
       # x64
       LABEL x64
         MENU LABEL Linux 64bit Installs (x64)
         KERNEL menu.c32
         APPEND conf/x64.conf
	# Windows
	LABEL Exit
	MENU LABEL Exit
	KERNEL abortpxe.0

Now you need to create the sub-menu configuration files for your 32 and 64 bit installs that you specified in your default file (RemoteInstall\Boot\x86\conf\x86.conf and RemoteInstall\Boot\x86\conf\x64.conf respectively). These files will list the available distros to install, and the path to your copied kernel\image files, including your kickstart file which contains the path for your FTP or HTTP installation media. Each option needs to point to the specific kernel and image that was created from the installation media earlier.

       # File: wdspath\RemoteInstall\Boot\x86\conf\x86.conf
       # Default boot option to use
       DEFAULT menu.c32
       # Prompt user for selection
       PROMPT 0
       # Menu Configuration
       MENU WIDTH 80
       MENU MARGIN 10
       MENU PASSWORDMARGIN 3
       MENU ROWS 12
       MENU TABMSGROW 18
       MENU CMDLINEROW 18
       MENU ENDROW 24
       MENU PASSWORDROW 11
       MENU TIMEOUTROW 20
       MENU TITLE Linux32Bit (x86) OS Selection
       # Return to Main Menu
       LABEL MainMenu
         MENU DEFAULT
         MENU LABEL ^Main Menu
         KERNEL menu.c32
       #
       # Blank boots
       #
       LABEL Fedora 9 32bit
         MENU LABEL Fedora 9 32bit
         KERNEL knl/vmlinuz-fedora9-x86
         APPEND initrd=img/initrd-fedora9-x86.img ks=ftp://ftpserver.mydomain.com/Fedora9_32bit/ks.cfg

       # File: wdspath\RemoteInstall\Boot\x86\conf\x64.conf
       # Default boot option to use
       DEFAULT menu.c32
       # Prompt user for selection
       PROMPT 0
       # Menu Configuration
       MENU WIDTH 80
       MENU MARGIN 10
       MENU PASSWORDMARGIN 3
       MENU ROWS 12
       MENU TABMSGROW 18
       MENU CMDLINEROW 18
       MENU ENDROW 24
       MENU PASSWORDROW 11
       MENU TIMEOUTROW 20
       MENU TITLE 64Bit (x64) OS Choice
       # Return to Main Menu
       LABEL MainMenu
         MENU DEFAULT
         MENU LABEL ^Main Menu
         KERNEL menu.c32
       #
       # Blank boots
       #
       LABEL CentOS 5.2 64bit
         MENU LABEL CentOS 5.2 64bit
         KERNEL knl/vmlinuz-centos52-x64
         APPEND initrd=img/initrd-centos52-x64.img ks=ftp://ftpserver.mydomain.com/CentOS52_64bit/ks.cfg
       LABEL Fedora 9 64bit
         MENU LABEL Fedora 9 64bit
         KERNEL knl/vmlinuz-fedora9-x64
         APPEND initrd=img/initrd-fedora9-x64.img ks=ftp://ftpserver.mydomain.com/Fedora9_64bit/ks.cfg
       LABEL RHEL 5.2 64bit
         MENU LABEL RHEL 5.2 64bit
         KERNEL knl/vmlinuz-rhel52-x64
         APPEND initrd=img/initrd-rhel52-x64.img ks=ftp://ftpserver.mydomain.com/RHEL52_64bit/ks.cfg

Lastly, set WDS to use the pxelinux.0 boot image. If you need to get to the normal WDS boot image, you can use the Windows Installer option created in your default menu.
- Open Windows Deployment Services on your WDS server. Right click your server -> Properties. Under the Boot tab, set the Default boot program for x86 architecture (Boot\x86\pxelinux.0), or browse to the pxelinux.0 file we created earlier. You may leave the other architectures alone or change as you see fit.

**For Windows 2008 R2 installations you must set the bootimage via command-line as followed:

wdsutil /set-server /bootprogram:boot\x86\pxelinux.0 /Architecture:x86
wdsutil /set-server /bootprogram:boot\x86\pxelinux.0 /Architecture:x64
wdsutil /set-server /N12bootprogram:boot\x86\pxelinux.0 /Architecture:x86
wdsutil /set-server /N12bootprogram:boot\x86\pxelinux.0 /Architecture:x64

Finished Result

Click here to view the embedded video.

Example Kickstart File

Here is an example kickstart file for Fedora 9. For each new distro I normally perform a cd install with my desired options, then use the resulting /root/anaconda-cfg.ks for assistance. Note that the kickstart file specifies the FTP path of your installation media that you created in the beginning of this article.

#Version=F9
#32bit
install
text
url --url ftp://ftpserver.mydomain.com/Fedora9_32bit
lang en_US.UTF-8
keyboard us
network --device eth0 --bootproto dhcp
rootpw --iscrypted $1$X.qPQYdk$L.YRbuORBd30
firewall --disabled
authconfig --enableshadow --enablemd5 --passalgo=sha512
selinux --disabled
timezone America/Chicago
bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
clearpart --all --drives=sda
part /boot --fstype ext3 --size=1000
part swap --size=2048
part / --fstype ext3 --size=1 --grow
%packages
@editors
@development-tools
@text-internet
@core
@base
@hardware-support
@admin-tools
grub
openldap
openldap-devel
openldap-client
net-snmp*
ntp

Linux SSH + PAM + LDAP + 2003 R2 AD Deployment

jro — Tue, 23 Sep 2008 14:47:47 +0000

Often I find my self working in a department where the skill sets of individuals varies significantly, and my current position is no different. While there is nothing wrong with this, there have been several occasions (like being on vacation), where help desk personnel or other less savvy users are called upon to perform basic functions . When you start dealing with a group of servers, it can be troublesome to maintain a local user base without some form of directory authentication. Since most corporate offices still revolve around Windows at the desktop, Active directory becomes a very logical option.

This will basically document the steps I performed in setting up our Linux machines (Fedora 9, RHEL 5, CentOS 5) to authenticate against our Active Directory domain for SSH, while restricting access to a specific security group so that we can give only specific users access as needed. While I have only used this with Red Hat distros, it may be helpful to others.

Phase 1: Preparing Active Directory

While Windows Services for UNIX is still available, Microsoft was nice enough to include a similar feature with Windows 2003 R2 out of the box. In add/remove Windows components under Active Directory Services, you will find Identity Management for UNIX. This will install the necessary LDAP attributes we need for getting this all to work, and will give you a new tab “UNIX Attributes” for your users.

Phase 2: Preparing Groups

Now create your first security group, note that it is beneficial not to include special characters or spaces in your group name. Once your group has been created edit the UNIX Attributes under properties and set it to the default created NIS Domain, you may leave the Group ID or change as needed.

Phase 3: Preparing Users

Once your security group has been setup (I named mine LinuxUsers), you can setup add your users. Under user properties, you will see a tab “UNIX Attributes” that contain our specific LDAP attributes. Even though we won’t be using NIS, you have to set the NIS Domain to have access to other options. As for the rest of the attributes, I personally prefer to use bash (/bin/bash) and ensure that home directories are all lower case.

Phase 4: Configuring Linux

The hardest part of this setup was getting the correct DN where needed. Due to our number of organizational units, I ended up using jxplore a few times which made finding a specific DN much easier.

Packages: openldap, openldap-devel, pam, pam_krb5, ntp

# yum install openldap, openldap-devel, pam, pam_krb5, ntp

In order to log in, you must make sure your time is synchronized with your domain controller. Since we use an external ntp server on our domain controller, we are going to sync with the same server before continuing. An optional step would be to setup a cron job to synchronize the date and time consistently. Also note that nptd must be stopped before updating, so in case you had it installed prior make sure the service is stopped.

# /etc/rc.d/init.d/ntpd stop
# ntpdate -u pool.ntp.org
# /etc/rc.d/init.d/ntpd start

Now there are several configuration files we must update, I will list the file paths I used and examples, though it may be different. In these examples, MYDOMAIN.COM is our active directory domain, and pdc.mydomain.com is our domain controller.

/etc/krb.conf

(Example)

MYDOMAIN.COM
MYDOMAIN.COM pdc.mydomain.com

/etc/krb5.conf

(Example)

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
 default_realm = MYDOMAIN.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes
 
[realms]
 MYDOMAIN.COM = {
  kdc = pdc.mydomain.com
  kdc = bdc.mydomain.com
 }
 
[domain_realm]
 .MYDOMAIN.COM = MYDOMAIN.COM
 MYDOMIN.COM = MYDOMAIN.COM
 
 mydomain.com = MYDOMAIN.COM
 .mydomain.com = MYDOMAIN.COM
[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

/etc/ldap.conf (NOTE: You must create a normal user for your Linux servers to bind to AD with, also you will need to change these DNs specific to your setup.)

(Example)

# Must be RESOLVABLE
host pdc.mydomain.com bdc.mydomain.com
 
# The distinguished name of the search base.
base dc=mydomain,dc=com
 
# Bind user you created in AD
# The credentials to bind with.
binddn CN=ldapuser,OU=Users,DC=mydomain,DC=com
bindpw Password123
 
# The search scope.
scope sub
 
# Search timelimit
timelimit 30
 
# Bind/connect timelimit
bind_timelimit 30
 
# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
idle_timelimit 3600
 
# Group to enforce membership of
# The group you setup in AD that contains your linux users
pam_groupdn CN=LinuxUsers,OU=Groups,DC=mydomain,DC=com
 
# Group member attribute
pam_member_attribute member
 
# Update Active Directory password, by
# creating Unicode password and updating
# unicodePwd attribute.
pam_password ad
 
nss_base_passwd    ou=Users,dc=mydomain,dc=com?sub
nss_base_shadow    ou=Users,dc=mydomain,dc=com?sub
nss_base_group     ou=Users,dc=mydomain,dc=com?sub
 
# Just assume that there are no supplemental groups for these named users
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman
 
# RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad
 
# Disable SASL security layers. This is needed for AD.
sasl_secprops maxssf=0
 
# Override the default Kerberos ticket cache location.
krb5_ccname FILE:/etc/.ldapcache
ssl no

/etc/nsswitch.conf

Append ldap to the end of the following lines:

passwd:
shadow:
group:
netgroup:

(Example)

passwd:     files ldap
shadow:     files ldap
group:      files ldap
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   files ldap
publickey:  nisplus
automount:  files ldap
aliases:    files nisplus

/etc/pam.d/sshd – Add the following ldap and krb5 pam modules, also create users home directory if it does not exist.

auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_ldap.so use_first_pass
 
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
 
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_ldap.so use_authtok
 
session     optional      pam_krb5.so
session     optional      pam_ldap.so
 
session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel silent

(Example)

#%PAM-1.0
auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_ldap.so use_first_pass
auth       include      system-auth
 
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account    required     pam_nologin.so
account    include      system-auth
 
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_ldap.so use_authtok
password   include      system-auth
 
session     optional      pam_krb5.so
session     optional      pam_ldap.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    required     pam_loginuid.so
session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel silent

Verify ldap authentication is working by logging in under a domain account with the correct permissions. You can watch the security log for information on failures.

Phase 5: Giving SUDO permissions (Optional)

Add the group to your sudoers file using %groupname.

(Example)

# Give our Windows Group linuxusers (system admins), ALL commands.
%linuxusers     ALL=(ALL)       ALL