{"id":230,"date":"2014-03-01T07:51:33","date_gmt":"2014-03-01T07:51:33","guid":{"rendered":"https:\/\/digitalchild.info\/?p=230"},"modified":"2014-03-01T07:51:33","modified_gmt":"2014-03-01T07:51:33","slug":"active-directory-authentication-with-centos","status":"publish","type":"post","link":"https:\/\/randomadult.local\/active-directory-authentication-with-centos\/","title":{"rendered":"Active Directory Authentication with CentOS"},"content":{"rendered":"
Active directory authentication for CentOS is quite easy to configure. Active directory is a central authentication system and organisations all over the world have relied on it for years. This is super easy to set up for your Windows and Mac desktops but is sometimes\u00a0a little harder with a Linux workstation. This is all done on a CentOS 6.5 minimal install with nothing but a LAMP stack installed.<\/p>\n
There are is one step you need to take to get your machine ready for configuration. Install the following packages, if they aren’t already.<\/p>\n
\n\n# yum -y install authconfig krb5-workstation pam_krb5 samba-common oddjob-mkhomedir\n\n<\/pre>\nThis will install everything you need to get up and running. There is two ways you can configure the authentication. From the command line (authconfig) or via a console GUI (authconfig-tui). It all works just depends on which version you are comfortable with.<\/p>\n
Authconfig<\/strong><\/h3>\n
\n# authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup=DOMAIN --smbrealm=DOMAIN.COM.AU --enablewinbindusedefaultdomain --winbindtemplatehomedir=\/home\/DOMAIN\/%U --winbindtemplateshell=\/bin\/bash --enablekrb5 --krb5realm=DOMAIN.COM.AU --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall\n\n<\/pre>\nThis will setup the necessary config files for both Kerberos and Samba. There is more config files to update from here.\u00a0<\/span><\/p>\n
Please Note:\u00a0When I ran this I got an error with Oddjobd not being able to start.\u00a0You can read the details in this post<\/a>. Just\u00a0make sure\u00a0that the\u00a0messagebus<\/em><\/strong>\u00a0service is running.<\/p>\n
Kerberos (\/etc\/krb5.conf<\/strong>)\u00a0<\/em><\/p>\n
Check that the file was generated and then add the relevant realms and domain_realm<\/strong> for your domain to the file. If you have multiple domain controllers you can add extra kdc<\/strong><\/em> lines like below.<\/p>\n
\n[logging]\n default = FILE:\/var\/log\/krb5libs.log\n kdc = FILE:\/var\/log\/krb5kdc.log\n admin_server = FILE:\/var\/log\/kadmind.log\n\n[libdefaults]\n default_realm = DOMAIN.COM.AU\n dns_lookup_realm = false\n dns_lookup_kdc = false\n ticket_lifetime = 24h\n renew_lifetime = 7d\n forwardable = true\n\n[realms]\n EXAMPLE.COM = {\n kdc = kerberos.example.com\n admin_server = kerberos.example.com\n }\n\nDOMAIN.COM.AU = {\nadmin_server = domain.com.au\nkdc = dc1.domain.com.au\nkdc = dc2.domain.com.au\n}\n\n[domain_realm]\n .example.com = EXAMPLE.COM\n example.com = EXAMPLE.COM\n domain.com.au = DOMAIN.COM.AU\n .domain.com.au = DOMAIN.COM.AU\n\n<\/pre>\nSave the file and test that it works using the kinit<\/em><\/strong> command.<\/p>\n
\n\n# kinit someaduser\n\n<\/pre>\nA password prompt will be displayed, type in the active directory password for that user and it\u00a0should return to the prompt with no messages. You can then check that you have your kerberos ticket by running the klist<\/em><\/strong> command. It should output something like the following.<\/p>\n
\n\nTicket cache: FILE:\/tmp\/krb5cc_0\nDefault principal: someaduser@DOMAIN.COM.AU\n\nValid starting Expires Service principal\n02\/27\/14 12:23:21 02\/27\/14 22:23:21 krbtgt\/DOMAIN.COM.AU@DOMAIN.COM.AU\n renew until 03\/06\/14 12:23:19\n\n<\/pre>\nJoin the Domain<\/em><\/strong><\/p>\n
You’re now ready to join the machine to the domain. You can use the trusty net<\/strong><\/em> command to join the machine to the domain.<\/p>\n
\n\n# net ads join domain.com.au -U someadadmin\n\n<\/pre>\nYou can test that this worked running the following command<\/p>\n
\n\n# net ads testjoin\nJoin is OK\n\n<\/pre>\nConsole GUI<\/strong><\/h3>\n
The other option to configure AD authentication\u00a0is to use the console GUI version of authconfig. This will pop up a familiar looking interface (think console RedHat installer) that is pretty straight forward when it comes to configuration. Start the GUI tool<\/p>\n
\n\n# authconfig-tui\n\n<\/pre>\nYou will get a screen like the following, make sure that only the items checked are the same as below.<\/p>\n
<\/p>\n
User Information<\/em><\/p>\n
\n
- Use Winbind<\/li>\n<\/ul>\n
Authentication<\/em><\/p>\n
\n
- Use Shadow Passwords<\/li>\n
- Use Kerberos<\/li>\n
- Local authorization is enough<\/li>\n<\/ul>\n
Make the above selections then next and you’ll be on the kerberos settings screen<\/p>\n
<\/p>\n
Settings for this screen are as follows:<\/p>\n
Realm<\/strong>: DOMAIN.COM.AU
\nKDC<\/strong>: dc1.domain.com.au,dc2.domain.com.au
\nAdmin Server:<\/strong> domain.com.au<\/p>\nOn the next screen you will find the Winbind Settings<\/p>\n
<\/strong><\/em><\/p>\n
Settings for this screen are as follows:<\/p>\n
Security<\/strong> Model: ads
\nDomain<\/strong>: DOMAIN
\nDomain Controllers<\/strong>: dc1.domain.com.au,dc2.domain.com.au
\nADS Realm<\/strong>: DOMAIN.COM.AU
\nTemplate Shell<\/strong>: \/bin\/bash (you can change to sh if you’d like)<\/p>\nSelect Join Domain<\/strong><\/p>\n
You’ll be prompted to save the details<\/p>\n
<\/p>\n
This will overwrite any other settings you would have had configured for this machine. You will then be prompted to provide domain admin credentials.<\/p>\n
<\/p>\n
This will run the following command behind the scenes and then join you to the domain.<\/p>\n
\n\n\/usr\/bin\/net join -w DOMAIN -S dc1.domain.com.au -U Administrator\n\n<\/pre>\nNote<\/strong>: If for any reason this doesn’t work in authconfig-tui. Select OK and return to the prompt and manually run the command above.<\/p>\n
Home Directories<\/strong><\/em><\/p>\n
You don’t really need to do this step but I find it’s a nice clean way to make sure you separate domain users from your local users. Back in the authconfig step for the console configuration \u00a0you used the following switch<\/p>\n
\n--winbindtemplatehomedir=\/home\/DOMAIN\/%U --enablemkhomedir\n<\/pre>\nThese switches enabled automatic creation of home directories. For this to work with the GUI version you will need to run authconfig with those 2 switches.<\/p>\n
\n\nauthconfig --winbindtemplatehomedir=\/home\/DOMAIN\/%U --enablemkhomedir --update\n\n<\/pre>\nThis is telling oddjobd to put any new home directories at the path \/home\/yourdomain\/username. You will need to create the \/home\/yourdomain path and make sure you’ve got your permissions correct. I’ll be using ACLs as you’re able to configure much finer grain permissions. ACLs ship with pretty much all modern linux distributions these days.<\/p>\n
\n\n# mkdir \/home\/DOMAIN\n# setfacl -m group:"Domain Users":rwx \/home\/DOMAIN\n\n<\/pre>\nPlease Note<\/strong>: There is a bug in oddjobd-mkhomedir that is creating the home directory with the 755 permissions which allows group and world to read every home directory. You can read the bug on Red Hats Bugzilla<\/a>.<\/p>\n
Restrict AD Logins (Optional)\u00a0<\/strong><\/em><\/p>\n
In my environment I only want to allow the linux admins to use their AD logins to SSH to the servers I have configured. You can restrict which AD groups can login to the machine by adding the AllowGroups<\/em><\/strong> directive to the sshd_config<\/strong><\/em><\/a> and restarting sshd.<\/p>\n
\n\n# echo 'AllowGroups linuxadmins' >> \/etc\/ssh\/sshd_config\n# service sshd restart\n\n<\/pre>\nThis will echo the required groups into the sshd config and then restart the service. This will now restrict ssh logins to those specific groups. If you’d like to configure AD access to more services you will have to check elsewhere. If I find the need to do this myself I’ll update this documentation to include it.<\/p>\n","protected":false},"excerpt":{"rendered":"
Active directory authentication for CentOS is quite easy to configure. Active directory is a central authentication system and organisations all over the world have relied on it for years. This is super easy to set up for your Windows and Mac desktops but is sometimes\u00a0a little harder with a Linux …<\/p>\n