Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

LDAP Authentication in Linux 189

Posted by ScuttleMonkey from the roadmaps dept.
hausmasta writes "HowtoForge has published a walkthrough to show you how to store your users in LDAP and authenticate some of the services against it. It will not show how to install particular packages, as it is distribution/system dependent, instead it will focus on pure configuration of all components needed to have LDAP authentication/storage of users. The howto assumes that you are migrating from a regular passwd/shadow authentication, but it is also suitable for people who do it from scratch."
This discussion has been archived. No new comments can be posted.

LDAP Authentication in Linux More

LDAP Authentication in Linux

Comments Filter:

  • Ldap on its own is not enough (Score:3, Interesting)

    by Anonymous Coward on Sunday September 03, 2006 @04:02PM (#16033842)
    Really, you need to add kerberos to the mix, especially the heimdall kerberos implementation is attractive, since it allows you to store its settings inside the ldap tree, providing a true centralised secure single signon enviroment.

    Using ldap itself is really not much better than using NIS, aside from the fact that it can contain much more than just the user database.

  • I always wondered... (Score:5, Interesting)

    by Lispy ( 136512 ) on Sunday September 03, 2006 @04:09PM (#16033878) Homepage
    Ever since I rolled out an LDAPed Samba domain for a customer I was wondering why this is not beeing used for more stuff?
    Its relatively eay to setup and quite stable. This in combination with PAM should be the once and for all way of authentication.
    If you have a directory like this you can add virtually everything to it, be it intranet pages, mailserver authentication, hell even an inhouse Jabber client for employees. This should be unified and used much more often.

    The management is a blast with the ability to choose whatever LDAP-Frontend you might wanna use and worstcase you can go back to browserbased or console. Its really flexible, elegant and in a Unix style a tool for the job.

    Who can enlighten me why this is still rather a niche? are Unixadmins simply too used to the passwd/shadow style auth?
    Oh yeah: In case you are going to set it up stay the hell away from BerkeleyDB 4.3.
    It can have some nasty surprises. :) Been there...

    • Re: (Score:2, Interesting)

      by antlope ( 926281 )
      Because the sites that could most benifit already run NIS or similar for Unix, and have working AD systems for windows. With a larger site (100+ servers) the admin groups are usually hard presses for time anyway and have to justify this kind of switch to a manager who most of the time doesn't fully see the advantage of spending all those man hours switching systems.

      Sad, but often true.

      /Anthony Whitehead
      NordicEdge AB

      • Re: (Score:2)

        by Lispy ( 136512 )
        Ah! Not that you mention it.
        I also had a though meeting after the migration where the CEOs asekd me what the benfit was.
        I replied: "Cheaper maintenance". Luckily I started this domain for them so I could also add "enhanced security, privacy" to the mix.
        Otherwise I would have gotten into trouble too.
        You are probably right. I was just wondering if there are architectural/technical issues I wasnt aware of.

    • Re:I always wondered... (Score:5, Informative)

      by guruevi ( 827432 ) on Sunday September 03, 2006 @04:39PM (#16033978)
      It is otherwise widely used hidden under proprietary MS code: Active Directory is a pure Kerberos + LDAPv3 implementation except that for synching and logging in (the essential outside communications that other platforms would like to use) is proprietary and they changed some things to the standard scheme too (SID etc.) which makes it useless for anybody but MS.

      OpenDirectory by Apple is also an LDAPv3 implementation be it more pure than MS's implementation. You can combine both AD and OD on Mac to get a unified Windows-compatible login capabilities in the network that also get the benefits of using OD (force preferences and security settings on users/computers) without schema changes on either side.

      RedHat also relies on LDAP for network-wide authentication in their products as does IBM and recently even Novell and lots of companies use it for different purposes in one or another way.

    • Re: (Score:3, Interesting)

      by 93 Escort Wagon ( 326346 )
      Ah, I was about to ask this same question...

      One of our former (and rather forward-looking) sysadmins moved our servers over to a centralized Kerberos+LDAP (via PAM) authentication and authorization system. He left for greener pastures; and since then I've seen a series of (mostly pretty young) sysadmins that just have this innate dislike for any sort of centralized management. It usually starts with complaints about OpenLDAP; but pretty soon you realize it's not the app, since they view any replacements wit

      • Re: (Score:2)

        by spauldo ( 118058 )
        Account management is boring and detracts from "real" work.

        Back when I worked in a network shop in the air force, all the people that really didn't know anything and weren't willing to put in the effort to learn were given the task of user account management, since it's easy (at least it was easy on NT4 with Enterprise Administrator). Some of them would get fed up doing the same old boring thing and find out what the more knowledgable people were doing, some wouldn't.

        I liked the way it was set up 'cause I

    • Re:I always wondered... (Score:5, Insightful)

      by Wylfing ( 144940 ) <brian@@@wylfing...net> on Sunday September 03, 2006 @05:25PM (#16034140) Homepage Journal

      Who can enlighten me why this is still rather a niche?

      Maybe you have a brain the size of this guy [wikipedia.org]. I don't know. I have tried a few times in the past to set up LDAP and all the documentation is written by space-aliens as far as I can tell. I can't even penetrate the language used, let alone follow the steps prescribed.

      This Fine Article is no different. After about the 3rd sentence I have no idea what is being described, because we're already talking about "a replication" but this has not been defined. It's all like that: undefined terms and references, and exhortations to read the ldap man pages if you want to understand what is going on. The man pages are also full of undefined terms and references, except they are presented in highly-compact text blocks with bad grammar.

      LDAP is niche because it is so freaking impossible to figure out. That's why.

      • I have tried a few times in the past to set up LDAP and all the documentation is written by space-aliens as far as I can tell. I can't even penetrate the language used, let alone follow the steps prescribed.

        Glad to see I'm not alone. I successfully set up Kerberos 5 for single signon on my little home network, complete with master/slave redundant KDCs. I then successfully set up NIS. The next step is to migrate to LDAP, right? Well, this totally mystified me.

        • Re: (Score:2)

          by jimicus ( 737525 )
          The main reason for that is that nothing really tries to explain what LDAP is.

          Which is a shame really, because once you know it's quite easy to understand.

          It's a tree-based database which may store objects as well as just text.

          Because it's tree based, you don't generally search it like you do with an SQL database (SELECT record FROM table WHERE condition). Instead, you already know at least roughly where what you're interested will be, so you say "starting from this point in the tree, find me this type of

      • Re: (Score:2)

        by afd8856 ( 700296 )
        Haven't read the article, but I had my share of LDAP learning [pixelblaster.ro] Basically, ldap is a sort of object-oriented database, with customizable schemas for the objects. That's all there is to it, and is especially easy to comprehend for anyone familiar with zope / Archetypes.

  • Other options (Score:3, Informative)

    by digitalhermit ( 113459 ) on Sunday September 03, 2006 @04:09PM (#16033879) Homepage
    OpenLDAP is great and does a good job. You may also want to look at Fedora Directory Server, which is based on a previously commercial product. Both are ridiculously easy to configure for basic authentication. Another option for OpenLDAP is to grab the VMWare OpenLDAP appliance. It's an easy way to get LDAP working.

    For administration, check out JXplorer. It makes it easy to add/delete/modify users.

    • Re: (Score:2, Informative)

      by hethopus ( 806708 )
      Best one I've used is Luma -- http://luma.sourceforge.net/ [sourceforge.net]
    • For large installations (read: hundreds of thousands of users) one might also want to take a look at the Sun Java System DS [sun.com] (former iPlanet), which is a very trustworthy and feature rich solution from what I've been told.

    • ... Fedora Directory Server, which is based on a previously commercial product.

      Do you mean previously proprietary? I have a hard time believing that very many LDAP installations are non-commercial.

      • Do you mean previously proprietary? I have a hard time believing that very many LDAP installations are non-commercial.

        No, he/she means commercial. He's referring to the product, Fedora Directory Server, not an installation of said product. That Netscape Directory Server was a proprietary product before becoming FDS is irrelevant to the OPs point. Nor does commercial/non-commercial LDAP installations.

    • Re: (Score:2)

      by jimicus ( 737525 )
      OpenLDAP is great except that its support for a number of (admittedly optional) plugins is lousy, like most LDAP implementations the ASN.1 used for the schema definitions is subtly different to everyone elses, it doesn't support multi-master replication, it has this awkward tendency to leave the most appallingly unintelligible logs, its single-master replication support isn't exactly stellar and its mailing lists can be downright hostile to the uninitiated.

      (Disclaimer: I use OpenLDAP myself. But it is so f

  • LDAP for everything (Score:5, Interesting)

    by linuxkrn ( 635044 ) <gwatson@lRASPinuxlogin.com minus berry> on Sunday September 03, 2006 @04:17PM (#16033909)
    I use LDAP at work for everything and life is so much better now.

    Windows Desktops (Samba PDC and BDC -> LDAP)
    Linux pam_ldap + nss -> LDAP and NFS shares

    You can log into either a windows desktop or linux box and have the same file shares open. Windows has H: and Linux is /home/username. Public drives are mapped as well.

    Then for email, postfix + dovecot -> ldap. You can store not only use the same username password as for linux, but you can add unlimited number of real-time mail aliases to each user. Also supports virtual domains.

    Directory services for phone numbers, room locations, etc. in ldap. Mapped to email clients search/contact lists.

    squid + ldap and apache + ldap, secure login to website.

    Squirrelmail/horde both use ldap as well. Auth is done via imap, but horde can do much more with ldap. Both can use it for directory services.

    Admin can be done either via CLI smbldap-tools, php ldap admin, gq (ldap tree browser), or ldapmodify if you're hard core. Plus with sync'ing data to other sites they have a copy of the data for their BDC/etc. If I need to add/modify a user there is only one place that needs to be modified. And I can do it from home. =)
    • This is the thing I'd love to see - more apps integrating with a LDAP user db. I hink it would enhance a lot of applications (and I'm thinking all those PHP web-based things) if they all used a single-signon sourced from a LDAP directory instead of rolling their own user login system every time.

      If only more apps used it...

  • Our wiki Linux LDAP Howto (Score:3, Informative)

    by Anonymous Coward on Sunday September 03, 2006 @04:26PM (#16033931)
    I figured this was as good time as any to point out our relatively complete Linux LDAP HOWTO [freaks-unidos.net], which covers quite a few LDAP servers (MS AD, Novell eDir, OpenLDAP) and the security implications of different setups (eg. using PAM_LDAP vs just using NSS_LDAP). The article lives in a wiki so any improvements are welcome. :-)

    I hope you find it useful.

  • LDAP/Postgres? (Score:3, Insightful)

    by Doc Ruby ( 173196 ) on Sunday September 03, 2006 @04:34PM (#16033960) Homepage Journal
    LDAP authentication is cool, but LDAP is just an interface. Unfortunately, it usually comes bundled monolithically with a dedicated datastore, the BerkeleyDB. Which is neat and fast, working well for "standalone LDAP". But it ghettoizes ID info away from other apps which don't already have an LDAP interface. Some of which need relational access for their app logic, or just higher performance than massive volumes of LDAP queries will permit. The OpenLDAP server is stuck this way. Its basic features are really good, but that's as far as it goes.

    So where's the HOWTO for porting OpenLDAP to Postgres for its datastore? There's some HOWTOs for porting it to MySQL, but MySQL doesn't scale as well as Postgres, and existing Postgres installs are out of luck. The few existing LDAP/Postgres HOWTOs [google.com] seem inconclusive, untested. And some of the commercial products that advertise the feature don't even respond to emails to sales departments asking about the cutover.

    As long as Slashdot is staring down "LDAP Auth in Linux", how about taking it to (and over) the Postgres wall?
    • Comment removed based on user account deletion
      • I said LDAP was cool, and said how useful I think it is. Then I detailed how much more useful it would be with an integrated datastore open to the rest of the apps.

        If you don't understand how a unified data layer for a network-available query interface is useful, refrain from commenting on it.
    • So where's the HOWTO for porting OpenLDAP to Postgres for its datastore? There's some HOWTOs for porting it to MySQL, but MySQL doesn't scale as well as Postgres, and existing Postgres installs are out of luck.

      Why would you want to port a hierarchical database to a relational DBMS?

      • Because I want the hierarchical ID data easily accessible to joins against other, more relational data. And I don't want the dependency on multiple DBs that might require more skills or even extra DBAs. While getting all the management features (replication, clustering, transactions) of an RDBMS.
  • https://dpw.threerings.net/projects/splat/ [threerings.net] (written by the wonderful people I work with and BSD-licensed) hooks into LDAP, allowing for the storage of public keys for SSH access and other niftiness. We use it for managing passwordless SSH-key based access to the two dozen or so servers here with great success.

  • The article uses OpenLDAP as the LDAP server. Has anyone got this to work using the Apache Directory Server [apache.org]?

  • Host-based control (Score:2, Informative)

    by sparr0w ( 902739 )
    The author failed to point out one of (IMHO) the neatest parts of doing PAM/NSS/LDAP authentication against your server: controlling by host. The LDAP authentication set includes the ability to dictate (using the "host" attribute) which users are allowed on which servers. From an enterprise POV, that helps limit the systems users have access to (controlling which servers your UNIX gurus have access to). You can also tie LDAP into Samba, and using some scripts emulate an active directory. We've been playing
  • I tried to migrate an existing file and NIS based system to LDAP - I had no problem with setting up PAM and openldap, however I did not find a replacement for the Debian adduser program, so I would have to hack my own user management tools. Does anyone know an alternative to this?

  • Nested groups (Score:3, Interesting)

    by Yag ( 537766 ) on Sunday September 03, 2006 @04:59PM (#16034053)
    The big problem with ldap is that most of autentication plugins (apache, pam and the others) matches only first level group members, not nested groups, normally used, expecially, in big micro$oft directories. This creates a lot of "difficul to mantain" groups containing very big lists of accounts. I know that filters or organizational units can be used to group them, but most of the times this is not enaugh. For this reason i usually prefer radius which integrates well *nix and m$ worlds (even if i still use ldap for apache cause radius mod for apache is not so customizable).

  • LDAP is NOT an authentication service (Score:4, Insightful)

    by KidSock ( 150684 ) on Sunday September 03, 2006 @05:25PM (#16034141)
    This tutorial should have some major security warnings plastered all over and I see nothing to that effect so here's a suppliment.

    First, LDAP is NOT an authentication service. I cringe a little whenever someone mentions using "LDAP authentication" for anything other than LDAP clients. Some of these tools use LDAP as a make-shift "pass-through" style authentication service. This is like passing credentials to an SSH server to authenticate web clients (only SSH would be more secure since it enforces confidentiality and integrity).

    Second, if you are going to use LDAP like this, make sure the bind is being conducted over SSL. Using SASL would be even better but that's a little harder for a long lived service account and somewhat pointless if you already have Kerberos setup. With a plain bind you're sending passwords in clear text. Do not ever do that or someone will eventually come to your cube asking funny questions.

    Finally, using LDAP as an authentication service does not provide Single Sign-On (SSO). You basically have to store some kind of token in the user's HTTP session which means someone could get your session ID and impersonate you (e.g. inadvertantly send a link with a session ID in it).

    In general I don't recommend using LDAP as a make-shift authentication service as it is very easy for it to be insecure. Use Kerberos through and through people. It's the correct way to do things, it scales well and it's portable across both UNIX and Microsoft.
    • They are using a SASL bind so Kerberos is being used. While it isn't an authentication service, it does let you make machines and user enviroments orthogonal. Every user has the same enviroment on whatever machine they pick that day.
    • Comment removed based on user account deletion

    • Funnily enough I was having a similar conversation with someone at work last week. It seems that our Intranet authenticates via an LDAP bind, and when I found this out I thought "huh?!" and went to talk to the guy responsible. Of course, I didn't really have any better answer for him because although it's very easy to say "Just use Kerberos!", I only really know the basic principles of it and not really the practice.

      So, my question to you is... do you have any good pointers to a nice, simple "getting start

  • I pride myself ... (Score:4, Interesting)

    by Zombie Ryushu ( 803103 ) on Sunday September 03, 2006 @05:32PM (#16034161)
    I believe I have one of the most advanced LDAP/Kerberos/Samba/Bind "Open Directory" setups. I have two Samba 3 Domain Controllers, both Kerberos and Bind Enabled. with OpenLDAP and MIT Kerberos. I have no need for NFS.

    My OpenLDAP stores:

    POSIX User Attributes
    Samba User Attributes
    Radius User Attributes
    eGroupware User Attributes (Egroupware accounts.)
    DNS Information for our internal DNS Server
    DHCP Lease information.

    I use Kerberos with ssh-agent to distribute software RPMS for Mandriva Linux to mass distibute RPMs with a single command.

    I have Samba Kerberos enabled so that Samba will not repeatedly ask for usernames and passwords, and requires zero configuration.

    I have had the code to Egroupware modified so that eGroupware, and Nagios can use Apache's mod_auth_kerb addon to authenticate eGroupware users with a single click instead of a whole second login process.

    I'm currently workong on creating a Samba Authenticated gateway with NTLM-SPNEGO support so that kerberos will handle Squid too.

    All I need now is for someone to make the modifications nesessary to eGroupware's XMLRPC so that Kontact could use Kerberos and I would have the "Exchange Killer" I always wanted.

    All of my users use Samba for network browsing under KDE's Konqueror, with Kerberos and LDAP, it just works.

    I consider this my shining accomplishment.
    I like to have myself believe that I accomplished "Active Direrctory" under Linux now. I don't use Windows at all in this network, so keep that in mind. The eGroupware people can attest to what a past I am. bugging them to include Kerberos detection in session management. But it all works.
  • In all but the largest unix/linux installations, managing the users in LDAP is an exercise in futility. When you're all done you have something that's still more difficult to manage than adduser/deluser on the individual machines. Worse, its now brittle: the LDAP server breaks and now every unix box in the system fails at every task that requires a UID to user mapping.

    Far more useful is managing the users locally but authenticating them (i.e. checking their password) via LDAP. For example, in an enterprise
    • It seems that every other post is quite to the contrary...
      • Meh. If Linux LDAP becomes widely accepted in the enterprise I'm sure I'll find the grace to be embarrassed. 'Till then there's a saying that fits:

        If fifty million people say a foolish thing, it is still a foolish thing.

  • Reliability (Score:3, Interesting)

    by Gaima ( 174551 ) on Sunday September 03, 2006 @06:10PM (#16034279)
    Yep centralised user management, great, no doubt.
    But, what happens when the LDAP service isn't available?
    I say service to not distinguish between a physical server, a cluster of servers, a crashed openLDAP process, broken network link, yadda, yadda, yadda.

    With AD if a PDC isn't there, you can still login if you've logged on before.
    The article really should have mentioned nss_updatedb and pam_ccreds from PADL [padl.com] (I don't know if there are any other alternatives, nor do I know if that actually work, sounds like they do though).

    • Re: (Score:3, Interesting)

      by myowntrueself ( 607117 )
      But, what happens when the LDAP service isn't available?

      Indeed...

      Where I work one of my 'genius' predecessors set up a Linux fileserver with LDAP 'authentication' (nice euphemism that). LDAP is only used for samba fileshares... and for login.

      The LDAP server runs on the fileserver itself, so at least it doesn't have to connect to a remote LDAP server.

      He did a lovely piece of work, hacking it into place on a debian woody system, butchering the PAM config to make it appear to work.

      He is long gone but his legac

      • Just make sure there's an enabled root account in your /etc/(passwd|shadow), make sure pam_unix is enabled in your /etc/pam.d/(system.auth|login), and your /etc/nsswitch.conf has a line that says "passwd: files ldap" and you're all set.

        • Just make sure there's an enabled root account in your /etc/(passwd|shadow),

          Yep, there is.

          make sure pam_unix is enabled in your /etc/pam.d/(system.auth|login),

          Yep, it is. Well, theres lines that say:

          auth required pam_unix.so nullok
          account required pam_unix.so
          session required pam_unix.so
          password required pam_unix.so nullok obscure min=4 max=8 md5

          and your /etc/nsswitch.conf has a line that says "passwd: files ldap"

          It did say this:
          passwd: compat ldap

          which I've changed to:
          passwd:

          • Re: (Score:3, Informative)

            by 19thNervousBreakdown ( 768619 ) *

            I'd change it back, or if you're not using NIS, give just "passwd: files ldap" a shot, both files and compat are redundant at best. Whichever PAM file you have there is odd, auth should fail if a "required" module doesn't succeed. Here's mine:

            auth required pam_env.so
            auth sufficient pam_unix.so likeauth nullok
            auth sufficient pam_ldap.so use_first_pass
            auth required pam_deny.so

            account sufficient pam_unix.so
            account sufficient pam_ldap.so
            account required pam_deny.so

            password required pam_cracklib.so difok

  • LDAP is a pain in the arse (Score:3, Interesting)

    by SnapperHead ( 178050 ) on Sunday September 03, 2006 @06:29PM (#16034336) Homepage Journal
    Few years ago, this was a common setup I would put in place. When I had a number of users accessing all different types of devices or services, I would setup an LDAP server and have everything auth against it. It worked well, but has 2 major flaws.

    Total pain in the ass to setup
    Total pain in the ass to maintain

    Now, I am using radius for the same thing. It works a lot better, because lets face it. PostgreSQL or MySQL is a hell of a lot easier to work with then LDAP.

    LDAP does have its place. If you are looking to tie more then just auth into a profile, then LDAP is the choice. If you just want auth, use something Radius.

    Of course, if you are a total LDAP guru, you are gonna recommend LDAP. But for average admins, or quick setups. LDAP isn't the way to go.
     

    • Re: (Score:2, Informative)

      by unsigned integer ( 721338 )
      Yeah, no kidding. Total pain in the ass.

      I tried to take a NIS domain, mixed linux/solaris clients and convert into a single LDAP auth'ing environment, plus LDAP auth for our webservers ... thus giving me finally a SSO environment where I didn't have to maintain numerous passwd files, etc. I went from knowing nothing about LDAP, to at least being able to set it all up. Even with the PADL tools things took a while. Setting up all the SSL certs ... self-signing etc. Incorrect examples and docs from people onli

  • This rocks (Score:4, Interesting)

    by PenguinX ( 18932 ) on Sunday September 03, 2006 @07:37PM (#16034545) Homepage
    We switched to ldap authentication on our UNIX systems about a year ago, and basically it rocks. Providing single-sign-on between all of your device of varying operating systems and utility (i.e. servers, routers, switches, terminal/console servers, a lot of applications, and even kvm's) is great when you have a multi-teared support organization, and even if you don't you can still save yourself a lot of useradd / usermod /userdel commands if you centralize.

    Why does it rock so much? LDAP seems unique that, unlike almost every other authentication method under the sun (NIS, NIS+ radius) it can be used on a number of devices. Additionally LDAP tends to be a great back-end for other authentication protocols (i.e. radius) can use an LDAP backend.

    Practically speaking, often times all someone needs to do is have read access to a device to find out if an interface is up but many system admins give up if they don't have the ability to centralize and allow the company to become altogether too dependent on them. LDAP basically gets rid of this hassle and the administration is minimal. This means that the system admin gets paged less and more people can get work done with better efficiency.

  • Just use Novell Directory Services, or EDirectory as it is now named.

    Nope it aint free, nope it aint open source. But it DOES rock the house!

    Scales to over a billion objects. Easy administration and setup.

    Runs on practicaly everything Form Linux, Unix, Solaris, Windows, Copiers, Printers to Toasters and Web Servers.

    Why yes I am a Novell Fan Boy. Whats your fucking point!

  • See the subject.
  • The enabling software pam_ldap [padl.com] and nss_ldap [padl.com] have been around for years. I worked on a project in Novell implementing similar functionality using NDS six years back.
  • Does anyone here have any experience with NIS gateways to LDAP servers, so existing infrastructure can continue to work?

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close