Skip to main content

Oracle Linux 7 authentication to Active Directory


I've been curious from some time to see how Active Directory users could natively authenticate to Linux, or said in a different way, how to configure Linux to allow AD users to log in without the need to have those users in each and every Linux box manually.
Although there are several different ways to accomplish this, I found that the easiest and less time consuming way to do it is with the use of Samba WinBind. Later I will show how to use Oracle Internet Directory (OID) to accomplish the same feat.
Using an IdM solution (AD, OID) can help to reduce the time to deploy users, you can centrally manage access to linux servers from Active Directory Users and Computers (ADUC) app, and can allow administrative tasks thru sudo depending on the group the users belong to.
For my Proof of Concept I created two virtual machines, one with Windows 2012 Server Essentials, and another one with Oracle Linux 7.1.
In AD I created 1 group named osd-linux-oretail, and several test users, of which some belong to this group.
The Oracle Linux VM is a basic server installation + GUI, nothing fancy or elaborate. I tried to keep it to a minimum so I could control what I needed to have installed for this to work.

Installing Prerequisites

The following linux packages are needed to enable Oracle Linux to authenticate user to Windows AD.
  • nscd
  • pam_krb5
  • samba-winbind
  • krb5-locator
As root (sudo is okay), you can run the following commands (you can simplify into a single one)[sourcecode language="shell"]sudo yum install nscd.x86_64 pam_krb5.x86_64[/sourcecode]
[sourcecode language="shell"]sudo yum install samba-winbind.x86_64 krb5-locator.x86_64[/sourcecode]

Configure Authentication Services

Once all the packages are in place, now you need configure WinBind to connect to your AD controller. for this we use authconfig-tui command as root.
When the application is open for the first time, you’ll get some preselected options, such as below:
[sourcecode language="shell"]sudo authconfig-tui[/sourcecode]
You'll need WinBind options selected, which are needed to authenticate to AD. MD5 is indicated in the samba configuration guide as needed when connecting to ldap, I didn't check if that still holds true for Active Directory.
When you click Next, you'll be asked the AD details, such as following:
  • Domain is the AD domain name.
  • Domain controller is the host(s) that belong to this Domain.
  • ADS Realm is the Qualified Domain Name (FQDN).
You have the option to select the default shell for the AD users. Once you are done entering the details, click on Join Domain. It will ask you if you want to save the settings, you can confirm/hit yes.
Now you have to type in the privileged/administrative user and password to let the linux box join the domain.
You'll be challenged again with the domain password.
You can now close the application. If everything went fine, you'll see something like this:
Now you can test an AD user can indeed connect to Linux.
You may have noticed that I had to use the domain name when I logged in
(in the format user@domain), I really don't like that, so I updated smb.conf with the changes listed below.
Update smb.conf global section to tell winbind where to create the users' home directory, if it should user the default domain - which in turn will enable you to not need to specify the domain name at the time of log in, and other parameters
[sourcecode language="plain"][global]
#Generated by authconfig on 2015/08/12 16:29:41
#DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--)
#Any modification may be deleted or altered by authconfig in future
workgroup = OSDTST
password server = osdtstad
security = ads
idmap config * : range = 16777216-33554431
template shell = /bin/bash
kerberos method = secrets only
winbind use default domain = false
winbind offline logon = false
template homedir = /home/%D/%U
client use spnego = yes
client ntlmv2 auth = yes
encrypt passwords = yes
winbind use default domain = yes
restrict anonymous = 2

Enable linux to autocreate home directory for new users

The other thing that you may have noticed, is that after logging in, it complains that it couldn't create the home directory. You have the option to manually create the home directories for the users, but I rather prefer to let windbind/linux to automatically create the home directory when the user logs in the first time. To enable this, you'll need to run the following command as root:
[sourcecode language="shell"]authconfig --enablemkhomedir --update[/sourcecode]
After this, when the user logs in for the first time, the home directory will be automatically created.

Restricting/Granting access to active directory users

Now the last step of this POC is to grant or restrict access to users based on an AD group. For this test I created two users, test01 and 02 (very original), test01 belongs to osd-linux-oretail, test02 does not. My test is very simple, I will grant the group osd-linux-oretail users to be able to sudo to any user and execute any command the want. For this I simply add the following line to the sudoers file (remember to use visudo for this action).
[sourcecode language="plain"]## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
%osd-linux-oretail ALL=(ALL) ALL
There are plenty of guides to setup sudoers file, this is just a silly setup.
The test came out working as designed, test01 was able to sudo to root:
Whereas test02 user was unable to sudo.
The home directories were successfully created for each user:



Popular posts from this blog

RMAN-06613: Connect identifier for DB_UNIQUE_NAME not configured

I ran into an issue with a recently cloned database. Every time I ran "resync catalog from db_unique_name all;" command in RMAN, it error out with RMAN-6613: connect identifier for db_unique_name not configured. We know that this command is not needed for non-dg enabled databases, but because we have a mix of DG and non-DG enabled databases, maintaining different scripts per type of database is not worth it. To the extent of my knowledge, this command is harmless; the error is more like a warning on non-dg databases, still is a symptom of something not well configured. Troubleshooting Once you connect to the target and catalog repository with RMAN, you try to resync catalog with the following command: RMAN> resync catalog FROM DB_UNIQUE_NAME ALL; starting full resync of recovery catalog full resync complete resyncing from database with DB_UNIQUE_NAME DBTST RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE

RMAN 12c - SBT vs TAPE

I recently upgraded a database from 11g to 12c without issues, but after several days, I noticed that the archived redo logs were not being deleted from the filesystem, even after they were backed up to tape. At first I thought that there might be some issues with that specific database, but when I verified other 12c databases that uses the same backup script, I found that they were exhibiting the same behaviour. So I started the troubleshooting process by checking the RMAN configuration, nothing seemed out of the ordinary. I use the following settings: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO TAPE; CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 4 BACKUP TYPE TO BACKUPSET; CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE BACKUP OPTIMIZATION OFF; The RMAN command is this: run { backup filesperset 1 tag ‘arl_test’ archivelog all; d