Authentication is easily one of the most critical services provided by your network infrastructure. It is the gatekeeper for every resource on your network. Workstations, applications, printers, and files would all be open to the world without a system of ensuring that only those people who need any given resource can gain access to it. Once you have accepted the fact that you need authentication, you must decide whether to stay with one network operating system in the interest of a completely homogenous network, or accept a "best of breed" system that will better fulfill your needs, even though it will complicate your environment. If you choose the second option, often times you are left with a management nightmare, where you have two, three, or even more authentication engines to maintain across your network operating systems.
One way of simplifying your authentication environment is to use a single authentication source for all of your nodes -- Windows, Linux, or Unix. You can authenticate them all against a directory service such as Active Directory or eDirectory. In this article, we'll describe how to unify your Linux and Active Directory environments. With minor changes, this same procedure can be used to authenticate your Linux hosts against eDirectory or any other LDAP compliant directory service.
For the purposes of this article, we have used Fedora Core 1 as a Linux operating system, Windows Server 2003 (in native mode) as the Active Directory Controller, and Microsoft's Services for Unix 3.5 to simplify the extension of the schema. Your Windows 2003 server should be installed as an Active Directory Controller, and your Fedora device can be just a basic installation with the OpenLDAP client tools and libraries. You'll also need updated NSS_LDAP software; the NSS_LDAP software included in the release has a bug that disables schema mapping.
In this section, we are going to perform the procedures on the Windows device that are a prerequisite to the use of AD to authenticate Linux against Active Directory. These tasks include the installation of Services for Unix, which will perform a schema extension for us.
CN=Users,DC=LanRx,DC=com Or CN=Users,DC=LanRxDomain,DC=LanRx,DC=com
c:\temp\sfu\setup.exeto install the Services for Unix software -Accept the standard installation -Where prompted for "security settings", leave both boxes blank -Where prompted for "username mapping" select "Local Username Mapping Server" and subsequently "Network Information Services" -Select the Windows Domain Name -Reboot server when complete
Next, we configure the Linux workstation to perform a pure LDAP
authentication against the Active Directory controller. We first install the
software to permit us to perform schema mapping, then authenticate as superuser.
Next, we run
rpm -Uvh nss_ldap-207-6.i386.rpm to install the new
NSS_LDAP package (or upgrade if it was already installed). Now we configure the
LDAP client on the Linux device to map the POSIX information to point to the
domain controller to collect the appropriate attributes within Active Directory:
mv /etc/ldap.conf /etc/ldap.origto backup your existing /etc/ldap.conf file.
vi /etc/ldap.confto create your ldap.conf file.
host 192.168.100.18 base cn=Users,dc=lanrx,dc=com binddn cn=dirsearch,cn=Users, dc=lanrx,dc=com bindpw D1rectory scope sub ssl no nss_base_passwd cn=Users,dc=lanrx,dc=com?sub nss_base_shadow cn=Users,dc=lanrx,dc=com?sub nss_base_group cn=Users,dc=lanrx,dc=com?sub nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute uniqueMember msSFU30PosixMember nss_map_attribute cn cn pam_login_attribute sAMAccountName pam_filter objectclass=user pam_member_attribute msSFU30PosixMember pam_groupdn cn=unixusergroup,dc=lanrx,dc=com pam_password ad
Above, notice the line for pam_groupdn. It specifies that any user to gain access to this server needs to be a posixMember of this particular user group. Upon successful authentication, the system will verify that the authenticated user is a member of the appropriate group. If the user is a member, authentication will occur. If the user is not a member, the system will notify the user that he needs to be a member of the specified group to authenticate entirely.
vi /etc/nsswitch.confto edit the nsswitch configuration file. Ensure that the following lines are configured as follows:
shadow: files ldap
passwd: files ldap
group: files ldap
authconfigto perform the configuration of "Pluggable Authentication." Note: To the best of my knowledge,
authconfigis specific to Red Hat Linux distributions. For a sample system-auth configuration file, please see the example configuration file package associated with the article.
accountcomponents. Note: This line provides us with the ability to authenticate locally as superuser in the event of a network failure.
account sufficient /lib/security/pam_localuser.so
As is the case with any other authentication mechanism, we need to configure the user objects for the users that are to use the system. However, if you are implementing this solution, more than likely your users already have Windows accounts. In that case, all we need to do is to modify the objects to be POSIX compliant.
At this point, you should have been able to provide authentication for your user objects against an Active Directory. If you would like example configuration files, you can reach them online with this article. Our intention was to help you find your way in Active Directory authentication. This by no means is a solution for everybody. For instance, many organizations will want to perform all LDAP communication over SSL/TLS, which adds a touch of complexity to your implementation due to some limitations on different software packages. If you experience issues pertaining to your implementation, you are welcome to visit our forums with questions.
Eric Anderson is a partner and solution architect for LanRx, which specializes in open source solutions and open source integration with commercial software.
[ top ]