nk23x/CentOS_AD_Integration

## authenticate against Active Directory Using SAMBA
How do I authenticate against Active Directory Using SAMBA/WINBIND?


How do I authenticate against Active Directory (AD) ?


There are a lot of ways to do this.  How Do I Integrate Bright With Active Directory using the native AD provider of SSSD? (/faq/index.php?action=artikel&cat=13&id=224&artlang=en) discusses a way using SSSD/AD_provider authentication with multiple RHEL servers integrated to an AD domain or forest, and is recommended for most purposes.


A differenet way, with a single RHEL server integrated to an AD domain or forest, uses the following steps to allow a Bright Cluster to authenticate against a Windows AD Server while maintaining the user information in Bright's LDAP. These instructions were tested on Windows Server 2008 and 2012.


1. Configure smb.conf

Edit /etc/samba/smb.conf and fill in the Windows AD Server information (workgroup, password server, and realm) under the [global] section. In this example, bright is used as workgroup, bcm.bright.local is used as password server, and BRIGHT.LOCAL is used as an Active Directory realm. The rest of the parameters should be kept the same.


[global]
   workgroup = bright
   password server = bcm.bright.local
   realm = BRIGHT.LOCAL
   encrypt passwords = yes
   winbind enum groups = yes
   winbind enum users = yes
   winbind use default domain = yes
   security = ADS
   debuglevel = 2
   wins support = no
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   template shell = /bin/false
   winbind offline logon = false


Tip:

Type "net config workstation" on the command line of the Windows AD Server to get the workgroup, password server and AD realm.


Logon Domain = workgroup

FQDN = password server

FQDN - Computer Name = realm


2. Configure krb5.conf
Edit /etc/krb5.conf and change the following sections to match the Windows AD Server Settings. Here,

    port 88 is the default port that is used for authentication in the forest level trusts (the underlying technology by which secured Active Directory communications occur)
    port 749 is the default port that is used for kadmin utilities.


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

[libdefaults]
 default_realm = BRIGHT.LOCAL
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = true

[realms]
 BRIGHT.LOCAL = {
  kdc = bcm.bright.local:88
  admin_server = bcm.bright.local:749
 }

[domain_realm]
 .bright.local = BRIGHT.LOCAL
 bright.local = BRIGHT.LOCAL


3. Configure Authentication Method


/etc/pam.d/system-auth-ac:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_winbind.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

/etc/pam.d/password-auth-ac:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_winbind.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid


session     required      pam_unix.so


/etc/pam.d/php

auth sufficient pam_winbind.so

account sufficient pam_winbind.so


Tip:

If you're using Red Hat based distributions, you may use "authconfig-tui" tool to autogenerate system-auth-ac and password-auth-ac, but then you'll have to check that the smb.conf still has the correct configurations.


3. Test The Connectivity to Windows Active Directory Server

Add an entry for the AD server "bcm.bright.local" into /etc/hosts.


/etc/hosts:

10.2.184.194 bcm.bright.local bright bright.local


Run the following command, which fetches the domain Security Identifier (SID) and stores it in the local secrets.tdb:


# net rpc getsid -S bcm.bright.local
Storing SID S-1-5-21-547601799-235048094-3373437802 for Domain BRIGHT in secrets.tdb


Make sure that the winbind service can start successfully


# /etc/init.d/winbind restart

# /etc/init.d/winbind status

winbindd (pid 17966) is running...


4. Join the Windows AD Domain

# net ads join -U Administrator -S bcm.bright.local
Enter Administrator's password:
Using short domain name -- BRIGHT
Joined 'AD-TEST' to dns domain 'bright.local'


5. Verify Authentication

a. Add user in Bright:

# cmsh
% user
% add user adel
%set password
% commit

b. Add user in Windows AD Server with different password.

c. At this stage:

* a log in attempt with the password that is stored in Bright's LDAP should be denied, and

* a log in with the password that is stored in Windows AD Server should be allowed.


6. Configuring Userportal Authentication Method


Edit /etc/pam.d/php to include the following lines:

auth sufficient pam_winbind.so

account sufficient pam_winbind.so


Restart the httpd service:

# /etc/init.d/httpd restart


Troubleshooting
Issue
# net rpc getsid -S bcm.bright.local
Unable to find a suitable server for domain BRIGHT.LOCAL

Resolution
smb.conf and krb5.conf need to be reconfigured

Issue
# net join -U Administrator -S bcm.bright.local
Enter Administrator's password:
Failed to join domain: failed to find DC for domain BRIGHT.LOCAL
ADS join did not work, falling back to RPC...
Unable to find a suitable server for domain BRIGHT.LOCAL
Unable to find a suitable server for domain BRIGHT.LOCAL

Resolution
samba.conf and krb5.conf need to be reconfigured

Issue
# net ads join -U Administrator -S bcm.bright.local
Enter Administrator's password:
Using short domain name -- BRIGHT
Joined 'AD-TEST' to dns domain 'bright.local'
kerberos_kinit_password AD-TEST$@BRIGHT.LOCAL failed: Clock skew too great

Resolution
Timezone between the AD server and Bright Cluster differs. Fix that.

Issue
# net join -U Administrator -S bcm.bright.local
Enter Administrator's password:
Using short domain name -- BRIGHT
Joined 'AD-TEST' to dns domain 'bright.local'
DNS Update for ad-test.cm.cluster failed: ERROR_DNS_GSS_ERROR
DNS update failed!

Resolution
A DNS error is normal if the server is not a domain DNS server. This is because the DNS record of the server cannot be updated. This error will not block joining the AD domain. It's related to the Windows DNS Server in which the AD is registered. To test that the join was successful:

# net ads testjoin
Join is OK

Issue

# net ads join -U Administrator -S bcm.bright.local

Enter Administrator's password:
kinit succeeded but ads_sasl_spnego_krb5_bind failed: Server not found in Kerberos database
Failed to join domain: failed to connect to AD: Server not found in Kerberos database

Resolution

re-issue "net rpc getsid -S bright.bcm.local"

## CentOS_AD_Integration
1. Install the neccessary dependancies

  # yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir sudo

This will install:
- authconfig which we will use to setup the configuration file basics, there may be parts missing or not quite accurate here, so some of the files seem to need a little massaging to work right later.
- krb5-workstation which installs required libraries and binaries to perform authentication against active directory using the kerberos protocol
- pam_krb5 this package provides libraries for PAM (Pluggable Authentication Modules) to interface with kerberos
- samba-common will installed the required libraries and binaries to join the linux box to the domain so domain accounts are trusted by the local machine
- oddjob-mkhomedir this package is used to automatically create home directories when your AD users log into the server the first time
- sudo will be used to configure which AD users have permission to perform elevated operations on the linux computer.


2. Run authconfig to setup the initial authentication configuration

  # authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup={AD DOMAIN NAME(short version all caps)} --smbrealm={AD DOMAIN NAME(long version all caps)} --enablewinbindusedefaultdomain --winbindtemplatehomedir=/home/{AD DOMAIN NAME(short version all lower case)}/%U --winbindtemplateshell=/bin/bash --enablekrb5 --krb5realm={AD DOMAIN NAME(long version all caps)} --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall

This will create the initial configuration files to setup samba and kerberos. Next we will update the initial files to make sure they are correct.


3. Verify that your /etc/krb5.conf file looks like this

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

[libdefaults]
 default_realm = STF.NUS.EDU.SG
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 STF.NUS.EDU.SG = {
 admin_server = dc01.stf.nus.edu.sg
 kdc_server = dc01.stf.nus.edu.sg
 }

