iLabs Open Source Software teams tackles cross-authentication

What looked to be an unobtrusive rack of 1U servers humming along to the InteropNet iLabs engineers’ rock music, actually represented a bit of an integration headache.

Within the line of racks that is the iLabs Open Source Software (OSS) initiative playground, the engineering team has simulated a corporate merger. The servers in one rack comprise the side of the company that functions solely on open source wares with Fedora Core 3 as the Linux base operating system, save a few Windows desktops. The second rack holds the operation of a primarily closed source (read Microsoft) shop. The remaining racks house gear that is used to provide identity and video streaming services to the first two networks.

The engineering feat to be demonstrated here is the melding of the two networks so users can transparently work together without losing application support they’ve become accustomed to in their respective environments.

OSS team lead Hege Trosvik says the biggest challenge presented to the group of 13 engineers - most of which have extensive experience with Linux and the open source way of life – was authenticating users across the open and closed platforms using a combination of directory-based technologies including LDAP , SAMBA and Microsoft’s Active Directory. 

Making a Linux client from the open source environment authenticate against an LDAP server located in the open source ISP network was a pretty straightforward process. The only caveat on the server side being that the OSS engineers had to make sure the LDAP server had the appropriate object classes for the posixAccount and shadowAccount attributed defined in the directory schema. The team found that a particular Java-based LDAP browser available from one non-descript open source site to be very useful in setting and reading LDAP attributes.

On the Linux client you need to modify three files within the Pluggable Authentication Modules (PAM) library to make authentication happen. PAM is a generalized API for authentication-related services that allows a system administrator to add new authentication methods to a Linux box. You need to add the IP address of the LDAP server into the /etc/ldap.conf file. Secondly, you need to let the /etc./nsswitch.conf file know that is search the LDAP directory for passwords and groups. Thirdly, the /etc/pam.d/system-auth file should be configured for LDAP authentication. The file change is automatically generated if you use the authconfig function to initially enable LDAP authentication on the client box.

To enable the Linux client to authenticate to Active Directory, the team had to install Microsoft’s Services for Unix on the client and create a user account in Active Directory. Additionally, the team had to add the POSIX attributes to the Active Directory schema and reset the user’s passwords to synchronize with the Active Directory and Linux passwords.

Setting up Windows clients to authenticate against SAMBA was not all that difficult. The two glitches are that newer Windows clients use encrypted password formats that cannot be converted into Unix-type encrypted passwords, and Windows stores more user information than is typically stored in a Unix user database. Therefore, SAMBA uses its own user database. You can use the smbpasswd-a command to add a user and create the Windows user’s home directory on the SAMBA server.