Fedora Directory Server: the Evolution of Linux Authentication

Check out Fedora Directory Server to authenticate your clients without licensing fees.
Authenticating Desktop Clients

With our infrastructure in place, we can connect our desktop clients. For our configuration, we use native Fedora 6 clients and Windows XP clients to simulate a mixed environment. Other Linux flavors can connect to FDS, but for space constraints, we won't delve into connecting them. It should be noted that most distributions like Fedora use PAM, the /etc/nsswitch.conf and /etc/ldap.conf files to set up LDAP authentication. Regardless of client type, the user account attempting to log in must contain Posix information in the directory in order to authenticate to the FDS server. To connect Fedora clients, use the built-in Authentication utility available in both GNOME and KDE (Figure 9). The nice thing about the utility is that it does all the work for you. You do not have to edit any of the other files previously mentioned manually. Open the utility and enable LDAP on the User Information tab and the Authentication tabs. Once you click OK to these settings, Fedora updates your nsswitch.conf and /etc/pam.d/system-auth files immediately. Upon reboot, your system now uses PAM instead of your local passwd and shadow files to authenticate users.

Figure 9. The Built-in Authentication Utility

During login, the local system pulls the LDAP account's Posix information from FDS and sets the system to match the preferences set on the account regarding home directory and shell options. With a little manual work, you also can use automount locally to authenticate and mount network volumes at login time automatically.

Connecting XP clients is almost as easy. Typically, NT/2000/XP users are forced to use the built-in MSGINA.dll to authenticate to Microsoft networks only. In the past, vendors such as Novell have used their own proprietary clients to work around this, but now the open-source pgina client has solved this problem. To connect 2000/XP clients, download the main pgina zipfile from the project page on SourceForge, and extract the files. For this article, I used version 1.8.4 as I ran into some dll issues with version 1.8.8. You also need to download and extract the Plugin bundle. Run the x86 installer from the extracted files, accepting all default options, but do not start the Configuration Tool at the end. Next, install the LDAPAuth plugin from the extracted Plugin bundle. When done installing, open the Configuration Tool under the Pgina Program Group under the Start menu. On the Plugin tab, browse to your ldapauth_plus.dll in the directory specified during the install. Check off the option to Show authentication method selection box. This gives you the option of logging locally if you run into problems. Without this, the only way to bypass the pgina client is through Safe Mode. Now, click on the Configure button, and enter the LDAP server name, port and context you want pgina to use to search for clients. I suggest using the Search Mode as your LDAP method as it will search the entire directory if it cannot find your user ID. Click OK twice to save your settings. Use the Plugin Tester tool before rebooting to load your client and test connectivity (Figure 10). On the next login, the user will receive the prompt shown in Figure 11.

Figure 10. Plugin Tester Tool

Figure 11. Login Prompt


FDS is a powerful platform, and this article has barely scratched the surface. There simply is not room to squeeze all of FDS's other features, such as encryption or AD synchronization, into a single article. If you are interested in these items or want to know how to extend FDS to other applications, check out the wiki and the how-tos on the project's documentation page for further information. Judging from our simple configuration here, FDS seems evolutionary, not revolutionary. It does not change the way in which LDAP operates at a fundamental level. What it does do is take the complex task of administering LDAP and makes it easier while extending normally commercial features, such as MMR, to open source. By adding pgina into the mix, you can tap further into FDS's flexibility and cost savings without needing to deploy an array of services to connect Windows and Linux clients. So, if you are looking for a simple, reliable and cost-saving alternative to other LDAP products, consider FDS.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

fds with ldap

manohar's picture

i m done with installing FDS successfully.
can please help how can i authenticate the windows users using FDS.

Password policy problem between FDS and ADS

selvakumar.a's picture

I have configured FDS and Syncronized with ADS.Every thing working fine.The password also syncronized between FDS server and ADS.When I change the password in windows client it is replicated to the FDS through ADS.But when I change the password in Linux client machine it does not replicated to the ADS. I need some clarification between FDS and ADS password policy.I hope some one will guide me.Thanks in advance.

el fedora es de maricones

Brunito's picture

es re penca la wea de fedora ds
es como una agenda ql
mas dificil de usar la mierda
ademas que el guru guru ql

LDAP isn't best suited for authentication

Anonymous's picture

Just to note, the directory usage that you describe (using LDAP for authentication) is a painfully wide-spread misconception.

Properly, you should use LDAP for publishing authorization data (e.g. group memberships), while authentication should be best implemented with use of Kerberos protocol.

By using LDAP for authentication, you throw away the possibility to provide single sign-on for your users.

You can use the Heimdal Kerberos server to store the data used by it in an LDAP directory - provided that it supports LDAPI connections and, as a result, it resides on the same machine that the LDAP server.

The version of Fedora Directory Server from CVS supports LDAPI.

BTW, IMHO the Kerberos and LDAP protocols should be merged in the future since they are so easily misused because of the distinction between them.

merge LDAP and Kerberos. LDAP

Anonymous's picture

merge LDAP and Kerberos. LDAP is a fully fledged directory access protocol not just an authentication widget. This is like saying SQL should be merged with Kerberos.

BTW, LDAPI support is now

Anonymous's picture

BTW, LDAPI support is now available with the latest stable version 1.1 of Fedora Directory Server.

Updating Alternatives (for Java and such)

Christopher Cashell's picture

Just a note, Red Hat provides a command, update-alternatives, for updating and maintaining links in /etc/alternatives.