[domain_realm]
 stf.nus.edu.sg = STF.NUS.EDU.SG
 .stf.nus.edu.sg = STF.NUS.EDU.SG


4. Test that domain authentication via kerberos is working
# kinit user_name@STF.NUS.EDU.SG
# klist
You should be returned to a prompt with no output if authentication works correctly. If you receive an error at this point, stop and resolve the error. If you do get an error, it will be something related to the krb5.conf file and the active directory setup. Compare all of your configuration directives and try it again until you can authenticate against AD with this command.


5. Join the linux box to the AD Domain

Note: Make sure your linux box host name is "host_name.domain.com" format before you join the domain

# net ads join {AD DOMAIN NAME(long version all lower case)} -U {ad user authorized to join computers to domain}

Example:
# net ads join stf.nus.edu.sg -U {USER_NAME all caps)}

You can then test that the join succeeded if you have any doubts using

# net ads testjoin

That command will reply with a good indicator if your all good to go.

This step is reliant on /etc/sama/smb.conf configuration file. If you have problems here, that would be a good place to start troubleshooting the issue.


6. Setup a home folder to store active directory user accounts

# mkdir /home/{ad domain short name.xxx}
# chmod 777 /home/{ad domain short name.xxx}/

Now when your AD users log into this box, a home directory will be created for them automatically in this location.


7. Update your /etc/pam.d/sshd

Change the "password-auth" module to "system-auth" module  for all 4 pam activities.

vim /etc/pam.d/sshd

#%PAM-1.0
auth       required     pam_sepermit.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      system-auth


8. Update your /etc/pam.d/system-auth

Add "account     requisite     pam_succeed_if.so user = AD_user_name debug" to the file to ONLY allow "AD_user_name" to ssh login.

If you want ONLY AD_group to ssh login, please add "account [default=bad success=ignore] pam_succeed_if.so user ingroup linuxusers quiet" instead.

vim /etc/pam.d/system-auth

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        sufficient    pam_winbind.so use_first_pass
auth        required      pam_deny.so

account     required      pam_access.so
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     requisite     pam_succeed_if.so user = AD_user_name debug
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_oddjob_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so


9. Add the AD_user_name or AD_user_group to /etc/sudoers

# echo '%AD_group ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

This will allow your users who are part of the active directory group 'AD_group' to perform elevated tasks on the server via sudo. The NOPASSWD can be replaced with ALL which will cause the server to ask the user again for their password. More secure, but if you're box is secured in other ways (as mine are) I find this to be more annoying than anything else...

On a side note, linux does not like spaces in the group names, so I've found that adding Domain Admins to this area doesn't work well, nor using that in PAM. honetsly though, it doesn't work at all.... So if you want to use a default m$ group, replace the space in the group name with an underscore or get rid of it all together in Active Directory.


10. Make sure required services are set to start on boot

# chkconfig oddjobd on
# chkconfig winbind on
# chkconfig messagebus on


11. Reboot the linux box and you should be ready to start authenticating your active directory users.

# init 6

In all honesty you don't have to reboot, you can simply start/restart the services you just turned on in step 9, but it's nice to know that the next time the power goes out and your server restarts everything will come up just fine... ;-)


Reference
http://community.spiceworks.com/how_to/show/44885-setup-centos-to-authenticate-via-active-directory
http://kb.kaminskiengineering.com/node/58
http://serverfault.com/questions/483643/linux-pam-pam-succeed-if-so


## Managing Debian with Active Directory
After you identify this system, the next best thing to do is create a DNS entry pointing to your PDC Server. This way if you ever need to decommission your current PDC server, you can just change the DNS record and not have to go back to all your Linux systems to update the system they authenticate to.

From here, everything you’re going to do, aside from creating new AD users and security groups, will all be done at the Linux command line. There’s a couple of conf files that we need to configure after installing some software on each of the systems. In one of my future blog posts, I’m (hopefully) going to be going over using Chef to distribute configuration files <http://wiki.opscode.com/pages/viewpage.action?pageId=7274862>.

This whole process isnt all that difficult as long as you have a decent understanding of the services and subsystems that you’re relying on. Here they are:

    Pluggable Authentication Modules (PAM)
    Server Message Block (SMB, Samba)
    WinBIND (part of Samba)
    Kerberos 5 (By MIT, with Microsoft compatibility hacks)

SO, lets get some software installed. Below is the EXACT command line that I used on my Ubuntu servers (10.04).

sudo apt-get install krb5-user libkrb53 krb5-config winbind samba ntp ntpdate nss-updatedb libnss-db libpam-ccreds libnss-ldap ldap-utils

After installing that software, you’ll want to stop all the services while you configure them:

sudo /etc/init.d/samba stop
sudo /etc/init.d/winbind stop
sudo /etc/init.d/ntp-server stop

Each server in a Kerberos authentication realm must be assigned a Fully Qualified Domain Name (FQDN) that is both forward- and reverse-resolvable.

Note: Active Directory depends heavily on DNS, so it is likely that the Active Directory Domain Controller is also running the Microsoft DNS server package. If this is the case, verify that each server has a FQDN assigned to it before performing the tests outlined in this section.

If the server already has an FQDN assigned to it, test forward and reverse look-up with the following commands:

nslookup server.example.com
nslookup  (ip address of server) 10.1.1.5

The output of the first command should contain the IP address of the server. The output of the second command should contain the FQDN of the server. If this is not the case, Kerberos authentication will not function properly. Next, we’ll be configuring the Kerberos Config file which is located here: /etc/krb5.conf Here’s what mine looks like (Make sure to read the comments I put in there):

[libdefaults]
default_realm = ERDMANOR.COM #Kerberos is CASE sensitive; this must be all UPPERCASE!
[logging]
default = FILE:/var/log/krb5.log
kdc = FILE:/var/log/krb5kdc.log
[realms]
MYDOMAIN.COM = { # MUST BE ALL CAPS ON THIS LINE!
kdc = kerberos.mydomain.com:88 #You really only need 1 kerberos domain controller
kdc = kerberos2.mydomain.com:88 #but in my network there are three, so I listed
kdc = kerberos3.mydomain.com:88 #all of them in here.
admin_server = kerberos.mydomain.com #This should be set to the DC that holds the PDC Role
default_domain = mydomain.com #
}

[login]
krb4_convert = true
krb4_get_tickets = false

#

Active Directory, for as long as I can remember, is time sensitive to about +/- 5 minutes. You can adjust that window to anything you want by editing your Domain Policies (Group Policies (GPOs)), but there’s no need to really do that. Anything outside that window of time and your Domain Controllers will deny any kerberos ticket requests. This is why you need to make sure and setup your NTP daemon to point at your domain controller. I recommend setting it up with a DNS name, but you can get by with an IP address. Reason is, if the PDC ever changes, you dont need to go back to all your old machines and update conf files. Run this command: “sudo nano /etc/ntp.conf”

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Specify one or more NTP servers.

server kerberos.mydomain.com #insert your PDC here
server kerberos2.mydomain.com #secondary DC
server kerberos3.mydomain.com #third DC
server 1.ubuntu.pool.ntp.org #fall back to Ubuntu's NTP
server 2.ubuntu.pool.ntp.org #
server 3.ubuntu.pool.ntp.org #

#

So, we’re on our way here. Without saying, you’re probably getting a DHCP address from a Domain Controller if you’re already on a Windows network. If you’re setting up a server with a Static address, then make sure to setup your DNS nameservers in your /etc/resolv.conf file so that you’re getting DNS from your PDC and any other Domain Controllers which host DNS. I DONT recommend using your “/etc/hosts” file for this.

