nk23x
10/29/2014 - 1:15 PM
Active Directory Integration
Active Directory Integration
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"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.
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/Kerberos1. 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