Enable CentOS 5.8 GNU / Linux Authentication on Windows Domain
In case you should ever be finding yourself having to configure your CentOS 5.8 GNU/Linux machines to allow active directoy windows users to login to them, this post will help.
While there are a few ways to set this up, i.e., likewise-open (see beyondtrust.com), centrify (centrify.com), the built-in System, Authentication graphical controls in CentOS, etc., the method in this post focuses on touching just a few config files to enable active directory authentication. K.I.S.S. is the way I like to roll.
Using the authentication methods below assume that you have already enabled services for Unix on your active directory server and that the users that would be logging in to CentOS have their Unix tab (on ad user and computers) populated with values.
The Authentication methods outlined here use LDAP and Kerberos. LDAP brings the UID/GID information (from the Unix tab in ad) for the user, and Kerberos provides for username/password authentication piece.
With the default install of CentOS 5.8, it's amazingly simple to setup authentication to your active directory for Unix-enabled ad users.
Here are the steps for enabling your CentOS 5.8 GNU/Linux computer to authenticate with active directory:
1.) Create a special user in active directory (e.g., ad-guest-01). Once you've created the user, add it to the group "Domain Guests", make it the Primary group, and remove all other group memberships (e.g., Domain Users should be removed).
2.) Make changes to the following configuration files on the CentOS 5.8 GNU/Linux machine as shown below:
If you want your windows users to be able to run sudo, run visudo as root, then add:
Note: The above setting is just an example of how to add FULL CONTROL for the ad-based "Domain Users" to the sudoers file. Changes to the sudoers file can be more finely tuned to only allow certain programs. If user restriction is a concern for your situation, I suggest you research "sudoers" and find the more granular settings that are appropriate for your needs.
Speaking of security, something else to consider is that if the user can become root with sudo -s on the machine, they will then be able to su and be seen as that user as far as the local machine is concerned. You can force them to authenticate (even as root) by commenting the line below in /etc/pam/su, but if they are root - they can still change it back:
That's it. Reboot your CentOS, then you should be able to login as your windows user on the box. Feel free to leave a comment below with any suggestions or questions.
Cheers!
Shannon VanWagner
08-03-2012
While there are a few ways to set this up, i.e., likewise-open (see beyondtrust.com), centrify (centrify.com), the built-in System, Authentication graphical controls in CentOS, etc., the method in this post focuses on touching just a few config files to enable active directory authentication. K.I.S.S. is the way I like to roll.
Using the authentication methods below assume that you have already enabled services for Unix on your active directory server and that the users that would be logging in to CentOS have their Unix tab (on ad user and computers) populated with values.
The Authentication methods outlined here use LDAP and Kerberos. LDAP brings the UID/GID information (from the Unix tab in ad) for the user, and Kerberos provides for username/password authentication piece.
With the default install of CentOS 5.8, it's amazingly simple to setup authentication to your active directory for Unix-enabled ad users.
Here are the steps for enabling your CentOS 5.8 GNU/Linux computer to authenticate with active directory:
1.) Create a special user in active directory (e.g., ad-guest-01). Once you've created the user, add it to the group "Domain Guests", make it the Primary group, and remove all other group memberships (e.g., Domain Users should be removed).
2.) Make changes to the following configuration files on the CentOS 5.8 GNU/Linux machine as shown below:
############################################################## #/etc/ldap.conf for connecting with Win-Server w/SFU Enabled # ############################################################## base dc=yourcompany,dc=com uri ldap://yourADserver.yourcompany.com ldap://yourADserver.yourcompany.com/ binddn ad-guest-01@yourcompany.COM bindpwbind_policy soft scope sub pam_min_uid 1000 bind_timelimit 5 timelimit 5 idle_timeout 3600 ssl no referrals no nss_base_group dc=yourcompany,dc=com?sub?&(objectCategory=group)(gidnumber=*) nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_objectclass posixGroup group nss_map_attribute gecos cn nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute uniqueMember member nss_initgroups_ignoreusers root,ldap
############################################################## #/etc/krb5.conf for connecting with Win-Server w/SFU Enabled # ############################################################## # Tip: You can use predefined DNS names for your kerberos, #+ ldap (ad) servers to make future ad dc hostname changes #+ less painful. [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = YOURCOMPANY.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes [realms] YOURCOMPANY.COM = { kdc = yourADserver.yourcompany.com:88 kdc = yourADserver admin_server = yourADserver.yourcompany.com:749 } [domain_realm] yourcompany.com = YOURCOMPANY.COM .yourcompany.com = YOURCOMPANY.COM [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
###################################################### #/etc/nsswitch.com for Win-Server w/SFU Enabled Auth# ###################################################### passwd: files ldap shadow: files ldap group: files ldap #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files ldap publickey: nisplus automount: files ldap aliases: files nisplus
############################################################## #/etc/pam.d/system-auth-ac for Win-Server w/SFU Enabled 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_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_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow #The line below allows local user login account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account [default=bad success=ok user_unknown=ignore] pam_krb5.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so #The line below triggers creation of home-dir upon user first login session optional pam_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 session optional pam_ldap.so
If you want your windows users to be able to run sudo, run visudo as root, then add:
%Domain\ Users ALL=(ALL) ALL
Note: The above setting is just an example of how to add FULL CONTROL for the ad-based "Domain Users" to the sudoers file. Changes to the sudoers file can be more finely tuned to only allow certain programs. If user restriction is a concern for your situation, I suggest you research "sudoers" and find the more granular settings that are appropriate for your needs.
Speaking of security, something else to consider is that if the user can become root with sudo -s on the machine, they will then be able to su
vi /etc/pam.d/su
#auth sufficient pam_rootok.so
That's it. Reboot your CentOS, then you should be able to login as your windows user on the box. Feel free to leave a comment below with any suggestions or questions.
Cheers!
Shannon VanWagner
08-03-2012
Can you explain where you enter the password for ad-guest-01@yourcompany.COM, i then for generating keytab file we need to authenticate it with ad.
ReplyDelete