So lets get to testing! From the command line issue this command:

kinit -p username@MYDOMAIN.COM
#obviously changing to your username and domain name on your network.
#Notice the UPPERCASE spelling of MYDOMAIN.COM?
#

After that command is entered you should be getting prompted for your DOMAIN password. From here just make sure that you’re not getting any errors (which you shouldn’t). If you’re looking to verify that you have a valid ticket, then issue this command:

Now that we have Kerberos and NTP working properly, we can move onto the next portion of authentication: PAM. If you dont know anything about PAM then you can safely move on to the configuration portion of this part. But for those of you wanting more of an understanding, here you go. I got this information from http://www.tldp.org/HOWTO/html_single/User-Authentication-HOWTO/, and it’s VERY good info. Also, verify that your “/etc/skel/” directory is setup properly. You can get creative with this and have some pretty neat options rolled out to all your users if you prefer.

#I took out all the #comments for this blog, but I HIGHLY recommend that you leave them in!

so here are what my PAM modules look like in /etc/pam.d/:

common-account:
# /etc/pam.d/common-account - authorization settings common to all services
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 #VERY IMPORTANT!
account [success=3 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=2 new_authtok_reqd=done default=ignore] pam_winbind.so
account [success=1 default=ignore] pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000
#

common-auth:
# /etc/pam.d/common-auth - authentication settings common to all services
# here are the per-package modules (the "Primary" block)
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
auth [success=6 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=5 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=4 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth [success=3 default=ignore] pam_ldap.so use_first_pass
auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update
auth requisite pam_deny.so
auth required pam_permit.so
auth optional pam_ccreds.so minimum_uid=1000 action=store
auth optional pam_mount.so
auth optional pam_cap.so
#

common-password:
# /etc/pam.d/common-password - password-related modules common to all services
password [success=4 default=ignore] pam_krb5.so minimum_uid=1000
password [success=3 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password [success=2 default=ignore] pam_winbind.so use_authtok try_first_pass
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so
password optional pam_gnome_keyring.so
#

common-session
# /etc/pam.d/common-session - session-related modules common to all services
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so
session optional pam_winbind.so
session optional pam_mount.so
session optional pam_ldap.so
session optional pam_ck_connector.so nox11
#

common-session-noninteractive
# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so
session optional pam_winbind.so
session optional pam_mount.so
session optional pam_ldap.so
#

This should be everything you need for PAM to work properly. Now we need to work on Samba. The Samba config is stored at “/etc/samba/smb.conf”. Again, I stripped my Samba config down and made a backup of the original. I dont want my end users sharing data between themselves, I want them using corporate file shares where I know that the data is backed up. Also, I want them using Print Servers, not hosting printers from their machines. So this smb.conf is pretty short compared to the original. If you visit the Samba website, you’ll even see that they want people to keep this file short and simple. According to the Samba Team, the longer this file is, the more it impacts performance of the system. Please heed the warnings in your smb.conf as well as the notes I post below:

# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.
#
#======================= Global Settings =======================

[global]

security = ads
realm = MYDOMAIN.COM #Must be UPPER case
password server = kerberos.mydomain.com #PDC that we mentioned earlier
workgroup = MYDOMAIN #This is the NetBIOS name of your Domain
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/MYDOMAIN/%U #Dont forget to update this directory!
template shell = /bin/bash #You can use whatever shell you'd like
client use spnego = yes
client ntlmv2 auth = yes
encrypt passwords = yes
winbind use default domain = yes
restrict anonymous = 2

server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog only = yes
syslog = 4
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
domain logons = no #Extremely important that this is NO.
usershare allow guests = yes

Next we’ll be setting up the “/etc/nsswitch.conf” file. This file does a few things to help communications with your LDAP server (AD in this case) as well as tell your local Linux system where to look for password information.

When fiddling with /etc/nsswitch.conf, it is best to turn the Name Services Caching Daemon off or you will be confused by cached results. Turn it on afterwards.

Now edit the nsswitch.conf file:

# /etc/nsswitch.conf
passwd: files winbind
group: files winbind
shadow: compat
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
#

And Turn back on your service:

Assuming that all goes well and Kerberos, Winbind and Samba are setup properly, you should be able to join your linux system to the domain. Due to restrictions in the NetBIOS protocol, the hostname must contain no more than 15 characters. If you see a STATUS_BUFFER_OVERFLOW message in the winbind log, odds are the hostname is invalid. Now would also be a good time to clear whatever cache files, if any, Winbind had previously generated. The Winbind cache is located in /var/lib/samba/. Backup this directory to /var/lib/samba.bak/ and delete all the files in the original. Now you can issue this command:

sudo net ads join -S MYDOMAIN.COM -U {domain-admin-user}

Couple things here.
First, you may need to change MYDOMAIN.COM to KERBEROS.MYDOMAIN.COM. If it doesn’t work the first way, try the next. Second is, {domain-admin-user} MUST be a Domain Admin account in Active Directory. Otherwise you’ll fail.

Now, I’ve gotten mixed results here… My Mint 12 and 13 boxes joined and I actually got a “Domain Joined!” message in the shell.

My Debian 6 machine threw an error:

steve @ mintdebianvm ~ :) ᛤ>   sudo net ads join -S ERDMANOR.COM -U administrator
[sudo] password for steve:
Enter administrator's password:
kinit succeeded but ads_sasl_spnego_krb5_bind failed: Server not found in Kerberos database
Failed to join domain: failed to connect to AD: Server not found in Kerberos database

I haven’t had much time to look into why this is happening, but I can assure you the system joined the domain, the computer account was created in AD and I’m able to SSH to this machine with domain creds… If anyone knows why this is happening, PLEASE contact me! Thanks!

Look up Windows Ports needed for Active Directory. Need Microsoft Link!
After your join to the domain is successfull, you can startup your services:

sudo /etc/init.d/samba start
sudo /etc/init.d/winbind start

From this point, you should be able to test some querys against the domain:

getent passwd
getent shadow
getent group

At this point, you should be able to resolve users and groups from the Windows Active Directory domain using getent passwd and getent group. If these commands don’t display your Windows accounts, try to resolve them using wbinfo -u and wbinfo -g. These commands query the Winbind service directly, bypassing the name service switch. If you can resolve users and groups with wbinfo, go back and make sure you configured /etc/nsswitch.conf properly.

Now with EVERYTHING setup properly, you *should* be able to fire up an SSH session to your linux box and log in with AD Credentals. BUT! Your Domain Users are NOT going to be able to “sudo” any commands. For the sake of security, you dont want ALL your domain users to be able to sudo commands, so what I did is create a domain security group, mine is named “linux-sudo”. Then I added in only the users I want to be able to sudo commands to that group. Then I edited my “sudoers” file to include the domain security group “linux-sudo”. So make sure to edit your “/etc/sudoers” file, and add this line:

%linux-sudo     ALL=(ALL:ALL) ALL

Now, I’m able to log into my Debian, Mint and Ubuntu Linux systems with Domain Credentials! :)

EDIT: In looking for information regarding this entire process on a RED HAT system. (RHEL 5 or 6), please refer to this guide:

http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/jcr:system/jcr:versionStorage/ae40084d0a052601783f1ea42715cdef/9/jcr:frozenNode/rh:resourceFile


Here are all the sites that I used in the making of this blog:


http://wiki.samba.org/index.php/Samba_%26_Active_Directory#Setting_up_PAM_Authentication_for_Active_Directory

https://help.ubuntu.com/community/ADAuthentication

https://help.ubuntu.com/community/Kerberos

https://help.ubuntu.com/community/PamCcredsHowto

https://help.ubuntu.com/community/ActiveDirectoryHowto

https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto

http://www.tldp.org/HOWTO/html_single/User-Authentication-HOWTO/

http://www.linuxcertif.com/man/5/libnss-ldap.conf/

http://debian.securedservers.com/kernel/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html

http://www.tldp.org/HOWTO/SMB-HOWTO.html

https://wiki.samba.org/index.php/Samba4/Winbind

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/install.html

http://www.ccs.neu.edu/home/battista/articles/winbind/index.html

http://www.samba.org/samba/docs/man/Samba-Guide/simple.html

http://communities.vmware.com/thread/298545

http://www.thegeekstuff.com/2010/09/sudo-command-examples/

http://serverfault.com/questions/444219/troubleshooting-sudoers-via-ldap

http://www.aeronetworks.ca/howtos/LinuxActiveDirectory.html

http://users.telenet.be/mydotcom/howto/linuxsbs/samba4.htm

https://help.ubuntu.com/8.04/serverguide/NTP.html

https://help.ubuntu.com/community/Samba/Kerberos

## PAM LDAP Authentication against Active Directory on Debian
Tutorial: PAM LDAP Authentication against Active Directory on Debian/Ubuntu
https://www.readability.com/articles/gme6ilxg

Using the LDAP plugin available for PAM, it’s possible to do LDAP authentication without joining the domain.

Note however that this requires installing Identity Management for Unix on your domain controllers.

Before we proceed, it’s a good idea to take a snapshot. I’ll wait for you to do that.

Okay, let’s install the required packages:
  apt-get install libnss-ldapd libpam-ldapd

Now edit /etc/nslcd.conf.
This assumes the user you created for binding to AD is named “ldap”.

# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.
# The user and group nslcd should run as.
uid nslcd
gid nslcd
# The location at which the LDAP server(s) should be reachable.
uri ldap://teamN.isucdc.com
# The search base that will be used for all queries.
base dc=teamN,dc=isucdc,dc=com
# The LDAP protocol version to use.
ldap_version 3
# The DN to bind with for normal lookups.
binddn ldap@teamN.isucdc.com
bindpw <password>
# The DN used for password modifications by root.
# Leave this blank unless you want to allow password changes from your debian systems
# If so, you will need to place the password in /etc/ldap.secret - be sure it is only readable by root
#rootpwmoddn cn=admin,dc=example,dc=com
# The search scope.
scope sub
# Mappings for Active Directory
# This is the important bit; these fields match up with the fields added by Directory Services for UNIX
pagesize 1000
#referrals no
filter passwd (&(&(objectClass=person)(uidNumber=*))(unixHomeDirectory=*))
map    passwd uid              sAMAccountName
map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos            displayName
# If you wish to override the shell given by LDAP, uncomment the next line
#map    passwd loginShell       "/bin/bash"
filter shadow (&(&(objectClass=person)(uidNumber=*))(unixHomeDirectory=*))
map    shadow uid              sAMAccountName
map    shadow shadowLastChange pwdLastSet
filter group  (&(objectClass=group)(gidNumber=*))
#map    group  gid              member
# SSL options
tls_reqcert never
#ssl start_tls
#ssl on
#tls_cacertfile /etc/ssl/ca.pem


After you edit this file, restart nslcd and nscd:

  service nslcd restart
  service nscd restart

Now edit /etc/nsswitch.conf:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd:         files ldap
group:          files ldap
shadow:         files ldap
hosts:          files dns ldap
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis

Make sure LDAP authentication is enabled by running
  pam-auth-update

In /etc/pam.d/common-session, add the following at the bottom of the file. This will make home directories for users that have never logged in before. Be careful – mis-editing PAM configuration could permanently lock you out of your system!

Take a snapshot before proceeding.

# make home directories
  session required   pam_mkhomedir.so skel=/etc/skel/ umask=0077

This umask will prevent users from reading each others’ home directories. If you’d prefer to be more open, use umask=0022 instead.

You can test this out by restarting sshd (service ssh restart) or by rebooting. If you managed to accidentally completely lock yourself out, revert to that snapshot you took earlier.
	How do I authenticate against Active Directory Using SAMBA/WINBIND?



	How do I authenticate against Active Directory (AD) ?



	There are a lot of ways to do this. How Do I Integrate Bright With Active Directory using the native AD provider of SSSD? (/faq/index.php?action=artikel&cat=13&id=224&artlang=en) discusses a way using SSSD/AD_provider authentication with multiple RHEL servers integrated to an AD domain or forest, and is recommended for most purposes.



	A differenet way, with a single RHEL server integrated to an AD domain or forest, uses the following steps to allow a Bright Cluster to authenticate against a Windows AD Server while maintaining the user information in Bright's LDAP. These instructions were tested on Windows Server 2008 and 2012.



	1. Configure smb.conf

	Edit /etc/samba/smb.conf and fill in the Windows AD Server information (workgroup, password server, and realm) under the [global] section. In this example, bright is used as workgroup, bcm.bright.local is used as password server, and BRIGHT.LOCAL is used as an Active Directory realm. The rest of the parameters should be kept the same.



	[global]
	workgroup = bright
	password server = bcm.bright.local
	realm = BRIGHT.LOCAL
	encrypt passwords = yes
	winbind enum groups = yes
	winbind enum users = yes
	winbind use default domain = yes
	security = ADS
	debuglevel = 2
	wins support = no
	idmap uid = 10000-20000
	idmap gid = 10000-20000
	template shell = /bin/false
	winbind offline logon = false



	Tip:

	Type "net config workstation" on the command line of the Windows AD Server to get the workgroup, password server and AD realm.



	Logon Domain = workgroup

	FQDN = password server

	FQDN - Computer Name = realm


	2. Configure krb5.conf
	Edit /etc/krb5.conf and change the following sections to match the Windows AD Server Settings. Here,

	port 88 is the default port that is used for authentication in the forest level trusts (the underlying technology by which secured Active Directory communications occur)
	port 749 is the default port that is used for kadmin utilities.



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

	[libdefaults]
	default_realm = BRIGHT.LOCAL
	dns_lookup_realm = true
	dns_lookup_kdc = true
	ticket_lifetime = 24h
	forwardable = true

	[realms]
	BRIGHT.LOCAL = {
	kdc = bcm.bright.local:88
	admin_server = bcm.bright.local:749
	}

	[domain_realm]
	.bright.local = BRIGHT.LOCAL
	bright.local = BRIGHT.LOCAL



	3. Configure Authentication Method



	/etc/pam.d/system-auth-ac:
	#%PAM-1.0
	# This file is auto-generated.
	# User changes will be destroyed the next time authconfig is run.
	auth required pam_env.so
	auth sufficient pam_unix.so nullok try_first_pass
	auth requisite pam_succeed_if.so uid >= 500 quiet
	auth sufficient pam_winbind.so use_first_pass
	auth required pam_deny.so

	account required pam_unix.so broken_shadow
	account sufficient pam_succeed_if.so uid < 500 quiet
	account [default=bad success=ok user_unknown=ignore] pam_winbind.so
	account required pam_permit.so

	password requisite pam_cracklib.so try_first_pass retry=3
	password sufficient pam_unix.so nullok try_first_pass use_authtok
	password sufficient pam_winbind.so use_authtok
	password required pam_deny.so

	session optional pam_keyinit.so revoke
	session required pam_limits.so
	session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
	session required pam_unix.so

	/etc/pam.d/password-auth-ac:

	#%PAM-1.0
	# This file is auto-generated.
	# User changes will be destroyed the next time authconfig is run.
	auth required pam_env.so
	auth sufficient pam_unix.so nullok try_first_pass
	auth requisite pam_succeed_if.so uid >= 500 quiet
	auth sufficient pam_winbind.so use_first_pass
	auth required pam_deny.so

	account required pam_unix.so broken_shadow
	account sufficient pam_succeed_if.so uid < 500 quiet
	account [default=bad success=ok user_unknown=ignore] pam_winbind.so
	account required pam_permit.so

	password requisite pam_cracklib.so try_first_pass retry=3
	password sufficient pam_unix.so nullok try_first_pass use_authtok
	password sufficient pam_winbind.so use_authtok
	password required pam_deny.so

	session optional pam_keyinit.so revoke
	session required pam_limits.so
	session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid



	session required pam_unix.so



	/etc/pam.d/php

	auth sufficient pam_winbind.so

	account sufficient pam_winbind.so



	Tip:

	If you're using Red Hat based distributions, you may use "authconfig-tui" tool to autogenerate system-auth-ac and password-auth-ac, but then you'll have to check that the smb.conf still has the correct configurations.



	3. Test The Connectivity to Windows Active Directory Server

	Add an entry for the AD server "bcm.bright.local" into /etc/hosts.



	/etc/hosts:

	10.2.184.194 bcm.bright.local bright bright.local



	Run the following command, which fetches the domain Security Identifier (SID) and stores it in the local secrets.tdb:



	# net rpc getsid -S bcm.bright.local
	Storing SID S-1-5-21-547601799-235048094-3373437802 for Domain BRIGHT in secrets.tdb





	Make sure that the winbind service can start successfully



	# /etc/init.d/winbind restart

	# /etc/init.d/winbind status

	winbindd (pid 17966) is running...







	4. Join the Windows AD Domain

	# net ads join -U Administrator -S bcm.bright.local
	Enter Administrator's password:
	Using short domain name -- BRIGHT
	Joined 'AD-TEST' to dns domain 'bright.local'



	5. Verify Authentication

	a. Add user in Bright:

	# cmsh
	% user
	% add user adel
	%set password
	% commit

	b. Add user in Windows AD Server with different password.

	c. At this stage:

	* a log in attempt with the password that is stored in Bright's LDAP should be denied, and

	* a log in with the password that is stored in Windows AD Server should be allowed.



	6. Configuring Userportal Authentication Method



	Edit /etc/pam.d/php to include the following lines:

	auth sufficient pam_winbind.so

	account sufficient pam_winbind.so



	Restart the httpd service:

	# /etc/init.d/httpd restart





	Troubleshooting
	Issue
	# net rpc getsid -S bcm.bright.local
	Unable to find a suitable server for domain BRIGHT.LOCAL

	Resolution
	smb.conf and krb5.conf need to be reconfigured

	Issue
	# net join -U Administrator -S bcm.bright.local
	Enter Administrator's password:
	Failed to join domain: failed to find DC for domain BRIGHT.LOCAL
	ADS join did not work, falling back to RPC...
	Unable to find a suitable server for domain BRIGHT.LOCAL
	Unable to find a suitable server for domain BRIGHT.LOCAL

	Resolution
	samba.conf and krb5.conf need to be reconfigured

	Issue
	# net ads join -U Administrator -S bcm.bright.local
	Enter Administrator's password:
	Using short domain name -- BRIGHT
	Joined 'AD-TEST' to dns domain 'bright.local'
	kerberos_kinit_password AD-TEST$@BRIGHT.LOCAL failed: Clock skew too great

	Resolution
	Timezone between the AD server and Bright Cluster differs. Fix that.

	Issue
	# net join -U Administrator -S bcm.bright.local
	Enter Administrator's password:
	Using short domain name -- BRIGHT
	Joined 'AD-TEST' to dns domain 'bright.local'
	DNS Update for ad-test.cm.cluster failed: ERROR_DNS_GSS_ERROR
	DNS update failed!

	Resolution
	A DNS error is normal if the server is not a domain DNS server. This is because the DNS record of the server cannot be updated. This error will not block joining the AD domain. It's related to the Windows DNS Server in which the AD is registered. To test that the join was successful:

	# net ads testjoin
	Join is OK

	Issue

	# net ads join -U Administrator -S bcm.bright.local

	Enter Administrator's password:
	kinit succeeded but ads_sasl_spnego_krb5_bind failed: Server not found in Kerberos database
	Failed to join domain: failed to connect to AD: Server not found in Kerberos database

	Resolution

	re-issue "net rpc getsid -S bright.bcm.local"
	1. Install the neccessary dependancies

	# yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir sudo

	This will install:
	- authconfig which we will use to setup the configuration file basics, there may be parts missing or not quite accurate here, so some of the files seem to need a little massaging to work right later.
	- krb5-workstation which installs required libraries and binaries to perform authentication against active directory using the kerberos protocol
	- pam_krb5 this package provides libraries for PAM (Pluggable Authentication Modules) to interface with kerberos
	- samba-common will installed the required libraries and binaries to join the linux box to the domain so domain accounts are trusted by the local machine
	- oddjob-mkhomedir this package is used to automatically create home directories when your AD users log into the server the first time
	- sudo will be used to configure which AD users have permission to perform elevated operations on the linux computer.



	2. Run authconfig to setup the initial authentication configuration

	# authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup={AD DOMAIN NAME(short version all caps)} --smbrealm={AD DOMAIN NAME(long version all caps)} --enablewinbindusedefaultdomain --winbindtemplatehomedir=/home/{AD DOMAIN NAME(short version all lower case)}/%U --winbindtemplateshell=/bin/bash --enablekrb5 --krb5realm={AD DOMAIN NAME(long version all caps)} --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall

	This will create the initial configuration files to setup samba and kerberos. Next we will update the initial files to make sure they are correct.



	3. Verify that your /etc/krb5.conf file looks like this

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

	[libdefaults]
	default_realm = STF.NUS.EDU.SG
	dns_lookup_realm = true
	dns_lookup_kdc = true
	ticket_lifetime = 24h
	renew_lifetime = 7d
	forwardable = true

	[realms]
	STF.NUS.EDU.SG = {
	admin_server = dc01.stf.nus.edu.sg
	kdc_server = dc01.stf.nus.edu.sg
	}

	[domain_realm]
	stf.nus.edu.sg = STF.NUS.EDU.SG
	.stf.nus.edu.sg = STF.NUS.EDU.SG



	4. Test that domain authentication via kerberos is working
	# kinit user_name@STF.NUS.EDU.SG
	# klist
	You should be returned to a prompt with no output if authentication works correctly. If you receive an error at this point, stop and resolve the error. If you do get an error, it will be something related to the krb5.conf file and the active directory setup. Compare all of your configuration directives and try it again until you can authenticate against AD with this command.



	5. Join the linux box to the AD Domain

	Note: Make sure your linux box host name is "host_name.domain.com" format before you join the domain

	# net ads join {AD DOMAIN NAME(long version all lower case)} -U {ad user authorized to join computers to domain}

	Example:
	# net ads join stf.nus.edu.sg -U {USER_NAME all caps)}

	You can then test that the join succeeded if you have any doubts using

	# net ads testjoin

	That command will reply with a good indicator if your all good to go.

	This step is reliant on /etc/sama/smb.conf configuration file. If you have problems here, that would be a good place to start troubleshooting the issue.



	6. Setup a home folder to store active directory user accounts

	# mkdir /home/{ad domain short name.xxx}
	# chmod 777 /home/{ad domain short name.xxx}/

	Now when your AD users log into this box, a home directory will be created for them automatically in this location.



	7. Update your /etc/pam.d/sshd

	Change the "password-auth" module to "system-auth" module for all 4 pam activities.

	vim /etc/pam.d/sshd

	#%PAM-1.0
	auth required pam_sepermit.so
	auth include system-auth
	account required pam_nologin.so
	account include system-auth
	password include system-auth
	# pam_selinux.so close should be the first session rule
	session required pam_selinux.so close
	session required pam_loginuid.so
	# pam_selinux.so open should only be followed by sessions to be executed in the user context
	session required pam_selinux.so open env_params
	session optional pam_keyinit.so force revoke
	session include system-auth



	8. Update your /etc/pam.d/system-auth

	Add "account requisite pam_succeed_if.so user = AD_user_name debug" to the file to ONLY allow "AD_user_name" to ssh login.

	If you want ONLY AD_group to ssh login, please add "account [default=bad success=ignore] pam_succeed_if.so user ingroup linuxusers quiet" instead.

	vim /etc/pam.d/system-auth

	#%PAM-1.0
	# This file is auto-generated.
	# User changes will be destroyed the next time authconfig is run.
	auth required pam_env.so
	auth sufficient pam_fprintd.so
	auth sufficient pam_unix.so nullok try_first_pass
	auth requisite pam_succeed_if.so uid >= 500 quiet
	auth sufficient pam_krb5.so use_first_pass
	auth sufficient pam_winbind.so use_first_pass
	auth required pam_deny.so

	account required pam_access.so
	account required pam_unix.so broken_shadow
	account sufficient pam_localuser.so
	account requisite pam_succeed_if.so user = AD_user_name debug
	account sufficient pam_succeed_if.so uid < 500 quiet
	account [default=bad success=ok user_unknown=ignore] pam_krb5.so
	account [default=bad success=ok user_unknown=ignore] pam_winbind.so
	account required pam_permit.so

	password requisite pam_cracklib.so try_first_pass retry=3 type=
	password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
	password sufficient pam_krb5.so use_authtok
	password sufficient pam_winbind.so use_authtok
	password required pam_deny.so

	session optional pam_keyinit.so revoke
	session required pam_limits.so
	session optional pam_oddjob_mkhomedir.so
	session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
	session required pam_unix.so
	session optional pam_krb5.so



	9. Add the AD_user_name or AD_user_group to /etc/sudoers

	# echo '%AD_group ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

	This will allow your users who are part of the active directory group 'AD_group' to perform elevated tasks on the server via sudo. The NOPASSWD can be replaced with ALL which will cause the server to ask the user again for their password. More secure, but if you're box is secured in other ways (as mine are) I find this to be more annoying than anything else...

	On a side note, linux does not like spaces in the group names, so I've found that adding Domain Admins to this area doesn't work well, nor using that in PAM. honetsly though, it doesn't work at all.... So if you want to use a default m$ group, replace the space in the group name with an underscore or get rid of it all together in Active Directory.



	10. Make sure required services are set to start on boot

	# chkconfig oddjobd on
	# chkconfig winbind on
	# chkconfig messagebus on



	11. Reboot the linux box and you should be ready to start authenticating your active directory users.

	# init 6

	In all honesty you don't have to reboot, you can simply start/restart the services you just turned on in step 9, but it's nice to know that the next time the power goes out and your server restarts everything will come up just fine... ;-)



	Reference
	http://community.spiceworks.com/how_to/show/44885-setup-centos-to-authenticate-via-active-directory
	http://kb.kaminskiengineering.com/node/58
	http://serverfault.com/questions/483643/linux-pam-pam-succeed-if-so
	After you identify this system, the next best thing to do is create a DNS entry pointing to your PDC Server. This way if you ever need to decommission your current PDC server, you can just change the DNS record and not have to go back to all your Linux systems to update the system they authenticate to.

	From here, everything you’re going to do, aside from creating new AD users and security groups, will all be done at the Linux command line. There’s a couple of conf files that we need to configure after installing some software on each of the systems. In one of my future blog posts, I’m (hopefully) going to be going over using Chef to distribute configuration files <http://wiki.opscode.com/pages/viewpage.action?pageId=7274862>.

	This whole process isnt all that difficult as long as you have a decent understanding of the services and subsystems that you’re relying on. Here they are:

	Pluggable Authentication Modules (PAM)
	Server Message Block (SMB, Samba)
	WinBIND (part of Samba)
	Kerberos 5 (By MIT, with Microsoft compatibility hacks)

	SO, lets get some software installed. Below is the EXACT command line that I used on my Ubuntu servers (10.04).

	sudo apt-get install krb5-user libkrb53 krb5-config winbind samba ntp ntpdate nss-updatedb libnss-db libpam-ccreds libnss-ldap ldap-utils

	After installing that software, you’ll want to stop all the services while you configure them:

	sudo /etc/init.d/samba stop
	sudo /etc/init.d/winbind stop
	sudo /etc/init.d/ntp-server stop

	Each server in a Kerberos authentication realm must be assigned a Fully Qualified Domain Name (FQDN) that is both forward- and reverse-resolvable.

	Note: Active Directory depends heavily on DNS, so it is likely that the Active Directory Domain Controller is also running the Microsoft DNS server package. If this is the case, verify that each server has a FQDN assigned to it before performing the tests outlined in this section.

	If the server already has an FQDN assigned to it, test forward and reverse look-up with the following commands:

	nslookup server.example.com
	nslookup (ip address of server) 10.1.1.5

	The output of the first command should contain the IP address of the server. The output of the second command should contain the FQDN of the server. If this is not the case, Kerberos authentication will not function properly. Next, we’ll be configuring the Kerberos Config file which is located here: /etc/krb5.conf Here’s what mine looks like (Make sure to read the comments I put in there):

	[libdefaults]
	default_realm = ERDMANOR.COM #Kerberos is CASE sensitive; this must be all UPPERCASE!
	[logging]
	default = FILE:/var/log/krb5.log
	kdc = FILE:/var/log/krb5kdc.log
	[realms]
	MYDOMAIN.COM = { # MUST BE ALL CAPS ON THIS LINE!
	kdc = kerberos.mydomain.com:88 #You really only need 1 kerberos domain controller
	kdc = kerberos2.mydomain.com:88 #but in my network there are three, so I listed
	kdc = kerberos3.mydomain.com:88 #all of them in here.
	admin_server = kerberos.mydomain.com #This should be set to the DC that holds the PDC Role
	default_domain = mydomain.com #
	}

	[login]
	krb4_convert = true
	krb4_get_tickets = false

	#

	Active Directory, for as long as I can remember, is time sensitive to about +/- 5 minutes. You can adjust that window to anything you want by editing your Domain Policies (Group Policies (GPOs)), but there’s no need to really do that. Anything outside that window of time and your Domain Controllers will deny any kerberos ticket requests. This is why you need to make sure and setup your NTP daemon to point at your domain controller. I recommend setting it up with a DNS name, but you can get by with an IP address. Reason is, if the PDC ever changes, you dont need to go back to all your old machines and update conf files. Run this command: “sudo nano /etc/ntp.conf”

	# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

	driftfile /var/lib/ntp/ntp.drift
	statistics loopstats peerstats clockstats
	filegen loopstats file loopstats type day enable
	filegen peerstats file peerstats type day enable
	filegen clockstats file clockstats type day enable

	# Specify one or more NTP servers.

	server kerberos.mydomain.com #insert your PDC here
	server kerberos2.mydomain.com #secondary DC
	server kerberos3.mydomain.com #third DC
	server 1.ubuntu.pool.ntp.org #fall back to Ubuntu's NTP
	server 2.ubuntu.pool.ntp.org #
	server 3.ubuntu.pool.ntp.org #

	#

	So, we’re on our way here. Without saying, you’re probably getting a DHCP address from a Domain Controller if you’re already on a Windows network. If you’re setting up a server with a Static address, then make sure to setup your DNS nameservers in your /etc/resolv.conf file so that you’re getting DNS from your PDC and any other Domain Controllers which host DNS. I DONT recommend using your “/etc/hosts” file for this.

	So lets get to testing! From the command line issue this command:

	kinit -p username@MYDOMAIN.COM
	#obviously changing to your username and domain name on your network.
	#Notice the UPPERCASE spelling of MYDOMAIN.COM?
	#

	After that command is entered you should be getting prompted for your DOMAIN password. From here just make sure that you’re not getting any errors (which you shouldn’t). If you’re looking to verify that you have a valid ticket, then issue this command:

	Now that we have Kerberos and NTP working properly, we can move onto the next portion of authentication: PAM. If you dont know anything about PAM then you can safely move on to the configuration portion of this part. But for those of you wanting more of an understanding, here you go. I got this information from http://www.tldp.org/HOWTO/html_single/User-Authentication-HOWTO/, and it’s VERY good info. Also, verify that your “/etc/skel/” directory is setup properly. You can get creative with this and have some pretty neat options rolled out to all your users if you prefer.

	#I took out all the #comments for this blog, but I HIGHLY recommend that you leave them in!

	so here are what my PAM modules look like in /etc/pam.d/:

	common-account:
	# /etc/pam.d/common-account - authorization settings common to all services
	session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 #VERY IMPORTANT!
	account [success=3 new_authtok_reqd=done default=ignore] pam_unix.so
	account [success=2 new_authtok_reqd=done default=ignore] pam_winbind.so
	account [success=1 default=ignore] pam_ldap.so
	account requisite pam_deny.so
	account required pam_permit.so
	account required pam_krb5.so minimum_uid=1000
	#

	common-auth:
	# /etc/pam.d/common-auth - authentication settings common to all services
	# here are the per-package modules (the "Primary" block)
	session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
	auth [success=6 default=ignore] pam_krb5.so minimum_uid=1000
	auth [success=5 default=ignore] pam_unix.so nullok_secure try_first_pass
	auth [success=4 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
	auth [success=3 default=ignore] pam_ldap.so use_first_pass
	auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
	auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update
	auth requisite pam_deny.so
	auth required pam_permit.so
	auth optional pam_ccreds.so minimum_uid=1000 action=store
	auth optional pam_mount.so
	auth optional pam_cap.so
	#

	common-password:
	# /etc/pam.d/common-password - password-related modules common to all services
	password [success=4 default=ignore] pam_krb5.so minimum_uid=1000
	password [success=3 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
	password [success=2 default=ignore] pam_winbind.so use_authtok try_first_pass
	password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
	password requisite pam_deny.so
	password required pam_permit.so
	password optional pam_gnome_keyring.so
	#

	common-session
	# /etc/pam.d/common-session - session-related modules common to all services
	session [default=1] pam_permit.so
	session requisite pam_deny.so
	session required pam_permit.so
	session optional pam_umask.so
	session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
	session optional pam_krb5.so minimum_uid=1000
	session required pam_unix.so
	session optional pam_winbind.so
	session optional pam_mount.so
	session optional pam_ldap.so
	session optional pam_ck_connector.so nox11
	#

	common-session-noninteractive
	# /etc/pam.d/common-session-noninteractive - session-related modules
	# common to all non-interactive services
	session [default=1] pam_permit.so
	session requisite pam_deny.so
	session required pam_permit.so
	session optional pam_umask.so
	session optional pam_krb5.so minimum_uid=1000
	session required pam_unix.so
	session optional pam_winbind.so
	session optional pam_mount.so
	session optional pam_ldap.so
	#

	This should be everything you need for PAM to work properly. Now we need to work on Samba. The Samba config is stored at “/etc/samba/smb.conf”. Again, I stripped my Samba config down and made a backup of the original. I dont want my end users sharing data between themselves, I want them using corporate file shares where I know that the data is backed up. Also, I want them using Print Servers, not hosting printers from their machines. So this smb.conf is pretty short compared to the original. If you visit the Samba website, you’ll even see that they want people to keep this file short and simple. According to the Samba Team, the longer this file is, the more it impacts performance of the system. Please heed the warnings in your smb.conf as well as the notes I post below:

	# NOTE: Whenever you modify this file you should run the command
	# "testparm" to check that you have not made any basic syntactic
	# errors.
	#
	#======================= Global Settings =======================

	[global]

	security = ads
	realm = MYDOMAIN.COM #Must be UPPER case
	password server = kerberos.mydomain.com #PDC that we mentioned earlier
	workgroup = MYDOMAIN #This is the NetBIOS name of your Domain
	idmap uid = 10000-20000
	idmap gid = 10000-20000
	winbind enum users = yes
	winbind enum groups = yes
	template homedir = /home/MYDOMAIN/%U #Dont forget to update this directory!
	template shell = /bin/bash #You can use whatever shell you'd like
	client use spnego = yes
	client ntlmv2 auth = yes
	encrypt passwords = yes
	winbind use default domain = yes
	restrict anonymous = 2

	server string = %h server (Samba, Ubuntu)
	dns proxy = no
	log file = /var/log/samba/log.%m
	max log size = 1000
	syslog only = yes
	syslog = 4
	panic action = /usr/share/samba/panic-action %d
	encrypt passwords = true
	passdb backend = tdbsam
	obey pam restrictions = yes
	unix password sync = yes
	passwd program = /usr/bin/passwd %u
	passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n password\supdated\ssuccessfully .
	pam password change = yes
	map to guest = bad user
	domain logons = no #Extremely important that this is NO.
	usershare allow guests = yes

	Next we’ll be setting up the “/etc/nsswitch.conf” file. This file does a few things to help communications with your LDAP server (AD in this case) as well as tell your local Linux system where to look for password information.

	When fiddling with /etc/nsswitch.conf, it is best to turn the Name Services Caching Daemon off or you will be confused by cached results. Turn it on afterwards.

	Now edit the nsswitch.conf file:

	# /etc/nsswitch.conf
	passwd: files winbind
	group: files winbind
	shadow: compat
	hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
	networks: files
	protocols: db files
	services: db files
	ethers: db files
	rpc: db files
	netgroup: nis
	#

	And Turn back on your service:

	Assuming that all goes well and Kerberos, Winbind and Samba are setup properly, you should be able to join your linux system to the domain. Due to restrictions in the NetBIOS protocol, the hostname must contain no more than 15 characters. If you see a STATUS_BUFFER_OVERFLOW message in the winbind log, odds are the hostname is invalid. Now would also be a good time to clear whatever cache files, if any, Winbind had previously generated. The Winbind cache is located in /var/lib/samba/. Backup this directory to /var/lib/samba.bak/ and delete all the files in the original. Now you can issue this command:

	sudo net ads join -S MYDOMAIN.COM -U {domain-admin-user}

	Couple things here.
	First, you may need to change MYDOMAIN.COM to KERBEROS.MYDOMAIN.COM. If it doesn’t work the first way, try the next. Second is, {domain-admin-user} MUST be a Domain Admin account in Active Directory. Otherwise you’ll fail.

	Now, I’ve gotten mixed results here… My Mint 12 and 13 boxes joined and I actually got a “Domain Joined!” message in the shell.

	My Debian 6 machine threw an error:

	steve @ mintdebianvm ~ :) ᛤ> sudo net ads join -S ERDMANOR.COM -U administrator
	[sudo] password for steve:
	Enter administrator's password:
	kinit succeeded but ads_sasl_spnego_krb5_bind failed: Server not found in Kerberos database
	Failed to join domain: failed to connect to AD: Server not found in Kerberos database

	I haven’t had much time to look into why this is happening, but I can assure you the system joined the domain, the computer account was created in AD and I’m able to SSH to this machine with domain creds… If anyone knows why this is happening, PLEASE contact me! Thanks!

	Look up Windows Ports needed for Active Directory. Need Microsoft Link!
	After your join to the domain is successfull, you can startup your services:

	sudo /etc/init.d/samba start
	sudo /etc/init.d/winbind start

	From this point, you should be able to test some querys against the domain:

	getent passwd
	getent shadow
	getent group

	At this point, you should be able to resolve users and groups from the Windows Active Directory domain using getent passwd and getent group. If these commands don’t display your Windows accounts, try to resolve them using wbinfo -u and wbinfo -g. These commands query the Winbind service directly, bypassing the name service switch. If you can resolve users and groups with wbinfo, go back and make sure you configured /etc/nsswitch.conf properly.

	Now with EVERYTHING setup properly, you should be able to fire up an SSH session to your linux box and log in with AD Credentals. BUT! Your Domain Users are NOT going to be able to “sudo” any commands. For the sake of security, you dont want ALL your domain users to be able to sudo commands, so what I did is create a domain security group, mine is named “linux-sudo”. Then I added in only the users I want to be able to sudo commands to that group. Then I edited my “sudoers” file to include the domain security group “linux-sudo”. So make sure to edit your “/etc/sudoers” file, and add this line:

	%linux-sudo ALL=(ALL:ALL) ALL

	Now, I’m able to log into my Debian, Mint and Ubuntu Linux systems with Domain Credentials! :)

	EDIT: In looking for information regarding this entire process on a RED HAT system. (RHEL 5 or 6), please refer to this guide:

	http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/jcr:system/jcr:versionStorage/ae40084d0a052601783f1ea42715cdef/9/jcr:frozenNode/rh:resourceFile


	Here are all the sites that I used in the making of this blog:


	http://wiki.samba.org/index.php/Samba_%26_Active_Directory#Setting_up_PAM_Authentication_for_Active_Directory

	https://help.ubuntu.com/community/ADAuthentication

	https://help.ubuntu.com/community/Kerberos

	https://help.ubuntu.com/community/PamCcredsHowto

	https://help.ubuntu.com/community/ActiveDirectoryHowto

	https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto

	http://www.tldp.org/HOWTO/html_single/User-Authentication-HOWTO/

	http://www.linuxcertif.com/man/5/libnss-ldap.conf/

	http://debian.securedservers.com/kernel/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html

	http://www.tldp.org/HOWTO/SMB-HOWTO.html

	https://wiki.samba.org/index.php/Samba4/Winbind

	http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/install.html

	http://www.ccs.neu.edu/home/battista/articles/winbind/index.html

	http://www.samba.org/samba/docs/man/Samba-Guide/simple.html

	http://communities.vmware.com/thread/298545

	http://www.thegeekstuff.com/2010/09/sudo-command-examples/

	http://serverfault.com/questions/444219/troubleshooting-sudoers-via-ldap

	http://www.aeronetworks.ca/howtos/LinuxActiveDirectory.html

	http://users.telenet.be/mydotcom/howto/linuxsbs/samba4.htm

	https://help.ubuntu.com/8.04/serverguide/NTP.html

	https://help.ubuntu.com/community/Samba/Kerberos
	Tutorial: PAM LDAP Authentication against Active Directory on Debian/Ubuntu
	https://www.readability.com/articles/gme6ilxg

	Using the LDAP plugin available for PAM, it’s possible to do LDAP authentication without joining the domain.

	Note however that this requires installing Identity Management for Unix on your domain controllers.

	Before we proceed, it’s a good idea to take a snapshot. I’ll wait for you to do that.

	Okay, let’s install the required packages:
	apt-get install libnss-ldapd libpam-ldapd

	Now edit /etc/nslcd.conf.
	This assumes the user you created for binding to AD is named “ldap”.

	# /etc/nslcd.conf
	# nslcd configuration file. See nslcd.conf(5)
	# for details.
	# The user and group nslcd should run as.
	uid nslcd
	gid nslcd
	# The location at which the LDAP server(s) should be reachable.
	uri ldap://teamN.isucdc.com
	# The search base that will be used for all queries.
	base dc=teamN,dc=isucdc,dc=com
	# The LDAP protocol version to use.
	ldap_version 3
	# The DN to bind with for normal lookups.
	binddn ldap@teamN.isucdc.com
	bindpw <password>
	# The DN used for password modifications by root.
	# Leave this blank unless you want to allow password changes from your debian systems
	# If so, you will need to place the password in /etc/ldap.secret - be sure it is only readable by root
	#rootpwmoddn cn=admin,dc=example,dc=com
	# The search scope.
	scope sub
	# Mappings for Active Directory
	# This is the important bit; these fields match up with the fields added by Directory Services for UNIX
	pagesize 1000
	#referrals no
	filter passwd (&(&(objectClass=person)(uidNumber=))(unixHomeDirectory=))
	map passwd uid sAMAccountName
	map passwd homeDirectory unixHomeDirectory
	map passwd gecos displayName
	# If you wish to override the shell given by LDAP, uncomment the next line
	#map passwd loginShell "/bin/bash"
	filter shadow (&(&(objectClass=person)(uidNumber=))(unixHomeDirectory=))
	map shadow uid sAMAccountName
	map shadow shadowLastChange pwdLastSet
	filter group (&(objectClass=group)(gidNumber=*))
	#map group gid member
	# SSL options
	tls_reqcert never
	#ssl start_tls
	#ssl on
	#tls_cacertfile /etc/ssl/ca.pem


	After you edit this file, restart nslcd and nscd:

	service nslcd restart
	service nscd restart

	Now edit /etc/nsswitch.conf:

	# /etc/nsswitch.conf
	#
	# Example configuration of GNU Name Service Switch functionality.
	# If you have the `glibc-doc-reference' and `info' packages installed, try:
	# `info libc "Name Service Switch"' for information about this file.
	passwd: files ldap
	group: files ldap
	shadow: files ldap
	hosts: files dns ldap
	networks: files
	protocols: db files
	services: db files
	ethers: db files
	rpc: db files
	netgroup: nis

	Make sure LDAP authentication is enabled by running
	pam-auth-update

	In /etc/pam.d/common-session, add the following at the bottom of the file. This will make home directories for users that have never logged in before. Be careful – mis-editing PAM configuration could permanently lock you out of your system!

	Take a snapshot before proceeding.

	# make home directories
	session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

	This umask will prevent users from reading each others’ home directories. If you’d prefer to be more open, use umask=0022 instead.

	You can test this out by restarting sshd (service ssh restart) or by rebooting. If you managed to accidentally completely lock yourself out, revert to that snapshot you took earlier.